Question about VCS 7.1 Media flow-thru

[Nick Halbert-Lillyman]

We currently have a call path that looks like this:

Endpoint (SIP + H323) > VCS Control > Neighbour zone to VCS-E (SIP + H323) > Firewall > Neighbour zone to CUBE (SIP only).

When the VCS-E interworks SIP to H323 it performs media flow-thru which allows traffic to go through the firewall as it proxies all media and signalling.  However If the call is SIP the whole way, it will proxy the call signalling but not the media.  Right now we have it working, but we need to convert SIP calls to H323 then back to SIP for it to work.

Is there a way to force the VCS-E to proxy all media to the CUBE, rather than just media from interworked calls?  I know that's usually what a traversal zone is for, but as far as I know that won't work when using CUBE to VCS-E.

VCS-E obviously has the hardware and processing capacity to do this (as it's working now via workarounds) so I'm hoping there's a way I can do it a bit more cleanly.

[Tomonori Taniguchi]

Is there any reason for deploying the VCS Control and VCS Expressway with neighbor configuration?

I'm not sure about "I know that's usually what a traversal zone is for, but as far as I know that won't work when using CUBE to VCS-E"...

VCS will handle as non-traversal call for the call between SIP UA and both SIP UA’s have same sip contact address and source IP address.

Therefore if VCS-C able to communicate VCS-E natively, VCS-E possible to see the call from VCS-C as non-traversal call.

If you change link type between VCS-C and VCS-E to "traversal", then VCS-E will treat the all call from VCS-C as traversal call therefore VCS-E will stay in media route.

[Nick Halbert-Lillyman]

Thanks - I've got a traversal zone and neighbour zone set up between the VCS-C and VCS-E but for some reason SIP doesn't work on the traversal zone? (it works fine on the neighbour zone).

As far as why I'm doing this, it's complicated The VCS-C and VCS-E both peer with other things where having a neighbour zone between them is desirable (they are in the same network segment). If I have to use a traversal zone then it means both the VCS-C and VCS-E are using traversal licenses as well as having to proxy all traffic - I'd rather that only the VCS-E and CUBE do this so as to take strain off my VCS-C.

[Tomonori Taniguchi]

We are planning to release next major release software soon which will support media encryption policy.

If you use this feature (enforce disable encryption, force encryption, or have encryption only one side) on specific zone, VCS will stay in media route regardless that is non-traversal or traversal call.

So this could be a possible solution for your deployment without making major change.

[Nick Halbert-Lillyman]

Ah OK.  As we don't use encryption on either side, could we go force encryption on one side then allow either on the other side to achieve this?

[Tomonori Taniguchi]

Any call that sets media encryption policy, the media go through VCS.

So you may enforce “non-encryption” call on both sides and then should works the way you are looking for.

Please note this is supporting plan feature and not commitment of how it works until officially released.

[Nick Halbert-Lillyman]

No problem, thanks for that!

Any idea on time frames for the next release?

[Tomonori Taniguchi]

Should be release it not so long from now.

Sorry I can’t be so specific on release date.

[Martin Koch · Accepted solution]

Hello Nick!

I do not know your deployment, especially that you run a neighbor zone from the

vcs-c to the -e surely works, but you have to know how it behaves to really know why

to use it, and a hack so save licenses is often not the best starting point.

You can set the media routing to latching which will bind the media to the vcs-e.

(this might not work with all  zone types, at least with all zone profiles, but at least with custom it does)

*h xConfiguration Zones Zone [1..1000] Neighbor SIP MediaRouting Mode: 
"Specifies how the VCS handles the media for calls to and from this neighbor, and where it will forward the media destined for this neighbor. Signaled: the media is always taken for calls to and from this neighbor. It will be forwarded as signaled in the SDP received from this neighbor. Latching: the media is always taken for calls to and from this neighbor. It will be forwarded to the IP address and port from which media from this neighbor is received. Auto: media is only taken if the call is a traversal call. If this neighbor is behind a NAT the VCS will forward the media to the IP address and port from which media from this zone is received (latching). Otherwise it will forward the media to the IP address and port signaled in the SDP (signaled). Default: Auto"

you have to figure out the zone id and then enter in the tsh-cli (admin ssh access):

(replace with your number)

xConfiguration Zones Zone  Neighbor SIP MediaRouting Mode: Latching

There are some other options which might be of your interest like setting routed for this zone to always,

custom zone settings or interwork options, I would recommend you look at the command line help and the admin guide

[Nick Halbert-Lillyman]

Martin,

Thanks - that's exactly what I'm looking for!

Saving licenses is really a secondary concern, it's more about design philosophy. It just seems wasteful of network resources to proxy traffic internal to my own network.

[Martin Koch]

Hi Nick!

Thank you for your feedback, voting and setting the thread to answered +5 for this as this is important and helpful!

Short comment, if you ever might have such a call scenario (or parts of it)

endpoint (private ip address or firewalled) <-> vcs-c (not public reachable) <-> vcs-e <-> remote site on internet

in short where the remote site can not directly reach the vcs-e, vcs-c nor the endpoint you would need

to use a traversal zone in between the vcs-c and the vcs-e.

If not there will be most likely failed calls by signaling (especially if somewhere set to optimal) or media.

So really handle that with care!

[Nick Halbert-Lillyman]

Thanks Martin, this particular scenario is all in private IP ranges, there is a firewall but no NAT (it's a direct link between two organisations).

[Nick Halbert-Lillyman]

Well the media latching worked and made the VCS-E proxy all media, unfortunately is caused TIP negotiation to fail to Telepresence Server 8710 (CTS 3010 -> CUCM -> CUBE -> VCS-E -> VCS-C -> Telepresence Server).

It works for all other call scenarios.  Is this something to do with VCS not understanding/translating TIP messaging properly?