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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 05 October 2012 21:26 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A3C21F871A for <rtcweb@ietfa.amsl.com>; Fri, 5 Oct 2012 14:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Level:
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODxH3Mc9rUMu for <rtcweb@ietfa.amsl.com>; Fri, 5 Oct 2012 14:26:40 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5728C21F870A for <rtcweb@ietf.org>; Fri, 5 Oct 2012 14:26:40 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-26-506f508ee05a
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6F.86.25676.E805F605; Fri, 5 Oct 2012 23:26:38 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 5 Oct 2012 23:26:38 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 5 Oct 2012 23:26:38 +0200
Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules?
Thread-Index: Ac2jIl5U0vHy8cGURFCyHvO/YwW4ugAHP8MW
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FE4@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <CABkgnnUFvw_J2+tvVBoHrzR9ZRkPT-6LhXvbaz_U1P7gqtJ4xw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <CABkgnnV6NcTeh=L_fpkpLv5UpkUSuacmQUtYwNKKwAfcb5+JQA@mail.gmail.com> <506D4F7A.5020109@alvestrand.no> <CABkgnnUgHRw4dtihk2fZppmzVWuV4hpvWtXt70N1HWQpJ+KsZw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no>, <CAD5OKxuM_q3CsOQt+huH6o=Yg+XufwhOc8pBxDjux48_AFbmAw@mail.gmail.com>
In-Reply-To: <CAD5OKxuM_q3CsOQt+huH6o=Yg+XufwhOc8pBxDjux48_AFbmAw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvrW5fQH6AwcGn1hbH+rrYLGZcmMps sfZfO7sDs8eVCVdYPZYs+cnkcWtKQQBzFJdNSmpOZllqkb5dAlfGr9v7GQumSlZ0bJzE3sA4 WaSLkZNDQsBEYuHM/8wQtpjEhXvr2UBsIYFTjBIzWnO6GLmA7NmMEvu3r2DpYuTgYBOwkOj+ pw1SIyIQKPH88ARWEJtZQF3izuJz7CA2i4CKxNJXX8BsYQFjic7Px5gg6k0k1uxYwwJhG0ls uv6BEcTmFQiXuNK0kBFi12UWiXOfn4IdxAm04N+RjWBFjEDHfT+1hglimbjErSfzmSCOFpBY suc81AOiEi8f/2OFqBeVuNO+nhGiXk/ixtQpbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRjZyFp mYWkZRaSlgWMLKsYhXMTM3PSy430Uosyk4uL8/P0ilM3MQKj6eCW36o7GO+cEznEKM3BoiTO a711j7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxjXzPbe1+Z405X/I9ujYsePfJBjESxIY 71g9fbr8OFvnkglXFM9mVJnG3+Av9zSwYu4s1omoKtat/MecYb7aO/df9GvDUnHfgpCL2xN6 uFinCH2/eXducOdHW/WqWOnj0oJrZAK2cYdt2iOxdVrMBCWTjVYvhGb91VvPvkLc5GSS4cXS gtlflFiKMxINtZiLihMB/57c/nQCAAA=
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2012 21:26:41 -0000

Hi,

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.

Regards,

Christer


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


On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> 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