CUBE SIP Media and Signalling Binding to an Interface

[Ayodeji Okanlawon]

Often times this is one of the most misunderstood aspect of a CUBE configuration. This stems from our knowledge of how bind commands work with h323 gateway. Typically when deploying h323 gateway with CUCM we need to configured h323 bind commands on the interface that we will use for h323 traffic.

Once this is defined, this interface IP address is seen on CUCM for the gateway. Hence all h225 signaling and h245 media negotiations will be directed towards this interface.This is good for H323 and doesn't create any issues for us. However this doesn't work the same way on a SIP to SIP CUBE solution. Question is why?

On a traditional H323 to TDM PSTN connection, we only have one leg of VoIP traffic, so all h323 signaling is directed towards that leg. The other leg is a TDM either digital PRI, or Analogue FXO ports. In this setup where we apply signaling and media traffic doesn't need much consideration as it can only be done on one leg of the call.

On a H323 to SIP connection, even though we have two VoIP legs, the leg that usually connects to the PSTN is the SIP leg. In this case we usually apply sip signalling and media to the outside leg that connects to the ITSP..This works okay too without any issues….

However since most people are migrating to a full homogenous SIP solution this becomes very important to know where to apply your sip bind commands. This is because in most deployment, customers typically have two different interfaces. One interface connects to the LAN, and the other Interface connects to the ITSP. In this scenario applying the bind command wrongly on a SIP to-SIP CUBE, has the potential to remove the listener from the external interface and in some cases create a one way audio problems

Lets look at an example to understand this last point

Here is the scenario:

CUCM-----SIP---CUBE---SIP---ITSP

NB: CUCM IP is 192.168.12.190, ITSP 10.205.20.50

CUBE Interface config

interface GigabitEthernet0/0

Decription LAN interface

ip address 192.168.10.5 255.255.255.0

!

interface GigabitEthernet0/2

Decription Connection to ITSP

ip address 172.29.25.246 255.255.255.252

duplex auto

speed auto

voice service voip

sip

bind all source-interface gig0/0

In this example, all sip signaling and media traffic will be sent to gig0/0, the LAN interface on the CUBE. What is wrong with that you may ask…Well a lot!

Let’s look at a sample trace for an outbound call originating from CUCM towards the CUBE..

Received:

INVITE sip:0447014824@192.168.10.5:5060 SIP/2.0

Via: SIP/2.0/TCP 192.168.12.190:5060;branch=z9hG4bK78adb3ecc5092

From: "5399" <sip:5399@192.168.12.190>;tag=1729466~70e9433b-1d79-44ae-9a16-09a52be377c5-30642592

To: <sip:0447014824@192.168.10.5>

Sent:

INVITE sip:0447014824@10.205.20.50:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.10.5:5060;branch=z9hG4bK2C9207D

Remote-Party-ID: "5399" <sip:8065399@192.168.10.5>;party=calling;screen=yes;privacy=off

From: "5399" <sip:8065399@192.168.10.5>;tag=242A3EF4-1315

In this scenario what we see is this…All sip traffic originates and terminates on the LAN interface. Hence when CUBE sends an INVITE to the ITSP it uses the Local LAN interface also. This presents a problem because the ITSP cant talk to CUBE on the Local LAN Interface. In one case I looked at the INVITE didn't even make it to the ITSP because we never got any response from them. This is most likely because the LOCAL interface doesn't have any route to the ITSP network.

Some folks rather than binding on the local interface will bind on the interface facing the ITSP.

The major problem with this is:

CUCM will not accept any sip traffic coming from an IP address that is not configured on its sip trunk.

Lets look at a sample trace..CUCM SIP trunk configured with ip address 192.168.10.5

Received:

INVITE sip:0344556677@172.25.29.246:5060 SIP/2.0

Via: SIP/2.0/TCP 10.10:5060;branch=z9hG4bK78adb3ecc5092

From: <sip: 0447014824@10.205.20.50:5060>;tag=1729466~70e9433b-1d79-44ae-9a16-09a52be377c5-30642592

To: <sip: 0344556677@172.25.29.246>

Sent:

INVITE sip:5399@192.168.12.190:5060 SIP/2.0

