Re: [rtcweb] Proposed text - remote recording use case

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[e-mail]] 
> Sent: 13 September 2011 15:38
> To: Ravindran Parthasarathi
> Cc: Elwell, John; <[e-mail]>
> Subject: Re: [rtcweb] Proposed text - remote recording use case
> 
> inline...
> 
> On Sep 11, 2011, at 4:29 PM, Ravindran Parthasarathi wrote:
> 
> > New requirements:
> > Fyy1: The browser MUST be able to send in real-time to an another
> > browser/session recording server(SRS) that are being 
> transmitted to and
> > received from remote browser.
> 
> That doesn't make sense in English - *what* needs to be sent 
> in real-time?  Removing the word "media" broke the meaning.  
> Also, the media it needs to replicate/fork may not be to/from 
> another "remote browser" - it could be to/from a remote 
> gateway, SIP UA, whatever.  Really what you want to say is 
> to/from a "remote peer".
> Same issues/comments go for the next requirement.
[JRE] I agree the modified words don't make sense and would like to stick to the words I proposed at the start of this thread.

> 
> > 
> > Ayy1: The web application MUST be able to ask the browser 
> to transmit in
> > real-time to another browser/session recording server(SRS) that are
> > being transmitted to and received from remote browser.
> 
> Same as above.
> 
> > As I asked in the meeting (but couldn't discuss due to time 
> constraint),
> > it is possible for browser to do the signaling directly to the SRS
> > without going through original webserver. The signaling towards
> > recording is not required to be SIP but it shall be websocket (let
> > discuss separately). Here, the advantageous in this model 
> is that the
> > recording signaling hop is reduced to 1 hop (browser to SRS)  from 2
> > hops (browser to webserver, webserver to SRS).
> > 
> 
> Actually, I don't think it is possible for the rtcweb browser 
> to properly do SIPREC, even if it had a SIP stack to do it 
> with.  The reason is the browser doesn't know the full call 
> metadata.  The browser doesn't know the calling/called party 
> info, for example.  Even the javascript itself may not know 
> it, depending on how the application provider does their 
> logic.  They could decide to have some state/logic be handled 
> by the web server, rather than all in the javascript.  For 
> example the javascript may just display a list of friends 
> using aliases or icons, and the web server may be the only 
> one who knows what the friend's AoR/URI actually is for that alias.  
[JRE] Quite so. Metadata would come from the application, but whether this is server-side or client-side is out of scope for RTC-Web. The important thing is that an application that is able to do the SIP and Metadata part of SIPREC can ask the browser to do the media part.

John


> 
> -hadriel
> 
>