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

[Emil Ivov <[e-mail]>]

I do think that a different MIME type makes more sense here for the reasons
Paul explained.

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.

--sent from my mobile
On 18 Oct 2013 16:55, "Christer Holmberg" <[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]
> https://www.ietf.org/mailman/listinfo/mmusic
>