Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

[Christer Holmberg <[e-mail]>]

Hi Emil,

I am not saying that trickle ICE has to be done using O/A. In Berlin I agreed that e.g. INFO seems to be a feasible mechanism.

What I am saying is that O/A also impact the ICE state, including candidates that you have trickeled using a non-O/A mechanism.

And, similar to POF/PAN, also for trickle ICE we need to describe the usage with BUNDLE, e.g. whether a trickled candidate applies (I assume it does) to all m- lines within a BUNDLE group, etc.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov <[e-mail]> wrote:


On Sun, Oct 20, 2013 at 10:55 PM, Paul Kyzivat <[e-mail]> 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" <[e-mail]
>> <mailto:[e-mail]>> 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"
>>     <[e-mail]
>>     <mailto:[e-mail]>> 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
>>
>



--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[e-mail]                        PHONE: [phone]
https://jitsi.org                       FAX:   [phone]