Symmetric NAT

1

Hello,

My licode server is installed on a server with a public IP.

When Chrome is behind a port-restricted-cone NAT, the video stream is sent
correctly.
If Chrome is behind a symmetric NAT, Chrome does not send any video packets.

Using Wireshark, Chrome sends STUN requests and receives replies from the
server in both cases.
It looks like the peer reflexive candidate is not taken into account. I do
not receive STUN request from licode as I’ve got when it works.
Any idea ?

Yannick

2

@Yannick that is great! You are a gentleman and a scholar :smiley:

We have added a patch for this in our code and are testing it in our demo
server. We have already noticed it solves some of the problems we had with
restrictive NATs.

We strongly suggest everyone that is having problems to update the code to
the latest version.

Cheers!El sábado, 18 de enero de 2014 15:13:44 UTC+1, Yannick LE COENT escribió:

Hi Geoffry,

If your server has a public IP, STUN and TURN are not required. During
connectivity check, ICE will detect your Laptop as a peer reflexive client.

In my case, I do not have STUN/TURN candidates in my SDP. There is only
the host candidate (e.g. 192.168.1.37).

To make it worked, I added the following line (in red) in
libnice-0.1.4/agent/conncheck.c at line 2826:

if (agent->compatibility == NICE_COMPATIBILITY_GOOGLE ||

  •  agent->compatibility == NICE_COMPATIBILITY_RFC5245 ||*
agent->compatibility == NICE_COMPATIBILITY_MSN ||
agent->compatibility == NICE_COMPATIBILITY_OC2007) {

This prevents from having a peer reflexive with empty username and
password when sending STUN request from licode.

Hope it helps,
Yannick

2014/1/18 Geoffry Nagy <geo...@talentina.co <javascript:>>

Hi Yannick,

your insights are helpful.
I have a similar problem where I the connection to Licode (run on AWS)
does not succeed from my home network. It’s an ordinary internet access
with an ordinary router, nothing fancy but it’s a real world scenario.
The addstream event is never called → black box scenario. Stun
candidates are shared correctly in both answer and offer sdp.

However, I made it to work when I changed the settings of my router. I
allowed the IP address of my laptop in the DMZ settings.
However, I have trouble to understand what this means and how this can be
solved without force using TURN.

You describe a bug in libnice where STUN candidates are not used
correctly. Would this bug cause the behaviour I experienced ?

Thanks in advance.

–
You received this message because you are subscribed to the Google Groups
“lynckia” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lynckia+u...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.

3

Hi,

It is a bug in libnice. My server has a public IP. It worked with a
previous version of licode (I think it was v0.9) with libnice-0.1.1.
I’am checking the code in libnice-0.1.4. and it seems that peer reflexive
is detected but ICE connectivity check fails on the peer reflexive code.

As you mentioned, TURN is an alternative solution, but it should work
without TURN thanks to peer the reflexive candidate.
Thanks,
Yannick2014/1/17 Maxim Shegai max.shegai@gmail.com

Hi
Have you configured TURN server???
If you had than your problem looks very similar to
Redirecting to Google Groups (unfortunately
still unresolved)

On Thursday, January 16, 2014 12:32:57 PM UTC+5, Yannick LE COENT wrote:

Hello,

My licode server is installed on a server with a public IP.

When Chrome is behind a port-restricted-cone NAT, the video stream is
sent correctly.
If Chrome is behind a symmetric NAT, Chrome does not send any video
packets.

Using Wireshark, Chrome sends STUN requests and receives replies from the
server in both cases.
It looks like the peer reflexive candidate is not taken into account. I
do not receive STUN request from licode as I’ve got when it works.
Any idea ?

Yannick

–
You received this message because you are subscribed to the Google Groups
“lynckia” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lynckia+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

4

Hi
Have you configured TURN server???
If you had than your problem looks very similar to
Redirecting to Google Groups (unfortunately
still unresolved)On Thursday, January 16, 2014 12:32:57 PM UTC+5, Yannick LE COENT wrote:

Hello,

My licode server is installed on a server with a public IP.

When Chrome is behind a port-restricted-cone NAT, the video stream is sent
correctly.
If Chrome is behind a symmetric NAT, Chrome does not send any video
packets.

Using Wireshark, Chrome sends STUN requests and receives replies from the
server in both cases.
It looks like the peer reflexive candidate is not taken into account. I do
not receive STUN request from licode as I’ve got when it works.
Any idea ?

Yannick

5

Hi Yannick,

your insights are helpful.
I have a similar problem where I the connection to Licode (run on AWS)
does not succeed from my home network. It’s an ordinary internet access
with an ordinary router, nothing fancy but it’s a real world scenario.
The addstream event is never called → black box scenario. Stun candidates
are shared correctly in both answer and offer sdp.

However, I made it to work when I changed the settings of my router. I
allowed the IP address of my laptop in the DMZ settings.
However, I have trouble to understand what this means and how this can be
solved without force using TURN.

You describe a bug in libnice where STUN candidates are not used correctly.
Would this bug cause the behaviour I experienced ?

Thanks in advance.

6

Hi Geoffry,

If your server has a public IP, STUN and TURN are not required. During
connectivity check, ICE will detect your Laptop as a peer reflexive client.

In my case, I do not have STUN/TURN candidates in my SDP. There is only the
host candidate (e.g. 192.168.1.37).

To make it worked, I added the following line (in red) in
libnice-0.1.4/agent/conncheck.c at line 2826:

if (agent->compatibility == NICE_COMPATIBILITY_GOOGLE ||

  •  agent->compatibility == NICE_COMPATIBILITY_RFC5245 ||*
agent->compatibility == NICE_COMPATIBILITY_MSN ||
agent->compatibility == NICE_COMPATIBILITY_OC2007) {

This prevents from having a peer reflexive with empty username and password
when sending STUN request from licode.

Hope it helps,
Yannick2014/1/18 Geoffry Nagy geoffry@talentina.co

Hi Yannick,

your insights are helpful.
I have a similar problem where I the connection to Licode (run on AWS)
does not succeed from my home network. It’s an ordinary internet access
with an ordinary router, nothing fancy but it’s a real world scenario.
The addstream event is never called → black box scenario. Stun candidates
are shared correctly in both answer and offer sdp.

However, I made it to work when I changed the settings of my router. I
allowed the IP address of my laptop in the DMZ settings.
However, I have trouble to understand what this means and how this can be
solved without force using TURN.

You describe a bug in libnice where STUN candidates are not used
correctly. Would this bug cause the behaviour I experienced ?

Thanks in advance.

–
You received this message because you are subscribed to the Google Groups
“lynckia” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lynckia+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.