Video via Inter-Cluster Trunk with MTP Required

[Mortaza Rohani]

Hi,

I have 2 CUCM 12.5su2 which are connected through MTP enabled sip trunks.

Side A does have a Hardware MTP and Side B uses CUCM built-in MTP but we are unable to make video calls.

does it need distinct hardware MTP for Side B CUCM also?

here is side A MTP status while call in ongoing:

[b.winter]

CUCM MTP only supports audio (a-law and u-law), so you need a hardware MTP, that supports video codecs.

BTW: why do you need MTP's anyway?

[Roger Kallberg]

As already asked by @b.winter why are you in forcing a MTP into the stream? For an inter-cluster trunk between CMs there should be no need to invoke any MTP.

[Nithin Eluvathingal]

As other member mentioned, why you need to invoke MTP ?

2.12.0.0

[Mortaza Rohani]

Clusters belong to two separate companies and the security unit does not allow IP phones end-to-end access.

Is there another way to proxy the call?

In response to @b.winter, we do have Hardware MTP on Side A Cluster and the attached image is from Side A MTP point.

In the image, RTCP rx counter is zero, what should be the cause?

[b.winter]

For your scenario, I would put a CUBE in between.

Therefore the SIP trunks in both cluster don't point to each other, but instead point to the CUBE.

Which would also pin the media on the CUBE. If you design your codec negotiation well, then you wouldn't even need any transcoding and therefore could also use a virtual CUBE.

Signalling flow would look like this:

Phone 1 <--> CUCM 1 <--> CUBE <--> CUCM 2 <--> Phone 2

Media flow would look like this:

Phone 1 <--> CUBE <--> Phone 2

[Mortaza Rohani]

This solution also has security concerns from the perspective of the security unit. because all the clients from Side B must have access to a device in Side A. while the MTP enabled solution just makes access between two servers, not all the clients.

clusters are from two completely different networks in two countries and we are only allowed for server-to-server access.

what about using separate CUBE in each site? does it cause the below media flow?

Phone1 <--> CUBE in SideA <--> CUBE in SideB <--> Phone 2

[b.winter]

I got your point with the separation of the customer networks.

That's why I said, use CUBE.

In your case, you would have 1 CUBE with 2 configured interfaces.

Interface 1 is pointing to customer networks 1 and interface 2 is pointing to customer networks 2.

Phones and server from customer 1 will only see and communicate with interface 1 (will never see anything beyond that) and the same for customer 2 devices, only see and communicate with interface 2.

Your flow "Phone1 <--> CUBE in SideA <--> CUBE in SideB <--> Phone 2" is just the same like mine, but instead of using 2 interfaces in one CUBE, you have 2 interfaces on 2 CUBEs, which doesn't bring any benefit / isn't needed / for what?

But you could do your flow as well.

Just wanted to give the basic information, that what you probably need is a CUBE in between.

In the end, how exactly you set it up / configure it, is your decision.

[Mortaza Rohani]

Using a single CUBE needs the following firewall access:

all the endpoints in Side B ---> CUBE in side A

while using distinct CUBE in each side cause to this:

CUBE in side a <--> CUBE in side B

because of a large range of RTP ports, the security team rejects case 1 and I had to proxy calls between just two devices like MTP enabled CUCMs or two CUBEs.

In a conclusion, when I use separate CUBEs on each side, I do not need to make "CUCM trunk to CUBE" MTP enabled, and thus no need to hardware MTP for video calls, is it true?

Thanks,

[b.winter · Accepted solution]

You are right, if using only 1 CUBE, it has to be somewhere in customer environment 1 or customer environment 2.

And I get it, that the other side will say "I don't trust it, if the CUBE is not in my environment"

Regarding your conclusion:

No, you won't need any (The built-in function of the CUBE is to behave like a MTP, so to say)

[Roger Kallberg]

I definitely agree with @b.winter advice on that using SBCs (Cube) on both ends is a much better solution than to use MTPs. With SBCs you’ll get a clear demarcation point between the two independent systems that would act as a border between them. From the other system it would only interact with the SBC, anything behind it would be obscured from view.

Think of it in the sense of using a SBC for public phone services, ie PSTN. With this you don’t know anything about what the service provider might have in their network and they don’t know anything about what you have in your network, all communication goes via the SBC.