Via: SIP/2.0/UDP 172.25.29.246:5060;branch=z9hG4bK2C9207D

From: <sip: : 0447014824@172.25.29.246>;tag=242A3EF4-1315

In this case, we can see that CUBE has sent out on INVITE to Cisco call Manager using the external interface.

The result of this is call failure. This is because CUCM is going to reject the call with “501 service unavailable” due to the fact that the IP address from which sip traffic originates and to which CUBE has indicated it want to receive a response back (through the via header) is not the ip configured on the SIP trunk on CUCM.

How do we then address SIP binds on deployments like this:

There are two ways to address this. The first is

• No SIP BIND COMMANDS AT ALL
  

Don't use sip binds command at all. Yes you heard me, this is because you shouldn't need a SIP bind on SIP to SIP because the IOS on CUBE will source from the interfaces closest to the destination of the SIP packet.

In this scenario without a sip bind, CUBE will receive traffic on the Local interface and will send out INVITE to the ITSP on the ITSP interface and all will be well.

However there are scenarios where this won’t work either.I recently had one of those scenarios.

CUBE was selecting the MPLS interface on the router as the destination closest to CUCM, but because this interface was not the one configured on the sip trunk, CUCM rejected the call.

We then decided to configure this interface on the sip trunk..Everything worked except there was no audio. It turned out that this subnet was not reachable from the IP Phones Subnet. So question is what do we do..If we configure bind on one interface we had issues. When we didn’t, CUBE selected the wrong interface to originate and terminate sip traffic..This brings us to our second method

• USE BIND COMMANDS on DIAL-PEER
  

Example..........

dial-peer voice 15 voip

description outbound dial-peer to CUCM

voice-class sip bind control source-interface GigabitEthernet0/0

voice-class sip bind media source-interface GigabitEthernet0/0

dial-peer voice 1 voip

description inbound from CUCM

voice-class sip bind control source-interface GigabitEthernet0/0

voice-class sip bind media source-interface GigabitEthernet0/0

dial-peer voice 2 voip

description inbound from ITSP

voice-class sip bind control source-interface GigabitEthernet0/2

voice-class sip bind media source-interface GigabitEthernet0/2

dial-peer voice 20 voip

description ***outbound dialpeer to ITSP***

voice-class sip bind control source-interface GigabitEthernet0/2

voice-class sip bind media source-interface GigabitEthernet0/2

In the config above, when traffic originates or terminate from or to CUCM-CUBE, the local interface will be used for both SIP signalling and Media traffic. When calls originate or terminate from ITSP to CUBE the external interface to ITSP will be used.

Sample trace

Received:

INVITE sip:0447014824@192.168.10.5:5060 SIP/2.0

Via: SIP/2.0/TCP 192.168.12.190:5060;branch=z9hG4bK78adb3ecc5092

From: "5399" <sip:5399@192.168.12.190>;tag=1729466~70e9433b-1d79-44ae-9a16-09a52be377c5-30642592

To: <sip:0447014824@192.168.10.5>

Sent:

INVITE sip:0447014824@10.205.20.50:5060 SIP/2.0

Via: SIP/2.0/UDP 172.25.29.246:5060;branch=z9hG4bK2C9207D

Remote-Party-ID: "5399" <sip:8065399@172.25.29.246>;party=calling;screen=yes;privacy=off

From: "5399" <sip:8065399@172.25.29.246>;tag=242A3EF4-1315

What we see here is how things should be..

CUCM sends invite to CUBE on its local interface and CUBE sends INVITE to ITSP on the external interface.

[Keysight.NetworkSupport]

What if we have options ping which does not match any dial-peer and when our side tries to reply it grabs wrong source interface. The other side cannot receive options ping and declares our side down.

And we cant enable global bind address because there are different source interfaces to CUCM and to ITSP?

How to make correct options ping behaviour?

I am running to same behavior explained above, but didn't see any solid solution to this. Any help/recommendation would be appreciated.

[Carl Ratcliffe]

Hi Ayodeji

Excellent post.

When we use CUCM and we have 4 CUCM servers running the CallManager service with run on all active nodes configured on the CUCM SIP trunk to the CUBE then the source address from CUCM could be any one of 4 IP addresses. On your example you use an inbound dial peer from CUCM that just matches 1 IP address.

