cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1044
Views
0
Helpful
11
Replies

SIP trunk registration ISR to CUCM

Jakub Stroinski
Enthusiast
Enthusiast

Having issues with new SIP trunks registering and going into full service

Rebooting CUCM solves the issue and the new SIP trunk comes up, but we cant always reboot CUCM to get a SIP trunk to come up.

Is there anything I can do from the gateway / CUCM to force the registration without rebooting?


Thanks!

11 Replies 11

Rajan
Collaborator
Collaborator

Hi Jakub,

Its worth checking the order of CUCM servers pointed on both sides as it should match the order in which the CUCM group is configured.

HTH

Rajan

Single server setup

Options ping enabled ? If yes, try removing that to see if that helps

Jakub,

What do you mean sip trunk registering? Do you mean using options ping for the trunk to go to full service? Is this a trunk from CUCM to ITSP or Gateway to ITSP?

What cucm version is this?

Please rate all useful posts

CUCM is 10.5.2

We have FXO ports on a remote gateway (remote office) and we have a SIP trunk setup between the Cisco 2901 and CUCM to pass the calls.

The trunk will stay in No Service unless we reboot CUCM. Options PING is currently enabled in the SIP Profile for this trunk

Jakub,

Can you provide us a debug ccsip message and possibly cucm traces.

You can of course disable options ping and I am sure that would help. But to get to the bottom of this issue, we can look at the logs

Please rate all useful posts

I unfortunately would have to bring down the network over there which I cannot since it is a production network.

How does the Option Ping negatively affect the registration?

Why would you bring down the network? Collecting traces or cucm logs doesn't bring down the network. If options ping is enabled and the other party in this case your gateway sends a 503 service unavailable, then cucm will take down the trunk. This is why I want to see the logs.

Please rate all useful posts

Options Ping is still enabled, I think I need to do a reset of the Trunk to apply the changes which would bring it down temporarily. I've attached some logs


Received:
OPTIONS sip:172.23.23.20:5060 SIP/2.0
Via: SIP/2.0/UDP 172.10.10.3:5060;branch=z9hG4bK18641156ecda
From: <sip:172.10.10.3>;tag=1723986784
To: <sip:172.23.23.20>
Date: Fri, 12 Feb 2016 13:56:46 GMT
Call-ID: 73002880-6bd1e49e-15d4-30a0aac@172.10.10.3
User-Agent: Cisco-CUCM10.5
CSeq: 101 OPTIONS
Contact: <sip:172.10.10.3:5060>
Max-Forwards: 0
Content-Length: 0


Feb 12 13:56:46.106: //64/49DE16878041/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.10.10.3:5060;branch=z9hG4bK18641156ecda
From: <sip:172.10.10.3>;tag=1723986784
To: <sip:172.23.23.20>;tag=3BBCF0-A4F
Date: Fri, 12 Feb 2016 13:56:46 GMT
Call-ID: 73002880-6bd1e49e-15d4-30a0aac@172.10.10.3
Server: Cisco-SIPGateway/IOS-15.5.3.M2
CSeq: 101 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 369

v=0
o=CiscoSystemsSIP-GW-UserAgent 6703 25 IN IP4 172.23.23.20
s=SIP Call
c=IN IP4 172.23.23.20
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 172.23.23.20
m=image 0 udptl t38
c=IN IP4 172.23.23.20
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy

Feb 12 13:57:47.167: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:172.23.23.20:5060 SIP/2.0
Via: SIP/2.0/UDP 172.10.10.3:5060;branch=z9hG4bK186f46e754ca
From: <sip:172.10.10.3>;tag=2073983039
To: <sip:172.23.23.20>
Date: Fri, 12 Feb 2016 13:57:47 GMT
Call-ID: 975c0500-6bd1e4db-15db-30a0aac@172.10.10.3
User-Agent: Cisco-CUCM10.5
CSeq: 101 OPTIONS
Contact: <sip:172.10.10.3:5060>
Max-Forwards: 0
Content-Length: 0


Feb 12 13:57:47.171: //65/6E43C6CF8042/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.10.10.3:5060;branch=z9hG4bK186f46e754ca
From: <sip:172.10.10.3>;tag=2073983039
To: <sip:172.23.23.20>;tag=3CAB78-1409
Date: Fri, 12 Feb 2016 13:57:47 GMT
Call-ID: 975c0500-6bd1e4db-15db-30a0aac@172.10.10.3
Server: Cisco-SIPGateway/IOS-15.5.3.M2
CSeq: 101 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 371

