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

Paul Kyzivat <> Wed, 10 October 2012 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12B2821F86DD for <>; Wed, 10 Oct 2012 11:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.381
X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Z9guYS2touh for <>; Wed, 10 Oct 2012 11:55:16 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:212]) by (Postfix) with ESMTP id 38EC821F86DC for <>; Wed, 10 Oct 2012 11:55:16 -0700 (PDT)
Received: from ([]) by with comcast id 9SVy1k00327AodY5EWvLA6; Wed, 10 Oct 2012 18:55:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id 9Wql1k00B3ZTu2S3fWqlK0; Wed, 10 Oct 2012 18:50:45 +0000
Message-ID: <>
Date: Wed, 10 Oct 2012 14:50:14 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
References: <> <> <> <> <>, <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Oct 2012 18:55:17 -0000

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.
>>> 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.