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

[Emil Ivov <[e-mail]>]

Hey Christer,
On 19 Oct 2013 08:10, "Christer Holmberg" <[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]> wrote:
>
>
> On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <[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]
> >>
> >>
> >> 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]>
> >>     https://www.ietf.org/mailman/listinfo/mmusic
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >>
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> [e-mail]                        PHONE: [phone]
> https://jitsi.org                       FAX:   [phone]
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>