Particular number getting fast busy.

chmorin

I just want to make sure I'm not insane before I open a ticket with the PSTN provider.

In one of our locations we have a particular number that, when dialed, is unrouteable with a fast-busy. I ran some DNA things coming from two different gateways, one that is able to dial the number and one that is not. Both had identical call outing straight to the PRI in their route group. So then the problem must be obvious when I get to the gateway.

This is the debug isdn q931 from the working gateway:

ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x0F65
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98393
                Exclusive, Channel 19
        Display i = 'Chris Morin'
        Calling Party Number i = 0x2181, '2813626849'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '19856653042'
                Plan:Unknown, Type:Unknown
ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8F65
        Channel ID i = 0xA98393
                Exclusive, Channel 19
[I]ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x8F65
        Progress Ind i = 0x8488 - In-band info or appropriate now available
ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x8F65
ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x0F65
ISDN Se0/0/0:23 Q931: RX <- STATUS_ENQ pd = 8  callref = 0x8F52
ISDN Se0/0/0:23 Q931: TX -> STATUS pd = 8  callref = 0x0F52
        Cause i = 0x809E - Response to STATUS ENQUIRY or number unassigned[/I]
        Call State i = 0x0Aun all
All possible debugging has been turned off
NCW-2851VG#
ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x0F65
        [B]Cause i = 0x8090 - Normal call clearing[/B]
ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8  callref = 0x8F65
ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x0F65

The person picked up the phone and I explained to him I was testing the phones.

This is the result from the not working gateway:

NDFLOU-2851#
Feb  9 17:06:40.298: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x0178
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98397
                Exclusive, Channel 23
        Display i = 'Lafayette Test'
        Calling Party Number i = 0x0081, '3377352998'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0xA1, '19856653042'
                [B]Plan:ISDN, Type:National[/B]
[I]Feb  9 17:06:40.346: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8178
        Channel ID i = 0xA18397
                Preferred, Channel 23[/I]
Feb  9 17:06:41.562: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x8178
        [B]Cause i = 0x829F - Normal, unspecified[/B]
Feb  9 17:06:41.678: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x0178
Feb  9 17:06:41.718: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x8178un all
All possible debugging has been turned off
NDFLOU-2851#

A few things stick out to me, indicated in bold. Or italicized. There is a complete and total lack of a call negotiation on the non-functioning call manager. However, it does show that it does get sent out the PRI. Am I missing something obvious or should I go ahead and call the PSTN provider? I appreciate any input, and even criticism on how I have troubleshooted this. I'm still trying to learn.

shodown

Your sending one call out national and the other out unknown. You would have to set the PRI in the call that doens't work just like the PRI for the call that doesn't work.



interface Serial0/0/0:23

isdn map address plan unknown type unknown

this is how the one that isn't working is being sent. So you will have to change it to the other

interface Serial0/0/0:23

isdn map address plan XXXXXXX type national

With that said if your PRI is from different providers it maybe a reason why they are set that way. Also if people there dial out internationally this may also cause some concern. So you were right with your thought to call the PSTN provider and ask them how they want you to send the calls.

chmorin

shodown wrote: »

Your sending one call out national and the other out unknown. You would have to set the PRI in the call that doens't work just like the PRI for the call that doesn't work.



interface Serial0/0/0:23

isdn map address plan unknown type unknown

this is how the one that isn't working is being sent. So you will have to change it to the other

interface Serial0/0/0:23

isdn map address plan XXXXXXX type national

With that said if your PRI is from different providers it maybe a reason why they are set that way. Also if people there dial out internationally this may also cause some concern. So you were right with your thought to call the PSTN provider and ask them how they want you to send the calls.

Thanks for the advice, I appreciate it. I'll get talking with the PSTN and see how they receive the call and how they route the call.

Kelkin

Actually seen this problem before.. When I worked with the Carrier they said they want either the 1 or National type but not both.

chmorin

Kelkin wrote: »

Actually seen this problem before.. When I worked with the Carrier they said they want either the 1 or National type but not both.

Reminds me of a problem we had recently with international calling. Wanting either 011 or International, but not both. Problem is, I'm still in need of re-designing our route patterns to allow this to work the way it should. I just got approved to plan out the changes... Let's try something anyway...

chmorin

Okay... the call still gets a fast busy, but I have changed it to send the number as an unknown type:

NDFLOU-2851#
Feb  9 20:56:45.081: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x0026
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98397
                Exclusive, Channel 23
        Display i = 'Lafayette Test'
        Calling Party Number i = 0x0081, '2998'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0x80, '1985665xxxx'
                Plan:Unknown, Type:Unknown
Feb  9 20:56:45.137: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8026
        Channel ID i = 0xA18397
                Preferred, Channel 23
Feb  9 20:56:46.297: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x8026
        Cause i = 0x829F - Normal, unspecified
Feb  9 20:56:46.417: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x0026
Feb  9 20:56:46.457: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x8026un all
All possible debugging has been turned off
NDFLOU-2851#

I'm even more leaning to it being a service provider issue now. I'll let you know what I find out.

shodown

chmorin wrote: »

Reminds me of a problem we had recently with international calling. Wanting either 011 or International, but not both. Problem is, I'm still in need of re-designing our route patterns to allow this to work the way it should. I just got approved to plan out the changes... Let's try something anyway...

if you add 011 and international. When the provider see's its international they will add anther 011 on there, which is the reason for that. Unknown/Unknown should work for all 7/10/11 digit dialing. International is where providers get picky.

chmorin

shodown wrote: »

if you add 011 and international. When the provider see's its international they will add anther 011 on there, which is the reason for that. Unknown/Unknown should work for all 7/10/11 digit dialing. International is where providers get picky.

Right, I understand this. I actually had a previous thread related to that problem. But it sounds like with this issue since it is 11 digit dialing unknown should work, which it is not.