LD Calls dropping when # called is busy

[FordMan77]

Working w/ a customer here that is having an issue w/ calls dropping that I haven't seen before, so I thought I'd see if anyone here would have any good suggestions.

Basically, when they make a LD call to someone, and that someone is busy, they do not hear the busy signal on the calling end, the call just terminates.


This is the email I got from the vendor:

"No it is not a number specific issue. The problem occurs anytime they make a long distance call to a number that is busy. We have tested with NPA-NXX’s going to different parts of the country and still get the same result. McLeod sees the call sends it through Sprint for the LD portion the end destination gives a busy signal, goes back over Sprint to McLeod and McLeod sends a busy signal via the “D” channel and call drops.

That was why my original question was if this could be a timing issue. That maybe since it is taking so long for the busy signal to finally get to the phone system that it hangs up before it receives the busy signal and maybe the system could be programmed to wait a little longer for a signal then they would actually get to hear the busy signal coming across.

The next thing to do, in my opinion, is to take a T-Bird out there and plug the circuit into it and duplicate the problem. If the busy signal is heard on the T-Bird then the only thing I can think of at that point is that the phone system is dropping the call."


Can the Legend even be adjusted for timing on a busy? To my knowledge it cannot, but I haven't had a lot of experience w/ T1's either, so I could be wrong.

Thanks,
Jay

 

[SYQUEST]

Since you mentioned DCH, we can assume the Legend has a PRIMARY ISDN ckt that is connected from McLoed?

All call setup and tear down happens via the DCH on PRI. The Co switches use SS7 to signal the same between other CO switches and themselves. What is possibly happening is either the "message" being sent from the CO switch is wrong for the call transaction type or the Legend is translating the "message" wrong and causing a forward disconnect. Also, in some cases with PRI, tones: busy, reorder, or ringing are generated in the Legend/Magix.

Unless your T-Berd has a function to interpret the "messages" on the DCH of a PRI it won't tell you anything. You could do an audio monitor of the BCHs but that should be no different from what you would hear on the handset connected to that selected channel.

This does not sound like a timing issue. There are no timers in the Legend/Magix that effect this.

One other thing, what happens on local calls that are busy?

The same condition or you hear the busy. If you hear the busy, then I think I would look in the direction of Sprint. I would also request the client try the same thing using a different LD carrier, MCI or Qwest for example. Then see if the same condition occurs. This type of troubleshooting will help to sectionalize the problem.

Did you check the Error Log in the Legend?

If things point back to the Legend, I would run tests on the 100D module and see what that reveals and go from there.

Hope this helps!

....JIM....

 

[dagwoodsystems]

I am totally with Jim on this. You might try dialing a 10-10-xxx code to bypass Sprint's long haul piece.

____________________________
Any sufficiently advanced technology is indistinguishable from magic. --Arthur C. Clarke

 

[TouchToneTommy]

McLeod sends a busy signal via the “D” channel and call drops.

I have a customer with the exact same issue - the busy signal is sen to the Magix, expecting the Magix to generate the tone locally. However, the Magix is not capable of generating the busy tone to the phone, so the call is simply dropped.

 

[SYQUEST]

Hi TTT,

Can you elaborate on the "busy" issue with the Magix? I know the Legend can generate a slow (60 IPM) busy and a fast (120 IPM) busy. Is the Magix firmware that different? Please explain...

....JIM....

 

[HarrisD1200]

Sysquest is most likely correct on this. Most "older" TDM CO's have an option on PRI trunk groups to either send Audible tones back, or send the corresponding PRI Cause Code. We always set our CO's to send audible for the simple reason we have no idea whether the CPE can correctly interpret the PRI Cause Code or not. Now, we are working with a new softswitch, that like most soft switches, was designed by data people. They insist on not allowing audible error messages since "PRI can take care of it with a data message, why waste CO resources on giving the customer an error tone?". This leads to issues like what are being described in this thread. And so far, they claim they haven't had enough interest in adding Audible tones to make it worth their while.

 

[FordMan77]

SYQUEST, below is the error log that I pulled before I had them set the L1 flag to "yes" on the CO side. After this change was made, it seemed like everything was fine, and now it seems they're back at it again... As far as I have been told the local calls are working fine.

A ERROR LOG


A Last 99 System Errors:

A Message ss/pp Cnt First Last Code
A E911 OVERFLOW 00/00 - - 02/20 10:39:32 0802
A PRI SVC STATE INCONSIST 09/14 - - 02/28 11:01:35 7002
A PRI SVC STATE INCONSIST 09/10 - - 02/28 14:03:20 7002
A PRI SVC STATE INCONSIST 09/12 - - 03/08 13:34:29 7002
A PRI SVC STATE INCONSIST 09/21 - - 03/09 12:01:39 7002
A PRI SVC STATE INCONSIST 09/21 - - 03/13 15:09:39 7002
A PRI SVC STATE INCONSIST 09/09 - - 03/14 12:35:01 7002
A PRI SVC STATE INCONSIST 09/12 - - 03/15 08:18:33 7002
A PRI SVC STATE INCONSIST 09/15 - - 03/16 15:45:29 7002
A PRI SVC STATE INCONSIST 09/20 - - 03/20 15:51:43 7002
A PRI SVC STATE INCONSIST 09/21 - - 03/21 09:58:52 7002
A PRI SVC STATE INCONSIST 09/10 - - 03/26 10:47:05 7002
A PRI SVC STATE INCONSIST 09/21 - - 03/26 14:03:21 7002
A DS1 LOSS OF SIGNAL ALARM 09/00 - - 04/08 12:55:47 6C01
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:56:23 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:56:28 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:56:33 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:56:38 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:56:43 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:56:49 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:56:54 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:56:59 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:04 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:09 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:14 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:19 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:24 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:29 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:34 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:39 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:44 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:49 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:57:55 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:00 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:05 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:10 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:15 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:20 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:25 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:30 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:36 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:41 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:46 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:58:55 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:00 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:05 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:10 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:15 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:20 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:25 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:31 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:36 7003
A ERROR LOG


A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 12:59:41 7003
A PRI PROTOCOL MISMATCH 09/00 - - 04/08 12:59:45 7006
A DS1 MISFRAME ALARM 09/00 - - 04/08 13:00:52 6C09
A DS1 LOSS OF SIGNAL ALARM 09/00 - - 04/08 13:07:03 6C01
A PRI PROTOCOL MISMATCH 09/00 - - 04/08 13:07:25 7006
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:07:34 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:07:43 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:07:48 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:07:53 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:07:59 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:08:04 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:08:09 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:08:14 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:08:19 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:08:24 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:08:29 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 04/08 13:08:34 7003
A PRI PROTOCOL MISMATCH 09/00 - - 04/08 13:08:45 7006
A PRI SVC STATE INCONSIST 09/21 - - 04/24 12:23:49 7002
A PRI SVC STATE INCONSIST 09/17 - - 05/01 07:47:46 7002
A PRI SVC STATE INCONSIST 09/11 - - 05/02 09:09:35 7002
A PRI SVC STATE INCONSIST 09/11 - - 05/15 08:01:53 7002
A PRI SVC STATE INCONSIST 09/06 - - 05/15 10:15:59 7002
A PRI SVC STATE INCONSIST 09/01 - - 05/15 11:02:50 7002
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:06:19 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:06:24 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:06:29 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:06:34 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:06:40 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:06:49 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:06:54 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:06:59 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:07:04 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:07:09 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:07:14 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:07:19 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:07:25 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:07:30 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:07:35 7003
A PRI D-CHNL INOPERATIVE 09/00 - - 02/08 17:07:40 7003
A PRI PROTOCOL MISMATCH 09/00 - - 02/08 17:07:41 7006
A DS1 SLIP ALARM 09/00 - - 02/08 17:17:22 6C0A
A PRI SVC STATE INCONSIST 09/19 - - 02/12 15:21:58 7002
A PRI SVC STATE INCONSIST 09/20 - - 02/13 14:56:49 7002
A PRI SVC STATE INCONSIST 09/13 - - 02/14 11:53:46 7002
A PRI SVC STATE INCONSIST 09/06 - - 02/20 08:10:53 7002
A E911 OVERFLOW 00/00 - - 02/20 10:35:40 0802

A Permanent Errors:

A Message ss/pp Cnt First Last Code
A E911 OVERFLOW 00/00 002 02/20 10:35:40 02/20 10:39:32 0802
A PRI PROTOCOL MISMATCH 09/00 001 04/08 13:08:45 04/08 13:08:45 7006

