Public Default Mediatype Candidate vs Default Media Canidate

[Douglas Baggett]

Any help is GREATLY appreciated!

I'm experiencing some strange behavior in regards to TURN/ICE and Movi/Jabber.

First question: Am I correct in my understanding that Public Default Mediatype Canidate only affects users that are logging into the external server field address (our expressway)?

Should Default MediaType Canidate (not public) be added to our Jabber users who are behind the firewall internally? Or should it just be left off?

I'm in a pretty simple setup (no clustering, one VCS and VCS-E). I'm an internal Movi/Jabber user and register with our Internal VCS-C. I've got the following configured (certain info redacted and or/changed for security reasons)

-----

Bandwidth Prober Auto Scheduling	on
Bandwidth Prober Time	30
ClearPath	on
Default Mediatype Candidate	Rflx
Detect Media Mangling	On
ICE	on
Inviter Contact URI	Test Call <test.call@domain.com>
Maximum In Bandwidth	4000
Maximum Out Bandwidth	4000
Multiway Participant URI	multiway@domain.com
Phone Book Server URI	phonebook@domain.com
Presence Server URI	presence@domain.com
Public Default Mediatype Candidate	Relay
Public SIP Server Address	vcs-e.domain.com
SIP Server Address	vcs-c.domain.com
Tcp Media Relay	Auto
Turn Fallback Timeout	3
TurnAuthPassword	turnpassword
TurnAuthUsername	Turn
TurnServer	vcs-e.domain.com

-----

I have a user at home on FIOS. Their configuration is the same as mine.

Here is where it gets strange....

When I try to make a call to the user at home, I can see him and hear him, but he can't see me. If I change my Default Mediatype Canidate from rflx to relay we are able to talk fine. Problem with this setup is of course that if I set that to relay then my calls to fellow Movi/Jabber users behind the firewall with me end up making relay calls between us which eats up a traversal license.

Why would my host behind the firewall need to use TURN at all? I should be connecting through my VCS-C and then going through the ACCENT tunnel up to my VCS-E and out to the user?

thanks ahead of time for any help

[Gonzalo Gasca Meza]

Hi Doug,

A very interesting problem, I believe you are right in the statement regards:

Public Default Mediatype Candidate.

By looking at the documentation I read:

If you use Default Mediatype Candidate set to >Rflx<

Turn Fallback Timeout will specify the time in seconds after which Jabber Video will give up waiting

for media coming directly from the other client, and fall back to using a TURN relay server for media in your case 3 seconds.

In summary:

Rflx: Public IP address

Relay: Turn Server

For the bad case when you enable Relay internally I would check the following:

a) Confirm Internal users log in to internal VCS-C IP address

b) Compare SDP m lines and see IP address negotiated with Rflx and with Relay.

If using Windows to get logs enable SIP Debug here in Logs.ini:

C:\Users\\AppData\Local\Cisco\JabberVideo\Logs

http://www.cisco.com/en/US/docs/voice_ip_comm/jabber/iPad/Admin_doc/output/b_Jabber_for_iPad_admin_guide_chapter_011.html#task_F36E342D8D234135A20FB019B08F513C

c) Increase timeout

Based on your notes:

"I can see him and hear him, but he can't see me", which obviously means External user media is redirected properly to you, but your media is not forwarded correctly to them. We need to find out where this is broken, (VCS-C, VCS-E, some firewall or remote end). I would say in this case.

In other cases I would login via root into VCS-E and do a packet capture using tcpdump in the external interface to verify if media from internal Jabber is sent.

HTH

[Douglas Baggett]

HI Gonzalo,

thanks for the help!

I had increased the timeout to 10 seconds but it did not fix the issue and evidently is not falling back to TURN like it should. This feels like a bug in the fallback mechanism that is preventing it from using TURN. The evidence that I can fix the issue by setting my client to relay is good evidence for that.

Thanks for the information on the Jabber log file, I definitely should look at that. Also, checking the SDP line should provide some good info.

I'm still at a loss as to WHY my internal client behind the firewall (none of our Jabber users behind the firewall are NAT'd, they all have public IP addresses) would NEED relay? As far as I understand the routing my Movi/Jabber client should be communicating with the VCS-C and then up through the ACCENT tunnel to the expressway. Shouldn't it be enough that the end user on FIOS is using STUN/TURN to talk to my expressway?

Gonzalo Gasca Meza wrote:
Hi Doug,
A very interesting problem, I believe you are right in the statement regards:
Public Default Mediatype Candidate.
By looking at the documentation I read:
If you use Default Mediatype Candidate set to >Rflx<
Turn Fallback Timeout will specify the time in seconds after which Jabber Video will give up waiting
for media coming directly from the other client, and fall back to using a TURN relay server for media in your case 3 seconds.
In summary:
 Rflx: Public IP address
Relay: Turn Server
For the bad case when you enable Relay internally I would check the following:
a) Confirm Internal users log in to internal VCS-C IP address
b) Compare SDP m lines and see IP address negotiated with Rflx and with Relay.
If using Windows to get logs enable SIP Debug here in Logs.ini:
C:\Users\\AppData\Local\Cisco\JabberVideo\Logs
http://www.cisco.com/en/US/docs/voice_ip_comm/jabber/iPad/Admin_doc/output/b_Jabber_for_iPad_admin_guide_chapter_011.html#task_F36E342D8D234135A20FB019B08F513C
c) Increase timeout
Based on your notes:
"I can see him and hear him, but he can't see me", which obviously means External user media is redirected properly to you, but your media is not forwarded correctly to them. We need to find out where this is broken, (VCS-C, VCS-E, some firewall or remote end). I would say in this case.
In other cases I would login via root into VCS-E and do a packet capture using tcpdump in the external interface to verify if media from internal Jabber is sent.
HTH

[Martin Koch]

Why do you use Default: Rflx and Public: Relay anyhow?

A firewall internally is not a problem, as long as no NAT is involved or not all clients registered to the VCSC

can talk to each others required ports, which can be quite an amount or traffic is only allowed to be opened in

one direction, ...

So if ports are closed down, are not open in both directions or NAT is involved the clients can not be placed

behind a VCS-C. In this scenario you would need to bind the traffic to a specific device and even if its an "internal" network you would need to deploy a VCS-E in that network.

If you just wonder about the external users, if they are provisioned via the external vcs, the internal

setting is not used. Its only used for users hitting the internal provisioning.

The JabberVideo client decides which setting it requests by the accessibility of the internal and if this fails

external configured host.

How does it work for you if you provision "Host" which is the default for Default Mediatype Candidate

which would also be the value which I would set up.

[Douglas Baggett]

Hi Martin,            

The recommendation in the Jabber 4.5 Admin guide is for external users to default to using "relay mode"

From the manual

"Relay is recommended for Jabber Video clients connecting from outside of the organization's network. ICE negotiation can take a few seconds to complete, and using the TURN relay will help media flow through the firewalls from the beginning of the call. Once ICE negotiation has completed, media will be redirected if a superior media path has been located. See Enabling ICE [p.26] for more information."

There is no recommendation for using Rflx for clients registering on in inside to VCS-C unless ICE is not understood by the majority of the endpoints you are connecting to (from the manual...not tested), but I noted how having that configuration and changing it to relay fixed the issue...strangley enough. The default for Default Mediatype Canidate on the inside if you have it configured is "Host", but it's redundant anyway to have it expressly configured because without it it's "host" anyway.

Configuring it as "host" fails in the same way as rlfx does, which is strange which points to some reason why the mechanism CISCO built in to fall back to using TURN is not working.

Martin Koch wrote:
Why do you use Default: Rflx and Public: Relay anyhow?
A firewall internally is not a problem, as long as no NAT is involved or not all clients registered to the VCSC
can talk to each others required ports, which can be quite an amount or traffic is only allowed to be opened in
one direction, ...
So if ports are closed down, are not open in both directions or NAT is involved the clients can not be placed
behind a VCS-C. In this scenario you would need to bind the traffic to a specific device and even if its an "internal" network you would need to deploy a VCS-E in that network.
If you just wonder about the external users, if they are provisioned via the external vcs, the internal 
setting is not used. Its only used for users hitting the internal provisioning.
The JabberVideo client decides which setting it requests by the accessibility of the internal and if this fails
external configured host.
How does it work for you if you provision "Host" which is the default for Default Mediatype Candidate
which would also be the value which I would set up.

[Martin Koch]

To be honest, in the scenario of a VCS I would like to be able to disable ICE completly,

but I think there is no official way to do this, as ICE is a general parameter if I remember it right.

My deployment where I use ICE does not have a VCS-C, so I can not really tell, maybe I set

it up in the lab when I have enough time.

What I would to is to check that all clients also on the inside have access to the

media ports of the vcs-e/stun/turn server. Or better said, everyone shall have access to the media ports:

VCS-E: Maintenance Tools > Port usage > Local VCS inbound ports:

default should be something like:

TURN	TURN server port	STUN		3478	UDP
TURN	TURN relays port range	Any		60000-61799	UDP

Media Media port range SIP 50000-54999 UDP

Like Gonzalo said, you can see whats going on by investigating the SDP (media) info of the SIP INVITE / OK

and also via debugging / network trace to see where RTP is send and where it gets lost.

You also want to check how the media flows on a jabber point to point call in between two clients on the VCS-C

Good success