[Nice] Various questions related to the api

[Kai.Vehmanen at nokia.com]

Hi,

sorry for the late reply!

On 10 Nov 2007,  Olivier Crête wrote:
>I've been trying to find a reasonable transmitter API for Farsight 2.
>Ideally, I'd like the transmitters to be controller on a 
>per-stream basis, so I have a few questions about the API.

This is already somewhat problematic, as in the IETF ICE spec, 
multiple streams share the ICE (agent) state. It is of course possible
to negotiate streams independently (a separate ICE agent instance
is created for each stream), but for instance to write a SIP 
client supporting ICE, you need to be able to also group 
streams (multiple streams per agent instance).

>First, why is the restart call global to the Agent and not per-stream?
>The ICE-19 draft seems to imply that it can be done per SIP 
>media stream.

This is indeed allowed by the ICE spec, but the current implementation
limits this to be per-agent. Changing this is possible, but would
change the public API quite a bit (exposing Stream objects to
the clients). If we do this, we should at least try to merge the
current full-mode branch first, and then start changing 
the agent.h/stream.h APIs...

>Second, I don't really see why the properties (stun/turn servers, local
>addresses) are on the agent instead of being per-stream, is 
>there actually any shared data?

Same applies here as well (allowed by spec, per-agent chosen in
implementation). A lot of data can be shared (and is
done by the current libnice implementation), but only a few
items must be shared: role of controlled/controlling, tie breaker
value, state of connectivity checks (for "frozen" mechanism), etc... 
But I guess most of the properties could be set per-stream.

>Third, why does the _add_remote_candidate() method not take a 
>CandidateDesc like _set_remote_candidates? I understand that 
>the _add() method is only used for compatibility with the 
>older drafts, but still, it would be nice if the API was consistent.

I've left the old method of adding remote candidates to
the fullmode branch to make merging easier (and also because
I'm not quite sure how we can support both IETF-ICE and 
old jingle...).

So I haven't touched add_remote_candidate() (same API as
in main branch), but added set_remote_candidates() (sufficient
API to implemented IETF-ICE).

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