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

[Christer Holmberg <[e-mail]>]

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, she will assume that Bob first provided candidates D and E (in the trickle ICE request), but then replaced them with candidates A, B and C (as the SDP Answer did not contain candidates D and E).

Regards,

Christer

Lähettäjä: Emil Ivov [mailto:[e-mail]]
Lähetetty: 19. lokakuuta 2013 20:49
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: VS: VS: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value


Could you please be more specific? I am not sure I see it.

Emil

--sent from my mobile
On 19 Oct 2013 19:01, "Christer Holmberg" <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

> If D and E are not provided and checked in the new O/A then they are no longer valid. Think of them as peer reflexive.

In that case there could be a race condition, if trickled candidates are provided at the same time as an ongoing O/A.

Regards,

Christer





--sent from my mobile
On 19 Oct 2013 18:44, "Christer Holmberg" <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I am trying to figure out how/if O/A and trickle ICE interact when it comes to providing candidates.

But, let's start with a more simple example:


-          I provide candidates A, B and C using O/A

-          Later, I provide candidates D and E using trickle ICE

-          Then, I send a new O/A, with candidates A, B and C

Now, are candidates D and E still valid, or did my new O/A disable them?

Regards,

Christer

Lähettäjä: Emil Ivov [mailto:[e-mail]<mailto:[e-mail]>]
Lähetetty: 19. lokakuuta 2013 18:56
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic
Aihe: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value


The new SDP O/A you mention would cause an ICE restart and that's what will define agent state. Not previously exchange trickled candidates.

I am not sure I understand the relation to your argument though (about trickled candidates affecting session SDP) so I might be missing your point.

Emil

--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Emil,



Assume you have an m- line, for which you provide candidates using trickle ICE.



Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it will inherit the address properties and candidates of the BUNDLE group.



Are you saying that the previously provided trickle candidates are still comsidered valid, eventhough they are associated with different address properties etc?



Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Emil Ivov <[e-mail]<mailto:[e-mail]>> wrote:



Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg" <[e-mail]<mailto:[e-mail]>> wrote:
Hi Emil,

Similar to POF/PAN, the sending of candidates do affect the session SDP (bacause, as you said, they are sent within SDP).

I don't think this is accurate. Use of SDP for additional candidates is just a coincidence. It was readily available syntax for describing candidates and it might be convenient in some implementations (although this is probably of marginal value).

The point is that the syntax is not due to a relationship to Offer/Answer and could have just as easily be based on JSON or XML or anything else.
Also, trickled candidates DO NOT update the session SDP the way a new m= line does. There is only a loose relation between them and subsequent O/As. The origin field does NOT need to be updated. New candidates in new O/As may appear without having been trickled and trickled candidates can just well be omitted in subsequent O/As. In other words, a trickled candidate would only affect the state of the ICE agent in exactly the same way a peer reflexive candidate would and it would be orthogonal to O/A, again, just as peer reflexive candidates are.

So, while we would need to think about whether using POF/PAN would make sense or not, why do you think that we "can't" do it?

OK, maybe "can't" is not entirely accurate here. I am sure that we *could* make it would with O/A if we really put our backs into it. In a similar way, I am sure we could also make it work by exchanging candidates in a shared Dropbox folder. In either case, I don't see why we would want to incur such a thing on our selves. I don't see any advantage to doing this.
On the downside, trickling candidates in Offer/Answer would imply the following problems:
*  Very high glare probability.
* Unnecessarily complex implementation (really, this would be a nightmare and I sincerely advise anyone supporting offer answer for trickle to first try and implement it).
* Ambiguity between ICE restarts and trickle updates.
Also, given how we have already had this discussion and converged on use of INFO, it is unclear to to me as to why we are revisiting this. I don't think anyone has reported any problems on the alternative.

Cheers,
Emil


Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Emil Ivov <[e-mail]<mailto:[e-mail]>> wrote:


On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <[e-mail]<mailto:[e-mail]>> wrote:
> On 10/18/13 6:11 PM, Emil Ivov wrote:
>>
>> I do think that a different MIME type makes more sense here for the
>> reasons Paul explained.
>
>
> In the sip world, we may *also* want a new content-disposition. Using
> 'session' as the content-disposition with the new content type implies that
> the the body is just a different representation of an offer or answer. (We
> were once considering exactly that with SDPng.)
>
> We *might* want to think of it that way, or not.
>
>
>> It might be worth adding that the same MIME type would be used when
>> sending candidate updates with Trickle ICE for SIP, which to me at
>> least, makes a lot of sense.
>
>
> I still wonder why trickle ICE needs a *different* mechanism for partial
> offers. Couldn't we just use this one?

By "this one", do you mean POF/PAN or application/sdpfrag?

We don't need anything different than application/sdpfrag.

We can't use POF/PAN because we are not sending offers and answers. We
are just exchanging candidates in agent-to-agent messages. The use of
SDP is an unfortunate coincidence, not an indication of offers and
answers.

Emil

>
>         Thanks,
>         Paul
>
>> --sent from my mobile
>>
>> On 18 Oct 2013 16:55, "Christer Holmberg"
>> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>>
>> wrote:
>>
>>     Hi,
>>
>>      > I think you and I are thinking of this differently.
>>      >
>>      > I'm thinking that the POFs and PANs are something new, different
>>     from offers and answers. They go on *between* offers and answers.
>>      >
>>      > IIUC you are thinking of POFs and PANs as extended forms of
>>     offers and answers.
>>
>>     It's not the way I think - I just wanted to explore how/if things
>>     would work IF we were thinking like that, and what the pros and cons
>>     would be :)
>>
>>     We have to keep in mind that, no matter how we look at it, the
>>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>>     they impact the same SDP state, can cause race conditions etc.
>>
>>     Regards,
>>
>>     Christer
>>
>>
>>
>>
>>
>>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>>      > Hi,
>>      >
>>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> proxy
>>      >>>>> that only understands application/sdp (e.g. for gate control
>>      >>>>> purpose) will not even look at the C-D header field value for
>>      >>>>> other bodies. And, unless such proxy understands POF/PAN, there
>>      >>>>> may not be any media passing through...
>>      >>>>
>>      >>>> Right. A middlebox that doesn't understand application/sdpfrag
>>      >>>> won't know to look at its contents and let the new streams
>>     through.
>>      >>>> And a middlebox that sees something marked as
>>     "application/sdp" that conveys only a tiny fraction of the session
>>     will probably be just as catastrophic; I would imagine everything
>>     but the modified streams would be shut off. There's no way to win
>> here.
>>      >>>
>>      >>> I think it would reject the Offer - at least that's what it
>>     should do according to 3264.
>>      >>
>>      >> 3264 only talks about how to process offers and answers described
>> in
>>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>>     that they are carried in body parts of content-type application/sdp
>>     with content-disposition of 'session'. If a body part has
>>     content-type application/sdp but has a disposition other than
>>     'session' then it isn't an offer or answer according to 3261, and so
>>     3264 doesn't apply.
>>      >
>>      > 3264 says that all m- line must be present in an Offer - even if
>>     they are not modified. So, what I meant was that in case all m-
>>     lines are NOT present (in the case of a POF), such Offer would be
>>     rejected - unless the middlebox understands the POF/PAN mechanism .
>>      >
>>      >>>> At some point, we have to come to peace with the fact that any
>>     middleboxes that aren't primarily in the business of stifling
>>     progress will need to keep pace with protocol extensions as they get
>>     deployed.
>>      >>>
>>      >>> I really wish things worked that way :)
>>      >>
>>      >> So progress ends because middleboxes don't permit it?
>>      >>
>>      >> Maybe you are right. Then sip will go the way of h323 while the
>>     world moves on to webrtc.
>>      >
>>      > I think that getting explicit rejections, rather than having to
>>     try to
>>      > figure out where things go wrong, is good for progress :)
>>      >
>>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>>      > brainstorming :)
>>      >
>>      > Regards,
>>      >
>>      > Christer
>>      >
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     [e-mail]<mailto:[e-mail]> <mailto:[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
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mmusic



--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[e-mail]<mailto:[e-mail]>                        PHONE: [phone]<tel:%2B33.1.77.62.43.30>
https://jitsi.org                       FAX:   [phone]<tel:%2B33.1.77.62.47.31>
_______________________________________________
mmusic mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic