Re: [rtcweb] Agenda requests for Atlanta meeting

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 14 October 2012 19:26 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 877B621F84D2 for <rtcweb@ietfa.amsl.com>; Sun, 14 Oct 2012 12:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.224
X-Spam-Level: *
X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, 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 JVtCk+HQ+9oY for <rtcweb@ietfa.amsl.com>; Sun, 14 Oct 2012 12:26:09 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A9BA521F849C for <rtcweb@ietf.org>; Sun, 14 Oct 2012 12:26:09 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id B0ts1k00L1ap0As537SEbR; Sun, 14 Oct 2012 19:26:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id B7Mk1k00G3ZTu2S3i7MkyF; Sun, 14 Oct 2012 19:21:44 +0000
Message-ID: <507B10A4.1010302@alum.mit.edu>
Date: Sun, 14 Oct 2012 15:21:08 -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: <506B0367.4000103@ericsson.com> <C5E08FE080ACFD4DAE31E4BDBF944EB111867718@xmb-aln-x02.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB11187F8F1@xmb-aln-x02.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD087E@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB1118810C3@xmb-aln-x02.cisco.com> <CABkgnnV8YbbPi3pZt9mBjBfSgkx4EgL=EY0YogpeRobUMQ506w@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6B@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB1118819FB@xmb-aln-x02.cisco.com> <CABkgnnVk-8Wq1DaK6D7J9uJTEzVBLJOiJQvCdDN-3mpm1BeP9g@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1118865CD@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB1118865CD@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting
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: Sun, 14 Oct 2012 19:26:10 -0000

On 10/12/12 11:59 AM, Cullen Jennings (fluffy) wrote:
>
> On Oct 9, 2012, at 4:58 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> On 9 October 2012 13:05, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>>> 3264, SDP, 3261, and related documents are dealing with a bunch of things including what happens at media plane and signaling plane.
>>>
>>> I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be. So from the media point of view (covered more in SDP spec than 3264) there is one O with a bunch of A. From signaling point of view there are a bunch of O/A pairs).
>>>
>>> The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the browser. So as 3264 says, after the offer is constructed, we have to be willing to receive media for all the codec type in the offer. When we get the answer 3264 makes it clear that one MAY stop receiving the codecs that were in the offer but not selected in the answer. However, this can not be done until the signaling layer is sure that no more offers will be honored. Since that signalling part of Offer/Answer is in the JS, the API need to to have a way to signal what the MAY part should do and that is the PRANSWER vs ANSWER.
>>
>> That's a consistent and logical view.  It is not what RFC 3264 says.
>> It may even be the only reasonable solution.
>>
>>> People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in stone [...]
>>
>> Quit beating around the bush: it's me you are talking about.
>>
>> It's not a complex weird argument, it's this:
>>   PRANSWER is not described in RFC 3264.
>>
>> draft-*-jsep might say something about it, but I'd have to guess about
>> what to do if I were to implement the feature and that doesn't help
>> with interoperation.
>>
>> If there was text that described the above, plus the implications in
>> some detail (including what resources can be released as they relate
>> to the SDP), then we're good.  I don't even think that writing this is
>> especially hard.
>
> Agree that text has to be a clear. But provision is a term from 3261 which is referenced from 3264 and bunch of this also relies on SDP RFC too. Some of the key information about it is 3262. This is all intertwined but my key point is that I don't think we are trying to do anything that was not part of 3264 offer / answer. This is more or less a SIP 180.

I am trying to follow this argument, but am having difficulty, even 
though I agree with much of what has been said by those who seem to be 
on different sides of the "argument".

There is much about what needs to be done in presence of forking that is 
not written, but which is a corollary to what is specified. Most of what 
Christer described falls into this category. Implementations that don't 
do this will fail on some cases.

The problem I have with PRANSWER is that I don't if it ever applies when 
sip is at one end, and if so, how it applies. IMO the simple answer is 
that it is an extension that should not be used when gatewaying to sip. 
But now I think I see people saying it is only there for gatewaying to 
sip. If so, then I want to see a specification for how this maps.

	Thanks,
	Paul