cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2775
Views
0
Helpful
8
Replies

SIP CUBE outgoing call goes busy

rramlal
Level 1
Level 1

Hi Team,

I am setting up a SIP connection to a SIP provider. So the call path is as follows:

CUCM11-->SIP Trunk-->VG(CUBE)(2921)-->SIP Provider

For testing I have just setup a dial-peer for cell phone however the call goes busy. All configs are setup properly on CUCM. I am not very familar with SIP so reading the debugs is difficult. 

The logs are as follows:

Dec 7 16:43:12.147: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:3611756@192.168.8.7:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.0.167:5060;branch=z9hG4bK76b02481125e
From: <sip:2206@192.168.0.167>;tag=289751~60db65cc-10e7-7296-2078-aecac853473e-48569089
To: <sip:3611756@192.168.8.7>
Date: Wed, 07 Dec 2016 16:43:12 GMT
Call-ID: 3ca21580-84813c20-755d-a700a8c0@192.168.0.167
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM11.0
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:192.168.0.167:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
Session-ID: 2b99b9444c0daa316c507a75aa289750;remote=00000000000000000000000000000000
Cisco-Guid: 1017255296-0000065536-0000000030-2801838272
Session-Expires: 1800
P-Asserted-Identity: <sip:2206@192.168.0.167>
Remote-Party-ID: <sip:2206@192.168.0.167>;party=calling;screen=yes;privacy=off
Contact: <sip:2206@192.168.0.167:5060;transport=tcp>
Max-Forwards: 69
Content-Length: 0


Dec 7 16:43:12.155: //17/3CA215800000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:3611756@10.255.0.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.8.7:5060;branch=z9hG4bK61F05
Remote-Party-ID: <sip:2206@192.168.8.7>;party=calling;screen=yes;privacy=off
From: <sip:2206@192.168.8.7>;tag=9C5D40-1A5C
To: <sip:3611756@10.255.0.2>
Date: Wed, 07 Dec 2016 16:43:12 GMT
Call-ID: 13880BC8-BBD311E6-802EDB82-DDEACA22@192.168.8.7
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1017255296-0000065536-0000000030-2801838272
User-Agent: Cisco-SIPGateway/IOS-15.5.1.T2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1481128992
Contact: <sip:2206@192.168.8.7:5060>
Call-Info: <sip:192.168.8.7:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 315

v=0
o=CiscoSystemsSIP-GW-UserAgent 2963 6639 IN IP4 192.168.8.7
s=SIP Call
c=IN IP4 172.16.0.7
t=0 0
m=audio 16412 RTP/AVP 0 100 101 19
c=IN IP4 172.16.0.7
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Dec 7 16:43:12.155: //16/3CA215800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.0.167:5060;branch=z9hG4bK76b02481125e
From: <sip:2206@192.168.0.167>;tag=289751~60db65cc-10e7-7296-2078-aecac853473e-48569089
To: <sip:3611756@192.168.8.7>
Date: Wed, 07 Dec 2016 16:43:12 GMT
Call-ID: 3ca21580-84813c20-755d-a700a8c0@192.168.0.167
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.5.1.T2
Content-Length: 0


Dec 7 16:43:12.307: //17/3CA215800000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:3611756@10.255.0.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.8.7:5060;branch=z9hG4bK61F05
Remote-Party-ID: <sip:2206@192.168.8.7>;party=calling;screen=yes;privacy=off
From: <sip:2206@192.168.8.7>;tag=9C5D40-1A5C
To: <sip:3611756@10.255.0.2>
Date: Wed, 07 Dec 2016 16:43:12 GMT
Call-ID: 13880BC8-BBD311E6-802EDB82-DDEACA22@192.168.8.7
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1017255296-0000065536-0000000030-2801838272
User-Agent: Cisco-SIPGateway/IOS-15.5.1.T2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1481128992
Contact: <sip:2206@192.168.8.7:5060>
Call-Info: <sip:192.168.8.7:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 315

v=0
o=CiscoSystemsSIP-GW-UserAgent 2963 6639 IN IP4 192.168.8.7
s=SIP Call
c=IN IP4 172.16.0.7
t=0 0
m=audio 16412 RTP/AVP 0 100 101 19
c=IN IP4 172.16.0.7
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Dec 7 16:43:12.607: //17/3CA215800000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:3611756@10.255.0.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.8.7:5060;branch=z9hG4bK61F05
Remote-Party-ID: <sip:2206@192.168.8.7>;party=calling;screen=yes;privacy=off
From: <sip:2206@192.168.8.7>;tag=9C5D40-1A5C
To: <sip:3611756@10.255.0.2>
Date: Wed, 07 Dec 2016 16:43:12 GMT
Call-ID: 13880BC8-BBD311E6-802EDB82-DDEACA22@192.168.8.7
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1017255296-0000065536-0000000030-2801838272
User-Agent: Cisco-SIPGateway/IOS-15.5.1.T2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1481128992
Contact: <sip:2206@192.168.8.7:5060>
Call-Info: <sip:192.168.8.7:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 315

