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

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.

65 Comments
New Member

I enjoyed that.  Nice work!

New 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

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

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

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.

New 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

New 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

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

You have no idea how much this helped me. Very good article i has trouble with inbound and outbound calls to/from SIP trunk. The binding on the dial-peers helped me completly.

Thank you so much,Biljana.

New Member

Hi all,

i am in the same situation. and figured out that we also needed to bind it per dial-peer.

only problem we have is how and where is determent where the response to OOD (options ping) is sourced.

we are using cube in HA setup whit a external VIP and a internal VIP.

the ITSP is using OOD to check if the trunk is up, from the inside we do the same. from cucm we check if the trunk is up.

The problem is that the response to OOD is sourced from either the outside VIP or inside VIP. debinding on the bind configuration.

anybody got a clue if it's possible to configure how the cube response to OOD messages ?

regards Ron

New Member

Nice post!

From the post - 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.

 

What if there is only one interface both for the LAN and the ITSP sides? i.e if the ITSP can reach the LAN interface (eg. if the ITSP provides the MPLS circuit as well or similar scenario)

Is it mandatory to have 2 separate interfaces? From the security perspective, however if the nearest interfaces are selected by the sip traffic, the internal interface is not visible to the ITSP/outside. Even if it is visible, how can someone reach the internal interface, as it might not be reachable from the outside interface mostly.

Thanks,

Johns

 

VIP Super Bronze

Hi John,

In a scenario where you have only one interface, you most times don't need to apply any bind command. However if you want to then you should apply the bind command to the single interface under the sip-ua config level.

No it is not mandatory. We only have one interface in my deployment.  With two interfaces, your bind statements needs to be applied at dial-peer level as explained in the blog

New Member

Cisco doc says about 2 separate interface, mainly for security purpose. In the case of only one interface what do we lack?

VIP Super Bronze

Two separate interfaces is better, from a security point of view. If you have a private mpls cloud to the itsp, then you can use a single interface. If you don't have a private cloud then ensure you use two separate interfaces.

New Member

But even in the case of a public network to ITSP, if there is no route between the internal interface and the public one, how can anyone reach the internal interface? What is the security threat?

VIP Super Bronze

In most cases your provide will deploy an edge router that will route between your internal network and their network. One way or another you have to ensure that there is IP routing between the two network. Security wise I am not an expert, but you will have to ensure that your internal network is secured

New Member

ok..Thank you so much. :-)

Nice read btw..

New Member

I have similar project where I have to replace the existing ISDN/PRI PBX with Digium switchvox SIP PBX. The Scenario will be  SIP PBX --------- Cisco IOS Gateway ----------MPLS -------VZB SBC.

**Existing working Scenario is PRI PBX --------Cisco IOS Gateway -------MPLS-----VZB SBC.

 

The existing configuration has the bind statement on "voice service VoIP" configuration to bind the outbound interface on the MPLS side where SIP calls coming. The dial-peer was also configured for VoIP and pots to accept SIP calls from VZB MPLS network.

The question i have here is, what changes I need to include in the Cisco IOS gateway to establish a new sip trunk with Digium Switchvox and make SIP to SIP calls while keeping the same configuration on the VZB SBC side? The above article seem providing me a guidance that I can retest tonight by changing the sip bind configuration at the dial-peer level but I am not sure the Digium SIP PBX will bring up the sip trunk if configured with the internal Cisco IOS gateway private IP (Gi0/2).

Any help on similar project will help me move forward in solving this puzzle and I will appreciate any idea on this. 

 

Planned changes on Dialer-peer configuration to swap the existing POTs dial-peer with SIP PBX-

 

"dial-peer voice 20  voip

 description OUTBOUND Voice SIP 

 translation-profile outgoing DIGITSTRIP-9

 destination-pattern 9T

 rtp payload-type nte 98

 session protocol sipv2

 session target sip-server

 voice-class codec 1  

 voice-class sip early-offer forced

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

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

 dtmf-relay rtp-nte

 no vad

!

 

 

!

 

 

dial-peer voice 501 voip

description switchvox

preference 1

destination-pattern 703456….

voice-class codec 1

session protocol sipv2

session target ipv4:10.1.X.X

session transport tcp

incoming called-number 703456….

forward-digits 4

dtmf-relay rtp-nte 

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

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

 

!

 

dial-peer voice 500 pots

 preference 2

 destination-pattern 703456….

 progress_ind alert strip 8

 direct-inward-dial

 port 0/0/0:23

 forward-digits 4

!

 

dial-peer voice 200 voip

 description voip dial peer - from proxy

 rtp payload-type nte 98

 session protocol sipv2

 session target sip-server

 incoming called-number .T

 voice-class codec 1  

 dtmf-relay rtp-nte

 ip qos dscp cs5 media

 ip qos dscp cs3 signaling

 no vad

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

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

 

!

dial-peer voice 501 voip

description switchvox

Preference 1

destination-pattern 526788….

voice-class codec 1

session protocol sipv2

session target ipv4:10.1.X.X

session transport tcp

forward-digits 4

dtmf-relay rtp-nte 

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

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

 

!

dial-peer voice 502 pots

 preference 2

 destination-pattern 526788….

 progress_ind alert strip 8

 direct-inward-dial

 port 0/0/0:23

 forward-digits 4

 

!

dial-peer voice 551 voip

description switchvox

preference 1

incoming called-number .

voice-class codec 1

session protocol sipv2

session target ipv4:10.1.X.X

session transport tcp

dtmf-relay rtp-nte 

no vad

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

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

!

dial-peer voice 550 pots

 preference 2

 incoming called-number .

 direct-inward-dial

 port 0/0/0:23

!"

 

***Any idea, if i need any configuration to reflect the new SIP PBX under sip-ua configuration other than the above dial-peer change, which is already configured with sip-server of the provider proxy.

 

 

VIP Super Bronze

You should apply the bind statement to the interface that connects to the SIP PBX. If that's gig0/2, then that should be fine. The same applies to the VZB SBC. If the interface is 0/1, then apply the bind statement there too..

I can see that you have changed the payload number for nte to 98. Is this what the SIP PBX is using for nte?

rtp payload-type nte 98

 

This dial-peer (551) is going to create issues for you. This is because all your inbound sip calls including calls from the SBC will match this dial-peer due to the incoming called number .

I am sure you don't want that. You need inbound calls from each call leg to have their signalling matching the correct interface. hence you will need to define specific dial-peers for inbound calls from both pbx and sbc..

dial-peer voice 551 voip

description switchvox

preference 1

incoming called-number .

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

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

New Member

Ayodeji, Thank you for your quick look on the planned configuration change. The rtp payload type nte 98 is towards the providers SBC and I am keeping the existing configuration. I will remove this if it is going to affect the interoperability with the SIP PBX. I will be creating more specific dial-peer for incoming called-number to avoid confusion.

 

New Member

Hi

 

I am trying to find out the relevance of the SIP bind commands when implemented on inbound dial-peers.  I totally get the SIP bind commands relating to outbound dial peers.  I don't understand the point of binding interfaces for SIP on inbound dial peers.  In the network set up above it is the originator of the call (i.e. the sender of the initial INVITE) that chooses the destination IP address on the CUBE for the INVITE packet.  Then surely the CUBE must respond to the INVITE request using that same IP address as the source  of the reply messages (i.e. for the 100 Trying, 180, 200 OK replies).  So why must one configure a bind command on inbound dial peers?

Regards,

Todd

 

PS.  Although I have much SIP experience from a SP (soft switch) side of things, I am a bit new to the way Cisco implement SIP so please excuse me if this is a silly question.

 

 

New Member

I have tested the configuration- I have successfully established outbound calls but inbound calls are failing due to a 407 challenge from the peering SIP Digium Switchvox PBX.

The failure looks on the Digium PBX side due to calls from unknown source. 

 

Let me know, if you have encounter similar interoperability issues.

 

VIP Super Bronze

Gashaw,

Please open a separate thread on the IP telephony forum and you will have enough hands to help on this.

VIP Super Bronze

Hi,

No question is silly but the one that is not asked :)

Having an inbound dial-peer is critical in most scenarios. Look at the call flow below

PBX---sip (fa0/1)----CUBE----sip(fa0/2)---ITSP

Most guys usually define the ff dial-peer for inbound calls..

dial-peer voice 1 voip

incoming called-number .

voice-class codec 1

session protocol sipv2

dtmf-relay rtp-nte 

no vad

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

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

The implication of this is that all your inbound sip signalling will happen on fa0/1.

So what are the issues with this

1. Security: It means that call coming from your ITSP will be routed via the fa0/1 interface even if the INVITE is sent to the ip address of fa0/2. The moment the call arrives on the gateway, the fa0/1 will be used for sip signalling because that's what you have configured.

2. If the fa0/1 interface is not routable from the ITSP point of view, then you have issues.

I recently saw this issue in one of our deployment where the ITSP was complaining that all sip responses was coming from the private interface on our CUBE.

For your scenario it wouldn't e an issue because you are using CCME and as such your  gateway is not really a CUBE. You have an two dial-peers (pots) and voip. Your VoIP dial-peer is facing your ITSP and your pots dial-peer for your ccme registered phones.

However if you have a separate ip interface on that CCME that points else where, then you need to consider how to apply your bind statements and ensure it is applied correctly..

Don't forget to rate the blog is you find it useful!

 

New Member

All the bind commands really only effect the outbound requests from cube.  I think what you might be looking for is a feature added in IOS 15.1

Inbound Dial-peer Match Based on Remote IP Address on SIP Trunks

Voice class is used to match where the SIP invite is coming from.

Voice class is applied on inbound dial peers

This allows 2 dial peers with duplicate clauses < incoming called-number .>   to differentiate between the source of the invite

Based on the source IP will determine the match

 

voice class uri FromATT sip

 host ipv4:12.194.141.181

 host ipv4:12.194.129.85

!        

