Re: [rtcweb] Agenda requests for Atlanta meeting

Cullen Jennings <fluffy@iii.ca> Tue, 09 October 2012 00:47 UTC

Return-Path: <fluffy@iii.ca>
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 6F45011E80DF for <rtcweb@ietfa.amsl.com>; Mon, 8 Oct 2012 17:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 QK1XqzAQalKA for <rtcweb@ietfa.amsl.com>; Mon, 8 Oct 2012 17:47:08 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E75CE11E809B for <rtcweb@ietf.org>; Mon, 8 Oct 2012 17:47:06 -0700 (PDT)
Received: from [10.21.86.152] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 074A522E253; Mon, 8 Oct 2012 20:46:56 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <17E29D7C-A9D9-4AF9-9514-F44DB54CDEAA@cisco.com>
Date: Mon, 8 Oct 2012 17:47:37 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6052E8F-9220-4F15-A319-4C6B570E1AA6@iii.ca>
References: <506B0367.4000103@ericsson.com> <C5E08FE080ACFD4DAE31E4BDBF944EB111867718@xmb-aln-x02.cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD03A6@ESESSCMS0356.eemea.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB11187F8FB@xmb-aln-x02.cisco.com> <CAD5OKxtDnXafE=3R-7X9vL1TaYMauYL56JFfyJoTztDMbe4DqQ@mail.gmail.com> <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@iii.ca> <CAD5OKxsEmgUJXUYaFRnkDZhoZdzZaD4rCvoUFPNVdd6L1FWDjQ@mail.gmail.com> <17E29D7C-A9D9-4AF9-9514-F44DB54CDEAA@cisco.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.1499)
Cc: rtcweb@ietf.org
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: Tue, 09 Oct 2012 00:47:09 -0000

One other thought on this. I think this just points out that it would be really nice to have a draft that showed how to build a RTCWeb / SIP gateway. 

 
On Oct 8, 2012, at 17:42 , Cullen Jennings <fluffy@cisco.com> wrote:

> 
> Check out text from RFC 3311 that says 
> 
>      o  If the UPDATE is being sent before the completion of the INVITE
>         transaction, and the initial INVITE contained an offer, the
>         UPDATE cannot be sent with an offer unless the callee has
>         generated an answer in a reliable provisional response, has
>         received a PRACK for that reliable provisional response, has
>         not received any requests (PRACK or UPDATE) with offers that it
>         has not answered, and has not sent any UPDATE requests
>         containing offers that have not been answered.
> 
> So the 183 would be need to be sent reliably at which case I would expect the gateways to map it to a final offer in RTCWeb not a provisional one. At that point when the update comes along with an offer, it just mapped to RTCweb offer. 
> 
> 
> On Oct 8, 2012, at 16:21 , Roman Shpount <roman@telurix.com>
> wrote:
> 
>> The scenario is:
>> 
>> WebRTC is placing a call through some sort of gateway to a SIP end point. It sends an offer that gets translated into INVITE with SDP. SIP end point sends back 183 with SDP that gets delivered to the WebRTC end point as PRANSWER. Then SIP end point sends an UPDATE with SDP in early dialog. And then finally SIP end point sends 200 OK with different SDP. I am not sure how to translate the SDP in UPDATE and the final answer in WebRTC API calls. I would guess this is not something that can be supported without cloning.
>> _____________
>> Roman Shpount
>> 
>> 
>> On Mon, Oct 8, 2012 at 7:09 PM, Cullen Jennings <fluffy@iii.ca> wrote:
>> 
>> Walk me through what the call flow would like it both endpoints were SIP UA's so I understand it better.
>> 
>> 
>> Note - I'm not against folks trying to figure out clone. I'm saying that we should not get rid of PRANSWER.
>> 
>> 
>> On Oct 8, 2012, at 15:58 , Roman Shpount <roman@telurix.com> wrote:
>> 
>>> Cullen,
>>> 
>>> I have an existing interop problem with SIP serial forking that I cannot solve with the proposed schema. With PRANSWER, how would I handle SIP UPDATE sith SDP received in early dialog?
>>> 
>>> Regards,
>>> _____________
>>> Roman Shpount
>>> 
>>> 
>>> On Mon, Oct 8, 2012 at 6:53 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>>> 
>>> On Oct 8, 2012, at 2:47 , Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I would like to discuss the different alternatives in order to support forking, e.g. whether we use cloning, whether we simply set additional local descriptor, and whether we can get rid of PRANSWER.
>>> 
>>> Seriously? we have discussed this so many times and always come to the same conclusion. I have not seen anything on the list that suggests why we need to remove this or how mapping to SIP 180 with sequential forking is going to work without it. It also has other important uses. There are a bunch of changes that are needed to the JSEP draft to remove some of the inconsistencies in this and clarify some parts but I'd rather wait till we had that updated before we got into a whole discussion about exploding it yet again.
>>> 
>>> Why don't we have a phone call to try and outline what the problems you are trying to solve that the current solution does not work for then figure out how much we want to explode this.
>>> 
>>> I'll note that current clone text has lots of "miracles happen here, insert supper fluffy hand wave" in it and plenty of weasel room on failure to allocate required resources on the clone. It's more or less a sketch of an idea at this point. I'm perfectly happy to see people try and sort out the details on clone but using it explode the consensus we have come to around PRANSWER seems like a really bad idea at this point.
>>> 
>>> Cullen
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> 
>