v=0
o=CiscoSystemsSIP-GW-UserAgent 6230 7178 IN IP4 172.23.23.20
s=SIP Call
c=IN IP4 172.23.23.20
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 172.23.23.20
m=image 0 udptl t38
c=IN IP4 172.23.23.20
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy

Feb 12 13:58:48.763: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:172.23.23.20:5060 SIP/2.0
Via: SIP/2.0/UDP 172.10.10.3:5060;branch=z9hG4bK187f3c0db148
From: <sip:172.10.10.3>;tag=1887334951
To: <sip:172.23.23.20>
Date: Fri, 12 Feb 2016 13:58:48 GMT
Call-ID: bbb7e180-6bd1e518-15e8-30a0aac@172.10.10.3
User-Agent: Cisco-CUCM10.5
CSeq: 101 OPTIONS
Contact: <sip:172.10.10.3:5060>
Max-Forwards: 0
Content-Length: 0


Feb 12 13:58:48.767: //66/92FAA32D8043/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.10.10.3:5060;branch=z9hG4bK187f3c0db148
From: <sip:172.10.10.3>;tag=1887334951
To: <sip:172.23.23.20>;tag=3D9C14-1924
Date: Fri, 12 Feb 2016 13:58:48 GMT
Call-ID: bbb7e180-6bd1e518-15e8-30a0aac@172.10.10.3
Server: Cisco-SIPGateway/IOS-15.5.3.M2
CSeq: 101 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 371

v=0
o=CiscoSystemsSIP-GW-UserAgent 3968 8389 IN IP4 172.23.23.20
s=SIP Call
c=IN IP4 172.23.23.20
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 172.23.23.20
m=image 0 udptl t38
c=IN IP4 172.23.23.20
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy

Feb 12 13:59:49.432: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:172.23.23.20:5060 SIP/2.0
Via: SIP/2.0/UDP 172.10.10.3:5060;branch=z9hG4bK18a515fde224
From: <sip:172.10.10.3>;tag=851501678
To: <sip:172.23.23.20>
Date: Fri, 12 Feb 2016 13:59:49 GMT
Call-ID: e013be00-6bd1e555-15f5-30a0aac@172.10.10.3
User-Agent: Cisco-CUCM10.5
CSeq: 101 OPTIONS
Contact: <sip:172.10.10.3:5060>
Max-Forwards: 0
Content-Length: 0


Feb 12 13:59:49.436: //67/B723E9738044/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.10.10.3:5060;branch=z9hG4bK18a515fde224
From: <sip:172.10.10.3>;tag=851501678
To: <sip:172.23.23.20>;tag=3E8910-5AE
Date: Fri, 12 Feb 2016 13:59:49 GMT
Call-ID: e013be00-6bd1e555-15f5-30a0aac@172.10.10.3
Server: Cisco-SIPGateway/IOS-15.5.3.M2
CSeq: 101 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 370

v=0
o=CiscoSystemsSIP-GW-UserAgent 3789 883 IN IP4 172.23.23.20
s=SIP Call
c=IN IP4 172.23.23.20
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 172.23.23.20
m=image 0 udptl t38
c=IN IP4 172.23.23.20
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy

Everything looks okay as you can see. I assume the link is in service now. We need to monitor it and look at the logs when the link goes out of service. Rather than rebooting CUCM, collect the logs, then disable options ping

Please rate all useful posts

This is how options ping affect your sip trunk..

SIP OPTIONS Ping

The SIP OPTIONS Ping feature can be enabled on the SIP Profile associated with a SIP trunk to dynamically track the state of the trunk's destination(s). When this feature is enabled, each node running the trunk's SIP daemon will periodically send an OPTIONS Request to each of the trunk's destination IP addresses to determine its reachability and will send calls only to reachable nodes. A destination address is considered to be "out of service" if it fails to respond to an OPTIONS Request, if it sends a Service Unavailable (503) response or Request Timeout (408) response, or if a TCP connection cannot be established. The overall trunk state is considered to be "in service" when at least one node receives a response (other than a 408 or 503) from a least one destination address. SIP trunk nodes can send OPTIONS Requests to the trunk's configured destination IP addresses or to the resolved IP addresses of the trunk's DNS SRV entry. Enabling SIP OPTIONS Ping is recommended for all SIP trunks because it allows Unified CM to track trunk state dynamically rather than determining trunk destination state on a per-node, per-call, and time-out basis.

Please rate all useful posts
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:

Recognize Your Peers