Cisco SIP Gateway configuration: The Ultimate Guide

Connecting the Cisco IOS Voice Gateway to CUCM via SIP has been the preferred way to do it in the past couple of years.
The slowly dying H323 protocol (ISDN based) is not being developed anymore while SIP (HTTP based) became the industry standard for VoIP. So whenever PSTN connection is implemented via an IOS Voice Gateway, the choice should be really between SIP & MGCP.
This is how it’s done, step by step, using SIP

Problem is, that implementing a Cisco SIP gateway often requires an extra touch, and while widely documented, Cisco SIP Gateway configuration documents often lack the proper structure and context, which makes it very difficult to navigate and find your way to a proper, clean SIP gateway configuration.

In this post, I will do my best to lay down the basics and the advanced topics around Cisco SIP Gateway configuration and implementation.

The implementation of SIP based Voice Gateway is roughly divided to two parts:
1. CUCM SIP Trunk configuration: Build the connection on the CUCM side towards the Cisco SIP Gateway.
2. Cisco IOS SIP Gateway configuration: Configure SIP on the voice router and integrate it with CUCM.

This will also be the structure and order I’ll be using in this post, so let’s get to work.

CUCM SIP Trunk configuration: Build the groundwork

The first step would be to configure the different parameters that we’re going to use in our SIP Trunk. These are divided to few groups:

CUCM Device Pool

Device Pool is a common set of configurations that the SIP Trunk will be using. The Device Pool as the SIP Trunk, has some hierarchy involved, so we’ll need to set up some parameters first.
lets break it down:

CUCM Region- Codec selection

the Region parameter will define the codec preference for our SIP Trunk. Specifically, the codec that will be negotiated between the Cisco SIP Gateway and the device it’s going to talk to (i.e an IP Phone, UCCX, Unity Connection etc.).

The basic rule is: Calls within the same Region should use the best quality codec, calls between Regions should use bandwidth sensitive codec.
The default Intra-Region bandwidth is 64kbps (g.711/g.722), the default Inter-Region bandwidth is g.729 (set in service parameters) so only change it if you specifically have to.
To change the bandwidth go to System–>Region Information–>Region.

CUCM Region
CUCM region

Cisco Unified CM Group

The Cisco Unified Communications Manager Group parameter is the place to choose with which CUCMs the Cisco SIP Gateway is going to work with (signaling wise). Your CM group should be set by now, if it isn’t, now is the time.
go to System–>Cisco Unified CM Group and choose the CUCMs.
If it’s a small-medium implementation with two CUCM nodes, use the CUCM Subscriber first and CUCM Publisher second.

CUCM Media Resource Group List

This is the place to pick all of you media resources that the SIP Gateway will be using. I won’t elaborate too much on Media Resources here, simply consider what the Cisco SIP Gateway will need:
MOH server, Annunciator, Transcoder (specifically if that’s a branch router with limited bandwidth and you have g.711 only devices in HQ).

CUCM Location

Location will define the number of calls available between the Cisco SIP Gateway location and other locations.
Whenever you are using a simple Hub & Spoke topology, check the dedicated VoIP bandwidth from the branch router to HQ (set within the priority queue in the router) and assign the audio bandwidth accordingly. David provides a great video explanation in his course (lecture 35 is free) if you want to dig deeper.
If you have a slightly more advanced inter-site connectivity, you might want to use the Enhanced Location CAC feature.

CUCM Location

The bandwidth calculation for the Location is not the same as configured in the router’s policy-map/Interface, so don’t fall into this trap. While in the Location screen, go to Help–>This Page and set the value based on the proper bandwidth.

After some hard work, we are all set to configure the Device Pool!
Go to System–>Device Pool and create a new Device Pool for our SIP Trunk using the parameters above.

CUCM Device Pool

Two more things we have to prepare before we our trunk can be configured:

CUCM SIP Trunk security profile

The SIP Trunk security profile is something we have to take into account whether we are using a secure SIP/RTP communication or not. I will not elaborate on secure trunks here as it is a full post topic by itself.
The one thing we have to pay attention to with the SIP Trunk security profile is the transport type.
You can set the Incoming Transport Type to accept TCP & UDP or one of them, depends on the amount of hardening you want to apply.
For the Outgoing Transport Type, set either UDP or TCP, just make sure that you set the same session transport type in the Dial Peer.
The default session transport for Dial-Peers is UDP.
Go to System–>Security–>SIP Trunk Security Profile, copy an existing one and update the parameters.

cisco sip trunk security profile

CUCM SIP Profile

SIP Profile is where the SIP magic happens for the SIP Trunk.
With dozens of different options and parameters to play with, it might be a bit intimidating at first but we will keep our focus and stick to the relevant ones.

    •  SIP Rel1XX Options The default for this one is disabled and it’s fine to leave it that way, unless you are having issues related to early media and silence on the line.
      This parameter can help the parties in the call to establish media path and exchange SDP prior to the call being answered.
      Whenever you are running CUCM based Call Queuing, you should set this parameter to Send PRACK if 1XX contains SDP.
  • Early Offer support for voice and video calls is a crucial parameter when shit hits the fan. It sets CUCM’s behavior in regard to using Early & Late Offer and controls the insertion of MTP to the call. It is very important as MTP in the call flow should only be used when absolutely necessary.
    Let’s try to understand what is what before we configure this:

    • Early offer: Is described as situation where the call initiator sends SDP(media negotiation parameters) in the Initial Invite message.
    • Delayed offer: with Delayed Offer the call initiator waits for the called side to send SDP first and then answers with it’s own media parameters in the 200OK message.
      Now, consider a situation where both sides (lets say CUCM and the Cisco IOS SIP Gateway) are configured to use Delayed Offer only. In this case SDP will never be sent thus the call will fail. Not exactly the result that we are after..

