Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client

Harald Alvestrand <> Wed, 24 August 2011 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0687921F8B11 for <>; Wed, 24 Aug 2011 05:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.553
X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=4.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hDXlyO0yABbQ for <>; Wed, 24 Aug 2011 05:03:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 08AE721F8ABD for <>; Wed, 24 Aug 2011 05:03:00 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D91D39E0D4; Wed, 24 Aug 2011 14:02:55 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LEBmCWV4MvKP; Wed, 24 Aug 2011 14:02:54 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id F108739E087; Wed, 24 Aug 2011 14:02:53 +0200 (CEST)
Message-ID: <>
Date: Wed, 24 Aug 2011 14:04:08 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040301000207010508020202"
Subject: Re: [rtcweb] Remote recording - RTC-Web client acting as SIPREC session recording client
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Aug 2011 12:03:01 -0000

On 08/23/11 22:38, Igor Faynberg wrote:
> On 8/23/2011 1:50 PM, Hutton, Andrew wrote:
>> ...
>> What I heard a number of times at IETF81 is that what people want is 
>> to build innovative new applications with a real time media enabled 
>> browser and to it seems clear to me we need a browser API which is 
>> flexible and enables applications to do clever things with media 
>> streams. So exploring some use cases which require the browser to 
>> duplicate and copy media streams is a good idea.
> Indeed the browser API must be flexible and it must enable 
> applications.  Strong ++ on that.
> Inasmuch as we, in the IETF, are not really in control of API, to 
> ensure its flexibility we can only make the right protocol 
> selection.   To this end, the worst thing would be trying to reinvent 
> the wheel.  People have been working on SIPREC for more than a year 
> now--would it be not wise on our part to take the output of that work?
> Overall, even if the browser does not support the full-blown SIP, I 
> think it must support some parts of it (REFER and SUBSCRIBE/NOTIFY, 
> for one thing) in order to enable flexibility.

I would like to focus on the functionality you think we need for this 
flexibility - if we really need it, I would like to capture it in an use 
case; if it's not vitally needed, I would like to leave it for further work.

I don't know what it would mean to support SUBSCRIBE/NOTIFY without 
supporting SIP. I'm not sure I want to have that discussion - it seems 
to me that some applications will require presence and subscription to 
presence, but that little of this has to be built into the browser; the 
Gmail chat function, which indeed exposes presence and subscription, has 
no browser component at all.

> A few thousand messages ago, I asked how (asynchronous) notifications 
> could be implemented without having SIP in the browser, and I don't 
> think we had a sufficient discussion.

have you absorbed this?

"Notification" is not a term that can be used without context - it means 
very many different things to different people. So one reason why you 
did not get sufficient discussion might be that we didn't have a shared 
understanding of what you were asking.