[Nice] Gracefull fallback, renegotiations?

mikhail.zabaluev at nokia.com mikhail.zabaluev at nokia.com
Tue May 6 08:16:19 PDT 2008


Hi,

>-----Original Message-----
>From: nice-bounces at lists.freedesktop.org 
>[mailto:nice-bounces at lists.freedesktop.org] On Behalf Of ext 
>Olivier Crête
>Sent: Tuesday, May 06, 2008 6:00 PM
>To: nice at lists.freedesktop.org
>Subject: Re: [Nice] Gracefull fallback, renegotiations?
>
>
>On Tue, 2008-05-06 at 17:53 +0300, Kai.Vehmanen at nokia.com wrote:
>> On 06 May 2008,  Olivier Crête wrote:
>> >Well, to be able to give libnice the address on the m= line, 
>> >you have to create a "non-ice" candidate which libnice won't 
>> >be able to differentiate from an ice candidate and will start 
>> >doing connchecks on.
>> 
>> ... aa, that's a good point. So yes, some STUN checks will be 
>> sent by current libnice code (between calling 
>nice_agent_set_remote_candidates()
>> and nice_nice_agent_set_selected_pair()).
>> 
>> So we need to add a new function to disable ICE processing (and
>> update design.txt). In practise, any sane RTP implementation
>> should gracefully handle invalid RTP packets (like a STUN packet).
>> But yes, this should be fixed.
>
>What about setting the candidates directly in set_selected_pair()
>instead of passing foundations (something like
>set_selected_candidates() ?

Actually, you need only one candidate (per socket) for fallback.
And the new function could be named nice_agent_fall_back(remote_cand) or something to reflect
that no ICE checks will be ever sent via this socket.

Thanks for the quick follow-ups, guys!

Best regards,
  Mikhail


More information about the Nice mailing list