CUCM by default will use Delayed Offer on its trunks and let the called side to the set the tone (codecs priorities) for the call.
As mentioned, not all devices and scenarios support this configuration and some modifications might be required in some cases. The options CUCM is offering are such:

  1. Disabled (Default value) – Disables Early Offer; no SDP will be included in the initial INVITE for outbound calls.
  2. Best Effort (no MTP inserted)
    – Provide Early Offer for the outbound call only when caller side’s media port, IP and codec information is available.
    – Provide Delayed Offer for the outbound call when caller side’s media port, IP and codec information is not available. No MTP is inserted to provide Early Offer in this case.
  3. Mandatory(insert MTP if needed) – Provide Early Offer for all outbound calls and insert MTP when caller side’s media port, IP and codec information is not available.

In most cases we should be fine with the default option of Disabled. If you are having an issue and MTP insertion fixes it, i suggest you check the root cause that summed up MTP in the first place as it might be fixed with proper codecs and Prack adjustment.

A question comes to mind here, why not just let the MTP loose and the hell with it?? After all, that is what we’re paying it to do right?? Well, that is very brave of you to ask!
There are several reason why you shouldn’t use MTP for your calls, on exception of very few cases.
1. It changes the RTP media flow. If your MTP is not on the Voice Gateway (it can be.. both SW and HW based), then your CUCM is, which means it’s in the RTP path. And you don’t want that because:
2. Media handling and termination can be CPU intensive, if you have a lot of calls, it is just a very bad practice and trust me, it will come back to haunt you.
3. It shows exactly how damn lazy you are. Patching around instead of taking care of the real problem. A great man once said:

“Man piss at wind and wind piss back”
Unknown Author.

If you really need an MTP, intentionally design it, think it through and possibly delegate it to another device rather then CUCM.
As SIP negotiations and call scenarios is an in depth topic I’ll stop here. If you are having issues with this, by all means, write in the comments below and we’ll do anything we can to help.

  • SIP Options Ping
    one last parameter that we need to understand in the SIP Profile configuration is the SIP Options Ping. This parameter will allow CUCM to monitor the trunk and check whether it is alive or not.
    There are several events that will trigger Out of Service situation:

    • 503 Service Unavailable
    • 408 Timeout
    • Remote SIP device fails to respond.

Cisco IOS SIP Voice Gateway will, by default, respond to SIP Options Ping packets, under the condition that you can pass the security prerequisite.

CUCM SIP ProfileCUCM SIP Profile

CUCM SIP Trunk configuration

After too many words of caution, it’s time to finally configure out SIP Trunk.
This should really be the easy part, so lay back and choose the proper selection from the drop down menu, you deserve it.

Go to Device–>Trunk–>Add New and create a new trunk
Add a Name, Device Pool, Location as configured and described in previous steps.

    • Media Termination Point Required field.
      If you want to override the dynamic MTP mechanism and insert MTP for all calls (not recommended), mark the check-box
      CUCM SIP Trunk
  • Run on all active Unified CM nodes
    This great feature is meant to reduce the number of intra-cluster communication (SDL) that is required to set up a call. To emphasize, without this parameter a call flow will act as follows:
    Phone_A registered to CUCM_A makes a call that should go out to the PSTN via SIP Gateway B configured by the Device Pool to work with CUCM_B.
    In this scenario, all signaling communication will be respectively to the configuration which will require constant CUCM_A to CUCM_B communication for the call.
    Using the Run On All Active Unified CM Nodes parameter will allow any CUCM node to contact the destination SIP Gateway according to the source device of the call. In the scenario above for example, only CUCM_A will be involved in the call.

CUCM SIP Trunk

In the Inbound Calls section, make sure that your CSS has access to internal extensions. A word of advice here, only allow your trunk to access specific dial-plan components (like internal extension or a translation pattern) as this is the place where call loops are born and toll fraud live.

All that is left is just to assign the Destination Address, the SIP Trunk Security Profile that we’ve created and the SIP Profile and we’re done! Well, at least with the CUCM side.

CUCM SIP Trunk

Cisco SIP Gateway

Now that we’re done with CUCM SIP Trunk configuration it’s time to get the job done on the Cisco IOS SIP Gateway.
Like in the CUCM section, we will first configure all of the required parameters and only then apply them to the “Trunk” (Dial-Peers in SIP Gateway’s case).
For the most part, it should really just be matching the parameters to what we’ve configured in CUCM SIP Trunk.

Cisco SIP Gateway: General config

To begin with, we’ll have to set some general settings to prepare the field.

First, let’s allow SIP communication between VOIP dial-peers.
This is not a mandatory command as not all scenarios will require it, but what I’ve found is that eventually i had to enable it for almost all of the Cisco SIP Gateway implementations.

voice service voip
 allow-connections sip to sip

Next step would be to Bind SIP signaling communication to the IP address that we’ve configured in the Destination Address in CUCM SIP Trunk configuration.

