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

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

RTC-Web is specifying:
- the browser API (W3C); and
- protocols that the browser uses for browser-to-browser communication (IETF).
Any use of WebSockets for communication between JS and elsewhere is not within scope, as far as I understand.

John


> -----Original Message-----
> From: Ravindran Parthasarathi [mailto:[e-mail]] 
> Sent: 15 September 2011 23:01
> To: Elwell, John; Hadriel Kaplan
> Cc: [e-mail]
> Subject: RE: [rtcweb] Proposed text - remote recording use case
> 
> John,
> 
> Could you please explain in detail about the reason for two websocket
> from browser wherein one towards webserver and another 
> towards recorder
> (another webserver) is outside the scope of RTCWeb. Also, I guess that
> it would have covered in one of usecase of RTCWeb document already.
> AFAIK, there is no restriction on number of websockets from browser.
> 
> Thanks
> Partha
> 
> >-----Original Message-----
> >From: Elwell, John [mailto:[e-mail]]
> >Sent: Thursday, September 15, 2011 8:58 PM
> >To: Ravindran Parthasarathi; Hadriel Kaplan
> >Cc: [e-mail]
> >Subject: RE: [rtcweb] Proposed text - remote recording use case
> >
> >Partha,
> >
> >> -----Original Message-----
> >> From: Ravindran Parthasarathi [mailto:[e-mail]]
> >> Sent: 14 September 2011 06:57
> >> To: Elwell, John; Hadriel Kaplan
> >> Cc: [e-mail]
> >> Subject: RE: [rtcweb] Proposed text - remote recording use case
> >>
> >> John,
> >>
> >> I'm fine with Hadriel proposal of "remote peer" instead
> >> "remote browser
> >> or SRS" but not the original wordings.
> >>
> >> At this moment, I'm not convinced whether SIPREC SRS will interop
> with
> >> RTCWeb browser because the signaling protocol is an open item
> >> in RTCWeb.
> >> The recording could be done by two websocket from browser 
> wherein one
> >> websocket towards webserver and other towards recorder. How these
> >> entities interact with each other has to be discussed &
> >> defined. Please
> >> let me know the reason why this approach may not be followed
> >> in RTCWeb.
> >[JRE] I am not saying it will not work, but I consider this to be
> >outside scope of RTC-Web.
> >
> >John
> >
> >
> >>
> >> Thanks
> >> Partha
> >>
> >>
> >> >-----Original Message-----
> >> >From: Elwell, John [mailto:[e-mail]]
> >> >Sent: Wednesday, September 14, 2011 11:21 AM
> >> >To: Hadriel Kaplan; Ravindran Parthasarathi
> >> >Cc: <[e-mail]>
> >> >Subject: RE: [rtcweb] Proposed text - remote recording use case
> >> >
> >> >
> >> >
> >> >> -----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
> >> >>
> >> >>
> >>
>