[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