[Nice] Various questions related to the api
Kai.Vehmanen at nokia.com
Kai.Vehmanen at nokia.com
Mon Nov 19 09:43:17 PST 2007
Hi,
On 16 Nov 2007, Olivier Crête wrote:
>> ""- To use the "dribble" mode, client first has to initialize the stream with
>> calling nice_agent_set_remote_candidates() with an empty set of
>> candidates, and then start adding new remote candidates with
>> nice_agent_add_remote_candidate().
>> - XXX: initial plan, needs review...""
>
>I read this, but I didn't like the idea of calling set() with
>an empty list, it doesn't feel like a nice API.
agreed, I have no problems dropping that.
>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?
Then to signal that all remote candidates of an offer/answer have
been delivered, we'd need the "_candidates_added()" method you
mentioned in an earlier post. So every stream of add_remote_candidate()
should end with _candidates_added(). Does this still make sense
for 'old-jingle' clients?
But, but, would these be otherwise ok from Farsight-2 point of view?
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?
--
first.surname at nokia.com (Kai Vehmanen)
More information about the Nice
mailing list