voice class uri FromCUCM sip

 host ipv4:10.3.90.6

 host ipv4:10.3.90.5

 host ipv4:10.3.90.7

 host ipv4:10.3.90.8

 host ipv4:10.3.90.9

 host ipv4:10.50.90.10

 host ipv4:10.8.78.11

 host ipv4:10.8.78.12

 

dial-peer voice 100 voip

 description Inbound SIP from Call Manager

 session protocol sipv2

 incoming called-number .

 incoming uri via FromCUCM

 

!

dial-peer voice 101 voip

 description Inbound SIP from ATT

 translation-profile incoming In-StripTo7Digits

 session protocol sipv2

 incoming called-number .

 incoming uri via FromATT

Silver

I did a scenario where the ITSP IP address was a loopback on the CUBE and the inside LAN through routing protocols knew about this IP address, and also the CUCM uses this IP address.

Worked very well

 

JH

VIP Super Bronze

JH,

I am not sure I understand your comments. Can you explain better.

Silver

We had a CUBE that was placed behind an MPLS router (MPLS was a 72XX I think)

The MPLS provider also provided SIP trunk. They gave us a /32 address which we put on the CUBE as a loopback interface.

Through redistribution this /32 was know in the inside LAN and also in the network between MPLS router and CUBE.

The callmanager SIP trunk was defined using this /32 IP. On the CUBE all SIP traffic was bound to this loopback interface. The IP addresses on the two Ethernet interfaces didn't play any role in the SIP traffic.

We just had to make sure that all routing devices knew about the /32 network. We achieved that by EIGRP and some static routes.

 

Works fine for 2,5 years now

 

JH

VIP Super Bronze

JH,

I am not sure if this comment is aimed at adding to the blog or correcting something on the blog.

I expect your solution to work as you described since the interface you are binding your sip signalling to is reachable from your ITSP. However most deployments do not use a single interface. Not many people trust their ITSP to give them access to their private LAN. Hence the reason why this blog was written. If we all have a single interface, then we probably wont have a need for this documentation.

You probably will find out in the future you will have requirements that use two different interfaces (private and public) for your deployment and hopefully then you will find this useful..

 

Silver

Hi,

Just adding :)

We have had several scenarios where provider gave us a /32 address and other scenarios where we had the real IP on the outside interface from the CUBE and sometimes we need to bind, sometimes not. Sometimes one interface, sometimes two interfaces.

Think it all depends on the scenario.

 

Thanks!

 

New Member

Hi Ayodeji,

 

Thanks for your reply.  I saw in my customer's production network the situation where the CUBE's matched inbound dial peer has a binding to an IP address that was not the destination of the original SIP INVITE.  In this scenario the SIP client (CME in my case) did not receive a response to the original INVITE.  I am pretty sure it was that the CUBE did not send the response (i.e. 1XX, 2XX..etc), although it may have been blocked by a firewall (am awaiting verification by the customer about their FW rules implemented).

If indeed the CUBE did not respond to the original INVITE it kinda answers my question regarding inbound dial beer with bindings.  Interestingly the CUBE did generate a separate INVITE to the ITSP as the destination phone rang  a couple of times before disconnecting.

 

Thanks,

 

Todd

 

New Member

Hi

Thank you for sharing. This saved me lots of troubleshooting.

Regards,

Tippu1

New Member

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?

VIP Super Bronze

You can apply options ping at the dual-purpose level or under global level. I am not aware of any other place where you can apply it. 

New Member

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?

New Member

Nice article Ayodeji,

I have a scenario i need our opinion on. Its related to SIP and bind commands. I have multiple sites which may have same IP address for phones. Each site has their own call manager. I want to connect all of them together via Cube.

 

I will install cube on each site and a centralized CUCM for Call routing. Cube on each site will have two sip sessions. One towards their own CUCM and one towards the centralized CUCM.

What i am not sure about is the media part. Since there is a chance that the Phone IP address may be same for some sites, I want to terminate IP Phone media session on cube and have a new media session using cube WAN IP towards the destination Cube.

Has anyone done similar setup?

New Member

J.H., would you be able provide an example config from your cube device? We are trying to implement the exact same setup you mentioned: a CUBE on MPLS that provides the SIP on one interface. I'm struggling to understand how to configure the interface(s) on the cube device.

thanks

JD

Silver

Hi,

The config is as follow:

Internal----CUBE---External---FW---MPLS

Internal and external IP's from the CUBE are private IP's. We got from the provider a real /32 IP address what we configured on the CUBE as a loopback. All traffic (internal/external) has to use this real IP. This means that the SIP trunk on the callmanager uses the loopback address and not any of the Ethernet IP's. It requires some routing in the internal network, so that this specific address will not be send to the internet, but to the CUBE's internal Ethernet IP. The same from the outside, traffic to the real IP address must be routed correctly to external IP from the CUBE. On the CUBE all SIP traffic is bound to the loopback. We couldn't use anything else because this IOS was a 12.X and didn't support binding on the dial-peer.

It works perfectly, this customer has a call center that receives around 4500 call per day, and we haven't had any problems with this configuration.

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.

New Member

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

New Member

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

New Member

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

VIP Super Bronze

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.

24773
Views
100
Helpful
65
Comments