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

[Roger Kallberg]

Great suggestion @b.winter 

I like this approach, clean and to the point. Will keep this handy for when needed. ‘(Y)’

[Roger Kallberg]

This could be an option. https://community.cisco.com/t5/ip-telephony-and-phones/dial-peer-and-carrier-id/td-p/2572161

[LibinBenedict]

Hi @b.winter and @Roger Kallberg I will definitely go through the above 2 links and modify my dial-peers accordingly.

However, my main query was reaching the CUCM from CUBE (the routing part) since there are 2 loopback interfaces configured for the 2 sip trunks from CUCM.

As @b.winter mentioned in one of the earlier replies, since I have the route to CUCM and the phone networks via the internal interface (say Gi0), I hope I can use that by sourcing the packets from loopback1 for calls to cluster A and loopback2 for calls to cluster B. Correct me if I am wrong.

Thanks,

Libin Benedict

[b.winter]

Routing the IP packets from CUCM to the loopbacks of the CUBE isn't really done in CUCM or CUBE.

You have to make sure on all the routers in between, that there are routes, the point the IP addresses of the loopbacks towards the CUBE's "internal" interface. So, it has mainly to do with correct IP routing in the network in between.

[LibinBenedict]

Hi @b.winter I went through the post you created, that approach looks interesting.

When I create 2 sip trunk security profiles with different ports than 5060 (my provider supports only 5060), my sip trunk also should use the same ports, correct? Will it affect the signaling since CUBE will listen on only one port?

Thanks,

Libin Benedict

[Roger Kallberg]

You'll need to understand that there are two call legs on an SBC, one internal and another external. The security profiles mentioned in @b.winter post is used on the internal call legs. This has no relevance on the external side, there you still use the port defined by your service provider.

[LibinBenedict]

@Roger Kallberg I understood that part. The internal leg from CUCM to CUBE will use one port and CUBE to ITSP will use another port.

I thought, if I create a SIP trunk security profile with 5560, the sip trunk destination port also should be 5560 which would make CUBE listen on 5560 on the internal leg. That understanding was incorrect.

So, I will create multiple sip trunks with the same destination/port pair, but different incoming ports thru the SIP trunk security profile.

Thanks,

Libin Benedict

[Roger Kallberg]

Okay, then I understand your question. As you mentioned your provider it made the question unclear, at least for me.

In CM you can not have multiple trunks or gateways that uses the same IP and port combination, so for this you would as @b.winter wrote create separate SIP trunk security profiles. Apart from this you would also on the trunk itself define the destination port as the same as the one used in the SIP trunk security profile. See this example for a multi trunk setup that we use between a leaf CM and SME.

As you can see the IPs are the same, but the destination ports are different, and this allows CM to have multiple trunks to the same destination.

[LibinBenedict]

Thanks Roger.

However, I want to make my understanding clear for the CUCM to CUBE trunk.

Since I am trying to achieve multiple trunks with the same destination, I will create separate SIP trunk security profiles with different incoming ports, say 5160 and 5260. Shouldn't I use the destination port in the trunks as 5060 because if I don't, the CUBE will need to listen on additional 2 ports (5160 and 5260) which is not possible? Is this understanding correct?

If the understanding is correct, is there any issue with using one outgoing port and a different incoming port on the same trunk?

Thanks,

Libin Benedict

[b.winter]

But you cannot point 2 (or more) different SIP trunks with 2 different destination ports to CUBE.

Because CUBE has only 1 listening port (1 more for secure calls)

That's why you need to have 2 different SIP Trunk security profiles with different ports (which define the source port of the trunk)

So, then in the SIP trunk configurations, the destination IP and ports are the same, but the source ports (configured in the security profile) are different for each SIP trunk.

The combination in CUCM, to differ the SIP trunks, is:

source port (defined in the SIP trunk security profile) + destination IP + destination port

E.g.

For trunk 1: 5560 (in security profile) + CUBE IP + 5060

For trunk 2: 5561 (in security profile) + CUBE IP + 5060

[LibinBenedict]

Hi @b.winter This clarifies my previous query. Thank you very much.

Thanks

Libin Benedict

[Roger Kallberg]

Got it, thanks for clarifying @b.winter. Learned something today as well. ':-)'