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

Harald Alvestrand <harald@alvestrand.no> Fri, 05 October 2012 17:13 UTC

Return-Path: <harald@alvestrand.no>
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 134BB21F87BA for <rtcweb@ietfa.amsl.com>; Fri, 5 Oct 2012 10:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.419
X-Spam-Level:
X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 r3oR66u3fs5k for <rtcweb@ietfa.amsl.com>; Fri, 5 Oct 2012 10:13:13 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4992821F87B8 for <rtcweb@ietf.org>; Fri, 5 Oct 2012 10:13:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55B6639E1D0; Fri, 5 Oct 2012 19:13:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY9DDStXKhdA; Fri, 5 Oct 2012 19:13:11 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7CEC939E1BD; Fri, 5 Oct 2012 19:13:11 +0200 (CEST)
Message-ID: <506F1526.4050306@alvestrand.no>
Date: Fri, 05 Oct 2012 19:13:10 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
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>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 17:13:14 -0000

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.
>>
>> PRANSWER:
>> 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?

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.

               Harald