[Nice] SIP forking?

[Kai.Vehmanen at nokia.com]

Hi,

On 19 June 2008,  Olivier Crête wrote:
>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?

that will be messy as you'd need to manage state machines for
each remote agent (remote credentials plus a set of remote 
candidates), and control it through one agent instance. You'd
at least somehow need to expose the set of remote agents
in the public API (ability to iterate and perform actions on 
a set of remote agents).

>Or would be call set_remote_candidates() with one set of candidates...
>and then if its not the one that's chosen, do a ICE restart 
>and re-set the candidates from the chosen partner?

I'd prefer this option (at start anyways). It's simple 
and stupid, and considering ICE is still very new technology (with
a lot of interoperability testing ahead), overengineering 
is a real danger.

For proper (= ability to perform connectivity checks, in
_parallel_, with multiple remote agents) forking support,
I have been thinking about an API to fork the NiceAgent
itself. Client would use the NiceAgent normally until it gets
an answer from a forked remote instance. At this point it would
use a new interface call to fork the NiceAgent instance, set new
remote credentials and set of remote candidates for it. The forked
NiceAgent would still be connected to its parent (as they
share sockets), but rest of the state would be totally 
isolated. Also from client application perspective, the two 
NiceAgent instances would be seperate. With this clear split,
handling cases where some forked sessions support ICE, while
some don't, are handled naturally without any extra effort.

But considering how few clients still support full ICE,
I'm not sure optimizing connectivity establisment speed for
the forked call case is our most urgent development item
for libnice at this point.

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