CUCM-CUBE-ITSP Multiple trunks

[LibinBenedict]

Hi,

I have a CUCM SME cluster that receives calls from 2 different CUCM clusters, say Org Unit A and Org Unit B. The SME cluster is connected to CUBE. I have 2 SIP trunks from the ITSP on the CUBE on 2 different WAN-side interfaces (say, Gi 1 and 2) - one towards ITSP SIP server A and the other to ITSP SIP server B. The idea is to send the Org Unit A calls to ITSP SIP server A and Org Unit B calls to ITSP server B.

So, I am planning to create 2 SIP trunks from CUCM to CUBE for Org Unit A calls and Org Unit B calls.

1) I already have a LAN-side interface (say, Gi0) with an IP address configured on the CUBE which CUCM can reach. Can I use this IP address as the destination with different SIP ports since the destination/port pair should be unique? Does CUBE accept SIP on 2 different ports?

2) If 1) is not possible, I am planning to create 2 loopback IPs on the CUBE for the 2 SIP trunks from CUCM.
Will there be an issue with the return traffic from ITSP because the CUBE will now have 2 routes to CUCM (via loopback1 and 2)? Will control and media binding help here by creating separate dial-peers for Unit A and B calls and binding the loopback interfaces accordingly or will it have to be done on the routing layer itself?
What is the best way to achieve this? (I already have reachability from CUBE to CUCM via the already existing LAN-side interface Gi0).

Sample Diagram for 2) is as below:

 

Thanks,

Libin Benedict

[b.winter]

Solution 1 is not possible, CUBE only can listen on one port for unsecure calls (and an additional port for secure calls)

Using loopback interfaces is a valid scenario.

You also should use separate dial-peers for each "tenant", then in those dial-peers you should set the corresponding bindings.

Are those SIP trunks with registration? If yes, you should check out the configuration with tenants.

There are already dozens of old threads in the forum.

If they are without registration, I would still recommend working with tenants, since it's the current "standard" on how to configure SIP trunks on CUBE.

[LibinBenedict]

Hi @b.winter Yes, they are with registration and I am using voice class tenants towards ITSP.

I am trying to understand how to send the calls to CUCM if I am using 2 different loopback interfaces. Will routing be an issue?

Thanks,

Libin Benedict

[Nithin Eluvathingal]

First option won't work. 

Bind commands should be on the dial-peer level. 

[LibinBenedict]

Hi Nithin,

How will CUBE decide which interface to use to send the call to CUCM? I understand dial-peer bind will help with the sourcing of the interface for media and signaling packets, but will the actual network routing be a problem as there are 2 routes to the CUCM (via Lo1 and Lo2)?

If I create static routes to CUCM, those are 2 equal routes via Lo1 and Lo2.

Or should I create a static route to the CUCM via Gi0 (which is already reachable) and keep the LAN side dial-peer bind with Lo1 and Lo2?

I am not sure whether my queries make sense, please correct if my understanding is incorrect.

Thanks,

Libin Benedict

[b.winter]

Hi,

if the loopback can reach the CUCM address via IP routing, then there shouldn't be a problem.

The packets will source from the loopbacks and travers via the internal interface towards CUCM or the phone networks.

But:

If you can wait till tomorrow, I will post a blog entry about multi tenant configuration on CUBE for such a scenario that you and also others have.

I haven't come up with a better solution then this, nor could anyone else show me a more elegant / better solution yet.

I will post the link to the blog entry here then

[LibinBenedict]

Yes @b.winter the internal interface can reach the CUCM and I will ask the network team to have the loopbacks reach CUCM.

For dial-peer configuration, I am using e164 pattern map to match the called number and dial-peer group to decide which dial-peer to choose to send the calls to CUCM.

Thanks,

Libin Benedict

[Roger Kallberg]

Can you differentiate calls between the two systems, for example by calling numbers or something else? If so you should be able achieve what you ask about without the need for multiple connections from the gateway to SME. I’ll wait for your answer and provide additional details if this is applicable for you.

[b.winter]

Hi @Roger Kallberg,

dial-peer matching based on calling number is not applicable here.

Just think about forward calls (external calls to internal, forward to external), the calling number can be anything.

Therefore, you would have to put something like "incoming calling e164-pattern-map xxx" with the pattern map including "+T" pattern on both incoming dial-peers from CUCM.

Which doesn't give you again, no control to match the right dial-peer.

What he could do, is prefix the called numbers in CUCM and send them to CUBE (e.g. add *90* or *91*) and match the called number based on the prefix (and on CUBE strip the prefix). But that isn't an elegant solution in my opinion.

[Roger Kallberg]

That would be the solution that I would have suggested actually. As it is set on the egress on the SIP trunk from the leaf cluster to SME it is pretty straight forward and then it can be used in the gateway to differentiate between the two SIP trunks.

Alternatively look at other options for inbound dial peer matching could be a viable option.

[LibinBenedict]

Hi @b.winter I am matching the calls as mentioned in my reply above to Roger. I created separate e164 pattern maps for the DIDs of the 2 different clusters. And then used incoming calling e164-pattern-map xxx or incoming called e164-pattern-map xxx accordingly.

Thanks,

Libin Benedict

[b.winter]

As I wrote:

What do you do in case of forwarded calls (external calls to internal, forward to external)? The calling number can be anything then. Matching based on calling number won't work, to really separate the calls. Because normally, you don't want that incoming calls from provider 1, are forwarded back to PSTN via provider 2.

But with matching based on calling number, you will get exactly this.

[LibinBenedict]

Ok, I get it now.

[LibinBenedict]

Yes @Roger Kallberg I can differentiate the calls. For outgoing calls to ITSP, I am using e164 pattern map on inbound CUCM dial-peers for matching calling number and dial-peer group to choose the outbound dial-peer. Similarly, I am using e164 pattern map for matching called number on the ITSP inbound dial-peer and dial-peer group to CUCMs.

Thanks,

Libin Benedict

[b.winter · Accepted solution]

@LibinBenedict:

Check this out:

https://community.cisco.com/t5/collaboration-voice-and-video/multiple-sip-trunks-on-cube-uri-based-dial-peer-matching/ta-p/4562385