cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
4284
Views
15
Helpful
4
Replies
Highlighted
Enthusiast

7937 Outbound Call Failures SIP Trunk

I'm experiencing outbound call failiures as follows:

1.  7937 <-> CUCM <-> CUBE <-> TSP <-> PSTN <-> Called Party  ----  FAILS

2.  7945 <-> CUCM <-> CUBE <-> TSP <-> PSTN <-> Called Party  ----  SUCCEEDS

The above results are consistent and there is no difference in the configuration of the various calling phones. Both are SCCP, have the same CSSs, DPs, MRGLs etc. 

The 7937 supports G722 whereas the 7945 does not.  The CUCM Enterpise parameters has Advertise G722 disabled.   In CUCM, MTP Required is unchecked.

The outbound dial-peer is as follows:

dial-peer voice 1 voip

description outbound dial-peer for outgoing calls to Verizon (11D)

destination-pattern ^1..........$

session protocol sipv2

session target ipv4:SIP_TSP_ADDR:5232

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

voice-class sip early-offer forced

dtmf-relay rtp-nte digit-drop

ip qos dscp cs5 media

ip qos dscp cs3 signaling

no vad

no supplementary-service sip moved-temporarily

no supplementary-service sip refer

!

voice class codec 1

codec preference 1 transparent

I have tried every combination of codec in this outbound dial-peer.  For example, hard coding G711ulaw or removing any codec reference and allowing it to default to g729r8 - but the outbound 7937 calls still fail. 

See attached debug ccsip messages for both a failed call from the 7937 and a successful call from a 7945.

TIA,

Amir

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
VIP Mentor

For the failed call, your rpovider is sending request timeout. Since you have filtered out your numbers it is difficult to know what number and how you are presenting the number from the failed call. Is the number presented to your provider by the 7937 part of your DDI range? I have seen similar cases where ITSP provider will send a 408 request timeout if the CLI is not part of the DDI range

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

View solution in original post

4 REPLIES 4
Highlighted
VIP Mentor

For the failed call, your rpovider is sending request timeout. Since you have filtered out your numbers it is difficult to know what number and how you are presenting the number from the failed call. Is the number presented to your provider by the 7937 part of your DDI range? I have seen similar cases where ITSP provider will send a 408 request timeout if the CLI is not part of the DDI range

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

View solution in original post

Highlighted

The client has built all of their DNs as follows: 1 999 999 9999. I've masked the actual number with 9s here.

The working phone (7945) had an external phone number mask of 10 Xs - XXXXXXXXXX. The failing phone (7937) had an external phone number mask that included the full 11 digits - 1 999 999 9999.

Both the working and failing phone DNs where in the DID range but the successful calls were presenting just the 10 digit calling number because of the XXX XXX XXXX external phone number mask.  The failing calls were presenting the entire DN which was "1" plus the 10 digit number.

I modified the external phone number mask of the 7937 to be XXX XXX XXXX and outbound calls succeeded.

Thank you aokanlawon, Jorge Armijo and Tapan Dutt!

Amir

Highlighted
Enthusiast

Amir, please take a new set of catpures:
debug voice ccapi inout
debug ccsip all
And please, do not hide the calling/called information, we are here to help, and that kind of things makes it really hard.

--
Jorge Armijo

Please remember to rate helpful responses and identify helpful or correct answers.

-- Jorge Armijo Please remember to rate helpful responses and identify helpful or correct answers.
Highlighted
Cisco Employee

Try Changing firmware on the Cisco 7937 phone.

Tapan