Re: [rtcweb] State of the Forking discussion

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 03 November 2011 13:03 UTC

Return-Path: <HKaplan@acmepacket.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 C547211E80D2 for <rtcweb@ietfa.amsl.com>; Thu, 3 Nov 2011 06:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level:
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 YD5yKRfdq0y4 for <rtcweb@ietfa.amsl.com>; Thu, 3 Nov 2011 06:03:23 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4483211E808E for <rtcweb@ietf.org>; Thu, 3 Nov 2011 06:03:22 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 3 Nov 2011 09:03:21 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 3 Nov 2011 09:03:21 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Thread-Topic: [rtcweb] State of the Forking discussion
Thread-Index: AQHMmij22NouMyfKS02Wa+lc/LFVrA==
Date: Thu, 3 Nov 2011 13:03:20 +0000
Message-ID: <CEC2948D-F335-4A14-87D1-E5F7A9FC1680@acmepacket.com>
References: <4EB26945.40607@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A058522359626A5@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6CD335@inba-mail01.sonusnet.com> <CALiegfnfzReWu_PU2JwWCXjx9vpgYoXLKMtYFXZAMDnAY5zRaw@mail.gmail.com>
In-Reply-To: <CALiegfnfzReWu_PU2JwWCXjx9vpgYoXLKMtYFXZAMDnAY5zRaw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8BD4A6E21FCDFF4492D96950E6C4E5B9@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] State of the Forking discussion
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: Thu, 03 Nov 2011 13:03:23 -0000

On Nov 3, 2011, at 8:27 AM, Iñaki Baz Castillo wrote:

> Right. But note however that most of the SIP devices just choose a
> single media session and render that to the human (regardless there
> could be N sessions due to multiple 18X with different Totag and
> SDPs). So I don't consider this a very important limitation as the
> very same occurs in 99% of SIP phones.
> 

Yes but what's cool is that browsers are a platform type that could actually render two streams at the same time: per the current requirements, the browser can mix incoming audio streams and display separate videos, and send out the same audio/video to multiple peers - so parallel forking could actually really work well for in WebRTC as compared to SIP.  :)

But anyway as we keep saying, we don't need native forking ability in the browser for WebRTC's sake, since it can all be done with app code - the main benefit to having it is to federate/interop with SIP more easily/sanely.

How hard is it to put in the browsers?  Has W3C given any input on this?

-hadriel