Media routing on VCS-E

[Bob Fitzgerald]

Hello!

I'm looking for clarification on something that I thought I knew.  We have a VCS-E (X7.2.2) on a public address, no NAT but we do have the DI option installed.  The VCS-E has both Traversal and non-traversal call licenses.  We also have two endpoints (EX90, C90, both running TC6.1.x software) also on public addresses, no NAT, both registered to the Default Subzone on the VCS-E.  I make a H.323 call from the EX90 to the C90.  I see in the call stats that the call signalling is routed, but the media is also routed and the call is being treated/identified as a Traversal call.  The call signalling makes sense because the VCS-E is configured that way, but why is the media being routed?  And why is it being called a Traversal call?

I see that the call is being routed DefaultSubZone -> DefaultSZtoTraversalSZ -> TraversalSubZone -> DefaultSZtoTraversalSZ -> DefaultSubZone.  Shouldn't the call signalling just go through the DefaultSubZone?  Is this something that happens with the DI option, or is this new in X7.2.x and I'm just missing it in the documentation? 

Thanks!

[Paulo Souza]

Hi Bob,

The call is considered as traversal Call in all these situations:

• firewall traversal calls, where the local VCS is either the traversal client or traversal server
• calls that are gatewayed (interworked) between H.323 and SIP on the local VCS
• calls that are gatewayed (interworked) between IPv4 and IPv6 on the local VCS
• for a VCS with Dual Network Interfaces enabled, calls that are inbound from one LAN port and outbound on the other
• a SIP to SIP call when one of the participants is behind a NAT (unless both endpoints are using ICE for

NAT traversal)

• calls that have a media encryption policy applied
• encrypted calls to and from Microsoft OCS Server 2007 / Lync Server 2010 where the Microsoft OCS/Lync B2BUA is not being used.

As you have dual network interface enable, maybe that is your case. Do you have DI with two interfaces connected or only one of them? Or maybe you have some SIP endpoints behind a NAT.

Another situation for traversal call license usage is, a non-traversal call on a VCS Expressway will consume a traversal license if there are no nontraversal call licenses available (in this situation, the call will remain a non-traversal call — the VCS Expressway will not take the media, even though it is using a traversal license).

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Martin Koch]

Hi though Paulo is not wrong here, the most likely cause is something different

(besides "calls that have a media encryption policy applied", which could be the (additional) reason here.

Thats the normal behavior on h323.

If you have h323 calls on a vcse with locally endpoints using assent / h480.18 the media

will always be bound. During the Tandberg times I made a feature request to have either:

* generic enable / disable it on the endpoint

* by call option on the endpoint

* disable it on the vcs on a registration / zone bases

None made into the VCS nor the Endpoints. SIP is anyhow the more used protocol.

You can completly disable it on the VCS-E, but then it would work more or less as a VCS-C

(which you could also deploy on a public ip for all your public ip endpoints in addition)

So why dont you simply use SIP, that will fix your issue

(though you could have the opposite issue there that you get in trouble if you have a firewalled system on a non nated ip address, ...).

If you still have the media bound on a sip call check the encryption policys for your zones.

[Paulo Souza]

Hi Martin,

Regarding H.323 calls from traversall clients using H460, you posted a curious information, because it is not described on VCS Administrator Guide. The information I posted was taken from VCS Administrator X7.2, page 383. But in the guide, there is no information about what you pointed here.

Of course you have more experience than I have, but could please you post some reference on this information? I am just trying to understanding better your statement, mainly because I guess it is not written in VCS administrator Guide.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Bob Fitzgerald]

Hi Paulo,

Thanks for your reply.  The scenario is just as I described it;

For the VCS-E;

One  NIC connected to a public IP address.  No NAT.  DI option is  installed.  VCS-E has both traversal and non-traversal call licenses available.

For the endpoints;

Both connected to public IP addresses.  No NAT.  Both using H.323.  Both registered to the Default Subzone of the VCS-E.

The call;

One endpoint makes a H.323 call the other by its e.164 alias.  The route the call takes is

DefaultSubZone -> DefaultSZtoTraversalSZ -> TraversalSubZone -> DefaultSZtoTraversalSZ -> DefaultSubZone.

Result:  both call signaling and media are routed through VCS-E.

Hi Martin,

The issue I'm trying to reproduce is for this particular scenario.  What I'm trying to get is an explanation of this behavior, not how to get around it.  From what the documents say about Media Encryption, that should only apply to SIP calls, no?

Thanks!

[Paulo Souza]

Hi Bob,

Following Marting's suggestion, I think you can try to disable H460 globally to see if the problem is resolved. If this changing resolves the issue, so Martin is right with his statement and Cisco documentation is missing some points, I would say.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Bob Fitzgerald]

Hi Paulo,

It's not necessariy a problem.  Putting aside the Assent/H.460 commentary (which shouldn't even be enteing into it with all devices on the same side of the firewall) why is the call being routed through the traversal subzone?

Thanks!

[Justin Ferello]

Bob,

Martin is correct.  I believe when the endpoint registers to the VCS it determines that it will do H460/Assent and therefore all media will be routed all the time.  This is the expected behavior.

Thank you,

Justin Ferello
Technical Support Specialist
KBZ, a Cisco Authorized Distributor
http://www.kbz.com
e/v: justin.ferello@kbz.com