cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
60910
Views
155
Helpful
74
Comments
Ayodeji Okanlawon
VIP Alumni
VIP Alumni

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.

74 Comments
Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Hi,

Please open a new thread in the IPT section of the forum, so you can get better help.

Thanks

Hey Deji, it has been a long time...I hope everything is fine with you!

Let me put a new scenario. I'm deploying a new site which I have a CUBE/DMZ area with only one interface behind a Firewall which will be NAT traffic from Internet/ITSP to the only interface/private IP we have in the CUBE. And the CUBE/DMZ using same interface will be talking to the corp network CUCM.

So, no bind will be needed. However, do you see any problem on that?

As always nice post. Thank you, Gustavo!

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Gustavo,

Long time, I am good thank you, How are you my friend?

Well NAT/DMZ alone could give you tons of issues :)

Second thing even if you are using a single interface to connect to your ITSP, you will still need a bind statement. This is because the CUBE is most likely to have more than a single interface on the router. Without the bind statement it will source its sip signalling from the closest interface to the sip traffic which may not be your intended interface

I'm good too my friend. It is always good to hear from you. Sorry for delay, I was on vacation...

You've mentioned having single interface wouldn't need a bind. Anyway, I setup with no bind and about the interfaces not sure how I would be able to use two interfaces as I have zero trust architecture in place and sharing internet circuit for both internet and voice/PSTN services.

Anyway, everything is working fine even with no bind and having FW/NAT/DMZ to ITSP :-)

Do you have that document saying Cisco recommends having two interface for security purposes?

Ochieng2006
Level 1
Level 1

Did you add CUBE as a VoIP provider in Digium Switchvox?

razor3105
Level 1
Level 1

Man... Excellent explanation. I was always wondering what the second line in the invite (Via: SIP/2.0/UDP 192.168.10.5:5060;branch=z9hG4bK2C9207D) was really referring to. 

Via refers to the interface where the traffic originates or is sourced from. Thank you.

miket
Level 5
Level 5

I was wondering when you create an H323 gateway and a SIp trunk will the bind on the local interface interefer with each other?

razor3105
Level 1
Level 1
I don't see how this could be a problem. H.323 signaling will only handle
H.225 and H.245, while SIP will only deal with SIP. Using the same
associated interface will not interfere or conflict with either process.
dineshshoba
Level 1
Level 1

Good document. Well explained. 

 

Can you also help me out for the below scenario.

CUCM - SIP -CUBE - SIP - ITSP

CUCM - CUBE -> configured the lan interface. Done the binding in the dial-peer

CUBE - ITSP -> configured the WAN interface. Done the binding in the dial-peer

 

Problem here is, the invite to the ITSP is going with the WAN interface and that should be the normal case.

 

But the ITSP is expecting the invite from our Public IP address which is different from our WAN int IP Address.

 

What could be the solution to resolve this issue. NATing needs to be done between my WAN interface IP and the Public IP ?

ccm@dm1n1
Level 1
Level 1

Hello,

Great write up!

I found this post after already having worked through a similar issue at one of our a "1-off" locations where we have a dedicated ITSP circuit/interface on the router for SIP service.

I solved the calling issues by binding the PSTN dial-peers individually to the itsp interface and the internal call dial-peers to the LAN subinterface.

 

But I still have another problem. Appreciate any ideas!

 

Also FYI this is for CME not CUBE. 

 

Our Normal branch location:

- The branch CME is trunked to our corp CUCM (SIP) for internal calls to corp CUCM users, and for calls to other branch CME's that route via CUCM SIP trunks to those branch cme's

- Verizon is our SIP provider and our MPLS provider so they can route all our internal and external traffic - so no issues there. Global SIP Bind to CME/Voice vlan sub-interface is all we need

-  all calls, internal to corp and external/PSTN work fine. SIP phones all register fine

 

1-off location with issue:

- No MPLS / No verizon so we have a dedicated ITSP circuit and interface (gi0/2) for SIP trunking

- I binded the PSTN dial-peers to this gi0/2 inf and PSTN calls work fine

- i binded internal calls to corp cucm to the local CME/Voice vlan interface (gi0/0.11) and internal calls work fine to corp and to other cme branches via SIP trunks to corp CUCM

 

ISSUE: we have SIP phones at this 1-off branch that no longer register to CME when I remove the global bind.

- As soon as I enter the global bind under voice service voip > SIP > bind all gi0/0.11 the sip phones register fine again

** But it breaks the PSTN calls. Even tho i still have static SIP binds on the ITSP dial-peers

 

I assumed and would expect, (and thought I read once) that the dial-peer binds would take precedence over the global bind, is this not the case. 

In a perfect world, the phones would use the global bind, while the calls would use their individual/explicit static dial-peer binds.

 

But it seems as soon as i enter global bind, CME ignores the dial-peer binds completely.

Expected behavior?

Any ideas/solutions?

 

thanks!

MJ

ananth1991
Level 1
Level 1

@Ayodeji Okanlawon Appreciate all your posts on this forum.Learned a lot from you.

 

I am having a doubt.It might be silly.But logically i cant understand.

 

Per your example if we bind the local Lan interface for CUCM communication and ITSP link connected port for service provider communication on dial-peers we will have a media like below.

 

192.168.12.190(CUCM) <--> 192.168.10.5(CUBE LAN) <---> 172.29.25.246(CUBE SP Link) <--> 10.205.20.50(ITSP)

 

I cant understand how the communication establishes between GigabitEthernet0/0(LAN) and GigabitEthernet0/2(ITSP link).Whether any local media establishes when inbound and outbound dial-peer matches?

 

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Hi Ananth

 

CUBE will terminate media on both legs of the call.

leg1: CUBE LAN---->rtp----IP Phone

leg2: CUBE SP link--->rtp----ITSP

Cube will bridge these two legs internally .

steveAkerman
Level 1
Level 1

Thanks for this very helpful article.

I appreciate that the thread is old, but have encountered the following anomaly with binding, and would appreciate guidance on how to address it:

 

Initial set up without binding:

Register and ood options work correctly with itsp on WAN interface

 

Add binding:

Register still fine

OOD options are now sent from a high source port (51xxx) and itsp does not reply. Message is identical, the only difference is the source port.

the dial-peer now busies out

 

Is there a workaround for this?

2911 / 15.7

 

michaelrodd
Level 1
Level 1

I'm currently having an issue where TLS is not connecting and I'm binding to a loop ack interface.  I can't find any documentation that states whether or not you can use a loopback for TLS connections.  

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: