Re: [MMUSIC] Trickle ICE for SIP Questions

["Parthasarathi R" <[e-mail]>]

Hi Emil,

As Cullen suggested in case 180 with different to-tag is used by UAS then
INFO package itself is not required right?

Thanks
Partha

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Emil Ivov
> Sent: Wednesday, July 24, 2013 3:31 PM
> To: Alan Johnston
> Cc: Cullen Jennings (fluffy); MMUSIC IETF WG
> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> 
> Hey Alan, Cullen,
> 
> On 24.07.13, 11:45, Alan Johnston wrote:
> > Agree with Cullen - if there is a reasonable approach (such as
> > retransmitting 180) that avoids PRACK, then we should use this
> approach.
> 
> There is one and it comes down to requiring the remote side to send an
> INFO request as soon as it gets it. The INFO request could contain
> trickled candidates (in the case of full trickle) or just
> end-of-candidates (in the case of half-trickle).
> 
> This could work and, personally, I have no issue with it.
> 
> I believe the suggestion that Christer made was: given how the above
> basically works as a PRACK minus the O/A and given how the O/A in
> PRACKs
> seems to be a deal breaker for many, then we might want to generalize
> the above mechanism so that other specs can also use it.
> 
> Cheers,
> Emil
> 
> 
> > - Alan -
> >
> >
> > On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy)
> > <[e-mail] <mailto:[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]
> >     <mailto:[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] <mailto:[e-mail]>
> >      > https://www.ietf.org/mailman/listinfo/mmusic
> >
> >     _______________________________________________
> >     mmusic mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/mmusic
> >
> >
> 
> --
> https://jitsi.org
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic