As I see the debug my guess

eric.ahernandez · ‎07-29-2015

Hi everyone,

I have a SIP Trunk from a service provider (Bandwidth.com) that I receive on a Cisco 2901 Router. Eerything's configured and the Inbound calls are working fine, problem is with the outbound calls. Whenever we make a call we get the ringback fora couple of rings and then the call drops, I attached file with the debug ccsip messages.

What I got from the debug is that the router sends the SIP CANCEL too soon:

Sent:
CANCEL sip:+19567298079@216.82.224.202:5060 SIP/2.0
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK179
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6A4158-2414
To: <sip:+19567298079@216.82.224.202>

And then the other end just terminates the session because of this:

Received:
SIP/2.0 200 canceling
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK179
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6A4158-2414
To: <sip:+19567298079@216.82.224.202>;tag=900f99aa6782d15100c9e392fc47a2c3-7297

*Jul 29 18:18:25.911: //68/7D593B800000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK179
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6A4158-2414
To: <sip:+19567298079@216.82.224.202>;tag=gK04d794fd

But I haven't been able to figure out why it keeps sending the CANCEL.

I also attached the running configuration, any help will be appreciated.

Tagir Temirgaliyev · ‎07-29-2015

voice service voip

mode border-e

dial-peer voice 102 voip

voice-class sip bind control source-interface GigabitEthernet0/0.1

dspfarm profile 3 transcode

no shut

dspfarm profile 1 transcode

no shut

delayed offer from cucm to cube

and delayed offer from cube to provider.

make both early offer forced

voice service voip

sip

early-offer forced

to do early offer on cucm enable MTP on the SIP trunk

eric.ahernandez · ‎07-29-2015

Hi Tagir, First of all thanks for your response. I did the following changes:

voice service voip

mode border-e

And did the reload

dial-peer voice 102 voip

voice-class sip bind control source-interface GigabitEthernet0/0.1

This was because when I configured this dial-peer there were active calls and the change didn't reflect on the router.

delayed offer from cucm to cube

and delayed offer from cube to provider.

make both early offer forced

voice service voip

sip

early-offer forced

I'll let you know how it goes once I get in contact with the people on site to do the proper tests.

The dspfarm transcode profiles were left as shutdown because the router only has a PVDM3-8 and can't do much with it, right now I'm using IOS Enhanced transcoding and confer resources from another router. Probably next week we'll get an additional PVDM3-64 so we can use local resources.

Tagir Temirgaliyev · ‎07-29-2015

if without transcoding u need the same codec from cucm to provider. ask provider. or see in debug. when inbound call.

https://supportforums.cisco.com/discussion/11675251/message-sip-488-not-acceptable-here

eric.ahernandez · ‎07-29-2015

Hi Tagir,

I'm still getting the same results:

*Jul 29 21:08:15.027: //6/367740000000/SIP/Msg/ccsipDisplayMsg:
Sent:
CANCEL sip:+19567917652@216.82.224.202:5060 SIP/2.0
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK41777
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=4EA3C8-10A2
To: <sip:+19567917652@216.82.224.202>
Date: Wed, 29 Jul 2015 21:08:10 GMT
Call-ID: C01A494A-356C11E5-801388A9-65B4C5CE@209.184.111.170
CSeq: 101 CANCEL
Max-Forwards: 70

Keeps sending the SIP CANCEL and the call drops after 2 rings, I don't see any problems with the Codec though, Provider uses g.711ulaw and that's the one I'm using.

Tagir Temirgaliyev · ‎07-29-2015

cancel coming from cucm?

share full debag

eric.ahernandez · ‎07-29-2015

As I see the debug my guess is the Cancel gets sent from the CUBE:

