Dialing troubles

[twiSSt]

Hi all,

I have a situation that is causing my blood pressure to go through the roof. So let me give a brief description of what it is:

B to B call center - I'm currently using 2 Ld T-1's from 2 different providers. Tadiran coral 3 pbx. we are currently doing a large project, approx 190k phone calls in 4 weeks.

I'm not using a predictive dialer the dialing is done via the modem on the client computer.

We have been recieving an error message when dialing - "The number you are trying to dial cannot be called from this special phone." If you try and redial it will connect (sometimes it takes several attempts)

Both providers state they have never heard that message and have no explanation. I'm fairly certain that my pbx will not spit out voice error messages so i have ruled that out.

Has anyone heard this message before? I have heard there is a new call block service being used by companies to limit the number of telemarketing calls, but the fact that we can redial and get through causes me to be suspect of that explanation. Any thoughts would be appreciated.



Twist

===========================================
Everything will be OK in the end.
If it's not OK, then it's not the end

 

[ISDNman]

My guess is that you are truncating a digit somewhere.

On possibility is that this is happening at the computer information, you might want to try a pause (often the character "," is used for this).

Are the trunks T1 or PRI?

If they are T1, you may be truncating a digit at thhe T1 if you are using immediate start signaling. Wink start is better because the PBX knows when the CO is ready to accept digits.

Another possibility (if T1) is that some common equipment problem (e.g. a bad DTMF sender that is marginal).

You could have a trunk(s) with excessive loss and that is causing unreliable DTMF reception at the CO.

You may want to try and see if the problem occurs only on certain channels. Also, you do not mention if it is confined to one of your T1s or possibly to one of the LECs.

Share some additional info there are some smart people in this group who should be able to help.

Good luck

 

[twiSSt]

Thanks for the info ISDNman,

to answer your questions
1. I already added extra commas in the string. I actually have it pausing after it dials 8 (to get an outside LD line) and after it dials the area code.
2. Trunks are T1.
3. The problem appears to happen on both T1's so it doesn't seem to be carrier specific.
4. One of my sales persons just notified me that this was happening on our local T1 as well which is a different carrier.



Twist

===========================================
Everything will be OK in the end.
If it's not OK, then it's not the end

 

[johnpoole]

haven't played with the coral in a while, we had one behind my meridian doing wireless, but recently cut to cisco. if your trunk type is did, try the same interface with tie. had a simular problem, central office was did (two way) but 1 out of 10 calls would fail from any auto dialer, fax speed call etc. some dms tech said he had seen that and asked if i would try changing to tie, problem went away. might be worth a try

john poole
bellsouth business
columbia,sc

 

[twiSSt]

Thanks John,

I'm not using DID's on my system. I had all of my providers monitor the lines and all of them show it clear all the way back to the smart jacks and CSU/DSU.

My Tadiran consultant monitored my switch yesterday afternoon and they did not see any errors either.

I'm really stumped with this one. I can update the text of the message we are recieving
"We're sorry you dialed a number which cannot reached from this special phone 8131"

Everyone I've spoken to has never heard that particular message. It appears to be a network message coming from some carrier.


Twist

===========================================
Everything will be OK in the end.
If it's not OK, then it's not the end

 

[ISDNman]

Twisst,

What is the signaling protocol on the T1 (1- what does the Telco sya it is and 2- what is the Tadiran set for)?

I am sorry, but I don't know the Tadiran. Ask your Tadiran rep how you can change any of the timers related to the above protocol. My guess is that in some cases you are truncating the first digit.

You miht test my guess by deliberately truncating and see if you get the same messag

if the number is 8, 12225551234 try

8, 2225551234

If your trunks do not need a 1 then try

8, 225551234

Very weird that both carriers apparently give the same error message.

BTW, you should not need a pause after the area code. I'd suggest taking that out. You could try a double pause after the 8 (,,)

If you can beg borrow or steal a NNC Network probe 7000 series you can actually log state changes on the signaling bits. It will be a royal PITA to figure out which channel it happended on and then find it on the log, but you may be able to see something different on the problem calls.

Good luck.

 

[twiSSt]

ISDNman,

Sounds like something to take a look at.

I will tell you this much, we collect the phone data via a SMDR, just a simple little terminal application running on a old Win95 box i had laying around. I can watch realtime as someone dials the phone identify them by the extension number and see the call complete. In therory if it was truncating a digit i would see it there. At least I think so.

I had an instance where one of my telephone staff recieved the error and i had them try it again with the same rsult and the number shows up as it should.

Now I am assuming that the switch is spitting out the exact number it attempted to connect to.

Twist

===========================================
Everything will be OK in the end.
If it's not OK, then it's not the end

 