What is the correct process for the CUBE to then accept the call from any CUCM  ?

1 - As we have outbound dial-peers pointing to the 4 CUCM servers the CUBE automatically accept the inbound call as it has the incoming CUCM IP in its outbound dial-peer

2 - Should we use the voice class URI SIP as somebody has mentioned in this post then have 1 incoming dial peer for the ITSP and 1 from CUCM.

Thanks, Carl Ratcliffe

Preston Lancashire England

[bvanbenschoten]

I'd recommend looking at the voice class URI command to match your inbound CUCM dialpeer.

Also shown are some of the other newer commands added in recent IOS versions (e164 pattern map and server groups)

Example below:

voice class uri FromCUCM1 sip
 !! CUCMCluster1 server IP addresses
 host ipv4:10.xx.xx.01  ! CUCM Server #1
 host ipv4:10.xx.xx.02  ! CUCM Server #2
 host ipv4:10.xx.xx.03  ! CUCM Server #3

voice class server-group 1100
 description CUCMCluster1 Servers - Preference selection low to high (0 to 5)
 ipv4 10.xx.xx.01 port 5060 preference 1  !! example CUCM SUB1
 ipv4 10.xx.xx.02 port 5060 preference 3  !! example CUCM SUB2
 ipv4 10.xx.xx.03 port 5060 preference 5  !! example CUCM PUB
 

voice class e164-pattern-map 1100
  description Calls to CUCMCluster1 - 4 digit dial plan
  e164 ^[2-8]...$

!  -------  CUCM Inbound -------------
no dial-peer voice 1000 voip
dial-peer voice 1000 voip
 description Inbound From CUCMCluster1 - This Gateway <== CUCM
 session protocol sipv2
 incoming uri via FromCUCM1
 voice-class codec 1  
 voice-class sip bind control source-interface GigabitEthernet x/y/z
 voice-class sip bind media source-interface GigabitEthernet x/y/z
 dtmf-relay rtp-nte sip-kpml
 no vad

 !  -------  CUCM Outbound -------------
no dial-peer voice 1100 voip
dial-peer voice 1100 voip
 description Outbound to CUCMCluster1 - This Gateway ==> CUCM
 session protocol sipv2
 session transport tcp
 session server-group 1100
 destination e164-pattern-map 1100
 voice-class codec 1  
 voice-class sip bind control source-interface GigabitEthernet x/y/z
 voice-class sip bind media source-interface GigabitEthernet x/y/z
 dtmf-relay rtp-nte sip-kpml
 ip qos dscp cs3 signaling
 no vad

[Carl Ratcliffe]

Thanks for the information and its something I am definitely going to make use of. The voice class uri, voice class server group and the voice class e164 pattern map give you a lot more control over the CUBE configuration.

If anyone is interested I have found additional examples in a Cisco Lab guide.

https://cisco.app.box.com/v/cube/1/3425875892/22699778971/1

Thanks, Carl Ratcliffe

Preston Lancashire England

[Ayodeji Okanlawon]

Carl,

Bvan has given an excellent answer for this and I am used voice class server groups and e164 pattern maps extensively and they work beautifully. The only thing I would add is this:

To reduce intra cluster SDL signalling, try and use CUCM servers that has a higher percentage of your phones registered to as higher priority .

ex: If you have 4 CUCM servers, A, B, C, D.

And your voice class server groups chooses A as the highest priority. Assuming most of the called endpoints are registered to B. when call is sent to A, then A must send an outbound SDL signal to CUCM server B.

[david.vanherck]

Thanks for this article! This solved my problem: set no bind/media in global voice service voip sip config. On the dial-peers I've set the correct media/bind interface: to CUCM the LAN interface & to ITSP the WAN interface (needs to see answers on SIP OPTIONS with WAN address).

Cheers,

David

[ruudvanstrijp]

Hi,

Is there any way to bind signaling interfaces to dial-peers while calls are active? We have an HSRP redundant CUBE setup that has few moments with no active calls. Even on the standby router it isn't possible to make any bindings. This effectively makes it nearly impossible to add dial-peers to a heavily used CUBE setup!

There must be a way I am overlooking - I cannot believe Cisco would sell ASR's which can have 30000+ concurrent calls but which do not have the possibility to make changes to the configuration while calls are running...

