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

["Ravindran Parthasarathi" <[e-mail]>]

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
>> >>
>> >>
>>