[Nice] Various questions related to the api
dafydd.harries at collabora.co.uk
Wed Mar 12 06:49:01 PDT 2008
Ar 12/03/2008 am 10:50, ysgrifennodd Kai.Vehmanen at nokia.com:
> 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:
> 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
> 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
This seems fine to me. Unless we know that people are using it, I think we can
just remove _add_remote_candidates entirely; I don't think we have to worry
about preserving API at this early stage.
> 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):
More information about the Nice