cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3731
Views
0
Helpful
12
Replies

Call forward not working from outside Call with Verizon T1

gimp
Level 1
Level 1

Hi guys,

I have a problem to make work call-forwarding on my IP Phones Cisco 7942 model. When an external phone (PSTN) calls on an IP phone of the company (where forwarding to an external US national number is setted), the forwarding is not possible and the VG returns "your call cannot be completed at this time".

 

Here is the trace of call failure generated with "debug isdn q931" command on the Cisco CISCO2911/K9 Voice Gateway with IOS version c2900-universalk9-mz.SPA.157-3.M4b.bin:

C2911_VoiceGateway_Usa#
Jul 9 13:00:55.577: ISDN Se0/0/0:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 13
Jul 9 13:00:55.577: ISDN Se0/0/0:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 13
Jul 9 13:00:55.577: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0125 callID = 0x80A6 switch = primary-ni interface = User
Jul 9 13:00:55.577: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0125
Sending Complete
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Calling Party Number i = 0x2181, '3014777041'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '3015295762'
Plan:ISDN, Type:National
Jul 9 13:00:55.593: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8125
Channel ID i = 0xA98381
Exclusive, Channel 1
Jul 9 13:00:56.253: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8125
Progress Ind i = 0x8288 - In-band info or appropriate now available
Jul 9 13:00:56.353: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8125
Jul 9 13:00:56.353: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0125
Jul 9 13:01:01.713: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0125
Cause i = 0x8090 - Normal call clearing
Jul 9 13:01:01.721: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x8125
Jul 9 13:01:01.721: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0125
C2911_VoiceGateway_Usa#

 

The call works properly if The same mobile number 3015295762 is called directly.

Does anyone can help me please ?

 

Regards,

 

Michele

12 Replies 12

piyush aghera
Spotlight
Spotlight

Please check if you have given proper CSS under DN's call forwarding option and selected "Use Configured CSS" rather than Use System Default option.

 

If possible, please share snapshot of DN where you are transferring to mobile number

piyush aghera
Spotlight
Spotlight

Please check if you have given proper CSS under DN's call forwarding option and selected "Use Configured CSS" rather than Use System Default option.

 

If possible, please share snapshot of DN where you are transferring to mobile number.

Hi Piyush, 

I already tried to give the proper CSS under DN's call forwarding, as you can see in the attached screenshot but the issue is the same...

 

Is the call originating in the US and being placed to a US number?

Exactly, the call is from US to a US mobile number

Gimp,

 

Just looking at the screenshot of the call forward settings, my thought would be you may not have a route pattern starting with a 0 in the US. How do your employees in the US dial out? 91, 81, 71? Those are typically the main three combinations you would see for an outside line. Other than that Maren is spot on with next steps.

It is your router that is sending the initial disconnect message, so it implies that the problem is on the CUCM side.

Is the gateway acquired in CUCM via MGCP, H323 or SIP? Regardless, can you provide a trace of the Cisco CallManager service that includes the call? That will tell us what is happening inside CUCM that might cause the disconnect to be sent.

Maren

Hello Maren,

the CUCM is acquired via H323. You can see the trace attached, I exported it in a time range where we tried the call.

Thanks for your help

 

Unfortunately, the file you attached is a log of the traces rather that the trace itself.

Here is a link on How to Collect Traces for CUCM 9.x or Later

The specific trace that needs to be collected is the "Cisco CallManager Service" trace. Give it a shot and post the trace and we'll take a look.

Maren

My bad, attached you can find the correct trace I just collected.

Here are the informations about the call:

  • Calling party phone number : +390731816541
  • Called party phone number : +13014777047 (our internal 147) => redirect to  +13015295762
  • Call start time : 08:46 (GMT+2)
  • Voice says "We're sorry, your call cannot be completed at this time, please hang up and try your call again later"

Thanks!

I see an internal phone (SEP001646C733E5) with extension 541 calling 147 and that call being forwarded to 03015295762 with the internal phone going off hook at 08:46:03.442. But that's not an outside call being forwarded back out. Am I missing something?

Hi Maren,

that one was between internal numbers, and the issue is the same.

Attached you can see the trace with:

  • Calling party phone number : +393311066577 (mobile Italian phone)
  • Called party phone number : +13014777047 (our internal 147) => redirect to  +13015295762
  • Call start time : 16:40 (GMT+2)

Attached you can also find screenshots of our gateway and our internal phone redirect configuration.  

Thank you for your support