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

Dzonatas Sol <> Wed, 24 August 2011 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B49C821F8BAA for <>; Wed, 24 Aug 2011 08:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.151
X-Spam-Status: No, score=-4.151 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sJsDrZoiksBy for <>; Wed, 24 Aug 2011 08:12:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D699821F8B74 for <>; Wed, 24 Aug 2011 08:12:40 -0700 (PDT)
Received: by gyf3 with SMTP id 3so1125455gyf.31 for <>; Wed, 24 Aug 2011 08:13:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=n8p0erXKePtEmOjyCLON8UDoHXt+6cqnJnDAulH6oeM=; b=ImP8x3X2xfxpexWFksq/8Cg8MYHyVEtV5bmzrDwUXcZcbwE5bcRGcr2bsjDAFdSwfG gxKD/+6zWly3Rvnu/hI81KcCb2kVfKVIE5SJmIStCvrrwo4P913N7lZTDL2SfY8d+FN3 S8leuodTUrhD/zKLImf2EzDDv50GugURpDHnc=
Received: by with SMTP id b6mr30673759yhm.96.1314198831423; Wed, 24 Aug 2011 08:13:51 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id f4sm1720822yhn.83.2011. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 08:13:50 -0700 (PDT)
Message-ID: <>
Date: Wed, 24 Aug 2011 08:15:14 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 15:12:41 -0000

On 08/24/2011 12:43 AM, Randell Jesup wrote:
> On 8/23/2011 1:50 PM, Hutton, Andrew wrote:
>> Hi,
>>   Also agree that implementing a full SIP Session Recording Client 
>> (SRC) as defined ]
>> by the SIPREC WG in to the browser would be a tall order and would 
>> open the flood
>> gates for a lot of other requests for SIP functionality in the browser.
> Agreed
>> If however SIP is not in the browser then I think it is a useful and 
>> interesting test case
>> to look at whether we could build a decomposed SRC with the browser 
>> handling the
>> media and the web server handling the signalling. 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.
>>   Therefore I think we should keep explore the remote recording use 
>> case further.
> My personal (not Mozilla's) opinion is that SIPREC-style recording is 
> out-of-scope,
> and would be handled in this context by a webrtc-B2BUA (i.e. something 
> that sits on the
> signalling and media paths), or something that interacts directly with 
> the app.
> What I do want to consider for in-scope are local recording options.  
> This can cover the "local
> answering machine" case, but also "I want to record my call with Dad", 
> "I want to record
> my team's chatter in the game", "I want to interview someone for 
> genealogy research", etc, etc.
> Yes, these can be done (poorly) by using some external app to capture 
> the screen and
> speaker/mic audio - I don't consider that a replacement for local 
> recording.
> Local recording is far less problematical protocol-wise than SIPREC, 
> and doesn't require
> mandating SIP.

Real-Time systems still imply static content. The source of that static 
content may be directly from such cases above, from client protocols, or 
from servers. How the capture is of static content done and distributed 
affects overall performance, yet that capture is useless to others in 
public cases if it packs credentials; we are redundancy aware.

Consider the blind user in 3D world (or earthquake survivor that NEEDS 
updated and accessible haptic maps), we shouldn't have to override 
SIP/vox-mixer or continue to call them ghosts in the machine to the 
non-blind. The word "incognito" (used instead) may seem like an 
evolutionary step forward for inclusion of such "accessibility" modes 
where before implementers thought the famous-dazzled words had no use. 
(Echo-location/sonar-simulation... anything but mere "ghosts" that pass 
through virtual walls because they can see them.)

Example: "This audio stream *beep* is in incognito mode while *beep* 
search and rescue is underway *beep*." If there is no emergency (or 
eavesdrop) then the beeps aren't mandatory in incognito usage.

--- ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant