Subject: [MMUSIC] How trickle ICE and INFO relate to O/A (Was: Partial Offer/Partial Answer draft - MIME type value)

From: Emil Ivov <[email-masked]>
Date: Mon, 21 Oct 2013 21:03:05 +0200

Paul, Christer,

On that we agree. There are relationships between the trickle and O/A and
they need to be explored.

We'll update the document shortly in order to reflect what seemed like
consensus in the beginning of the summer and we'll take it from there.

I do agree with Paul that some clarifications might be needed in Vanilla
ICE as well. I'll follow up on that in the following days.

Emil

--sent from my mobile
On 21 Oct 2013 15:53, "Paul Kyzivat" <[email-masked]> wrote:

> Emil,
>
> I'm open to your arguments that there is reason to have trickle ICE
> alongside O/A and POF/PAN.
>
> But then we must recognize that these all have interactions with one
> another. Rather than just ignore them, or hand wave, ISTM that these need
> to be specified. It introduces complexity, and dealing with that is part of
> the job.
>
> Vanilla ICE specifies the interactions between O/A and the discovery of
> candidates via ICE itself. But should it be updated to talk about all these
> other mechanisms as well? If not, where should those be documented? Should
> trickle ICE discuss interactions with POF/PAN, or should POF/PAN discuss
> interactions with trickle ICE, or both?
>
>         Thanks,
>         Paul
>
> On 10/20/13 9:03 PM, Emil Ivov wrote:
>
>> On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat <[email-masked]>
>> wrote:
>>
>>> On 10/20/13 4:23 PM, Emil Ivov wrote:
>>>
>>>>
>>>> One more thought:
>>>>
>>>> Please understand that trickle ICE is NOT a session modification.
>>>>
>>>
>>>
>>> Isn't the session modified as a result of the trickle ICE? (E.g., end up
>>> using a different media address than it otherwise would have.)
>>>
>>> And the use of trickle ICE can (I think) require that a subsequent offer
>>> be
>>> sent (or answered) differently than it would had trickle ice not been
>>> used.
>>>
>>
>> The above statements are also true for vanilla ICE and peer reflexive
>> candidates, where ICE processing not reflected in SDP can already lead
>> to potential changes of addresses. If the change occurs, then an O/A
>> would follow. Currently Trickle ICE works along these exact same
>> lines.
>>
>>  And AFAIK everything that can be accomplished with trickle ICE could
>>> also be
>>> accomplished with Partial Offer/Answer.
>>>
>>
>> I already agreed that it is implementable ... the point is that it
>> would be *incredibly inconvenient*. I already gave a few reasons
>> earlier in this thread, let's try again:
>>
>> * there would be an extremely high glare probability (which is
>> perfectly avoidable without O/A), * there would be a lot of added
>> complexity. Imagine POFs / PANs that send additional candidates *and*
>> change codecs and/or add/remove streams.
>> *  it would be very clumsy: after trickling candidates with a POF,
>> agents would block and wait for a PAN before they can do it again
>> * POF/PAN would be a dependency for trickle and there is no reason for it
>> to be.
>> * In Berlin we agreed that we are adopting Unified for WebRTC cases.
>> There are Plan B and No Plan style implementations out there and my
>> understanding is that they have not been outlawed. Such
>> implementations would be unlikely to adopt POF/PAN. Yet, it would be
>> great if we made it possible for them to still use Trickle ICE.
>>
>> The disadvantages aside:
>>
>> Why would we want to do it this way?
>> What would we hope to gain?
>>
>>  So the differences aren't functional
>>> ones.
>>> I presume that trickle ICE is expected to be faster, and/or easier to
>>> implement. (But easier to implement becomes moot if both need to be
>>> implemented.)
>>>
>>
>> I can promise you that it doesn't. You don't have to take my word for
>> it. Just try and implement it.
>>
>>  In my book those justify considering it a session modification.
>>>
>>
>> Let's not take things out of context. Christer's point was that
>> because it is a session modification, it has to be done in
>> Offer/Answer.
>>
>> This is wrong.
>>
>> You can consider it a session modification if you like but it is not
>> the kind that requires Offer/Answer. Vanilla ICE proves this.
>>
>> Emil
>>
>>
>>
>>
>>
>>
>>           Thanks,
>>>          Paul
>>>
>>>  Please
>>>> try to isolate the SDP syntax that it uses from general O/A. It is not
>>>> part of it.
>>>>
>>>> Think of it as JSON if that would make thinks easier.
>>>>
>>>> Emil
>>>>
>>>> --sent from my mobile
>>>>
>>>> On 20 Oct 2013 22:18, "Emil Ivov" <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>      Christer, "I tried to explain" to you that what you are saying has
>>>>      been addressed and cannot happen. If you believe that there is a
>>>>      specific situation that is still possible and is a problem, then
>>>>      please describe that rather than continuing to suggest that things
>>>>      don't work without any valid arguments whatsoever.
>>>>
>>>>      --sent from my mobile
>>>>
>>>>      On 20 Oct 2013 21:50, "Christer Holmberg"
>>>>      <christer.holmberg@ericsson.**com <[email-masked]>
>>>>      <mailto:christer.holmberg@**ericsson.com<[email-masked]>>>
>>>> wrote:
>>>>
>>>>
>>>>          Hi,
>>>>
>>>>           >> Example:
>>>>           >>
>>>>           >> 1. Alice sends an SDP Offer to Bob.
>>>>           >>
>>>>           >> 2. Bob sends the SDP Answer to Alice, with candidates A, B
>>>>          and C.
>>>>           >>
>>>>           >> 3. After that, Bob sends, using trickle ICE, candidates D
>>>>          and E to Alice.
>>>>           >>
>>>>           >> If Alice receives the SDP Answer first, and then the
>>>> trickle
>>>>          ICE request, she will assume that Bob first provided candidates
>>>>          A, B and C (in the SDP Answer), and then added D and E (in the
>>>>          trickle ICE request).
>>>>           >>
>>>>           >> If Alice receives the trickle ICE request first, and then
>>>>          the SDP Answer
>>>>           >
>>>>           > Don't do that then.
>>>>           >
>>>>           > It's been pretty clear from the start that any session
>>>>          *modification* mechanism that does not also contain the full
>>>>          session state completely falls apart in the face of unordered
>>>>          delivery. This is a fundamental information problem, and you
>>>>          aren't going to write rules that somehow cause it not to be
>>>> true.
>>>>           >
>>>>           > We haven't yet tackled how to send trickle ICE in SIP, much
>>>>          less partial offers and partial answers. When we do, the only
>>>>          way it's going to have any chance of working at all is by
>>>>          requiring ordered delivery.
>>>>
>>>>          I totally agree, and my opinion (which I tried to explain to
>>>>          Emil) is that it applies also to candidates.
>>>>
>>>>          Regards,
>>>>
>>>>          Christer
>>>>
>>>>
>>>
>>
>>
>>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>