[Nice] question about asymetric path

[Youness Alaoui]

Hi Madaro,

The asymetric path issue resurfaces again! I've had a few issues like that, but
it was fixed. It was mostly when one side was using a host/srvrflx candidate and
the other used TURN for no reason. But in your case, both sides are using TURN,
just different servers/candidates.
In your case, I think it's possibly a race condition that is described here :
http://tools.ietf.org/html/rfc5245#page-113
I remember investigating adding support for the a=remote-candidate attribute but
found out that it would need major refactoring before being able to do it.
I'm not sure though if that's exactly the case.
Unfortunately, I'm really busy lately so I don't have any time to look into
this. If you find any more information on this, or if you have a patch, it would
be great.

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/74f621fb/attachment.pgp>