voice service voip
 sip
  bind control source-interface GigabitEthernet0/0
  bind media source-interface GigabitEthernet0/0

Cisco SIP Gateway: Codec selection

It’s time to look back at what we’ve configured in the Region section (link back).
What i usually do, is set up a list of codecs, by preference, in the Cisco SIP Gateway and use the CUCM region to decide which codec will be used.
For example, for a branch office i would configure:

voice class codec 1
 codec preference 1 g729r8
 codec preference 2 g711ulaw
 codec preference 3 g711alaw
 codec preference 4 g722-64

In CUCM Region, i would leave the default for Intra-Region (64kbps) and inter-region(8kbps) and would change the Max Bit Rate for specific Regions (like those assigned to fax machines) to 64kbps. This allows the flexibility for the SIP Gateway to use several codecs depends on the device it has to communicate with.

Cisco SIP Gateway: Fax over IP

Fax over IP is an in depth subject and deserves a post of it’s own. Basically you can choose between the more reliable T38 and pass-through which uses the RTP stream to transparently send fax messages over it.
I’ve written about FoIP in the context of CUBE, it should give you a basic understanding of the concepts and pros & cons of each method.

Cisco SIP Gateway: DTMF

In the SIP Trunk: DTMF Signaling Method, we’ve configured no preference, using this method CUCM will try to minimize the usage of MTP while trying to select mutually supported codec.
Roughly, there are two preferred SIP DTMF methods that are widely supported by Cisco devices.

  • Out-of-band (OOB): Sent in the signaling path.
    SIP KPML (Key Press Mark-up Language), defined by RFC 4730 is the preferred and supported method by Cisco.
  • In-band DTMF: sends the DTMF as either raw tones in the RTP media stream or as signaled tones in the RTP payload using RFC 2833.
    RFC 2833 is supported by most VoIP vendors and is the preferred in-band DTMF method by Cisco as well, supported by most of their devices.

For our SIP Trunk, these are the methods we will be using.
In each VOIP dial-peer, we’ll configure:

dial-peer voice 10 voip
  dtmf-relay sip-kpml rtp-nte

OK, now that we’re done with the appetizers, it’s time for the main dish. Dial-Peers here we come!

Cisco SIP Gateway: Dial-Peers

In IOS based SIP Voice Gateways there are two legs for each call. One incoming call-leg and one outgoing call-leg. Call-legs are changing with the direction of the call. For example, for incoming calls from the PSTN, POTS Dial-Peer will be the incoming call-leg while VOIP Dial-Peer will serve as the outgoing call-leg. For calls from CUCM to PSTN, VOIP Dial-Peer will be the incoming call-leg and POTS will be the outgoing.

Dial-peer structure

I use the following structure in my deployments, it’s best practice and makes troubleshooting a whole lot easier.

Incoming Dial-Peer from PSTN
Incoming Dial-Peer from CUCM
Outgoing Dial-Peer to CUCM
Outgoing Dial-Peer to PSTN

The next most important thing you have to deal with is (drums……) Dial-Peer matching. give it quick read and come back here to finish the job.

Now, that you are one step closer to enlightenment, let’s review some examples. I’ll use the following parameters:

DID is 21243XX
Outbound calls are prefixed with a 9
CUCM Pub: 192.168.1.10
CUCM Sub: 192.168.1.11

Incoming Dial-Peer from PSTN
Easiest way to catch all of the traffic coming from PSTN is to match the incoming called-number. I used ANY in this example, but you can set you DID range instead if you wish.

dial-peer voice 1 pots
 description incoming calls from PSTN
 incoming called-number .
 direct-inward-dial

Incoming Dial-Peer from CUCM
Using Incoming uri VIA is a great way to match calls coming from CUCM servers. First, CUCM will always replace the VIA field with its own address (or host). Second, it has the highest priority in dial-peer matching.

voice class uri 2 SIP
  host ipv4:192.168.1.10
  host ipv4:192.168.1.11

dial-peer voice 2 voip
 description incoming calls from CUCM
 session protocol sipv2
 incoming uri via 2
 voice-class codec 1
 dtmf-relay sip-kpml rtp-nte 
 no vad

Outgoing Dial-Peer to CUCM
Nothing fancy here, it’s a good practice to keep the DID structure here with the destination-pattern command

dial-peer voice 10 voip
 description Outgoing calls to CUCM-Sub
 destination-pattern 21243..
 session protocol sipv2
 session target ipv4:192.168.1.11
 voice-class codec 1
 dtmf-relay sip-kpml rtp-nte
 no vad

dial-peer voice 11 voip
 description Outgoing calls to CUCM-Pub
 preference 1
 destination-pattern 21243..
 session protocol sipv2
 session target ipv4:192.168.1.10
 voice-class codec 1
 dtmf-relay sip-kpml rtp-nte
 no vad

Outgoing Dial-Peer to PSTN
Create as many DP as you need for your dial plan. It should look something like this:

dial-peer voice 2 pots
 description Outgoing calls to PSTN - Int
 destination-pattern 9011T
 port 0/0/0:15
 prefix 011

dial-peer voice 3 pots
 description Outgoing calls to PSTN - LD
 destination-pattern 91[2-9]..[2-9]......
 port 0/0/0:15
 forward-digits 10

Basically, we are done here, but i like to tweak some parameters to make things work much smoother:

Cisco SIP Gateway redundancy configuration

If you have 2 or more CUCMs and one of them is down, it’s going to take your SIP Gateway quite a while to fallback to the next Dial-Peer (Dial-Peer 10 to 11 in the example above).
Exactly how long you ask? Well, to find out we need to look at two parameters: Retry count and Timer.
You can check it out running the following commands in your Voice Gateway:

SIP-GW#show sip-ua timers
 SIP UA Timer Values (millisecs unless noted)
 trying 500, expires 180000, connect 500, disconnect 500
 prack 500, rel1xx 500, notify 500, update 500
 refer 500, register 500, info 500, options 500, hold 2880 minutes
 , registrar-dns-cache 3600 seconds
 tcp/udp aging 5 minutes
 tls aging 60 minutes

SIP-GW#show sip-ua retry
SIP UA Retry Values
invite retry count = 6   response retry count = 6
bye retry count    = 10  cancel retry count   = 10
prack retry count  = 10  update retry count    = 6
reliable 1xx count = 6   notify retry count   = 10
refer retry count  = 10  register retry count = 6
info retry count   = 6   subscribe retry count = 6
options retry count = 6

We can see that the default timer is 500ms and the invite retry count is 6.
That means that i would take whole 3 seconds for our SIP Gateway to try our secondary Dial-Peer. For real-time communication that is way off the chart.
Adjust the timers and retry counts based on your network performance. If packet-loss and high delays are not uncommon, leave the config as is. If your network infrastructure is solid, you can drop the retry count by half.

sip-ua
  retry invite 3

To make the timeout even shorter and the operation smoother, you can use the SIP Options Ping on the SIP Gateway side as well. This will allow the Gateway to identify and mark a CUCM node as down and skip dead-end Dial-Peers altogether, until the destination CUCM is up and running.
To enable SIP Options Ping, just add the following command to the VOIP Dial-Peers facing CUCM:

voice-class sip options-keepalive up-interval 30 down-interval 60 retry 5

The following error codes will busy-out the Dial-Peer:

  • 503 – Service Unavailable
  • 505 – SIP Version Not Supported
  • No Response – Request Timeout

Cisco SIP Gateway security configuration

One last thing to note, if you use the Run on all active Unified CM nodes(link back) parameter (and you really should..) and you don’t have all of the CUCM nodes in your Dial-Peers, you must manually add the missing CUCMs to your IP address trust list:

Voice service voip
 ip address trusted list
  ipv4 192.168.1.12
  ipv4 192.168.1.0 255.255.255.0

Final words:
I know that this has been a lot to take, and building a trouble free Cisco SIP Gateway takes some experience, I sincerely hope that this guide will bring you closer to achieving this goal.
I encourage you to ask whatever questions you may have in the comments below.

I mention it in all of my SIP related posts, simply because it made a huge difference for me in my career. Learning the SIP protocol, turned me to something more then the CCIE number i carry. Knowing how to configure a SIP trunk or a Dial-Peer is only half the job. Understanding how SIP works will give you power to perform root cause analysis and make SIP troubleshooting a walk in the park.
There are endless ways to learn SIP, Keith has put up a well structured SIP course that covers critical topics like SIP Registration & Authentication (CUBE), NAT issues (CUBE & Expressway), SDP and troubleshooting.

22 thoughts on “Cisco SIP Gateway configuration: The Ultimate Guide”

  1. I’m having issues with incoming calls, I’m getting a busy signal. I even involved Cisco TAC but they haven’t been able to figure it out. It seems that the SIP gateway is sending a 403 Forbidden message to the ISP

    1. Hi Fernando,

      Can you post the output of debug ccsip messages while the issue occurs?

      1. Hi Pasha, sorry for the late response. We were able to figure that out. it was a parameter that we had on the sip-ua configuration. We had it to use a proxy (or something like that, Cisco TAC figured it out after a couple of more days.) Now, the problem that I have is that the incoming calls are being forwarded to only one Ext#, that’s because the CUBE is reading the INVITE field instead of the TO field on the SIP messages. We were told by Cisco TAC that the only reliable fields to route calls are the PAI and the Request URI. I was reading in some forums that there’s a way to copy the information from TO field to the INVITE field, but I haven’t been able to figure it out.

        Do you have any thoughts or comments? have you seen something like this before?

        Thanks for your help

        1. I tried this (per some forums on Internet):

          voice class sip-profiles 1
          request INVITE sip-header Diversion copy “sip:(.*)@” u01
          request INVITE sip-header To modify “.*@(.*)” “To: <sip:\u01@\1"
          !
          !
          voice class sip-copylist 1
          sip-header Diversion

          The problem here, is that I can't apply this voice classes to the incoming calls from ISP since my dial-peer is pots not voip

        2. Hi Fernando,
          Sure, look into this post.
          Look for the “CUCM: 404 Not Found” section.

          Let me know if it solved your problem.

          1. Hi Pasha,

            Thanks for your quick response.

            I tried what you suggested. but it is doing the same thing. For example:

            I’m calling 1(760)336 3339 (The ISP is sending me only 3339 on the TO field)

            Originally the INVITE field contains 7603121150@xxxx.net

            I think that what CUBE is looking at is 7603121150, I have a dial peer that matches 760312…. and I have a phone with Ext# 1150 so all the calls are being forwarded to Ext# 1150.

            I did a debug after doing the changes you suggested. but now the INVITE and the TO fields have 7603121150, and I think that is why CUBE is sending the calls to 1150 ext

            Let me know if that makes sense.

            By the way, your post is Awesome!! very complete and helped me a lot to get on track with my SIP project.

            Thanks!

          2. Here are the output of the SIP messages:

            Received:
            INVITE sip:7603121150@X.X.X.X:5060 SIP/2.0
            Via: SIP/2.0/UDP 204.86.253.90:5060;rport;branch=z9hG4bK+175aef65294c05c21d8bf8b54bb31ecd1+sip+1+c17f0598
            From: ;tag=204.86.253.90+1+8c207d03+6d651232;isup-oli=62
            To:
            CSeq: 1012813631 INVITE
            Expires: 180
            Content-Length: 178

            Sent:
            INVITE sip:7603121150@X.X.X.X:5060 SIP/2.0
            Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK143A3911
            From: ;tag=1BD5965F-2016
            To:
            Date: Mon, 16 Oct 2017 11:04:56 GMT

          3. Hi Fernando,
            In the message you have copied it seems like the “To” field is empty.
            Since i can’t see the whole picture, lets play the If-Then game, it works like this:
            IF the the “To” field contains the number that you want to send to CUCM
            and you have a proper dial-peer to forward it to CUCM
            and the SIP-REQ-URI always looks like this INVITE “sip:7603121150@X.X.X.X:5060 SIP/2.0”
            THEN this should help:

            voice service voip
            sip
            sip-profiles inbound

            Dial-peer voice 2 voip
            Description Incoming from ITSP
            voice-class sip profiles 2 inbound

            Voice class sip-profiles 2
            request ANY sip-header To copy “sip:(.*)@” u10
            request ANY sip-header SIP-Req-URI modify “7603121150@(.*)” “\u10@\1”

          4. Of course Dial-Peer 2 should be configured to receive all calls from ITSP.
            This should help.

          5. Yes, I don’t know why the TO field is empty here (maybe the copy feature didn’t work) but yes, you’re right the invite field always looks like 7603121150@domain.net, and the to field shows the correct number that I want to dial, and according to Cisco TAC all the dial-peers are fine. So, based on this. I will try again what you suggested and see how it goes. I’ll let you know the outcome in about 15 min.

            Thanks for being so helpful!!

          6. This is driving me crazy!!!!

            it is doing the same thing. here it is what I have:

            voice service voip
            ip address trusted list
            ipv4 CUCM1 IP
            ipv4 CUCM2 IP
            ipv4 CUCM3 IP
            ipv4 SIP ServerIP
            allow-connections sip to sip
            no supplementary-service sip moved-temporarily
            no supplementary-service sip refer
            no supplementary-service sip handle-replaces
            redirect ip2ip
            fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
            no fax-relay sg3-to-g3
            modem passthrough nse codec g711ulaw
            sip
            bind control source-interface GigabitEthernet0/0/1
            bind media source-interface GigabitEthernet0/0/1
            asymmetric payload full
            no update-callerid
            call-route url
            sip-profiles inbound
            no call service stop

            dial-peer voice 2 voip
            description incoming calls from PSTN
            session protocol sipv2
            session target sip-server
            incoming called-number 760336….
            voice-class sip profiles 1 inbound

            dial-peer voice 3300 voip
            description Outgoing calls to CUCM-pub
            preference 1
            destination-pattern 33..
            session protocol sipv2
            session target ipv4:IP of CUCM1
            voice-class codec 1
            dtmf-relay sip-kpml rtp-nte
            no vad

            voice class sip-profiles 1
            request ANY sip-header To copy “sip:(.*)@” u10
            request ANY sip-header SIP-Req-URI modify “7603121150@(.*)” “\u10@\1”

            The calls keep ringing to Ext# 1150 even though I called 760 336 3339

            I also have two more dial-peers pointing to the other two CUCMs exactly the same

          7. Hi,
            Please post the debug ccsip messages for that call.
            I suspect that you don’t have a match for the incoming dial-peer from ITSP

          8. Here it is, hopefully nothing is missing on the copy:

            E
            Syslog logging: enabled (0 messages dropped, 15 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)

            No Active Message Discriminator.

            No Inactive Message Discriminator.

            Console logging: disabled
            Monitor logging: disabled
            Buffer logging: level debugging, 203270 messages logged, xml disabled,
            filtering disabled
            Exception Logging: size (4096 bytes)
            Count and timestamp logging messages: disabled
            Persistent logging: disabled

            No active filter modules.

            Trap logging: level warnings, 198 message lines logged
            Logging to 10.10.50.22 (udp port 514, audit disabled,
            link up),
            16 message lines logged,
            0 message lines rate-limited,
            0 message lines dropped-by-MD,
            xml disabled, sequence number disabled
            filtering disabled
            Logging Source-Interface: VRF Name:

            Log Buffer (200000 bytes):

            677095: Oct 16 12:01:59.112: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
            Received:
            INVITE sip:7603121150@x.x.x.x:5060 SIP/2.0
            Via: SIP/2.0/UDP 204.86.253.90:5060;rport;branch=z9hG4bK+56ce20c1ac6eafe32d9621f54c66ff801+sip+1+c184e5b1
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62
            To:
            CSeq: 837739730 INVITE
            Expires: 180
            Content-Length: 176
            Call-Info: ;method=”NOTIFY;Event=telephone-event;Duration=2000″
            Supported: resource-priority,siprec, 100rel
            Contact: ;isup-oli=62
            Content-Type: application/sdp
            Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            Organization: MetaSwitch
            Max-Forwards: 69
            P-Asserted-Identity: “MACIAS,FERNANDO”
            Accept: application/sdp, application/dtmf-relay

            v=0
            o=- 79521918683133 79521918683133 IN IP4 204.86.253.90
            s=-
            c=IN IP4 204.86.253.90
            t=0 0
            m=audio 29736 RTP/AVP 18 0 101
            a=rtpmap:101 telephone-event/8000
            a=ptime:20

            677096: Oct 16 12:01:59.117: //392897/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Sent:
            SIP/2.0 100 Trying
            Via: SIP/2.0/UDP 204.86.253.90:5060;rport;branch=z9hG4bK+56ce20c1ac6eafe32d9621f54c66ff801+sip+1+c184e5b1
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62
            To:
            Date: Mon, 16 Oct 2017 12:01:59 GMT
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            CSeq: 837739730 INVITE
            Allow-Events: kpml, telephone-event
            Server: Cisco-SIPGateway/IOS-15.5.3.S4b
            Content-Length: 0

            677097: Oct 16 12:01:59.117: //392898/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Sent:
            INVITE sip:7603121150@x.x.x.x:5060 SIP/2.0
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK143E4944
            From: “MACIAS,FERNANDO” ;tag=1C09D142-5F2
            To:
            Date: Mon, 16 Oct 2017 12:01:59 GMT
            Call-ID: 52152069-B1DB11E7-8E549342-33CDD51B@x.x.x.x
            Supported: 100rel,timer,resource-priority,replaces,sdp-anat
            Min-SE: 1800
            Cisco-Guid: 1377076289-2983924199-2387514178-0869127451
            User-Agent: Cisco-SIPGateway/IOS-15.5.3.S4b
            Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
            CSeq: 101 INVITE
            Timestamp: 1508180519
            Contact:

            Expires: 180
            Allow-Events: kpml, telephone-event
            Max-Forwards: 68
            Content-Type: application/sdp
            Content-Disposition: session;handling=required
            Content-Length: 341

            v=0
            o=CiscoSystemsSIP-GW-UserAgent 347 8450 IN IP4 x.x.x.x
            s=SIP Call
            c=IN IP4 x.x.x.x
            t=0 0
            m=audio 9372 RTP/AVP 18 0 100 101
            c=IN IP4 x.x.x.x
            a=rtpmap:18 G729/8000
            a=fmtp:18 annexb=no
            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-15
            a=ptime:20

            677098: Oct 16 12:01:59.131: //392898/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Received:
            SIP/2.0 100 Trying
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK143E4944
            From: “MACIAS,FERNANDO” ;tag=1C09D142-5F2
            To:
            Date: Mon, 16 Oct 2017 19:01:59 GMT
            Call-ID: 52152069-B1DB11E7-8E549342-33CDD51B@x.x.x.x
            CSeq: 101 INVITE
            Allow-Events: presence
            Content-Length: 0

            677099: Oct 16 12:01:59.161: //392898/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Received:
            SIP/2.0 180 Ringing
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK143E4944
            From: “MACIAS,FERNANDO” ;tag=1C09D142-5F2
            To: ;tag=144391~1782f793-79ce-4b6f-a6bd-738fad363d70-50740387
            Date: Mon, 16 Oct 2017 19:01:59 GMT
            Call-ID: 52152069-B1DB11E7-8E549342-33CDD51B@x.x.x.x
            CSeq: 101 INVITE
            Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
            Allow-Events: presence
            Server: Cisco-CUCM10.5
            Supported: X-cisco-srtp-fallback
            Supported: Geolocation
            P-Asserted-Identity: “IT Test”
            Remote-Party-ID: “IT Test” ;party=called;screen=yes;privacy=off
            Contact:
            Content-Length: 0

            677100: Oct 16 12:01:59.162: //392897/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Sent:
            SIP/2.0 180 Ringing
            Via: SIP/2.0/UDP 204.86.253.90:5060;rport;branch=z9hG4bK+56ce20c1ac6eafe32d9621f54c66ff801+sip+1+c184e5b1
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62

            To: ;tag=1C09D170-161A
            Date: Mon, 16 Oct 2017 12:01:59 GMT
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            CSeq: 837739730 INVITE
            Require: 100rel
            RSeq: 524
            Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
            Allow-Events: kpml, telephone-event
            Contact:
            Server: Cisco-SIPGateway/IOS-15.5.3.S4b
            Content-Length: 0

            677101: Oct 16 12:01:59.189: //392897/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Received:
            PRACK sip:7603121150@x.x.x.x:5060 SIP/2.0
            Via: SIP/2.0/UDP 204.86.253.90:5060;branch=z9hG4bK+22e15d3b5a3151a1c63df273872f60311+sip+1+c184e5b5
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62
            To: ;tag=1C09D170-161A
            CSeq: 837739731 PRACK
            RAck: 524 837739730 INVITE
            Content-Length: 0
            Supported: resource-priority, siprec, 100rel
            Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name
            Max-Forwards: 69
            Organization: MetaSwitch

            677102: Oct 16 12:01:59.190: //392897/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Sent:
            SIP/2.0 200 OK
            Via: SIP/2.0/UDP 204.86.253.90:5060;branch=z9hG4bK+22e15d3b5a3151a1c63df273872f60311+sip+1+c184e5b5
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62
            To: ;tag=1C09D170-161A
            Date: Mon, 16 Oct 2017 12:01:59 GMT
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            Server: Cisco-SIPGateway/IOS-15.5.3.S4b
            CSeq: 837739731 PRACK
            Content-Length: 0

            677103: Oct 16 12:02:02.484: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
            Received:
            OPTIONS sip:x.x.x.x:5060 SIP/2.0
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK1c988d30c8c8
            From: ;tag=250472179
            To:
            Date: Mon, 16 Oct 2017 19:02:02 GMT
            Call-ID: 7cfef680-9e51022a-1c965-21411ac@x.x.x.x
            User-Agent: Cisco-CUCM10.5
            CSeq: 101 OPTIONS
            Contact:
            Max-Forwards: 0
            Content-Length: 0

            677104: Oct 16 12:02:02.486: //392899/541730C28E55/SIP/Msg/ccsipDisplayMsg:
            Sent:
            SIP/2.0 200 OK
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK1c988d30c8c8

            From: ;tag=250472179
            To: ;tag=1C09DE6B-793
            Date: Mon, 16 Oct 2017 12:02:02 GMT
            Call-ID: 7cfef680-9e51022a-1c965-21411ac@x.x.x.x
            Server: Cisco-SIPGateway/IOS-15.5.3.S4b
            CSeq: 101 OPTIONS
            Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
            Allow-Events: kpml, telephone-event
            Accept: application/sdp
            Supported: 100rel,timer,resource-priority,replaces,sdp-anat
            Content-Type: application/sdp
            Content-Length: 373

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

            677105: Oct 16 12:02:04.642: //392897/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Received:
            CANCEL sip:7603121150@x.x.x.x:5060 SIP/2.0
            Via: SIP/2.0/UDP 204.86.253.90:5060;rport;branch=z9hG4bK+56ce20c1ac6eafe32d9621f54c66ff801+sip+1+c184e5b1
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62
            To:
            CSeq: 837739730 CANCEL
            Content-Length: 0
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            Max-Forwards: 69
            Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name
            Organization: MetaSwitch
            P-Asserted-Identity: “MACIAS,FERNANDO”

            677106: Oct 16 12:02:04.643: //392897/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Sent:
            SIP/2.0 200 OK
            Via: SIP/2.0/UDP 204.86.253.90:5060;rport;branch=z9hG4bK+56ce20c1ac6eafe32d9621f54c66ff801+sip+1+c184e5b1
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62
            To:
            Date: Mon, 16 Oct 2017 12:02:04 GMT
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            CSeq: 837739730 CANCEL
            Content-Length: 0

            677107: Oct 16 12:02:04.643: //392898/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Sent:
            CANCEL sip:7603121150@x.x.x.x:5060 SIP/2.0
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK143E4944
            From: “MACIAS,FERNANDO” ;tag=1C09D142-5F2

            To:
            Date: Mon, 16 Oct 2017 12:01:59 GMT
            Call-ID: 52152069-B1DB11E7-8E549342-33CDD51B@x.x.x.x
            CSeq: 101 CANCEL
            Max-Forwards: 70
            Timestamp: 1508180524
            Reason: Q.850;cause=16
            Content-Length: 0

            677108: Oct 16 12:02:04.643: //392897/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Sent:
            SIP/2.0 487 Request Cancelled
            Via: SIP/2.0/UDP 204.86.253.90:5060;rport;branch=z9hG4bK+56ce20c1ac6eafe32d9621f54c66ff801+sip+1+c184e5b1
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62
            To: ;tag=1C09D170-161A
            Date: Mon, 16 Oct 2017 12:02:04 GMT
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            CSeq: 837739730 INVITE
            Allow-Events: kpml, telephone-event
            Server: Cisco-SIPGateway/IOS-15.5.3.S4b
            Reason: Q.850;cause=16
            Content-Length: 0

            677109: Oct 16 12:02:04.656: //392898/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Received:
            SIP/2.0 200 OK
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK143E4944
            From: “MACIAS,FERNANDO” ;tag=1C09D142-5F2
            To:
            Date: Mon, 16 Oct 2017 19:02:04 GMT
            Call-ID: 52152069-B1DB11E7-8E549342-33CDD51B@x.x.x.x
            Server: Cisco-CUCM10.5
            CSeq: 101 CANCEL
            Content-Length: 0

            677110: Oct 16 12:02:04.657: //392898/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Received:
            SIP/2.0 487 Request Cancelled
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK143E4944
            From: “MACIAS,FERNANDO” ;tag=1C09D142-5F2
            To: ;tag=144391~1782f793-79ce-4b6f-a6bd-738fad363d70-50740387
            Date: Mon, 16 Oct 2017 19:02:04 GMT
            Call-ID: 52152069-B1DB11E7-8E549342-33CDD51B@x.x.x.x
            CSeq: 101 INVITE
            Allow-Events: presence
            Server: Cisco-CUCM10.5
            Content-Length: 0

            677111: Oct 16 12:02:04.658: //392898/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Sent:
            ACK sip:7603121150@x.x.x.x:5060 SIP/2.0
            Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK143E4944
            From: “MACIAS,FERNANDO” ;tag=1C09D142-5F2
            To: ;tag=144391~1782f793-79ce-4b6f-a6bd-738fad363d70-50740387
            Date: Mon, 16 Oct 2017 12:01:59 GMT
            Call-ID: 52152069-B1DB11E7-8E549342-33CDD51B@x.x.x.x
            Max-Forwards: 70

            CSeq: 101 ACK
            Allow-Events: kpml, telephone-event
            Content-Length: 0

            677112: Oct 16 12:02:04.661: //392897/521484418E4E/SIP/Msg/ccsipDisplayMsg:
            Received:
            ACK sip:7603121150@x.x.x.x:5060 SIP/2.0
            Via: SIP/2.0/UDP 204.86.253.90:5060;rport;branch=z9hG4bK+56ce20c1ac6eafe32d9621f54c66ff801+sip+1+c184e5b1
            From: “MACIAS,FERNANDO” ;tag=204.86.253.90+1+7c3087f6+a6d834d;isup-oli=62
            To: ;tag=1C09D170-161A
            CSeq: 837739730 ACK
            Content-Length: 0
            Call-ID: 0gQAAC8WAAACBAAALxYAAICm1CBzlqRQU27sVI1RDsUSEZIfpr2DnzcQE+YJ+fce@204.86.253.90
            Max-Forwards: 69

          9. Seems that the TO field is empty again, I don’t know why is not being copied. but it shows somwthing like this to: sip:7603121150@x.x.x.x on the sent section, and to:sip:3339@x.x.x.x on the received section. If you have a way for me to send you a txt file with the complete output I think it would be better.

            Thanks!

          10. I have these dial-peers, and I think the call is matching them because if I delete them, I get a busy signal:

            dial-peer voice 3 voip
            description Outgoing calls to CUCM-pub
            destination-pattern 760312….
            session protocol sipv2
            session target ipv4:IP_CUCM1
            voice-class codec 1
            dtmf-relay sip-kpml rtp-nte
            no vad
            !
            dial-peer voice 4 voip
            description Outgoing calls to CUCM-sub
            preference 1
            destination-pattern 760312….
            session protocol sipv2
            session target ipv4:IP_CUCM2
            voice-class codec 1
            dtmf-relay sip-kpml rtp-nte
            no vad
            !
            dial-peer voice 6 voip
            description Outgoing calls to CUCM-sub2
            destination-pattern 760312….
            session protocol sipv2
            session target ipv4:IP_CUCM3
            voice-class codec 1
            dtmf-relay sip-kpml rtp-nte
            no vad

          11. Hi,
            Seems like you destination patterns and incoming called numbers are not inline with the number in the sip-req-uri.
            I suggest you go over this guide, get your dials-peers to properly route the calls by the SIP-REQ-URI (including after the SIP-REQ-URI change after the sip-profile) and use some tools like
            this one to test your profile.

  2. Hi Pasha, I have been reading about SIP more than 1 year. not constantly, but sometimes looking in to CiscoLive presentations, and sometimes in Google. I have never seen a perfect guide like you made. I appreciate your effort. It would help many people. You helped me and made me the sip more interessting. Regards
    Ahmad

    1. Hi Ahmad,
      Thank you so much for the kind words!
      I really appreciate the feedback, it means a lot to me!

  3. Hi Pasha,Hope you doing great.Could you please help me understand whats going on here.

    Ring No answer incoming call from PSTN drop after exact 60 Sec!!. Internal call rings for 120 sec and then gets forwarded to voicemail as per CUCM configuration and I would like to achieve this for incoming PSTN call.

    Call flow: (ITSP) ==SIp trunk—— > (CUBE) ==SIP trunk—–> (CUCM) ——->Sip Phone.

    ITSP —–INVITE —–> CUBE ———–INVITE—->CUCM

    ITSP<—–100 trying—–CUBE

    CUBE <—–100 Trying——CUCM

    CUBE<——-180 Ringing—CUCM

    ITSP CUBE

    Not sure, what causing them to send CANCEL and way exactly at 60Sec ???! Cisco CNS blamed on ITSP which make sense because ITSP sends CANCEL message first.And ITSP blaming on us. Huh!

    Min-SE: 60

    Session-Expires: 1800;refresher=uac

    Max-Forwards: 68

    Content-Length: 242

    Content-Disposition: session; handling=required

    Content-Type: application/sdp

    Much appreciated.Cheers!

  4. Hi Ash,
    How are you doing?

    This is quite an interesting case you have got there 🙂

    It’s kinda hard to tell without seeing the detailed messages in the flow but lets try anyway.

    The first thing i would look for is an “expires” header (not to confuse with “Session-Expires”) in the invite message from the ITSP.
    This header represents the timer for this request, i.e the INVITE request. In other words, for how long this INVITE request is valid. If there was no final response (any non 1xx response) received during this time the INVITE is canceled.
    So this is the first thing that comes to mind.

    The other thing that could give us a good clue is the CANCEL cause code.
    the text in SIP responses is “free text”, what counts is the number that follows.

    It would be really helpful if you could paste the “debug ccsip messages” output from CUBE for the call.

It's time to let us know what's on your mind!