[Nice] question about asymetric path

[Youness Alaoui]

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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20130328/28435505/attachment.pgp>