Re: [rtcweb] Agenda requests for Atlanta meeting

Roman Shpount <roman@telurix.com> Mon, 08 October 2012 23:21 UTC

Return-Path: <roman@telurix.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 7A6EE1F0C61 for <rtcweb@ietfa.amsl.com>; Mon, 8 Oct 2012 16:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 2YyitiqIuXhc for <rtcweb@ietfa.amsl.com>; Mon, 8 Oct 2012 16:21:57 -0700 (PDT)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8FD51F0417 for <rtcweb@ietf.org>; Mon, 8 Oct 2012 16:21:56 -0700 (PDT)
Received: by mail-da0-f44.google.com with SMTP id h15so1822721dan.31 for <rtcweb@ietf.org>; Mon, 08 Oct 2012 16:21:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Qt5FqnclnY6D9MYbHGVKJhT/W4vvjZkbZAgNZG2DKmg=; b=WDJjN6RyrsxzUeawMz7ZHfiMM2Ant1pqcUdZDipDVbqRHaJqt49RhxyDr/MR9BbZRq rY6NFlKfqWGX0hsUF2Y9KgpV5l73UJvCNYULz2Xwtlv/JcHo6GGxTuNLYQeTTmg4bjSI 8K3czZDnhwLoe/ejCZp2uM1uTf34yh5I48jqaZdnj06l4YFVLs3vDgBYLrQhHHUCpKhZ sHzB8rJ14UKUrGifdmij0JGjzRVkSWOnWFOSSlOtRX7TrFTWMddoqxgkiItbpXilPfpu cbBmGg6QinxYI1UcY4X7JO+Yyd8/cvSu7LYltRhMDms/liLPCqdVXGx7qYyqsrWkSrpy sA9g==
Received: by 10.68.116.239 with SMTP id jz15mr57148830pbb.43.1349738516372; Mon, 08 Oct 2012 16:21:56 -0700 (PDT)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id vu7sm11370706pbc.9.2012.10.08.16.21.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 16:21:54 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id fb11so4487134pad.31 for <rtcweb@ietf.org>; Mon, 08 Oct 2012 16:21:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.86.133 with SMTP id p5mr46855536paz.35.1349738513762; Mon, 08 Oct 2012 16:21:53 -0700 (PDT)
Received: by 10.68.42.8 with HTTP; Mon, 8 Oct 2012 16:21:53 -0700 (PDT)
In-Reply-To: <723C9B03-B45B-4214-9A36-7B4CEBD2FC2E@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>
Date: Mon, 8 Oct 2012 19:21:53 -0400
Message-ID: <CAD5OKxsEmgUJXUYaFRnkDZhoZdzZaD4rCvoUFPNVdd6L1FWDjQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary=f46d042de40ba70a3404cb947ca7
X-Gm-Message-State: ALoCoQkJnTrHTn/+uqhWgBO6e1toWzhMwbVy5ScNdEtxRlsD1dUQElN+8J+12JXEKg4C3ETfdEOu
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "rtcweb@ietf.org" <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: Mon, 08 Oct 2012 23:21:58 -0000

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
>
>