[Nice] SIP forking?

mikhail.zabaluev at nokia.com mikhail.zabaluev at nokia.com
Mon Jun 23 07:09:18 PDT 2008


>-----Original Message-----
>From: nice-bounces at lists.freedesktop.org 
>[mailto:nice-bounces at lists.freedesktop.org] On Behalf Of ext 
>Rémi Denis-Courmont
>Sent: Monday, June 23, 2008 4:26 PM
>To: nice at lists.freedesktop.org
>Subject: Re: [Nice] SIP forking?
>> I guess one would have to set more than one set of remote 
>candidates and
>> do connectivity checks with them before selecting the set 
>that will be
>> picked?
>Yeah. In theory. This gets really nasty, though. As far as I 
>can tell, you 
>would need to map incoming STUN connectivity checks to forked 
>branch based 
>solely on the USERNAME, since the source IP/port might not 
>even match any 
>known remote candidate. And then you duplicate the role 
>handling state, the 
>timers, everything...

In fact, this may be required even in the non-forked case, because you may start getting connchecks before you learn any remote candidates through signaling, and you MUST respond and keep state for the pairs thus discovered.


More information about the Nice mailing list