Call Forward External Issue

[msteeler]

Hello -

Little background, we have CUCM 10.5.2 with 8 nodes and 100 plus sites. Each site has its own VG Router registered back to a Sub via SIP Trunk. We have one site where call forward external is not working correctly. When they forward their phone to an external number and call comes in from the outside the call will forward external but only rings the phone that the call is forwarded to maybe twice and then the call is dropped.

Now if you call the phone being forwarded from another Cisco phone within the cluster the call is forwarded external just fine. The difference between an external call is coming in on the PRI on say channel 1 and going forwarding back out on channel 23, where as the internal call from another Cisco phone is on the network and then going out one of the channels on the PRI.

This is a typical set up at every site we have with a PRI, but other sites are not having this issue, call forwarding to an external number coming in from the outside works just fine.

I opened a ticket with the LEC. They say its not the PRI. I have a TAC open and they see what I see with the below debug and think it's the LEC. I'm trying to get both on the phone at the same time but until that happens has anyone seen this before? Any ISDN timers I might be able to adjust just to test. I've compared the ISDN timers with other working sites and they all set the same. Thanks All!


002399: Jun 28 18:47:34.031: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x06AB

Cause i = 0x82E6 - Recovery on timer expiry[/b]

 

[gnrslash4life]

So Carrier -> PRI -> Router -> SIP -> CUCM?



Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS
CIPTV1
CIPTV2

 

[msteeler]

Yeah, so the call is being forwarded to a cell phone so I guess Carrier > PRI > Router > SIP Trunk to CUCM for Call Set up > Router > PRI > Carrier.

I did some more testing last night. The carrier is using a DMS-10, which isnt an option for switch type on the router so I tried a ISDN switch type as DMS100. had the same results, i see the call coming to my cell but it only rings once or twice and the call fails. I changed it back to primary-ni.

I set up my CIPC with a number from that office and changed my External Phone Mask to a non DID (random number) and called my cell. The number displayed on my cell was the front desk number, not the number I put in there. I then changed it back to the actual number of the phone and it displayed that number on my cell (like it should). It seems that if the LEC doesn't recognize the number they use the front desk number because I have it set to use the Calling Parties Mask on the Route Pattern.

When the phone is being forwarded I would expect to see on caller ID the number of the phone that actually placed the call, but I see the front desk number. The SIP Truck for outbound is set to Originator.

Thanks

 

[gnrslash4life]

It seems that if the LEC doesn't recognize the number they use the front desk number because I have it set to use the Calling Parties Mask on the Route Pattern." - That would be a carrier thing then.

When you run a debug what do you see?



Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS
CIPTV1
CIPTV2

 

[msteeler]

Sorry, been out. Below is the debug when I tested with Cisco

+1st Incoming call from PSTN:

002232: Jun 28 18:47:24.319: ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x06AB
Bearer Capability i = 0x9090A2
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA18381
Preferred, Channel 1
Facility i = 0x9F8B0100A110020236AA06072A8648CE1500040A0100
Protocol Profile = Networking Extensions
0xA110020236AA06072A8648CE1500040A0100
Component = Invoke component
Invoke Id = 13994
Operation = InformationFollowing (calling_name)
Name information in subsequent FACILITY message
Progress Ind i = 0x8483 - Origination address is non-ISDN
Calling Party Number i = 0x2183, '7753867134'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '4406'
Plan:Unknown, Type:Unknown

002268: Jun 28 18:47:24.327: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x86AB
Channel ID i = 0xA98381
Exclusive, Channel 1


+Then the second call (forwarded) To the PSTN again:


002307: Jun 28 18:47:24.399: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x2 0x1, Calling num 7753867134
002308: Jun 28 18:47:24.399: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x1B9A callID = 0xF984 switch = primary-ni interface = User
002309: Jun 28 18:47:24.399: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x1B9A
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
Exclusive, Channel 2
Calling Party Number i = 0x2181, '7753867134'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '17752330540'
Plan:Unknown, Type:Unknown
Redirecting Number i = 0x00018F, '5415734406'
Plan:Unknown, Type:Unknown


002311: Jun 28 18:47:24.567: ISDN Se0/0/0:23 Q931: RX <- STATUS pd = 8 callref = 0x9B9A
Cause i = 0x82E46C - Invalid information element contents
Call State i = 0x01
002312: Jun 28 18:47:24.571: ISDN Se0/0/0:23 Q931: RX <- STATUS pd = 8 callref = 0x9B9A
Cause i = 0x82E474 - Invalid information element contents
Call State i = 0x01
002313: Jun 28 18:47:24.575: ISDN Se0/0/0:23 Q931: RX <- STATUS pd = 8 callref = 0x9B9A
Cause i = 0x82AB6C74 - Access information discarded
Call State i = 0x01
002314: Jun 28 18:47:24.579: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x9B9A
Channel ID i = 0xA98382
Exclusive, Channel 2
002315: Jun 28 18:47:24.579: //5441766/383A4B800004/CCAPI/cc_api_call_proceeding:
Interface=0x161F1BE4, Progress Indication=NULL(0)



002316: Jun 28 18:47:24.775: ISDN Se0/0/0:23 Q931: RX <- FACILITY pd = 8 callref = 0x06AB
Facility i = 0x9F8B0100A118020236AA020100800F4E45564144412043414C4C20202020
Protocol Profile = Networking Extensions
0xA118020236AA020100800F4E45564144412043414C4C20202020
Component = Invoke component
Invoke Id = 170
Operation = CallingName
Name Presentation Allowed Extended
Name = NEVADA CALL


002319: Jun 28 18:47:27.963: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x9B9A
Progress Ind i = 0x8488 - In-band info or appropriate now available
002320: Jun 28 18:47:27.963: //5441766/383A4B800004/CCAPI/cc_api_call_alert:
Interface=0x161F1BE4, Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)



002388: Jun 28 18:47:28.003: ISDN Se0/0/0:23 Q931: TX -> PROGRESS pd = 8 callref = 0x86AB
Progress Ind i = 0x8188 - In-band info or appropriate now available


+after 10 seconds the Voice gateway received a disconnect message from the Telco for the First call:


002399: Jun 28 18:47:34.031: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x06AB
Cause i = 0x82E6 - Recovery on timer expiry
002400: Jun 28 18:47:34.031: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x86AB
002401: Jun 28 18:47:34.031: //5441763/0F3938439BDB/CCAPI/cc_api_call_disconnected:
Cause Value=102, Interface=0x161F1BE4, Call Id=5441763

 

[gnrslash4life]

Can you provide ISDN and SIP Debugs of 1 call getting forwarded externally?

Certifications:
A+
Network+
CCENT
CCNA Voice
TVOICE
CAPPS
CIPTV1
CIPTV2

 

[msteeler]

Forgot to post back because I went on vacation but the issue was with the LEC's switch. The Tech never did tell what he changed, but they compared the settings of their DMS with another DMS (which we have a PRI off of and forward external worked fine). There were some differences and after the change forward external is no longer dropping calls. Thanks All