Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

[Harald Alvestrand <[e-mail]>]

On 10/04/2012 08:21 PM, Christer Holmberg wrote:
> Hi,
>
>>> For the Web use case, I think PRANSWER is an unnecessary distraction; if
>>> we're writing both initiator and responder, multiple O/A rounds, or use of
>>> multiple PeerConnections, is a much cleaner solution for the use cases I can
>>> wrap my head around.
>> I'd remove that qualifier.  We currently have a draft that describes
>> both cloning AND PRANSWER, both of which are more cleanly addressed by
>> either multiple O/A rounds or multiple independent sessions.
>>
>> PRANSWER:
>> The ability to describe a session that includes receipt capabilities
>> that are a superset of send capabilities.  SDP O/A doesn't really
>> provide a way for me to describe this because the default assumption
>> is that items not appearing in the answer are no longer needed.
>> With something like bundle involved, we could split m= lines into
>> sendonly and recvonly portions to allow for this case to be provided.
> I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.
I've asked that question before, but I don't remember seeing an answer 
from people who know what they're talking about:

Does serial forking, as practiced by SIP UAs, violate the SDP O/A model, 
or does it not violate the SDP O/A model?

I don't understand how it, in the form that has been described as "what 
we have to support", can be SDP O/A compatible, but then there are many 
things about SIP that I don't understand, so I may understand it when 
it's explained to me.

               Harald