Re: [MMUSIC] Trickle ICE for SIP Questions

[Emil Ivov <[e-mail]>]

Hey Dan,

On 03.07.13, 21:01, Dan Wing wrote:
>
> On Jul 3, 2013, at 7:13 AM, Emil Ivov <[e-mail]> wrote:
>
>> Hey all,
>>
>> Christer, Enrico and I are preparing the next version of Trickle
>> ICE for SIP. Now that discussions on BUNDLE and the plans seem to
>> be winding down, we wanted to run a few questions by the working
>> group.
>>
>> Q1: Making reliable provisional responses and PRACK mandatory.
>> Obviously this would be nice to avoid, so the question is: is there
>> a reasonable mechanism to achieve this (and by reasonable, we mean
>> something that wouldn't be harder than implementing support for
>> PRACK).
>>
>> There was some discussion about this back in April and there was a
>> suggestion for implementing a 5245-style hack where the answerer
>> basically resends the 180 until it knows that it has been
>> received.
>>
>> 5245 uses connectivity checks for this (i.e. it stops 180
>> retransmissions when the first connectivity check is received) but
>> we don't have that option here since the 180 may contain either
>> none or only host candidates so there are strong chances that no
>> binding request would be received on them.
>
> I might work, because each re-transmission would probably have
> additional candidates (because the STUN/TURN transactions will have
> completed), and thus more likely that those re-transmissions
> (containing those additional candidates) would result in the remote
> endpoint sending a STUN binding request.

If we do it cumulatively, then yes. We can then move to INFOs the moment 
we get either a first check (which would more often be the case with 
half trickle) or a first INFO request (which would be the case for full 
trickle).

This could indeed work. However it would also imply that we keep sending 
candidates cumulatively even in the INFO requests since we wouldn't know 
how many of the 180s got through.

This makes me slightly uncomfortable as it would imply that someone 
would have to maintain state on the sending side, and do a number of 
comparisons on the receiving side ...

Emil

--
https://jitsi.org



>> Thomas also suggested a second option which would be to also use
>> INFO requests with trickled candidates as an indication that 180
>> was received. This however wouldn't work with half trickle so we
>> are basically back to vanilla ICE for all (non-re) INVITEs.
>>
>> Another option would be to mandate an INFO request with
>> "end-of-candidates" in response to the 180, but that would be just
>> the same as mandating PRACK support.
>>
>> Thomas also suggested that the answerer can start sending INFOs
>> right after it sends its answer in the 180 and then it can just
>> resend the 180 if the INFOs result in a 481 response.
>>
>> Personally I think this could potentially be made to work, but it
>> would imply a level of complexity that considerably exceeds PRACK
>> support.
>>
>> Opinions?
>>
>> Q2: How do we send INFOs? Are they blocking or do we just send them
>> in parallel? If the latter, then what happens when an INFO fails
>> because it is received out of order? Do we just tell the
>> application to resend the candidates asap?
>>
>> This also leads to the following question:
>>
>> Q3: What exactly do we send in INFOs? Just the latest batch of
>> freshly learned candidates or all candidates we've learned so far?
>> Dale suggested that if we do this cumulatively we wouldn't need to
>> worry about the case with the out-of-order INFOs from Q2 since the
>> information gets resent anyway. A drawback here would obviously be
>> that this adds more complexity for trickle ICE users (WebRTC
>> applications specifically)
>>
>> A third option would be to allow both and leave it to the
>> application.
>>
>> Comments are most welcome!
>>
>> Emil