[Nice] Various questions related to the api

[Kai.Vehmanen at nokia.com]

Hi,

On 24 Jan 2008,  Olivier Crête wrote:
>In the spirit of better late than never,

oops -- trust me, this is not late on purpose. :)

[updating an existing candidate]
>> 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?
>
>That seems ok to me from the outside. 

Ok, let's use this approach for updates.

[dribble-vs-ietf_ice]
>I don't think old-jingle has a signal when all candidates have 
>been added, but I may be wrong here. I think thats the 
>difficulty,otherwise we could have just waited for the signal 
>and called set(). 

Probably not. That's a clear difference.

>> One alternative would be to have add_remote_candidates(), but modified 
>> so that it would update candidates that already exist. IETF clients 
>> would provide remote candidates of one offer/answer in one go, while 
>> dribble-mode clients would call add_remote_candidates() multiple 
>> times. No need for candidates_added() anymore. Would this work?
>
>Does libnice has to know if its in dribble or regular mode? On the
>Farsight2 side, it would be very easy to make the mode a 
>contruct-time property and then have a single 
>add_remote_candidates() function. This would seem even better to me.

Current libnice only supports non-dribble mode (regular is a bad
term in this context, as IETF-ICE uses terms "regular nomination"
and "aggressive nomination" and these are a bit different things).

Both IETF-ICE and XEP-176 now include a mechanism to conclude 
the process for a transport ("concluding ICE" in IETF lingo, while 
"Acceptance of Successful Candidate" in XEP-176). 
And in order to make that decision ("concluded or not"), you need
to either: 1) wait for all local/remote candidates and the related
results, 2) wait for some local/remote candidates and the related
test results. So basicly, implementation wise, we need a signal 
to go ahead with the current set of local/remote candidates.

I admit I haven't fully thought out all the possible ways to
combine old-jingle and XEP-176/IETF-ICE. For instance, in dribble
mode, you could treat the first added remote candidate as the go ahead 
signal, and all later candidates would be updates to the session. 
So processing could conclude (in XEP-176/IETF-ICE terms) already 
after the checks for the first pair complete, but the client
would keep restarting the agent by adding more remote candidates (as
they dribble in). I'm a bit worried about possible timing issues w.r.t. 
the state machines, but who knows, this might just work (-> in the 
sense that you could implement a old-jingle compliant client on top
of current libnice interface).

But, but, even if we can unify the public API, the possible differences 
under the hood (in STUN processing, etc) might anyways warrant for 
a consruct time toggle in case old-jingle support is added to libnice.

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