Re: [MMUSIC] Trickle ICE for SIP Questions

["Stach, Thomas" <[e-mail]>]

Paul, 

inline

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Paul Kyzivat
> Sent: Friday, 05 July, 2013 18:47
> To: [e-mail]
> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> 
> 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?
[TS] I see potential for easier GW/SBC interworking with vanilla-ICE UAs, that did not implement PRACK
> It is a good thing to implement for many reasons. 
[TS] There are also good reasons against PRACK. e.g. the much more complicated state machine.
So in conjunction
> with
> defining other new functionality, why not require it?
[TS] We did not need to require PRACK for vanilla ICE, why require it now. There is a proposal on the table that solves the problem without the complexity of PRACK. 
As already said I don't object to recommending PRACK (as in 5245), I just don't want it mandatory. 

> 
> >> 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.
[TS] Please refer to my reply to Emil, the rule above does not apply here.
> 
> > 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.
[TS] What is the problem? The previous INFO had fewer candidates, you just got all additional candidates.  
I can't see a case were a candidate got removed in a subsequent INFO.

> 
> >>> 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
> >>
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic