Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 10 October 2012 18:42 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 1E07121F86B1 for <rtcweb@ietfa.amsl.com>; Wed, 10 Oct 2012 11:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.381
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLNT-0jiFi3t for <rtcweb@ietfa.amsl.com>; Wed, 10 Oct 2012 11:42:44 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 5052B21F8617 for <rtcweb@ietf.org>; Wed, 10 Oct 2012 11:42:44 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id 9RBa1k0040SCNGk51WiofE; Wed, 10 Oct 2012 18:42:48 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 9WeA1k00a3ZTu2S3VWeAgj; Wed, 10 Oct 2012 18:38:10 +0000
Message-ID: <5075C076.5060806@alum.mit.edu>
Date: Wed, 10 Oct 2012 14:37:42 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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
To: rtcweb@ietf.org
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>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: 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 <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. 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. Yep. > 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. Thanks, Paul
- [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Kaiduan Xie
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Martin Thomson
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Kaiduan Xie
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Martin Thomson
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Harald Alvestrand
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Martin Thomson
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Martin Thomson
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Cullen Jennings (fluffy)
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Harald Alvestrand
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Martin Thomson
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Roman Shpount
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Martin Thomson
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Parthasarathi R
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Cullen Jennings (fluffy)
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Cullen Jennings (fluffy)
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Cullen Jennings (fluffy)
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Roman Shpount
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Christer Holmberg
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Cullen Jennings (fluffy)
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Paul Kyzivat
- Re: [rtcweb] JSEP: Relaxing SDP O/A rules? Paul Kyzivat