*Jul 29 21:29:47.707: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+19567917652@172.16.2.26:5060 SIP/2.0
Via: SIP/2.0/TCP 172.20.15.15:5060;branch=z9hG4bK7b5437b132f
From: "CIPC TEST" <sip:1250@172.20.15.15>;tag=156408~b7ae3098-2a9b-497e-afb0-5257d696068a-31643133
To: <sip:+19567917652@172.16.2.26>
Date: Wed, 29 Jul 2015 21:39:07 GMT
Call-ID: 3c225500-5b9147fb-13d9-f0f14ac@172.20.15.15
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM10.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:172.20.15.15:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=VIDEO_UNSPECIFIED
Cisco-Guid: 1008882944-0000065536-0000002418-0252646572
Session-Expires: 1800
P-Asserted-Identity: "CIPC TEST" <sip:1250@172.20.15.15>
Remote-Party-ID: "CIPC TEST" <sip:1250@172.20.15.15>;party=calling;screen=yes;privacy=off
Contact: <sip:1250@172.20.15.15:5060;transport=tcp>
Max-Forwards: 70
Content-Length: 0

*Jul 29 21:29:47.719: //10/3C2255000000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+19567917652@216.82.224.202:5060 SIP/2.0
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK8157
Remote-Party-ID: "CIPC TEST" <sip:9562679960@209.184.111.170>;party=calling;screen=yes;privacy=off
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6270DC-18D9
To: <sip:+19567917652@216.82.224.202>
Date: Wed, 29 Jul 2015 21:29:47 GMT
Call-ID: C5952136-356F11E5-802088A9-65B4C5CE@209.184.111.170
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1008882944-0000065536-0000002418-0252646572
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M6
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1438205387
Contact: <sip:9562679960@209.184.111.170:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 291

v=0
o=CiscoSystemsSIP-GW-UserAgent 2975 2246 IN IP4 209.184.111.170
s=SIP Call
c=IN IP4 209.184.111.170
t=0 0
m=audio 16400 RTP/AVP 0 18 101
c=IN IP4 209.184.111.170
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

*Jul 29 21:29:47.783: //10/3C2255000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK8157
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6270DC-18D9
To: <sip:+19567917652@216.82.224.202>
Call-ID: C5952136-356F11E5-802088A9-65B4C5CE@209.184.111.170
CSeq: 101 INVITE
Server: Bandwidth.com TRM (bw7.gold.13)
Content-Length: 0

*Jul 29 21:29:49.067: //10/3C2255000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK8157
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6270DC-18D9
To: <sip:+19567917652@216.82.224.202>;tag=gK04b6b465
Call-ID: C5952136-356F11E5-802088A9-65B4C5CE@209.184.111.170
CSeq: 101 INVITE
Record-Route: <sip:216.82.224.202:5060;lr;ftag=6270DC-18D9>
Contact: <sip:+19567917652@67.231.1.135:5060>
Allow: INVITE,ACK,CANCEL,BYE,PRACK,OPTIONS
Content-Length: 246
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 113511998 741340679 IN IP4 67.231.1.135
s=SIP Media Capabilities
c=IN IP4 69.252.200.134
t=0 0
m=audio 27064 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

*Jul 29 21:29:52.711: //10/3C2255000000/SIP/Msg/ccsipDisplayMsg:
Sent:
CANCEL sip:+19567917652@216.82.224.202:5060 SIP/2.0
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK8157
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6270DC-18D9
To: <sip:+19567917652@216.82.224.202>
Date: Wed, 29 Jul 2015 21:29:47 GMT
Call-ID: C5952136-356F11E5-802088A9-65B4C5CE@209.184.111.170
CSeq: 101 CANCEL
Max-Forwards: 70
Timestamp: 1438205392
Reason: Q.850;cause=38
Content-Length: 0

*Jul 29 21:29:52.771: //10/3C2255000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 canceling
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK8157
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6270DC-18D9
To: <sip:+19567917652@216.82.224.202>;tag=900f99aa6782d15100c9e392fc47a2c3-a966
Call-ID: C5952136-356F11E5-802088A9-65B4C5CE@209.184.111.170
CSeq: 101 CANCEL
Server: Bandwidth.com TRM (bw7.gold.13)
Content-Length: 0

*Jul 29 21:29:52.827: //10/3C2255000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK8157
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6270DC-18D9
To: <sip:+19567917652@216.82.224.202>;tag=gK04b6b465
Call-ID: C5952136-356F11E5-802088A9-65B4C5CE@209.184.111.170
CSeq: 101 INVITE
Content-Length: 0

