Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

CUBE SIP Media and Signalling Binding to an Interface

VIP Super Bronze

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.

69 Comments
Community Member

I enjoyed that.  Nice work!

Community Member

What if i have the ITSP's interface built on to a Core WAN device and CUBE is inside to the WAN router?

I have two interface on CUBE for physical link level redundancy that connects to the core routing device. Do i need to worry about the bind command on the Gi interfaces of the Cube?

VIP Super Bronze

If I understand you correctly, your ITSP connects to your Core router and not your CUBE? That suggests you have two CUBES....

Can you draw a topology diagram of your networ..

CUCM--sip--CUBE---sip--Core router (cube2)--sip---ITSP?

I am so pleased for your document , really very helpfull

Community Member

Nice post!

You can also bind to the LAN interface and use sip-profiles to re-write SIP and SDP headers!

I really liked the bind command on a per dial-peer basis!! haven't thought about it!

Joan

VIP Super Bronze

Joan,

Interesting..Would you share a sample config of binding to lAN and re-writing sip and SDP headers

Community Member

Sure I can, something like:

!

voice class sip-profiles 100

request INVITE sip-header From modify "<sip:(.*)@192.168.10.5>" "<sip:\1@172.29.25.246>"

request INVITE sip-header Contact modify "<sip:(.*)@192.168.10.5:5060>" "<sip:\1@172.29.25.246:5060>"

response 180 sip-header Replaces modify "192.168.10.5" "172.29.25.246"

response ANY sdp-header Connection-Info modify "192.168.10.5" "172.29.25.246"

response ANY sdp-header Audio-Attribute modify "sendonly" "sendrecv"

request ANY sdp-header Audio-Attribute modify "sendonly" "sendrecv"

request INVITE sdp-header Connection-Info modify "192.168.10.5" "172.29.25.246"

request INVITE sdp-header Session-Owner modify "192.168.10.5" "172.29.25.246"

request INVITE sdp-header Audio-Connection-Info modify "192.168.10.5" "172.29.25.246"

!

!

then you have to apply the sip profile inside the dial-peer to your ITSP:

dial-peer voice 9999 voip

  description International calls to ITSP

  voice-class sip profiles 100

<rest of the config>

Here I was modifying some SDP and SIP headers because the CUBE was behind NAT... You can actually sumarize those rules a little more...

This is a test I did to replace pretty much everything since I ended up wit a lot of headers being modified..

!

voice class sip-profiles 100

request ANY sip-header Replaces modify "192.168.10.5" "172.29.25.246"

response ANY sip-header Replaces modify "192.168.10.5" "172.29.25.246"

request ANY sdp-header Connection-Info modify "192.168.10.5" "172.29.25.246"

request ANY sdp-header Session-Owner modify "192.168.10.5" "172.29.25.246"

request ANY sdp-header Audio-Connection-Info modify "192.168.10.5" "172.29.25.246"

response ANY sdp-header Connection-Info modify "192.168.10.5" "172.29.25.246"

response ANY sdp-header Session-Owner modify "192.168.10.5" "172.29.25.246"

response ANY sdp-header Audio-Connection-Info modify "192.168.10.5" "172.29.25.246"

response ANY sdp-header Audio-Attribute modify "sendonly" "sendrecv"

request ANY sdp-header Audio-Attribute modify "sendonly" "sendrecv"

!

Regards guys!

VIP Super Bronze

Wao! This is a lot of work just to get your media and signalling going out the right interface...dont you think it is better to just configure your bind commands properly and let traffic orignate fromt he right interface and use your sip profiles for much needed tasks

Community Member

I agree, but that was a design constraint... sometimes you have to work with what you have.. Beleive me, I am all about making things easy. However, it is nice to know you have the tools.

Community Member

Hello

Its been a long time since I posted my question and I forgot to follow up. Sorry for that. yes, the ITSP connects to the Core WAN router and not the CUBE directly. Cube is connected to Main distribution frome [MDF] switch. All Ip routing is done in CUBE to vgo ia MDF to reach WAN. I also need to do NAT for the CUBE router's signaling interface. PFA the topology diagram

CUBE Topology.jpg

VIP Super Bronze

Hi, sorry this is late..Perhaps you have already deployed this..

My thoughts..

1. If you bind to loopback interface..can the wan edge router talk to the loopback ip of the CUBE? if it cant then you will have one way audio

2. Does the ITSP not provide an IP to connect to on their network? Shouldnt you have that IP on the wan edge router..Why do you need to NAT

Community Member

Im yet to deploy, got stuck only with this connectivity portion with ITSP and IP routing.

WAN edge can reach the Loopback IP of the CUBE. Still in talks with ITSP whether they would provide a Public IP thats needs to be harded coded to one of the gig interface of CUBE.

I dont have a firewall between the WAN edge and Provider edge, neither internal to WAN edge. Since its MPLS and all the WAN links are for Intranet, the interfaces will be on private IP's. However ITSP would need me to send the signaling to a Public IP of their SIP agent.

Still confused on this... NAT i need for hiding the private IP of CUBE and other devices

VIP Super Bronze

Ok..What you need to do is this...

CUBE router...configure your loopback ip..bind both media and signalling to it...

WAN edge router....Bind media and signalling to the inbound dial-peer that connects to the loopback ip on CUBE

WAn edge router....Bind media and signalling to the outbound dial-peer and inbound dial-peer from ITSP...

CUCM sip trunk--points to ip address of loopback on CUBE

CUBE router-----loopback 0

voice service voip

sip

bind all source-interface loop0

WANedge router (assumin interface as follows)

gig0/0----Local interface that connects to loop0 on cube

gig0/1---WAn interface that connects to ITSP

dial-peer voice 1 voip

description all calls from CUBE

incoming called number .

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

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

dial-peer voice 2 voip

description all calls to CUBE from ITSP

destination-pattern XXXXXX

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

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

dial-peer voice 3 voip

incoming called number yyyyyyy (yyy=your DDI from ITSP)

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

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

dial-peer voice 4 voip

description all outbound calls to ITSP

destination-pattern 9T...or whtever it is

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

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

Summary:

On CUBE..all traffic goes to the loopback..CUCM can reach it and Wan edge router can

on WAN edge...inbound traffic and outbound to CUBE uses interface that can reach the loopback and

outbound traffic uses the WAN interfcae..

Your ITSP shoul provide a public ip to connect to..

This is how your rtp flow will look like

      ipphone--loopback-rtp-cube---rtp--gig/0--WAN edge-----gig0/1--ITSP

Community Member

Hello

So,i read that The WAN edge router will also need to be configured with Dial peers? I dont get the whole picture. Then WAN edge router will also be a broder element and SBC?

VIP Super Bronze

Absolutely, otherwise calls will not even  make it in or out to your ITSP. Your ITSP is going to send sip packets to the WAN edge router..SIP signalling at least..but because they your ITSP cant connect to your internal CUBE you need them to terminate media to the WAN edge router too..

33814
Views
135
Helpful
69
Comments