Re: [MMUSIC] Trickle ICE for SIP Questions

[Paul Kyzivat <[e-mail]>]

On 7/5/13 10:12 AM, Emil Ivov wrote:
> Hey Thomas
>
> On 04.07.13, 15:15, Stach, Thomas wrote:
>> Emil,
>> inline
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Emil Ivov
>>> Sent: Wednesday, 03 July, 2013 16:13
>>> To: MMUSIC IETF WG
>>> Subject: [MMUSIC] Trickle ICE for SIP Questions
>>>
>>> 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.

Yes.

>>> 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.
>>>
>>> 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.
>> [TS] I'm not convinced about the different level of complexity.
>> If you use PRACK you have SIP timer T1 running and would re-transmit
>> the 180 in case that the PRACK is not received.
>
> Right.
>
>> Assuming that you want to wait with sending of the INFO until you saw
>> the PRACK, would lead to delay in that case.
>
> True. Is this the only problem that we are trying to optimize? Save half
> an RTT? (This is a really a question. I am not trying to make a point. I
> am simply trying to understand why PRACK is an issue.)

Yes, why is it such an issue to require PRACK?
It is a good thing to implement for many reasons. So in conjunction with 
defining other new functionality, why not require it?

>> If you don't wait you would also have to treat a 481 response to the
>> INFO.
>
> I am always a bit nervous when it comes to interpreting error responses.
> We are indeed likely to get a 481 when sending INFOs and the 180 hasn't
> yet made it to the remote side. However 481 might also imply that our
> dialog is simply dead for some reason and in this case 3261 says:
>
>
>    If the response for a request within a dialog is a 481
>    (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
>    SHOULD terminate the dialog.
>
>> ... and you would detect quicker that the 180 was lost than by waiting
>> for the PRACK.

This just highlights how "delicate" things get if you start trying to 
work around the lack of PRACK. It might be possible to get something 
that seems to work, but its a house of cards.

> As said above: a lost 180 is not the only possible cause for a 408 in
> this case.
>
>> BTW: 5245 recommends to use PRACK. However it does not mandate it, but
>> gives the alternative procedures as an option.
>> You could do the same here.
>
> Of course. I should have made that clearer: all alternative approaches
> were meant as something we could have in addition to the PRACK one.
>
> Also, keep in mind that the 180 carries an entire SDP answer. If INFOs
> are competing with 180s then they may potentially need to carry that too
> (or at least the ICE parts) and it would be good if we don't have to
> open that can of worms.

Yes. The trickle ICE INFOs are *relative* to what was set up in the O/A. 
In the absence of the answer the trickle ICE is problematic.

>>> 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?

*If* you are going to send in a non-blocking way then they should be 
cumulative.

If you treat them as blocking, then they don't have to be, but it might 
still be better.

>> [TS] I would go with the proposal below and send cumulatively. You
>> also have the CSeq: header field to detect late arrivals.

Yes, you can detect the late arrival. But you have at that point already 
acted on the one that should have been preceded by it.

>>> 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.

Exactly.

>>> A drawback here would obviously be that this adds
>>> more complexity for trickle ICE users (WebRTC applications
>>> specifically)
>> [TS] Again I'm not convinced about the complexity. Both peer know
>> their candidates, what is the issue in putting all of them into the INFO?
>
> I am not sure how current WebRTC stacks handle provisioning of repeating
> candidates. If they don't then it would be up to the receiving JS app,
> to sort our which are the new candidates and which were already there.
>
> The sending side would be similarly tricky for a JS app: it would need
> to construct SDP so that the a=candidate attributes appear under the
> right "a=mid" line.

I don't know enough about ICE to comment specifically on this.

But ISTM that this is analogous to what a SIP device must do to manage 
the target set of destinations for a request - it is required to keep 
track and not add the same address to the target set more than once.

	Thanks,
	Paul

>>> A third option would be to allow both and leave it to the application.
>> [TS] This now adds complexity. ;-)
>
> Likely yes.
>
> Emil
>
>> I would just always send all candidates.
>
>
>
>
>> Regards
>> Thomas
>>>
>>> Comments are most welcome!
>>>
>>> Emil
>>>
>>> --
>>> https://jitsi.org
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>