A Transient Errors:

A ERROR LOG


A Message ss/pp Cnt First Last Code
A PRI SVC STATE INCONSIST 09/11 001 05/15 08:01:53 05/15 08:01:53 7002
A PRI SVC STATE INCONSIST 09/06 001 05/15 10:15:59 05/15 10:15:59 7002
A PRI SVC STATE INCONSIST 09/01 001 05/15 11:02:50 05/15 11:02:50 7002

 

[dagwoodsystems]

From where I sit, TouchToneTommy, SYQUEST and HarrisD1200 are all saying the same thing.

The difference is that while SYSQUEST knows that our switch can generate these audio codes, and Tom seems to believe that the PBX won't generate them on cue from a D-Channel message. Busy tones are probably handled differently on a PRI than on analog trunks. Simple.

Outside of all that, it looks like your PRI is a mess. "Mess" is a bit of an exaggeration, but sheesh, what's with the circuit falling down so regularly? Inoperative D-Channels, inconsistant service state messages...this all points to either physical layer problems OR (as you began to point out) that something is not quite right in the carrier's implementation of Custom protocol. This is point where the comments of HarrisD1200 REALLY make sense. I know that a Santera softswitch will emulate 5ESS or DMS. Do you happen to know what kind of switch you are talking to?

Tim Alberstein

http://www.dagwoodsystems.com

 

[FordMan77]

I believe it's a DMS-100.

Jay

 

[tdaugirdas]

If it is a DMS 100 - make sure the protocol they are using is NI-2 - AND - also have then set the L1Flag in the Trunks SugGroup to "Yes" (L1 is a layer 1 flag) - otherwise you will have all sorts of problems. Then make sure you have the switch-type set to DMS 100 in PRI programming.

Tom Daugirdas,
President
STCG, Inc.
stcg.com

 

[FordMan77]

I'll check on the protocal they are using. I told them the last time I was out there to set the L1 flag to "yes", as we discovered they did not have this set. And I verified that the Legend is indeed set to DMS-100 on the PRI.

Jay

 

[tdaugirdas]

Verify that they have the L1Flag set as well.

Tom Daugirdas,
President
STCG, Inc.
stcg.com

 

[FordMan77]

Just an update: Local calls made to a busy number receive the busy tone back as normal. I'm still waiting for them to try and dial LD around the Sprint piece.

Jay

 

[FordMan77]

Well, had a pow-wow between us and McLeod (the local provider). They got a T-Berd on site and made some test calls and after all was said and done, it seems that the issue is between Sprint and McLeod. McLeod temproarily re-routed the LD Pick and had us make a call to a test # that they had busied out, and we got a busy signal back. After looking at some traps, it looks like Sprint is indeed sending the busy back to McLeod, but for some reason the McLeod switch is stopping it and not passing it back to the Legend. If I hear what the final resolution was, I'll post back so maybe it can give you guys some insight.

Jay

 

[merlinman]

At one time, there was only 1 phone company, and they were responsible for all service, from hand set to hand set.

But, Sprint, MCI and others thought it would be a great idea if they could play in this field also.

So now, how great do you feel that idea was?

http://home.comcast.net/~merlinman/index.htm

 

[phonesrus]

MM,
Nice to see you back!
Yea! 1 phone company, analog service, call the OP for LD, The Breakup did bring some interesting changes/advancements and problems that we may, or not, have seen. Then they split again and what did that lead to ?, Bell Labs/Lucent sold, AVAYA being sold to an investment group (bye bye, eventually) And Last but not least, One of the kids (SBC) buying the Momma (AT&T), taking her good name, and making her work for them, and some of the other kids too. How did that song go? "round, like a circle in a spiral, a wheel within a wheel"
And last, but not least, The CISCO kid! The serial was better.
The next few years will be interesting too, I fear.

 

[FordMan77]

I guess everyone wanted a piece of the pie as far as providers go. I wish it was just one company from start to finish. Sure would take a lot of the headache out of my job, lol... Of course then I'm sure they'd come up with something else to make it difficult. Learn something new everyday.

 

[Dexman]

I think Avaya will be around in some form even after the sale to the private investment groups is complete. There are a lot of AT&T/Lucent/Avaya phone systems out there. I can't see a company with the reach of Avaya just fading away.