Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]
Roman Shpount <roman@telurix.com> Mon, 31 October 2011 14:26 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 01D1521F8BF4 for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 07:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.908
X-Spam-Level:
X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 GNYknNHRBgXG for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 07:26:06 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 406C421F8B0D for <rtcweb@ietf.org>; Mon, 31 Oct 2011 07:26:06 -0700 (PDT)
Received: by ywt2 with SMTP id 2so7137741ywt.31 for <rtcweb@ietf.org>; Mon, 31 Oct 2011 07:26:05 -0700 (PDT)
Received: by 10.150.212.15 with SMTP id k15mr11270899ybg.56.1320071165680; Mon, 31 Oct 2011 07:26:05 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mx.google.com with ESMTPS id r9sm52279387anh.8.2011.10.31.07.26.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Oct 2011 07:26:04 -0700 (PDT)
Received: by qyk34 with SMTP id 34so3685224qyk.10 for <rtcweb@ietf.org>; Mon, 31 Oct 2011 07:26:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.12.138 with SMTP id y10mr23527649pbb.70.1320071161570; Mon, 31 Oct 2011 07:26:01 -0700 (PDT)
Received: by 10.68.62.170 with HTTP; Mon, 31 Oct 2011 07:26:01 -0700 (PDT)
In-Reply-To: <4EAEA670.7000403@ericsson.com>
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> <CAD5OKxu=3FvnUDV5m1TW8n+7D+B6ihp_g7TXKtJVaVW3gtiySQ@mail.gmail.com> <4EAC24A2.70401@alvestrand.no> <4EADBAD3.5020804@mozilla.com> <4EAEA670.7000403@ericsson.com>
Date: Mon, 31 Oct 2011 10:26:01 -0400
Message-ID: <CAD5OKxvdSV_qNqLODAT_vyKEJwDD+BcPWyd1AK5Uq8miyyBCrQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="bcaec51f907fa9e63404b099042b"
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: Mon, 31 Oct 2011 14:26:07 -0000
As a lot of people pointed out here there are two issues here: 1. Use Case for Parallel Forking It is obviously needed for SIP interop. There are ways around it by using different signaling scenarios, or there are way to cheat this for some use cases (serial forking), but in the end of the day, to work with the widest possible set of end points parallel forking is highly desirable. Once again, a lot of people here raised the concern that parallel forking is only needed for SIP interop and nothing else. In some sense this is true, but in general, ability to do parallel forking should save a round trip and some complexity during call setup. Imagine a scenario where a call is answered by a single peer most of the times and by multiple peers in few cases. This can be the case when some of the peers are either groups or "shared lines" in PSTN speak. If we have parallel forking, WebRTC client will send an offer with media description. If the client gets a single answer it will setup a call as soon as this answer is available. If the client gets multiple answers, it will clone the PeerConnection and process each of those answers independently. Now, if we do not have parallel forking, WebRTC client will need to start a call without an offer, get offers from all the potential call destinations, and then create a PeerConnection for each and send an answer. Extra round trip and more code, even when the call is setup to one destination only (since the client does not know in advance if the destination it is calling is a single person or a group). So, yes, everything can be implemented without parallel forking, but will be a bit more complex. 2. Complexity this will introduce to the API: I think all we need is a single clone method on the PeerConnection. If you do not need parallel forking, you never call the clone method and no additional complexity is introduced. If you need parallel forking, it is available to you. _____________ Roman Shpount
- [rtcweb] draft-kaplan-rtcweb-sip-interworking-req… Hadriel Kaplan
- Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking… Ravindran Parthasarathi
- Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking… Ravindran Parthasarathi
- Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking… Hadriel Kaplan
- Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking… Hadriel Kaplan
- Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking… Iñaki Baz Castillo
- Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking… Iñaki Baz Castillo
- Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking… Iñaki Baz Castillo
- Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking… Hadriel Kaplan
- [rtcweb] RTCWeb Forking usecase [was RE: draft-ka… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Harald Alvestrand
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Roman Shpount
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Christer Holmberg
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb Forking usecase [was RE:draft… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Hadriel Kaplan
- Re: [rtcweb] RTCWeb Forking usecase [was RE:draft… Christer Holmberg
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Randell Jesup
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Hadriel Kaplan
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Roman Shpount
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Roman Shpount
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Harald Alvestrand
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Harald Alvestrand
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Hadriel Kaplan
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Harald Alvestrand
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Christer Holmberg
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Iñaki Baz Castillo
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Christer Holmberg
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Timothy B. Terriberry
- [rtcweb] New usecase & requirement for media fork… Ravindran Parthasarathi
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Stefan Håkansson
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Roman Shpount
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Iñaki Baz Castillo
- Re: [rtcweb] New usecase & requirement for media … Harald Alvestrand
- Re: [rtcweb] RTCWeb Forking usecase [was RE: draf… Randell Jesup
- [rtcweb] SDES and forking [was RE: RTCWeb Forking… Christer Holmberg
- [rtcweb] SDES and forking [was RE: RTCWeb Forking… Christer Holmberg
- Re: [rtcweb] New usecase & requirement for media … Ravindran Parthasarathi
- Re: [rtcweb] New usecase & requirement for media … Harald Alvestrand
- Re: [rtcweb] New usecase & requirement for media … Ravindran Parthasarathi
- Re: [rtcweb] New usecase & requirement for media … Harald Alvestrand