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

[Paul Kyzivat <[e-mail]>]

On 10/5/12 1:13 PM, Harald Alvestrand wrote:
> 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?

In addition to what Roman already said, I'll add:

SIP (3261 & friends) doesn't say much about how to *do* forking. It sets 
down a bunch of rules, and developing algorithms that adhere to the 
rules is left as an exercise for the reader. There are also many things 
that are implicit but that must be inferred via long chains of 
reasoning. Much of this has become folklore. (RFC 6337 attempts to 
explain a lot of O/A, but doesn't directly address forking.)

The use of a separate dialog per fork falls out for free, by the nature 
of how to-tags (part of dialog id) are assigned.

But this is still a point of confusion among new (and some not so new) 
sip implementers. Questions about this come up regularly on the 
sip-implementers list. I think the frequency of them has been maintained 
for as long as I can remember.

So indeed there are ongoing violations, and some implementations are 
built to tolerate those violations.

	Thanks,
	Paul