Call issues With SIP Trunk

Geevarghese Cheria · ‎09-28-2012

Introduction.

This document discuss about some of the issues that occur when calling across SIP Trunk and solution for the same.

Problem

you have a SIP trunk on CUCM connecting to a remote system. When ever you receive an inbound call on a PRI

and send the call to the SIP trunk, the SIP trace is sending sip:anonymous@anonymous.invalid to the remote system.

you want this to be send with an IP address so the call will not be rejected.

Topology

PRI > Cisco Voice GW > CUCM > CUCM SIP TRUNK > remote system.

Solution

CUCM sends calling number as anonymous@anonymous over SIP, because you receive the calling party type as 'private' on the SIP Trunk.

So CUCM is behaving as expected. Here what you need is to come up with a workaround is to have the CUCM pass this

information. The most straightforward solution would be to convert the incoming Gateway to H323 and put a Translation Rule on the Gateway to change the Calling Party Type.

Reproduce the problem and then get the call manager traces.
Note the calling number, the called number, call manager ip and the remote system

After Analyzing the traces following steps were done to resolve the issue. Since, the last CLI governing connection was the SIP Trunk on SIP Trunk,

Enable Transmit UTF-8 for Calling Party Name
Change Calling Party Selection: From Originator to First Redirect Number
Calling Line Id Presentation: From Default to Allowed
Calling Name Presentation: From Default to Allowed

Problem

You have a CUBE and SIP trunk for PSTN calling. Here Your outbound calls work fine, but inbound calls are failing.

You had an original block of inbound DIDs that are working fine but a new block of them is not working.

Topology:

ITSP - - [SIP] - - CUBE - - [SIP] - - CUCM

Solution

In debugging it was found that the new block of DIDs was 917-647-24XX. This was matching the ITSP facing dial-peer

which was set for 9.T instead of the CUCM facing dial-peer. That dial-peer was stripping the 9 off the call and sending

it back to the PSTN.

So to fix this issue you need to make another more specific dial-peer for that block with no digit stripping

and sends the call to CUCM. This will work correctly and will not adversly affect anything.

Problem

Incoming and outgoing calls to cube are not working

Topology:

NET UX2000 >> SIP Trunk >> CUBE >> SIP Trunk >> CUCM >> IP Phone

Solution

In genereal following are the steps that need to be performed to resolve the issue:

Configure a bind command under dial-peers to CUCM.
Add css to sip trunk
Use a translation rule to send 4 digits to cucm
For outgoing calls add the ip addresses to trust list under voice service voip

Here since you have two sip trunk providers on the same cube and the calls that are using a 9 to route outbound calls works fine.

You are dialing the numbers directly for eg, 2xxxxxxxxx or 7xxxxxxxxx. Here you need to use

an 8 for access to the SIP trunk that connects cucm.

To accomplish this update the route pattern with 8.@ and no prefix strip

Also update the cube config with the following

voice translation-rule 100

rule 1 /^8/ //

voice translation-profile Strip_8

translate called 100

dial-peer voice 9001 voip

description INBOUND CUCM to CUBE

session protocol sipv2

incoming called-number 8.

voice-class sip profiles 1

dtmf-relay rtp-nte h245-alphanumeric

codec g711ulaw

no vad

dial-peer voice 9002 voip

destination-pattern 8T

session protocol sipv2

session target ipv4:155.203.48.9

voice-class sip profiles 1

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

translation-profile outgoing Strip_8

Problem

Router is not registering with service provider

Topology:

CUCM ---- H323 ---- 2951 ---- SIP ---- ITSP

Solution

Here in this case the ideal scenario would be

======

Router ITSP

------------->

REGISTER

<-------------

100 TRYING

<-------------

401 UNAUTHORiZED (www-authenticate: challenge presented)

------------->

REGISTER (www-authenticate: response to challenge)

<-------------

200 OK

======

Router 2951# show sip-ua register status

Line peer expires(sec) registered P-Associ-URI

================================ ========== ============ ========== ============

81[2-9]..[2-9]...... 352 107 no

8[2-9]...... 351 107 no

9043833521 -1 145 no

Following is the o/p from debugs:

-------

REGISTER sip:10.255.255.5:5060 SIP/2.0

Via: SIP/2.0/UDP 209.156.51.26:5060;branch=z9hG4bK5C822

