[Nice] SIP forking?

[Kai.Vehmanen at nokia.com]

Hi,

On 23 June 2008,  mikhail.zabaluev at nokia.com wrote:
> On 23 June 2008, Rémi Denis-Courmont wrote:

>>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 
>
>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.

... and this is handled in current libnice code: we respond to 
incoming checks immediately, queue the events, and then when
we have info about the remote candidates, we need to rerun the
events through the state machine. Painful to implement, but 
is needed for relatively basic use-cases.

But this code would need quite a few modifications to support
forking (separate state machines are needed).

-- 
first.surname at nokia.com (Kai Vehmanen)