Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

Iñaki Baz Castillo <ibc@aliax.net> Sat, 29 October 2011 22:26 UTC

Return-Path: <ibc@aliax.net>
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 30F7921F854D for <rtcweb@ietfa.amsl.com>; Sat, 29 Oct 2011 15:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.643
X-Spam-Level:
X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX0V1a6uQVj1 for <rtcweb@ietfa.amsl.com>; Sat, 29 Oct 2011 15:26:33 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93AF821F8548 for <rtcweb@ietf.org>; Sat, 29 Oct 2011 15:26:33 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so4951593vcb.31 for <rtcweb@ietf.org>; Sat, 29 Oct 2011 15:26:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.150.212 with SMTP id z20mr1346077vcv.58.1319927193032; Sat, 29 Oct 2011 15:26:33 -0700 (PDT)
Received: by 10.220.184.6 with HTTP; Sat, 29 Oct 2011 15:26:32 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234CFCA00@ESESSCMS0356.eemea.ericsson.se>
References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <CALiegfnVaZjh1K+brd180Z9Ufheau3v6OJe6Ejv8P7wzw6ROQw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <817D03B4-A50D-4047-A638-4BFA231543E2@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852234CFCA00@ESESSCMS0356.eemea.ericsson.se>
Date: Sun, 30 Oct 2011 00:26:32 +0200
Message-ID: <CALiegf=DfzjPW5BzYc9HV9wpfc6ETR8HQx2VzLA0cmm1ND=FZQ@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Randell Jesup <randell-ietf@jesup.org>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]
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: Sat, 29 Oct 2011 22:26:34 -0000

2011/10/29 Christer Holmberg <christer.holmberg@ericsson.com>:
> Hi,
>
>> Yes, but in theory we don't need to support ROAP forking to let you do that, because you don't need to do it that way.  For example you
>> can write the JS to send a "session request" message without any ROAP/SDP, and as each "session response" comes back from each team
>> member with a ROAP OFFER, the local JS creates a new PeerConnection and sends back to each team member a ROAP ANSWER from you.
>> So basically mimicking the offerless-INVITE model of SIP.
>
> That would cause issues with SIP interworking. I hope we can agree on the fact that many (most?) SIP environments and use-cases rely on the SDP offer being sent in the INVITE. The gateway would end up having to map SIP answers into ROAP offers, and vice verse, which could become very messy.
>
> And, when the gateway receveis on offerless ROAD offer, if it needs to map it into an INVITE with an SDP offer, what information would it include in the SDP offer?

Take into account that not all of us will require a protocol gateway :)

-- 
Iñaki Baz Castillo
<ibc@aliax.net>