[Nice] Ideas on how to implement support for SIP forking

[Kai.Vehmanen at nokia.com]

Hi,

just a few random ideas.

On 24 April 2009,  Olivier Crête wrote:
>After much though, I think I know how to properly implement support for
>SIP forking.. But that will entail changing the API quite a bit.
[...]
>I propose splitting the Agent object into two parts, a Socket wrapper
>and the agent.

I was thinking of just extending the Agent interface with a fork() type of method.
So if you get an anwwer from a another peer to the same offer, you fork the Agent 
object by passing a new set remote candidates (a new method is needed for
this), and as a result you get another Agent object. After this, the application 
can continue to use both of the Agent objects normally (and independently of
each other from application point of view).

Under the hood, libnice would of course have to do some interfacing
between the forked objects (as e.g. the local sockets are shared).

For applications this would be nice (pun intended :)) as the interface
would remain the same.
 
>Then one would create an Agent object by giving it N socket 
>objects (one per component). There would be one Agent per remote party. 
>
>So in the case of ICE forking, one can just create multiple agents for
>the same socket object and possibly do negotiations with all of them,
>and then destroy the ones that fail.

But you'd still need to duplicate some of the local Agent 
state (e.g. credentials -> you have one offer and multiple answers).

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