Re: [MMUSIC] Trickle ICE for SIP Questions

[Alan Johnston <[e-mail]>]

Agree with Cullen - if there is a reasonable approach (such as
retransmitting 180) that avoids PRACK, then we should use this approach.

- Alan -


On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) <[e-mail]
> wrote:

>
> I prefer the 180 resend approach and all the right things are already
> looking at them.  I have always objected to mandating use of PRACK.
> Obviously I'm fine with things that have PRACK can use it but I want some
> solution for things that don't.
>
> One small note, the SDP in the 180 can change as long as the to-tag is
> also changed.
>
>
>
> On Jul 3, 2013, at 8: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.
> >
> > 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
> >
> > --
> > 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
>