cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
594
Views
0
Helpful
5
Replies
Highlighted

Public Default Mediatype Candidate vs Default Media Canidate

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

5 REPLIES 5
Highlighted

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

Highlighted

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

Highlighted
Engager

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.

Please remember to rate helpful responses and identify

Highlighted

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.

Highlighted

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:

TURNTURN server portSTUN
3478UDP
TURNTURN relays port rangeAny
60000-61799UDP

MediaMedia port rangeSIP
50000-54999UDP

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

Please remember to rate helpful responses and identify

Content for Community-Ad