*Jul 29 21:29:52.827: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:+19567917652@216.82.224.202:5060 SIP/2.0
Via: SIP/2.0/UDP 209.184.111.170:5060;branch=z9hG4bK8157
From: "CIPC TEST" <sip:9562679960@209.184.111.170>;tag=6270DC-18D9
To: <sip:+19567917652@216.82.224.202>;tag=gK04b6b465
Date: Wed, 29 Jul 2015 21:29:47 GMT
Call-ID: C5952136-356F11E5-802088A9-65B4C5CE@209.184.111.170
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

Tagir Temirgaliyev · ‎07-29-2015

cube still receive delayed offer from cucm (without codec)

and cube sends early offer to provider (codec PCMU)

sh dspf all

to make CUCM to send an Early Offer INVITE you have enable MTP on the SIP trunk. The codec being sent to the SIP trunk is "MTP Preferred Originating Codec" . default is G711ulaw

eric.ahernandez · ‎07-29-2015

Hi Tagir,

This is a fragment of the SIP Trunk Configuration:

We also installed a PVDM3-64 and registered MTP Hardware resources for this and are the ones I'm using:

dspfarm profile 3 mtp
codec g711ulaw
maximum sessions hardware 10
associate application SCCP

sccp local GigabitEthernet0/0.1
sccp ccm 172.20.15.15 identifier 1 version 7.0
sccp
sccp ccm group 1
bind interface GigabitEthernet0/0.1
associate ccm 1 priority 1
associate profile 3 register MTP-HW-LAR
associate profile 1 register XCODE-HW-LAR
associate profile 2 register CONF-HW-LAR

I did some calls and I keep getting the same results

Tagir Temirgaliyev · ‎07-29-2015

This is a fragment of the SIP Trunk Configuration:

make dtmf signaling rtp-nte

sh dspf all

and share debug

for some reason cube dont send sip 100 trying to cucm?

voice service voip
ip address trusted list
ipv4 69.252.200.134

Mohammed al Baqari · ‎07-29-2015

Hi,

Can you please share the full debug from the CUBE? Your debugs aren't complete as we don't see any SDP contents, we don't see any message between CUCM and CUBE, etc.

Without a complete debug, it is difficult to troubleshoot,

eric.ahernandez · ‎08-07-2015

Ok so apparently I've got it working now.

What Tagir said got me thinking, about CUBE not sending SIP 100 trying to CUCM, So I did full ccsip debugs and saw that when trying to establish the SIP session to CUCM the CUBE would use source IP Address 11.11.11.1 (Which is an Interface Tunnel Interface for a GRE Tunnel to another site). Hmm weird... then what's the point in doing the sip bind media and sip bind control commands on the dial-peers.

So what I did was configure NAT for the Inside Subinterface (172.16.2.26) so it can reach the ITSP as well as the CUCM and then I configured the SIP binds globally:

voice service voip

sip

bind control source-interface Gi 0/0.1

bind media source-interface Gi 0/0.1

I also removed the bind commands from the dial-peers

no voice-class sip bind control source-interface GigabitEthernet0/0.1

no voice-class sip bind media source-interface GigabitEthernet0/0.1

I did some tests and the outgoing calls worked!! But the Incoming calls failed... (really?) So I added the bind commands on the dial-peers again (the ones above that I removed previously), did some tests and both outgoing and incoming calls worked.

Thanks again guys, you set me on the right path and also helped me out on getting a cleaner config on the CUBE and the CUCM for the SIP Trunk

AnnM410 · ‎03-02-2018

I have this problem too except when the call is answered and goes into a queue (...on hold waiting to be answered by Help Desk) the call drops after about 1 min. If the call is answered right away and doesn't go in the queue, it doesn't drop. I need help trouble shooting.

Saurabh · ‎03-02-2018

Hi
Can you elaborate the scenario and provide any call flow diagram.
Also provide sip debugs.

AnnM410 · ‎03-02-2018

SIP Trunk to Service Provider getting SIP 487 Session Terminated