[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