[Nice] Gracefull fallback, renegotiations?

[mikhail.zabaluev at nokia.com]

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: Friday, June 20, 2008 9:19 PM
>To: nice at lists.freedesktop.org
>Subject: Re: [Nice] Gracefull fallback, renegotiations?
>
>> > >> 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.
>> 
>> Well, you need one per component, so it would have to be
>> nice_agent_fallback(agent, streamid, componentid, 
>remote_cand), but you
>> also need to select the local candidates I guess. I'm not 
>really certain
>> what a nice, simple api would be.
>
>What if you have IPv6 and IPv4 local candidates or candidates on
>different interfaces, I guess in this case you'd need to select the
>local candidate too..
>
>Maybe we should allow set_selected_pair() first (and same the name of
>the candidates) and then set the remote candidates and if they match,
>not do connectivity checks, but start sending immediately. Would that
>sound good?

Sounds hackish (use of remote candidate name before specifying the candidate?), but workable.

-- 
  Mikhail