Jabber/Movi clients being relayed (without STUN/TURN)

[Douglas Baggett]

Thanks ahead of time for any help on this.

I was doing a wireshark capture of both the free version of Jabber and the Enterprise version and came across a media routing issue that's rather perplexing.

The client (Movi/Jabber) was on a NAT'd guest network. The destination is an 8510 MCU.

When I fired up the Enterprise version of Jabber on the NAT'd network and proceeded to make a call, I noticed all of my UDP media flows had a destination that was MY expressway (on a different network where the Jabber client was NAT'd, but still local to me and not out on the internet).

When I fired up the free version nof Jabber and proceeded to make a call to the same destination, the media flow UDP was going directly to the 8510 IP address.

I don't have STUN or TURN enabled on my expressway. The call history on our expressway says the call was a SIP call (so it wasn't doing an H.323 to SIP interwork call).

Why would my Enterprise client's UDP media go to our expressway first, but the free version's media route goes directly to the destination?

[Martin Koch]

If you did not enable and use TURN/ICE/STUN this is the expected behaviour if your

JabberVideo client is in a network behind NAT.

TURN/ICE/STUN will do some tests to see if and how media can flow. Without knowing

what might be possible, the VCS-E will only say, media can not be send directly, I have to stay in the media path.

You would also see the same with two clients in the same network behind your NAT.

Without TURN/ICE/STUN both clients will loop traffic through your VCS-E, with  it

it the direct media path should be detectd and flow in between the clients.

So just that you did not configure does not mean that Cisco would follow your example ;-)

I can also fully understand that they want to offload media traffic as much as possible.

If it would be a call from a h323 endpoint registered wo your VCS-E using h.460.18/19

it would for example also always be bound to the VCS-E, even it its a h323-h323 call.

it all depents on how your deployment is.

Btw, media traffic should only flow to the mcu if that one is on a public ip and possibly

registered to your VCS-E. Which would anyhow be a not so common deployment.

So if you want to enable it, check the admin and deployment and firewall guides first.

Please remember to rate helpful responses and identify helpful or correct answers.

[Douglas Baggett]

So you are saying that by enabling ICE/STUN a direct connection between endpoints outside of my expressway is possible, but without ICE/STUN turned on with my clients they will route through my expressway if they are NAT'd regardless of where they are?

I have some additional data as well. I did repeated tests with wireshark using the free Jabber client/service that CISCO offers. Interestingly enough, the direct connection between the NAT'd free client and our hosted 8510 only happened once, subsequent connects went through CISCO's expressway (or whatever they are using for a SIP registrar/ICE/STUN server. I'm wondering how ICE/STUN decides if it needs to use TURN on the expressway because it's obvious that some sort of detection process makes the decision. The head scratcher is that in at least ONE instance during my tests using the free client it routed directly to the externally hosted MCU (which is ideal).

The goal is of course to avoid having external Jabber/Movi clients route media through our expressway on their way to our hosted MCU.

Currently, the hosted MCU is not registered to our expressway. It has a public IP though.