[Nice] Various questions related to the api
Kai.Vehmanen at nokia.com
Kai.Vehmanen at nokia.com
Wed Mar 12 01:50:08 PDT 2008
Hi,
following up to an earlier mail of mine.
On 19 Nov 2007, Kai Vehmanen wrote:
>On 16 Nov 2007, Olivier Crête wrote:
>>What about just calling add() again with the same candidate (ie one
>>that has the same ID) ?
>
>Hmm, that could work. There is no such thing as a candidate ID
>anymore, but one can (or I guess, should) use the tuple of
>"IP-address,IP-port,transport-protocol" as a unique identifier.
>So we could solve the updating problem by having
>add_remote_candidate() which either adds an entry, or updates
>if entry matching the "addr,port,proto"
>tuple exists. Is this ok?
I've now implemented this and put the code to a new branch at:
http://monkey.collabora.co.uk/nice-kvehmane-setremotecands-update/
The code now triggers the connectivity check process whenever you
call nice_agent_set_remote_candidates(). In non-dribble mode, you'd
pass all the remote candidates at once, while in dribble mode
you pass the candidates one by one (but using this same
interface).
So this works essentially without the candidates_added() method.
In dribble mode, connectivity check process is potentially
started multiple times, but this would seem to be the right
thing to do. In non-dribble mode, you'll always pass one offer
as one nice_agent_set_remote_candidates().
If you are ok with this, I'll make another patch that deprecates
the old nice_agent_add_remote_candidate() function. Alternatively
we can keep it, but turn it to a simple wrapper that calls
nice_agent_set_remote_candidates().
PS I also released a new version of sofsip-cli that provides
a SIP-using test client for NICE (update to work with the
merged tree, see the sofsip-cli README):
http://permalink.gmane.org/gmane.comp.telephony.sofia-sip.devel/2385
br,
--
first.surname at nokia.com (Kai Vehmanen)
More information about the Nice
mailing list