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

[Dzonatas Sol <[e-mail]>]

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.

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant