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.
Contents
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.
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.
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.
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.
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.
- 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.
- 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:
- Disabled (Default value) – Disables Early Offer; no SDP will be included in the initial INVITE for outbound calls.
- 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.
- 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.
- 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:
- 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.
- 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 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
- Media Termination Point Required field.
- 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.
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.
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.
This section is master piece, you nailed it
Thanks Bermin,
Appreciate the feedback!
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
Hi Fernando,
Can you post the output of debug ccsip messages while the issue occurs?
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
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
Hi Fernando,
Sure, look into this post.
Look for the “CUCM: 404 Not Found” section.
Let me know if it solved your problem.
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!
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
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”
Of course Dial-Peer 2 should be configured to receive all calls from ITSP.
This should help.
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!!
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
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
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
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!
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
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.
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
Hi Ahmad,
Thank you so much for the kind words!
I really appreciate the feedback, it means a lot to me!
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!
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.
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
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.
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!
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?
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,…)
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
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.
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?
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.
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.
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
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.
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.
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.
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.
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.
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
!
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.
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
!
Hi Paul,
sure, let’s try to see what the problem is.
Let’s move this to the forum, it will be easier to manage.
http://localhost/uccommunity/
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
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.
Hi Pasha,
No worries,
I have created new post under the member’s area 🙂
thank you again.
regards
Paul
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 SIPSBCCisco SME(CUCM)SIP to IOS GatewayISDN(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
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.
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?
Hi Osvaldo,
Are you looking for a permanent registration solution or just as a backup when the WAN is down?