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

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

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.

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