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

Christer Holmberg <> Sat, 06 October 2012 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2DC021F84C5 for <>; Sat, 6 Oct 2012 11:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.103
X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IvDMMYIknO-J for <>; Sat, 6 Oct 2012 11:28:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5063821F84C4 for <>; Sat, 6 Oct 2012 11:28:56 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-9f-507078661f0c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F8.35.17130.66870705; Sat, 6 Oct 2012 20:28:54 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Sat, 6 Oct 2012 20:28:54 +0200
From: Christer Holmberg <>
To: Parthasarathi R <>, 'Roman Shpount' <>, 'Harald Alvestrand' <>
Date: Sat, 6 Oct 2012 20:24:40 +0200
Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules?
Thread-Index: Ac2jIl5U0vHy8cGURFCyHvO/YwW4ugAHP8MWABGg9BAAGn4UwA==
Message-ID: <>
References: <> <> <> <> <> <> <> <>, <> <>, <000701cda387$4abc4fa0$e034eee0$>
In-Reply-To: <000701cda387$4abc4fa0$e034eee0$>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvrW5aRUGAwa03ihbH+rrYLCZ/6mO1 mHFhKrPF2n/t7A4sHlcmXGH1WLLkJ5PHh/lf2D1uTSkIYInisklJzcksSy3St0vgylh0oY29 4JhixYwz09kbGPukuxg5OSQETCRWfr3HDGGLSVy4t56ti5GLQ0jgFKPEs4Y3zBDOHEaJ+6/+ sncxcnCwCVhIdP/TBomLCDQzSky8vIYFpJtZQF3izuJz7CA2i4CKxK0Fs8GmCgsYS3R+PsYE YosAbVuzA6SeA8h2krgwMxckzCsQLrH56yk2EFtI4AyrxJG1xiA2J1D5+7d7wcYwAh33/dQa JohV4hK3nsxngjhaQGLJnvNQD4hKvHz8jxWiXlTiTvt6Roh6HYkFuz+xQdjaEssWvmaG2Cso cXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkvN9dLLcpMLi7Oz9MrTt3ECIywg1t+ G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MGf07xLN9xe4E SwZyXbe3U7rhKG2t/uvF9guHHkRqnD4h3Khc0Phkg0/8QuH5+27eSt/feUt1yk79O1enLFPm +9prqcOqqvH++XKV+0sNVrosnOXdcCK94ExnUusZNw+vs+fkZ+74HR3dUmZwR5K72SSif1G9 7kS1Rq+cg9JiydeeaZi1Sy1RYinOSDTUYi4qTgQAkJ5nmH4CAAA=
Cc: "" <>
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: Sat, 06 Oct 2012 18:28:57 -0000


>We discussed earlier that PRANSWER states complicates SIP offer/answer
>mechanism as the mapping with SIP offer/answer is not well defined. For
>Example: "UPDATE with SDP from SIP UAS after sending 18x with SDP has to be
>considered as PRANSWER or OFFER or ANSWER in originating JSEP side" ?
>I agree with Roman that Cloning is the solution for serial forking as well.

If we support cloning (no matter whether it's a separate function call, or simply creating a new session with the same local descriptor), I agree that PRANSWER probably could be removed.

At least I have never thought of any other use of it than to support serial forking.



-----Original Message-----
From: [] On Behalf Of
Christer Holmberg
Sent: Saturday, October 06, 2012 2:57 AM
To: Roman Shpount; Harald Alvestrand
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?


Roman is correct.

The SDP O/A doesn't consider forking, because each forked SIP leg creates a
unique early dialog, and each early dialog has its own O/A state machine.



From: Roman Shpount []
Sent: Friday, October 05, 2012 8:46 PM
To: Harald Alvestrand
Cc: Christer Holmberg;
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

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. 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. 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. This is not an
issue with WebRTC where consent to receive media is required. 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.
Roman Shpount

rtcweb mailing list