From: <sip:9043833521@10.255.255.5>;tag=489DE4-1A09

To: <sip:9043833521@10.255.255.5>

Date: Tue, 18 Sep 2012 04:02:37 GMT

Call-ID: 86BD5D87-7111E2-8002B6E5-A1B39CB6

User-Agent: Cisco-SIPGateway/IOS-12.x

Max-Forwards: 70

Timestamp: 1347940957

CSeq: 28 REGISTER

Contact: <sip:9043833521@209.156.51.26:5060>

Expires: 3600

Supported: path

Content-Length: 0

000522: Sep 18 00:02:37.745: //97/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 403 Forbidden

Via: SIP/2.0/UDP 209.156.51.26:5060;branch=z9hG4bK5C822

From: <sip:9043833521@10.255.255.5>;tag=489DE4-1A09

To: <sip:9043833521@10.255.255.5>;tag=aprqngfrt-p1qqhk00000o1

Call-ID: 86BD5D87-7111E2-8002B6E5-A1B39CB6

Timestamp: 1347940957

CSeq: 28 REGISTER

----------

To resolve this issue Contact the Service Provider and they told to REGISTER message with different IP address.

To accomplish this you need bind the SIP traffic with a different interface (Ex GigabitEthernet0/0.2).

Problem

All the inbound/outbound calls are failing.

Solution

Collected debug output from CUBE found when CUBE has never received any 100Trying or

180Ring message from CUCM for inbound call, it appears CUCM has never respond any SIP

invite.

<snip>

91 22:59:27.322 INVITE 2586123269466 W->

244 22:59:27.338 <-------------100 Trying

258 22:59:27.342 INVITE 6123269466 W/ S->

296 22:59:27.434 INVITE 6123269466 W/ S->

334 22:59:27.634 INVITE 6123269466 W/ S->

457 22:59:28.042 INVITE 6123269466 W/

SDP----------------------->

495 22:59:28.142 INVITE 6123269466 W/

SDP----------------------->

533 22:59:28.342 INVITE 6123269466 W/

SDP----------------------->

598 22:59:28.750 <----408 Request Timeout

613 22:59:28.774 ACK-------------------->

636 22:59:28.850

<--------------------------------------------INVITE 2586123269466 W/ SDP

789 22:59:28.866 100

Trying------------------------------------------------------------->

803 22:59:28.866 INVITE 6123269466 W/

SDP-------------------------------------------

<snip>

Reviewed CUCM ccm Trace, found CUCM in fact did respond 100Trying and 180Ring message

back to CUBE. But the messages have never reached to the CUBE.

<snip>

0.97.222.123---------CUCM----------------10.97.222.123-----------10.97.222.123-----------1

0.97.222.123-----------10.97.222.123-----------10.97.222.123-----------10.97.222.123------

-----10.97.222.123

1611 23:29:47.299 INVITE 6123269466 W/ S->

1689 23:29:47.301 <-------------100 Trying

1987 23:29:47.311 <------------180 Ringing

2017 23:29:47.397 INVITE 6123269466 W/ S->

2068 23:29:47.398 <------------180 Ringing

2099 23:29:47.597 INVITE 6123269466 W/ S->

2150 23:29:47.598 <------------180 Ringing

2442 23:29:48.451 <----------200 OK W/ SDP

2504 23:29:48.840 <-INVITE 6123269466 W/ S

2582 23:29:48.841 100 Trying------------->

2877 23:29:48.851 180 Ringing------------>

2905 23:29:48.933 <-INVITE 6123269466 W/ S

2956 23:29:48.934 180 Ringing------------>

2985 23:29:48.962 <----------200 OK W/ SDP

3029 23:29:49.134 <-INVITE 6123269466 W/ S

3080 23:29:49.134 180 Ringing------------>

3187 23:29:49.974 <----------200 OK W/ SDP

<snip>

Further troubleshooting it was found that there is a sip binding command that binds to out side interface of the router,

while CUCM has also configured router out side interface for the SIP trunk.

As a result CUCM did not really respond 100Trying and 180ring message back to CUBE (enabled

SIP binding on ISR1 would caused issue while there are separated network for internal and

external).

To resolve this

Remove sip binding command from voice service
Change the CUCM SIP trunk IP address to CUBE's internal IP.

Call issues With SIP Trunk

No voice when calls accross SIP Trunk