[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