Re: [MMUSIC] Trickle ICE for SIP Questions

Hi,

Keep in mind that, no matter if we use PRACK, PRACK-lite, INFO, or simply re-transmission, the SDP can not change from one 180 to another (for the same To tag, that is).

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Vijaya Mandava (vimandav) [vimandav@cisco.com]
To: Parthasarathi R [partha@parthasarathi.co.in]; &apos;Emil Ivov&apos; [emcho@jitsi.org]; &apos;Alan Johnston&apos; [alan.b.johnston@gmail.com]
CC: Cullen Jennings (fluffy) [fluffy@cisco.com]; &apos;MMUSIC IETF WG&apos; [mmusic@ietf.org]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
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" <partha@parthasarathi.co.in> 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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 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)
>> > <fluffy@cisco.com <mailto:fluffy@cisco.com>> 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 <emcho@jitsi.org
>> >     <mailto:emcho@jitsi.org>> 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
>> >      > mmusic@ietf.org <mailto:mmusic@ietf.org>
>> >      > https://www.ietf.org/mailman/listinfo/mmusic
>> >
>> >     _______________________________________________
>> >     mmusic mailing list
>> >     mmusic@ietf.org <mailto:mmusic@ietf.org>
>> >     https://www.ietf.org/mailman/listinfo/mmusic
>> >
>> >
>>
>> --
>> https://jitsi.org
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic