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.

Edit: I recommended using the SIPgw Config Utility in conjunction with this post

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 into 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 into 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.

Let’s 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 your 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 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 a 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 a 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 its own media parameters in the 200OK message.
      Now, consider a situation where both sides (let’s 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.
  1. 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 reasons why you shouldn’t use MTP for your calls, on the 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 are 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 an 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 its 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 a 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 fall back 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.

Build pro IOS configs. FAST.

49 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.

  5. i have avaya pbx which support only h323 & i want to connect with customer through sip trunk i don’t have cucm but i have cisco 38xx router how to do that if possible

    1. Hi Mohamed,
      You sure can.
      You will have to use the CUBE feature to interconnect between SIP and H.323. You will have to configure a set of dial-peers towards your Avaya PBX using H.323 and a set of dial-peers towards your customer using SIP.
      This guide has some good information to start with.
      You can check out this link to see which IOS version you will need and the proper license.

  6. Hi Pasha! Thanks for a great resource!

    We have a CUCM 11.5 system, upgraded several times over the years, starting originally at v4.x. We still have the same VGW as the one we started with, a 2801 router. We use a PRI over fiber to link with our phone provider to the PSTN. Now we are preparing to move to a new building, and our fiber provider will no longer provide a dual media converter as an option to split out ethernet and PRI from the same fiber link. This means we’ll need to migrate from using PRI to a SIP trunk to our phone provider.

    Our Cisco partner said that we’ll need a newer series router to support the SIP trunk to our provider. However, our provider says he has set up SIP trunks with 2801 routers before, so I’m not sure who to believe.

    Can you give me any guidance on the kinds of questions to ask, or how to determine whether in fact I do need to buy a new router to successfully set up a SIP trunk to the equipment of our phone provider?

    Thanks again!

    1. Hi Bryan,
      As always, the answer is – ‘it depends’.
      Basically 2800 series router support CUBE (Cisco’s SBC to connect via SIP to the service provider).
      but you do need the right IOS version and license installed.
      You can see here the required versions and license.
      The thing is 2800 series routers are end of sale and we are already a year and a half past the last date of support, so if you have a fault Cisco won’t be able to help you.
      That also means that you can’t buy the proper license for this router, which is honor based anyway if i remember correctly (just enter the command in the router and you have it).

      Bottom line, 2800 supports SIP Trunking.
      But, if you want your implementation to be supported by Cisco and be covered by their support you gotta have a newer equipment with the proper licensing.
      Does that help?

  7. Hi Pasha, perfect reply for Bryan. I wanted to tell him the same, that the 2800 is eol & eos. Better to use 2900 or 4000 (4321, 4331,…)

  8. Bravo Pasha, 2 years latter and still helpful. Question: I have 2 cubes (supposedly redundant) that I just inherited. They periodically 10 times a day show VoIP SIP dial peers busied out and then return. This happens on BOTH units (not at the same times) to BOTH the long haul peer (over a layer 2 mpls link) AND the local CUCM devices.

    My timers are default:

    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

    voice-class sip options-keepalive up-interval 12 down-interval 65 retry 1

    We get complaints of 1st dial attempt failures, then it works. At it’s random (the paths are not inundated with calls, so we wouldn’t be catching it each time with complaints as a result).

    Thoughts? No errors on either GigE links and I don’t see MPLS errors triggering it. Should I relax my timers?

    Thanks in advance.

    Jon

    1. Hi Jon,
      Thank you for the feedback 🙂

      Regarding the issue you are having, I have tons of questions, but instead of an interrogation i would suggest something else.

      Personally i don’t like guessing, so i would enable the debugs on the CUBE:
      debug ccsip messages & debug ccsip non-call and let it log to buffer.

      It’s important to use logging best practice here and disable logging monitor and config more mem for the logging buffer etc.. you can easily find it on google.
      then just wait for the issue to occur and you’ll have all the details to find the root cause.
      A quick tip here. You can load IOS sip debugs in translatorX to get a more visual representation.
      Anyway, the “retry 1” is a bit harsh. it means that if one sip-options message goes unanswered CUBE would mark the link as down. Unless you know that your network is inch perfect, i would give it some grace.

      Let me know if it helps.

  9. It does and I will enable debugging for that shortly. Thanks for the info on the retry 1. I’ll look on Cisco’s site for process after a failed SIP Option ping message. Do you know off the top of your head how quickly the next message goes out?

  10. Hi Jon,
    It’s actually written in the output that you’ve sent:
    voice-class sip options-keepalive up-interval 12 down-interval 65 retry 1
    so when the link is up it’s sent every 12 seconds, once the link marked as down it sends it every 65 seconds.

  11. Master – is there a way we can enable fail over for the SIP Gateway.
    I have total 5 T1’s
    3T1’s on one Router & another 2 T1’s on another router.
    both Routers are added as SIP trunk on the GW and all works fine. but in case one of my router all the PRI’s are fully utilized or all down. it is not trying to route the calls via second alternate GW.. is there way we can make this working.

    these both GW’s were on h.323. due to some issues we converted to sip.

    1. Hi there,
      Sure, you have to add both of the SIP Trunks to a Route Group, then add the Route Group to a Route List and point the Route Pattern to this Route List.
      Makes sense?

      Pasha

      1. Thanks for your help.
        This is exactly i have this configured. but when my all the T1’s are down on the GW the cucm still the SIP trunk/GW is in up stat and its still trying to send the call to the same GW.

        1. I don’t think the CM has a way of knowing when PRIs are down. It only sees the connection the the gateway and unless the gateway itself is down, it will continue to send calls to it. This is why I still use MGCP for our gateways. MGCP ensures that when any of the PRI’s are unavailable, the call routes to the next available gateway.

  12. Pasha – thanks so much for this guide. I love the attention to detail as well as the way the information is presented. Much more conversational, rather than as a traditional ‘white page.’ Makes it much easier to read without passing out!

    Question – we are working on setting up a DR site, so obviously it will be off campus, and we moved our old 2900 series router to the offsite location and we are currently using a 3925 CUBE in it’s place. My question is, when it comes to setting up the config on the old VG, can I essentially copy most of the running config over, then just make a few small adjustments as well as set up the trunk in CUCM?

    My experience in the UC environment is more tailored to UCCX management/scripting, so this is…new grounds for me.

    Thanks for your time.

    1. Hi Kevin,
      Thank you for the feedback, much appreciated 🙂

      Well, technically, yes.. you can use similar config on the IOS side towards CUCM.
      But if I understood correctly the 2900 router will be used as PRI PSTN GW?
      If so, the outgoing leg towards the provider will be different.. ie using POTS Dial-Peers rather then VOIP.

      Did you get the IOS config guides by email?
      There is one for CUBE and one for PRI GW, you can use it to generate the config, or just as reference.

      Pasha.

  13. I wish I was at work stumbling upon your site. Great info. I hit you up on facebook as well. Based off what i read and looking over the configs that were done on my system its seems I need to tweak some things to make my voip network more resilient. I began by falling into a prebuilt system and have been back tracking all the configs to learn at the same time. I am not settling for a system that JUST works.

  14. Hi Pasha
    I have managed to config the CUBE ISR 4331 as an SIP gateway for FXS port connection.On the test part i have configured 2 extensions in the FXS ports and have done the routing from Gateway side and CUCM side ,the issue i am facing is when i make an call from CUCM side SIP phone to FXS port extension i am not getting ringback tone from the called phone , the FXS port extension is ringing but when picked up it has one way audio , audio path from FXS port to CUCM side phone is not working.could you please help me .
    !
    no aaa new-model
    clock timezone utc 4 30
    !
    !

    subscriber templating
    !
    !
    multilink bundle-name authenticated
    !

    voice call send-alert
    !
    voice service voip
    allow-connections sip to sip
    fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
    sip
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    !
    !
    voice class uri 2 sip
    host ipv4:172.14.14.10
    host ipv4:172.14.14.13
    voice class codec 1
    codec preference 1 g711ulaw
    codec preference 2 g722-64
    !
    !
    !
    voice class server-group 1
    ipv4 172.14.14.10 preference 1
    ipv4 172.14.14.13 preference 2
    !
    voice class sip-options-keepalive 1
    !

    voice-card 0/1
    no watchdog
    !
    voice-card 0/2
    no watchdog
    !
    voice-card 0/4
    no watchdog
    !
    license udi pid ISR4331/K9 sn FDO223109CZ
    diagnostic bootup level minimal
    spanning-tree extend system-id
    !
    !
    !
    username mcitadmin privilege 15 password 0 Mc!t@k@bul
    !
    redundancy
    mode none
    !
    !

    interface GigabitEthernet0/0/0
    ip address 172.14.14.20 255.255.255.0
    negotiation auto
    !
    interface GigabitEthernet0/0/1
    no ip address
    negotiation auto
    !
    interface GigabitEthernet0/0/2
    no ip address
    negotiation auto
    !
    interface Service-Engine0/1/0
    no ip address
    !
    interface Service-Engine0/2/0
    no ip address
    !
    interface Service-Engine0/4/0
    no ip address
    !
    interface GigabitEthernet0
    vrf forwarding Mgmt-intf
    no ip address
    negotiation auto
    !
    ip forward-protocol nd
    ip http server
    ip http authentication local
    ip http secure-server
    ip http client source-interface GigabitEthernet0/0/0
    ip route 0.0.0.0 0.0.0.0 172.14.14.3
    !

    control-plane
    !
    !
    voice-port 0/1/0
    ring frequency 50
    ring cadence pattern01
    !
    voice-port 0/1/1
    ring frequency 50
    ring cadence pattern01
    !
    voice-port 0/1/2
    !
    voice-port 0/1/3
    !
    voice-port 0/2/0
    !
    voice-port 0/2/1
    !
    voice-port 0/2/2
    !
    voice-port 0/2/3
    !
    mgcp behavior rsip-range tgcp-only
    mgcp behavior comedia-role none
    mgcp behavior comedia-check-media-src disable
    mgcp behavior comedia-sdp-force disable
    !
    mgcp profile default
    !

    dial-peer voice 1901 pots
    destination-pattern 1901
    port 0/1/0
    !
    dial-peer voice 1902 pots
    destination-pattern 1902
    port 0/1/1
    !
    dial-peer voice 2 voip
    description incomming calls from CUCM
    session protocol sipv2
    incoming uri via 2
    voice-class codec 1
    dtmf-relay sip-kpml rtp-nte
    no vad
    !
    dial-peer voice 1801 voip
    description outgoing calls to CUCM
    destination-pattern 1801
    session protocol sipv2
    session server-group 1
    voice-class codec 1
    dtmf-relay sip-kpml rtp-nte
    no vad
    !

    1. Hi Regu,

      I see that you are allowing only two codecs g711ulaw and g722,
      I don’t know where the calls are coming from but these codecs should be supported on the other device,
      otherwise, and this is something that might be happening here, an MTP or a transcoder might sneak in the audio path.
      Did you try to consult the One-way audio post?

      Pasha.

  15. Hi Pasha,
    I hope you can help me,
    we are currently doing a sip migration from ISDN,
    I have programmed up new cube,
    and accept the calls from the SIP provider.
    although im unable to get the call to pass onto the CM 11.5
    I’m totally new to this 🙁 but any help is appreciated.
    I dare say im missing phone number translations somewhere to direct to the CM,
    I have copied the config into this forum.
    thanks
    regards
    Paul

    show run
    Building configuration…

    Current configuration : 3413 bytes
    !
    version 15.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    !
    hostname lavvgw002
    !
    boot-start-marker
    boot-end-marker
    !
    !
    enable secret 5 $1$RNqx$fvOhNq/wy1BONvI3pN5GH/
    !
    no aaa new-model
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    ip domain name xx.com.au
    ip name-server 10.3.1.81
    ip cef
    no ipv6 cef
    multilink bundle-name authenticated
    !
    !
    !
    !
    !
    !
    cts logging verbose
    !
    !
    voice-card 0
    !
    !
    !
    voice service voip
    ip address trusted list
    ipv4 10.0.0.0 255.0.0.0
    ipv4 210.193.x.x
    ipv4 210.193.x.x
    address-hiding
    mode border-element
    allow-connections h323 to h323
    allow-connections h323 to sip
    allow-connections sip to h323
    allow-connections sip to sip
    fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
    modem passthrough nse codec g711alaw
    h323
    h225 display-ie ccm-compatible
    h225 id-passthru
    call start slow
    sip
    bind control source-interface GigabitEthernet0/0.20
    bind media source-interface GigabitEthernet0/0.20
    header-passing
    error-passthru
    outbound-proxy ipv4:210.193.x.x
    early-offer forced
    midcall-signaling passthru
    pass-thru content sdp
    !
    voice class codec 1
    codec preference 1 g711alaw
    codec preference 2 g711ulaw
    codec preference 3 g729br8
    !
    !
    voice class sip-profiles 1
    request CANCEL sip-header Max-Forwards modify “.*” “User-Agent: CUBE”
    !
    !
    !
    !
    !
    !
    !
    license udi pid CISCO2901/K9 sn FGL191422HV
    hw-module pvdm 0/0
    !
    !
    !
    username pepperxxx privilege 15 secret 5 $1$ptE9$H7kDBpjiokAhzq.OmwaI3/
    !
    redundancy
    !
    !
    !
    !
    !
    !
    interface Embedded-Service-Engine0/0
    no ip address
    shutdown
    !
    interface GigabitEthernet0/0
    description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
    no ip address
    duplex auto
    speed auto
    !
    interface GigabitEthernet0/0.20
    encapsulation dot1Q 20
    ip address 10.3.20.6 255.255.255.0
    ip pim dense-mode
    h323-gateway voip interface
    !
    interface GigabitEthernet0/1
    ip address dhcp
    duplex auto
    speed auto
    !
    ip default-gateway 10.3.20.1
    ip forward-protocol nd
    !
    no ip http server
    no ip http secure-server
    !
    ip route 0.0.0.0 0.0.0.0 10.3.20.1
    !
    !
    !
    !
    control-plane
    !
    !
    !
    !
    !
    !
    mgcp behavior rsip-range tgcp-only
    mgcp behavior comedia-role none
    mgcp behavior comedia-check-media-src disable
    mgcp behavior comedia-sdp-force disable
    !
    mgcp profile default
    !
    !
    !
    !
    dial-peer voice 1 voip
    description *** Outgoing call . outgoing call leg from CUBE to Broadsoft***
    destination-pattern .T
    session protocol sipv2
    session target ipv4:210.193.xx.xx
    voice-class codec 1
    no vad
    !
    dial-peer voice 2 voip
    description *** CUBE to UC***
    huntstop
    answer-address 0391015981.
    destination-pattern 0391015981.
    media forking
    session protocol sipv2
    session target ipv4:10.3.20.4
    incoming called-number 0391015981.
    voice-class codec 1
    dtmf-relay rtp-nte
    no vad
    !
    !
    gateway
    timer receive-rtp 1200
    !
    sip-ua
    credentials username 039101xxx password 7 0526352611781C50495541425B5E realm domain.com
    retry invite 2
    retry response 3
    retry register 4
    timers expires 300000
    registrar dns:domain.com expires 120
    host-registrar
    !
    !
    !
    gatekeeper
    shutdown
    !
    !
    !
    line con 0
    line aux 0
    line 2
    no activation-character
    no exec
    transport preferred none
    transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
    stopbits 1
    line vty 0 4
    login local
    transport input telnet ssh
    !

    1. Hi Pasha,
      thanks for this,
      I’ve been trying to find the post where it has been moved too with out success.
      thanks
      Regards
      Paul

      1. Hi Paul,
        unfortunately I’m unable to move comments to forum topics, although not a bad idea for a feature 🙂
        You’ll have to register and add a topic in the relevant section.

        1. Hi Pasha,
          No worries,
          I have created new post under the member’s area 🙂
          thank you again.
          regards
          Paul

  16. Hi Pasha,

    What you are publishing is a great content. I love how specific it is to the target audience. I’m hoping that you could help me out with configuring dial-peers with best practice in mind as well as ease to implement across multiple sites. (scalability)

    Here is the scenario:

    We have multiple sites that still have Nortel PBX equipment we are working on a project that will eventually port all of the carrier PRI DID’s to a IPSTN SIP connection from a single carrier, the SBC’s are in place a few of the major sites have been converted. In doing these sites I’m finding weird behavior with the Nortel (propriety) SIP interoperating with standards-based SIP (Cisco) and would like to move to a more uniform architecture.

    Carrier SIPSBCCisco SME(CUCM)SIP to IOS GatewayISDN(PRI)Nortel PBX

    The ISDN interaction with the Nortel equipment works beautifully as this is what they built their platform around.

    What I would like to do is make a configuration as vanilla as possible, basically my goal is to leave all the routing and heavy lifting to be done by my SME cluster, with the IOS gateway solely serving the purpose of a media converter from SIP to ISDN.

    My thoughts were something along the lines of:
    Incoming Dial-peer from SME
    voice class uri 100 SIP
    host ipv4:SME-SUB1
    host ipv4:SME-PUB

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

    Outgoing calls to SME
    dial-peer voice 11 voip
    description outgoing calls to SME
    session protocol sipv2
    session server-group 1 (sme servers)
    voice-class codec 1 voice-class sip options-keepalive profile 1
    dtmf-relay sip-kpml rtp-nte
    no vad

    the POTS dial peers I’m not so sure on: really what I’m after is very basic and easy dial peers that can be applied in any situation, that do this….

    Anything coming in matching my incoming voip dial peer should be sent to the PRI trunk group. And anything coming in form the PRI trunk group should be sent to the outgoing voip dial peer. Since we have 5-digit extensions across the enterprise I was hoping something like this would work.

    Dial-peer voice 100 pots (incoming)
    Trunkgroup
    Description calls from SME to PBX
    Destination-pattern 21[7-9]..
    No digit-strip

    Dial-peer voice 101 pots (outgoing)
    Trunkgroup
    Description calls form PBX to IPSTN via SME
    Destination-pattern 9T
    No digit strip

    Dial-peer voice 102 pots (outgoing)
    Trunkgroup
    Description calls form PBX to SME for internal calls
    Destination-pattern …..
    No digit strip

    My goal ultimately is to not have to define the extension range for a site in the pots dial (100) and make it completely universal and easy to deploy. Then make all routing decisions in the SME rather than the IOS gateway.

    Any help is more than appreciated.

    Cheers,

    Angelo

    1. Hi Angelo,
      Thanks for the feedback, it’s much appreciated 🙂

      It actually seems like you have 99% of this already figured out.
      It’s just a matter of avoiding loops between the dial-peers and this is done with a solid numbering plan.

      The problem here is that 100 and 102 are conflicting.
      I would place the destination pattern 9T on dp 11 instead of 101,
      add another voip dp (similar to 11) for ….
      on DP 102 replace destination patter with Incoming Called Number …..
      and change the destination pattern on 100 to …..

      So in this scenario, a call from SME to PBX:
      DP 11 –> DP 100

      A call from PBX to SME
      DP 102 –> DP 11 (+ another DP for 5 digit dial)

      If there is still a conflict (loop) between 100 and 102, you can just add a prefix on the incoming DP from the PBX and remove it in CUCM or a VOIP DP.

      Hope this makes sense.

  17. I have been tasked to configure a Paxton Net2Entry video call box at a remote site as a SIP device that will work when the WAN is down. This device is currently configured to register with the CallManager but I am not sure how to configure the voice gateway as a SIP server so that the call box can register with it. We have IP speakers that are registered with routers configured as H.323 gateways but the speakers don’t need a password. The Net2Entry does require a password and uses a SIP security profile and an end user to authenticate.

    Do you have any ideas suggestions to get this to work with the ISR as a SIP UA?

  18. Hi Osvaldo,
    Are you looking for a permanent registration solution or just as a backup when the WAN is down?

Leave a Reply

Your email address will not be published. Required fields are marked *