Re: [MMUSIC] Trickle ICE for SIP Questions

["Vijaya Mandava (vimandav)" <[e-mail]>]

180 with different to-tag would mean call is forked.
If uac side do not support call forking, then we cannot use this 180
response to collect trickled candidates.

As Emil said, I think INFO is the right way to go here.

Thanks,
Vijaya

On 7/24/13 12:55 PM, "Parthasarathi R" <[e-mail]> wrote:

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