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

[Paul Kyzivat <[e-mail]>]

On 10/20/13 1:07 PM, Parthasarathi R wrote:
> Paul,
>
>> Maybe you are right. Then sip will go the way of h323 while the world
>> moves on to webrtc.
>
> It is amazing to hear from you that h323 way of media negotiation is better
> than SIP now :-)

Even though you included a smiley, I think maybe you didn't understand 
how I meant that statement. I didn't intend to suggest that sip should 
adopt any new behavior from h323. I meant that then sip may become old 
and obsolete, the way h323 is. (Some think it already has. It certainly 
is working on it.)

	Thanks,
	Paul

> Let us assume content-disposition "partial-session" for partial offer/answer
> exist. So, RFC 3264 does not applies for "partial-session". How the normal
> interaction and race condition between "session" and "partial-session" will
> be handled as both impact the same session in the media layer? Could you
> please explain.
>
> Thanks
> Partha
>
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Paul Kyzivat
>> Sent: Saturday, October 19, 2013 2:24 AM
>> To: Christer Holmberg
>> Cc: [e-mail]
>> Subject: Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type
>> value
>>
>> On 10/18/13 4:44 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.
>>
>>>> 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.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>