[Nice] question about asymetric path

Wed Apr 3 07:40:49 PDT 2013

Hi Youness,
Thanks for the reply. The problem looks like a race condition.

I worked around the problem by patching libnice to refresh the TURN CreatePermission when receiving DataIndication (if not already refreshed). The patch doesn't totally solve the problem but it let libnice works when a race condition happens.
I send the patch for review.

I think patching libnice to avoid  the race condition would be a better solution but it takes a lot of time to develop and to test it.

Livio

-----Original Message-----
From: nice-bounces+livio.madaro=telecomitalia.it at lists.freedesktop.org [mailto:nice-bounces+livio.madaro=telecomitalia.it at lists.freedesktop.org] On Behalf Of Youness Alaoui
Sent: Friday, March 29, 2013 3:11 AM
To: nice at lists.freedesktop.org
Subject: Re: [Nice] question about asymetric path

Actually, what you could also do is to make the libnice controller do the ICE connchecks (without USE-CANDIDATE attribute) and then decide on which remote candidate to use, then once it's decided, resend the conncheck with the USE-CANDIDATE attribute.
For your info, the USE-CANDIDATE attribute is sent from the controller to the controller agent to tell it to use that candidate for the processing. What should be done is for the controller to do the connchecks, then decide on the most appropriate candidate pair and resend connchecks with USE-CANDIDATE so the peer (controlled) knows which candidate pair was nominated. What we do though (and what most people seem to be doing as well) is to send all connchecks with USE-CANDIDATE from the start, the controlled would select whatever conncheck it receives since it will be nominated right away since it has the USE-CANDIDATE attribute.
The advantage is that the connectivity establishment is much faster in that case, the disadvantage is the risk for that race condition if the controlled receives two connchecks from candidates with the same priority.
If you are interested in doing that, then I would suggest you do it as a property so it's that behavior is not enabled by default.

Hope this helps.
Youness.

On 03/26/2013 07:17 AM, Madaro Livio wrote:
> Hi,
>
> I've a use case where libnice client uses different path to send and
> receive data. The configuration is the following:
>
>
>
> -          One libnice client (client A) in the corporate intranet.
>
> -          One libnice client (client B) connected to big internet by a ADSL/NAT
>
> -          One UDP TURN server reachable from the corporate intranet and from
> big internet
>
>
>
> Client A and B both allocate a TURN port. The TURN server allocates
> port 10000 for client A and port 20000 for client B.
>
> At the end of the ICE processing libnice select an asymmetric path:
>
> -          client A sends direct  UDP data to port 20000 (port B) at the TURN
> server and receives data from the TURN server using STUN
> DataIndication
>
> -          client B sends direct UDP data to port 10000 (port A) at the TURN
> server and receives data from TURN server using STUN DataIndication
>
>
>
> I don't understand if asymmetric path is supported by the ICE protocol
> or is forbidden. What do you think?
>
>
>
> The problem is that in this situation libnice doesn't refresh the TURN
> CreatePermission because the client is receiving but is not
> transmitting using STUN/TURN .
>
> By the way, in this use case libnice doesn't always select the same path.
> Sometimes a symmetrical path is selected, sometimes an asymmetric path is selected.
>
>
>
> Livio
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
>
> /This e-mail and any attachments// is //confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is
> unauthorised. If you are not the intended recipient, please delete
> this message and any attachments and advise the sender by return
> e-mail, Thanks./
>
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se
> non è
> necessario.*
>
>
>
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
>

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Refresh-TURN-CreatePermission-at-receiving-data.patch
Type: application/octet-stream
Size: 1030 bytes
Desc: 0001-Refresh-TURN-CreatePermission-at-receiving-data.patch
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130403/df50a555/attachment-0001.obj>