v=0
o=CiscoSystemsSIP-GW-UserAgent 2963 6639 IN IP4 192.168.8.7
s=SIP Call
c=IN IP4 172.16.0.7
t=0 0
m=audio 16412 RTP/AVP 0 100 101 19
c=IN IP4 172.16.0.7
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Dec 7 16:43:13.207: //16/3CA215800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 408 Request Timeout
Via: SIP/2.0/TCP 192.168.0.167:5060;branch=z9hG4bK76b02481125e
From: <sip:2206@192.168.0.167>;tag=289751~60db65cc-10e7-7296-2078-aecac853473e-48569089
To: <sip:3611756@192.168.8.7>;tag=9C615C-B1A
Date: Wed, 07 Dec 2016 16:43:12 GMT
Call-ID: 3ca21580-84813c20-755d-a700a8c0@192.168.0.167
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.5.1.T2
Reason: Q.850;cause=102
Content-Length: 0


Dec 7 16:43:13.211: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:3611756@192.168.8.7:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.0.167:5060;branch=z9hG4bK76b02481125e
From: <sip:2206@192.168.0.167>;tag=289751~60db65cc-10e7-7296-2078-aecac853473e-48569089
To: <sip:3611756@192.168.8.7>;tag=9C615C-B1A
Date: Wed, 07 Dec 2016 16:43:12 GMT
Call-ID: 3ca21580-84813c20-755d-a700a8c0@192.168.0.167
User-Agent: Cisco-CUCM11.0
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence, kpml
Content-Length: 0

1 Accepted Solution

Accepted Solutions

As per current config;

dial-peer 403

 This is outbound dial peer towards provider. Seems good.

dial-peer 404

 This is inbound dial peer for incoming calls from provider. You should bind this dial peer with Gig 0/2 interface.

dial-peer 405

 You don't need this dial peer if all incoming calls from provider are simply needed to convert to 6500. Attach the existing translation profile in inbound direction to dial-peer 404 which will convert the called number to 6500.

dial-peer 402

 If this is the dial peer you want to use to route the call to CUC extension, bind this dial peer with Gig 0/0 and add session protocol sipv2 as well.

You should also have inbound dial peer for calls from CUCM and bind the same with Gig 0/0 interface.

Please check if this is inline with your existing configuration as you said you already have H.323 E1 as well.

- Vivek 

View solution in original post

8 Replies 8

Vivek Batra
VIP Alumni
VIP Alumni

Since there is no response from provider, CUBE is sending 408 Request Timeout back to CUCM.

Please check couple of things like connectivity to provider, using correct interface for signaling and media and correct number in Request-URI and From field. If it doesn't help, please share CUBE config.

- Vivek

Hi Vivek,

Thanks for the swift response. Yes I have connectivity to the provider. what will be the interface for signalling and media? Will it be the one that connects to the CUCM or the interface to the provider?

Seems Gig0/0 interface is used to get traffic from CUCM, correct?

Which interface you want to use to send SIP traffic to provider, Gig0/1 or 0/2?

- Vivek

yes G0/0 is used to get traffic to the CUCM

The interface I want to use to send traffic to provider is G0/2.

I actually just changed it on the outgoing dial peer to source traffic from the G0/2 and the call was successful.

can you explain why this is needed?

Well if you look at SDP body, you will see that INVITE was sourced from Gig0/0 and incorrect media address and in result, it may not be reaching to provider or provider ignoring the same. This has been rectified by binding the dial peer with correct interface.

Although call is successful now, I will suggest you to use separate dial peers in inbound and outbound direction and bind it with correct interface. This will make the configuration neat and avoid many other issues which may occur otherwise.

- Vivek

Hi Vivek,

Thanks for your detailed answer. I am trying to set up the incoming dial peer for this SIP provider. So essential they are sending the entire 7 digits eg. 612-0279. I created two dial peers, one to catch the digits and then another to translate to the CUC extension. But when i call its ringing and logs is not making much sense.

The other dial-peers in the router need to be reviewed because there is an H323 E1 circuit here as well, but once the SIP is working I will review them.

I have attached the logs with the configs.

As per current config;

dial-peer 403

 This is outbound dial peer towards provider. Seems good.

dial-peer 404

 This is inbound dial peer for incoming calls from provider. You should bind this dial peer with Gig 0/2 interface.

dial-peer 405

 You don't need this dial peer if all incoming calls from provider are simply needed to convert to 6500. Attach the existing translation profile in inbound direction to dial-peer 404 which will convert the called number to 6500.

dial-peer 402

 If this is the dial peer you want to use to route the call to CUC extension, bind this dial peer with Gig 0/0 and add session protocol sipv2 as well.

You should also have inbound dial peer for calls from CUCM and bind the same with Gig 0/0 interface.

Please check if this is inline with your existing configuration as you said you already have H.323 E1 as well.

- Vivek 

Thanks Vivek,

It worked perfectly, I hope to gain your knowledge on SIP one day :).

I noticed an issue when the incoming call gets answered by the auto-attendant. When the extension is dialed, i don't hear a ring back but the phone rings and the call connects fine.

I have attached the logs for both ccsip message and debug ccapi inout along with my running configurations. If you are able to see anything let me know, not sure if the SIP provider will need to make changes.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: