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