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

[Youness Alaoui]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Crête wrote:
> On Fri, 2009-04-24 at 12:01 +0200, Kai.Vehmanen at nokia.com wrote:
>> 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).
> 
> I guess that approach would also be workable.

yes, I would also vote for a 'nice_agent_fork' API which would create a
new NiceAgent* and copy the local candidates in it, and credentials,
leave out the remote candidates/credentials, etc... (not a real dup, but
a fork specific to SIP forking).

The problem I see with that is that if we receive a buffer on a socket,
then it's really a matter of which thread will read from it first..
agent 1 could get a message destined to agent 2, and vice versa...
With regards to the API, I like the nice_agent_fork() but I think we
should do it a bit differently internally to avoid the above-mentioned
issue.
I don't know yet how it should be done, but i'll have to think about it
a bit more... We could have a single dispatcher (a layer on top of the
sockets layer) which sends the messages to the right agent considering
the address it's coming from, but it will need to be intelligent in
order to handle correctly the peer reflexive candidates (check the ip,
not the port) and also TURN messages (they come from the same ip/port
but the information in it helps describe who it really came from).
Note also that someone could have a SIP phone at home, and also be
online with SIP with his N810, so we could be getting two remotes with
the same ip but different ports, so the dispatcher would also need to
check for credentials, etc...

My first task is to actually modularize libnice correctly and make
everything a gobject, without it, we really can't move forward (I
currently have lots of hacks to avoid very common race conditions that
gobject refcounting will solve automatically, and i can't even work
around all the crashes).
Also, without refcounting, it will be a huge PITA to have to share a
single NiceSocket amongst two NiceAgents...


Youness.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknyHQcACgkQqvxLNLvrsxwAPwCfY3M9EgeVNANV3EYxPQq3bzDm
sv8An20Kt4TIMaL5wUP+xxsAzxYDIE7e
=7piO
-----END PGP SIGNATURE-----