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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E07121F86B1 for <>; Wed, 10 Oct 2012 11:42:45 -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 JLNT-0jiFi3t for <>; Wed, 10 Oct 2012 11:42:44 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:16]) by (Postfix) with ESMTP id 5052B21F8617 for <>; Wed, 10 Oct 2012 11:42:44 -0700 (PDT)
Received: from ([]) by with comcast id 9RBa1k0040SCNGk51WiofE; Wed, 10 Oct 2012 18:42:48 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id 9WeA1k00a3ZTu2S3VWeAgj; Wed, 10 Oct 2012 18:38:10 +0000
Message-ID: <>
Date: Wed, 10 Oct 2012 14:37:42 -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:42:45 -0000

On 10/5/12 1:46 PM, Roman Shpount wrote:
> On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand <
> <>> wrote:
>     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.
> O/A does not describe multiple answers to a single offer. Nothing
> explicitly prohibits it there but I would argue this is not part of this
> specification. No standard document that I am aware of describes how
> serial O/A is supposed to work. Serial forking as practiced by SIP UA
> does violate SIP RFC 3261 which states that each dialog can only have
> one answer to each offer. If answer is sent in both provisional and
> final response, it should be the same. You can, however, create multiple
> dialogs with the same offer. This normally implies parallel forking, but
> the most common use case is with early media, where you end up with
> multiple early dialogs. For instance you call a phone number, phone
> network sends you SDP in early media and plays a dial tone, then the
> called number does not answer, and you get connected to a voice mail
> which uses a completely different SDP in final answer. According to SIP
> these answers should come with different to-tags and technically would
> be parts of two different dialogs.

Good summary. That is indeed the compliant way to handle this case.

> What makes this a bit tricky is when
> the phone network and the voice mail are behind SBC (or some other sort
> of B2BUA) you only see one dialog which send you multiple answers to the
> same offer. This scenario is so common that it is more likely to be
> implemented then parallel forking.

If you see this then you should complain to the vendor of the SBC/B2BUA 
that they are broken. There is nothing to prevent the SBC from 
generating multiple dialogs in order to do this case correctly.

> This is why PRANSWER was suggested.
> If cloning can be implemented in WebRTC it would be more standard
> compliant then PRANSWER and would allow for a lot more use cases.
> Typical difficulty in parallel forking implementation in SIP is due to
> RTP from multiple sources coming to the same IP and port with no consent
> or notification to the receiving side. This makes it very difficult to
> present this media to the user.


> There is no way to tie media to actual
> dialogs since RTP can come from different IP and ports then specified in
> answer SDPs.

Known problem. There was a proposal *long* ago to solve this by the 
caller generating new O/As (with distinct addr/port) as soon as possible 
after discovering that forking has occurred. But that didn't go 
anywhere. And it would still leave a window where the association of 
address to dialog isn't known.

> This is not an issue with WebRTC where consent to receive
> media is required.

Yes. ICE helps a lot.

> I would argue let's implement cloning and not waste
> any more time on PRANSWER which in my opinion will always stay a half
> working hack.

Sounds good to me.