Regards,
Ruud van Strijp

[Hafthor Hilmarsson O'Connor]

Hi Ruud 

From top of my head , you cannot change bind if its global and you have active calls. If you are using  Dial-peer bind then you can just create another dial-peer with the new binds and put the preference in lower order then when you are ready shutdown the one you need to change ( this will force new calls to go through the new peer using the new bind commands , wait for the Active calls to finish ( that are on that dial-peer ) then you can change the orginal dial-peer bind.

[ruudvanstrijp]

Hi Hafthor,

Thanks for your reply! I am indeed trying to add bindings to dial-peers. However, I cannot add control bindings to dial-peers when there are active calls, even if the calls are running over completely different dial-peers and loopback interfaces.

I also tried shutting down the dial-peer I am trying to change before adding/changing the control binding, but I still get the error:

ASR02(config)#dial-peer voice 920 voip
ASR02(config-dial-peer)#shut
ASR02(config-dial-peer)#voice-class sip bind control source-interface SBC902
There are active sip calls
The bind command change will not take effect

Regards,
Ruud

[Hafthor Hilmarsson O'Connor]

Thats why you create a new dial-peer.

i.e.

dial-peer voice 921 voip

voice-class sip bind control source-interface SBC902

Preference 1

.....

dial-peer voice 920 voip

shut

........

wait for the active calls that where going through 920 dial-peer to be completed.

then change the orginal one, and un shut it.

Then you can sh the 921 and delete it after its calls are completed.

[ruudvanstrijp]

The issue I have is that I cannot create a new dial-peer while any calls are running on the CUBE. In my case, I have calls running on dial-peers in the 300-range, on SBC300, SBC301, SBC302 and SBC303 lookback interfaces. So they have nothing to do with this new dial-peer 920 and it's SBC902 interface.

I tried creating a completely new dial-peer 921 and binding it to the dial-peer 920's SBC902 interface, but still it doesn't work because calls are active on other dial-peers:

ASR02(config)#dial-peer voice 921 voip
ASR02(config-dial-peer)#voice-class sip bind control source-interface SBC902
There are active sip calls
The bind command change will not take effect

[Hafthor Hilmarsson O'Connor]

hmm 

I have not run into this before, I would need to take a look at the complete config to beable to comment more on this.

[Joan ma Mauri barbosa]

Hi,

You need to deploy  CUBE Box-to-box redundancy.

There is a Cisco Live Document that is pretty good. From There (since I do not want to take credit lol):

The CUBE box-to-box redundancy HA implementation supports both signaling and media preservation over an HSRP switchover of SIP-SIP calls.

CUBE HSRP configuration follows a specific order of steps, including:

Step 1: Enable CUBE Redundancy

Step 2: Enable Inter-dependency between HSRP and CUBE

Step 3: Configure Inter-device Communication Transport

Step 4: Configure HSRP on the Interfaces

Step 5: Configure HSRP Timers (Optional)

Step 6: Configure the Media Inactivity Timer

Step 7: Configure SIP Binding to HSRP Address

Step 8: Configure Interface Tracking

Step 9: Reload the Routers

Step 10: Point peer PBX/Provider to the CUBE HSRP Virtual Address.

I have a pretty good guide so email and I can share

Cheers

Joan M

[Ayodeji Okanlawon]

This is one of the major issues with the CUBEs. You cant configure new dial-peers when you have active calls and thats not all. Most of the CUBEs both running on ISR and ASR have defects where there are many hung calls and as such even if you do not have any active call, you still cannot add new dial-peers with bind commands. This doesn't not depend on your HA configuration. It affects solutions with box-to-box redundancy.

There are two solutions. One is proactive planning, the other is reactive

1. Proactively configure additional dial-peers at the start of your cube deployment. Configure your cube bind statements as needed and then shut down these additional dial-peers. You can then enable them when you need to in the future

2. The reactive solution is to schedule a maintenance window to reload the CUBE. This will clear all hung calls and will allow you to configure additional dial-peers. At this point you may want to proactively add additional dial-peers because you will need them again in the future

[Christopher Scopa]

This is my first time posting so please forgive any errors.  We are experiencing one way audio issues in our newly implemented SIP platform. I came across this thread and think I may be on the right track as to what is going on. I am very new to Cisco Call Manager as most of my experience has been in the Avaya world. Currently, our organization has multiple phone systems and we will be consolidating shortly. For the sake of this comment, I will talk of our Cisco and Avaya as this is where we are experiencing problems. 

On the west coast, we have a Cisco Call Manager and on the East Coast, Avaya. We have AT&T SIP trunks in both locations. On the west coast is where I think the problem lies. Our connection is as follows:

Call Manager -> CUBE -> ATT SIP RTR (hope that makes sense)

The problem that we are facing is that west coast users can hear east coast but, east cannot hear west. This happens whether the call is inbound or outbound.

here is my config... are we missing something or is there a misconfiguration that you may see?

interface GigabitEthernet0/0/0
 description *** Voice Gateway LAN ***
 ip address x.x.x.x 255.255.255.0
 negotiation auto
!
interface GigabitEthernet0/0/1
 description TO AT&T_Voice ROUTER
 ip address x.x.x.x 255.255.255.248
 negotiation auto
!

!
router eigrp 100
 network x.x.x.x 0.0.0.255
!
ip forward-protocol nd
no ip http server
no ip http secure-server
ip tftp source-interface GigabitEthernet0
ip route x.x.x.x 255.255.0.0 y.y.y.y
ip ssh version 2
!
!

!
!
!
!
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
!
sccp local GigabitEthernet0/0/0
sccp ccm x.x.x.x identifier 1 priority 1 version 7.0
sccp ccm x.x.x.x identifier 2 priority 2 version 7.0
sccp
!
sccp ccm group 1
 associate ccm 1 priority 1
 associate ccm 2 priority 2
 associate profile 1 register MTP_CUBE_SCDC
 associate profile 2 register CFB_CUBE_SCDC
 associate profile 3 register XCODE_CUBE_SCDC
 keepalive retries 5
 switchover method immediate
 switchback method immediate
 switchback interval 15
!
!
!
dspfarm profile 3 transcode
 codec g729abr8
 codec g729ar8
 codec g711alaw
 codec g711ulaw
 maximum sessions 15
 associate application SCCP
!
dspfarm profile 2 conference
 codec g729br8
 codec g729r8
 codec g729abr8
 codec g729ar8
 codec g711alaw
 codec g711ulaw
 maximum sessions 15
 associate application SCCP
!
dspfarm profile 1 mtp
 codec g711ulaw
 codec pass-through
 maximum sessions software 150
 associate application SCCP
!
dial-peer voice 100 voip
 description INBOUND From-CUCM
 session protocol sipv2
 incoming called-number 7T
 voice-class codec 1
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte sip-kpml sip-notify
 no vad
!
dial-peer voice 101 voip
 session protocol sipv2
 incoming called-number [2-9]..[2-9]......$
 voice-class codec 1
 voice-class sip bind control source-interface GigabitEthernet0/0/1
 voice-class sip bind media source-interface GigabitEthernet0/0/1
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 200 voip
 description OUTBOUND to-CUCM-SUB
 preference 1
 destination-pattern [2-9]..[2-9]......$
 session protocol sipv2
 session target ipv4:x.x.x.x.
 voice-class codec 1
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 201 voip
 description OUTBOUND to-CUCM-PUB
 preference 2
 destination-pattern [2-9]..[2-9]......$
 session protocol sipv2
 session target ipv4:x.x.x.x
 voice-class codec 1
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 300 voip
 description OUTBOUND to-ATT
 translation-profile outgoing OUTGOING-WAN
 preference 1
 destination-pattern 7T
 session protocol sipv2
 session server-group 111
 voice-class codec 1
 voice-class sip bind control source-interface GigabitEthernet0/0/1
 voice-class sip bind media source-interface GigabitEthernet0/0/1
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 301 voip
 description INBOUND from-ATT
 preference 2
 session protocol sipv2
 incoming called-number 650.......
 voice-class codec 1
 voice-class sip bind media source-interface GigabitEthernet0/0/1
 dtmf-relay rtp-nte
 no vad
!
!
sip-ua
 retry invite 2
 retry bye 2
 retry cancel 2
 retry register 10