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

[Christer Holmberg <[e-mail]>]

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]> 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