[ISDNman]

Twist,

but that is a big asumption. My thought it is truncated at the CO end, probably due to some sort of timing issue. If you can sucessfully get the same symptoms by deliberately truncating that would confirm my theory.

Just fo rlaughts you might try placing a # at the end of the dialed numbers. This shold change some timing (within the PBX) because it will cause the tadiran's digit collection timer to expire (should save some time) but it still should not make any difference in terms of your probelm. It wouldn't hurt to try.

Is it DTMF of DP adressing on the T1?

Assuming DTMF (most likley) then I'd suspect some sort of DTMF level or frequency problem with the Tad. If you can borrow a T1 tester that can drop audio to a port you might put a digit analyzer and see if the DTMF is within spec (at leaast as far as frequency, it would be much harder to determine level unless you have a digital transmission impairment test set.

Here is another possibility. Do you have any trunk(s) that are noisy? Maybe they are noisy enough to impair the accuracy of DTMF detection at the far end.

If the Tad has some sort of DTMF generator board that is shared across trunks I'd see i your rep can loan you one and swap it out.

Best of luck.

 

[exverizon]

Admitting up front that any T-1 business is over my pay grade and I might therefore make a fool of myself, can you have half the channels made busy and see if it continues? By a process of elimination, you might smoke out which channel(s), if any, are responsible. That's the way we used to narrow down DiD trunk problems when nothing else worked. I'm figuring since you can usually redial a couple times and get through, you're eventually accessing a good channel. Unless both circuits are marginal completely , which I doubt.

 

[ISDNman]

Exverizon,

Good idea.

You know I was thinking the same thing, it smells like a trunk problem. But since it happens on two different T1s (form different providers) it is a weird one.

The other possibility is some sort of shared equipment, like a bad DTMF generator.

Good LUck Twiss

 

[SYQUEST]

How repeatable is this problem. From your SMDR log do you see any pattern from calls to certain NPAs or NXXs?

Can you directly select a trunk and place a call to one of numbers on a repeated basis and does it fail?

Do all the outgoing calls on the respective T1s use the same LD carrier?

Having a Channel Access Testset would be a great help in troubleshooting your problem, because you can directly monitor the selected T1 channel for everything: signalling, DTMF/MF/DP, and audio. Even though it is time consumming, you may have to sit there monitoring for hours watching the call progress of calls inorder to solve the problem.

With call completion recordings the number or code at the end is an identifier for the carrier or where the call stopped. What you might try is to hold up the call with the recording on the trunk and have it traced by the provider to see where the recording is comming from. You would want to make arrangements ahead of time with your diiferent service providers to do this.

I had a similar problem several years ago with some MCI traffic on a trunk group. They were able to track the problem down and fix it. In this case it was a translations error with one of the tandem switches for some new NXXs that had opened. MCI was very cooperative in those cases. Although it helps when you know the switch manager.

....JIM....

 

[jgideon]

Another possibility that comes to mind is that the intercept is from the same _destination_ telcom (that's why it's the same from multiple carriers.) Are the trunks for this business set up as a special classification of any kind? The CO sends a set of ANI-II digits with each call. Normal calls are usually sent with 00 (no special treatment), but if your trunks were mis-classified and sending something else (such as 06 for hotel/motel, 07 for special operator handling or some of the handicapped special handling codes), the receiving LEC could be sending your call to intercept. It is strange that the same number and be successfully dialled on subsequent attempts tho.

You've got plain T1's. Just re-read that they're direct to LD carriers, so that actually knocks my infodig theory to some degree. One of my carriers will actually LCR a call to any of about 7 other wholesale carriers. Have you opened a ticket with your LD provider on one of these instances to confirm if they're getting all the digits, or if the 'failed' calls are all going to the same outbound route from the switch that serves your T1's?

 

[twiSSt]

Wow, there is so much information it's going to take me awhile to process all of it. Thanks to all.

I had a tech out this afternoon from my Tad vendor. He was able to duplicate the error message by direct selecting a trunk and truncating a digit. On one providers T-1 only.

To go back to an earleier post I am using wink not immediate.

Did some test calling with the provider that i could replicate the problem on and when i truncated the digit he does not even see the call activity. If i add the 1 back into the string it all works.

The Tad tech was sure that it is not the switch - but i'm not 100% satisfied with his determination. I'm still thinking that the truncated number is the issue but not sure where it is truncating.

Twist

===========================================
Everything will be OK in the end.
If it's not OK, then it's not the end

 

[johnpoole]

compare the routing tables, if your failing from a single route, try truncating and using a # as a terminator, with the end of dial the test may be more viable

john poole
bellsouth business
columbia,sc