Re: [rtcweb] Use cases - recording and voicemail

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 22 August 2011 13:12 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A881B21F8B58 for <rtcweb@ietfa.amsl.com>; Mon, 22 Aug 2011 06:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_36=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpWPyyWcAbwI for <rtcweb@ietfa.amsl.com>; Mon, 22 Aug 2011 06:12:06 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 90AE521F863A for <rtcweb@ietf.org>; Mon, 22 Aug 2011 06:12:06 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta09.westchester.pa.mail.comcast.net with comcast id PQUX1h0010xGWP859RDBSx; Mon, 22 Aug 2011 13:13:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta12.westchester.pa.mail.comcast.net with comcast id PRCq1h01i0tdiYw3YRCzMN; Mon, 22 Aug 2011 13:13:04 +0000
Message-ID: <4E5255D0.90409@alum.mit.edu>
Date: Mon, 22 Aug 2011 09:12:48 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <BBF498F2D030E84AB1179E24D1AC41D616C389F16D@ESESSCMS0362.eemea.ericsson.se><4E3AB4D4.4070308@jesup.org>, <A444A0F8084434499206E78C106220CA09BDB6A238@MCHP058A.global-ad.net><BBF498F2D030E84AB1179E24D1AC41D616C389F242@ESESSCMS0362.eemea.ericsson.se>, <A444A0F8084434499206E78C106220CA09BDB6A34F@MCHP058A.global-ad.net><BBF498F2D030E84AB1179E24D1AC41D616C389F245@ESESSCMS0362.eemea.ericsson.se>, <A444A0F8084434499206E78C106220CA09BDB6A397@MCHP058A.global-ad.net><BBF498F2D030E84AB1179E24D1AC41D616C389F24A@ESESSCMS0362.eemea.ericsson.se><2E239D6FCD033C4BAF15F386A979BF510640D0@sonusinmail02.sonusnet.com><A444A0F8084434499206E78C106220CA0B00FDABAD@MCHP058A.global-ad.net> <2E239D6FCD033C4BAF15F386A979BF51064106@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09801F1550D@HKGMBOXPRD22.polycom.com> <2E239D6FCD033C4BAF15F386A979BF51064117@sonusinmail02.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09801F1555B@HKGMBOXPRD22.polycom.com> <4E52391B.6000900@alvestrand.no>
In-Reply-To: <4E52391B.6000900@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Use cases - recording and voicemail
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2011 13:12:07 -0000

On 8/22/11 7:10 AM, Harald Alvestrand wrote:
> On 08/22/11 12:17, Avasarala, Ranjit wrote:
>> Hi Partha
>>
>> I agree with Paul that we could use the recording mechanism discussed
>> in siprec mailing list could be added here as webbrowser would
>> essentially be a SIP UA which could initiate and terminate SIP sessions.
> mandatory standard clarification (?):
>
> .. as somewhere in the combination of the Web browser, the Javascript
> and the Web server it connects to, there would be something that
> performs the functions of a SIP UA which could initiate and terminate
> SIP sessions ...

Yes, *something* of this sort - the devil is in the details.

IIUC, its the intent of RTCWEB that the media flow directly between 
source and recipient, rather than following the path of the "signaling".

(That of course was also the intent of SIP with proxies, but the almost 
pervasive use of SBCs has usually forced media to follow the signaling 
path.)

In siprec, it is assumed that an entity called the SRC is in the 
signaling and media path of the call being recorded, as well as in the 
signaling and media path of a session with the recorder.

If we assume that the RTCWEB "client" is in the media path, but not in a 
sip signaling path, and that the RTCWEB "server" is sip-capable but not 
in the media path, then we have a structure that doesn't quite fit the 
siprec model.

However this could perhaps be made to work with siprec via some 
additional functionality in the RTCWEB client and server, and maybe some 
tweaks to what is being specified for siprec. The details will depend on 
which end is making the decision to do recording. If its the client, 
then that client will need a way to ask "the" server to establish a 
siprec session and to pass metadata. If its the server that makes the 
decision, then there needs to be a way for the server to ask the client 
to fork media and send it to multiple destinations.

There are of course privacy concerns in this. Whether they are different 
in RTCWEB than they are for siprec in general remains to be seen.

	Thanks,
	Paul

>> Regards
>> Ranjit
>>
>>
>> -----Original Message-----
>> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com]
>> Sent: Monday, August 22, 2011 1:46 PM
>> To: Avasarala, Ranjit; Elwell, John; Stefan Håkansson LK;
>> rtcweb@ietf.org; public-webrtc@w3.org
>> Subject: RE: [rtcweb] Use cases - recording and voicemail
>>
>> Hi Ranjit,
>>
>> I have mentioned as JavaScript API because there is no specific
>> dependency on browser. Let us discuss about the exact mechanism later.
>> Currently, let us have common understanding whether recording usecase
>> has to be added in RTCWeb or not.
>>
>> Thanks
>> Partha
>>
>>> -----Original Message-----
>>> From: Avasarala, Ranjit [mailto:Ranjit.Avasarala@Polycom.com]
>>> Sent: Monday, August 22, 2011 12:22 PM
>>> To: Ravindran Parthasarathi; Elwell, John; Stefan Håkansson LK;
>>> rtcweb@ietf.org; public-webrtc@w3.org
>>> Subject: RE: [rtcweb] Use cases - recording and voicemail
>>>
>>> Hi
>>>
>>> We could use websockets protocol to pass metadata information.
>>>
>>> Regards
>>> Ranjit
>>>
>>> -----Original Message-----
>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>>> Of Ravindran Parthasarathi
>>> Sent: Monday, August 22, 2011 12:12 PM
>>> To: Elwell, John; Stefan Håkansson LK; rtcweb@ietf.org; public-
>>> webrtc@w3.org
>>> Subject: Re: [rtcweb] Use cases - recording and voicemail
>>>
>>> John,
>>>
>>> I agree with you. JavaScript API should have the provision to pass the
>>> metadata.
>>>
>>> Thanks
>>> Partha
>>>
>>>> -----Original Message-----
>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
>>>> Sent: Monday, August 22, 2011 11:59 AM
>>>> To: Ravindran Parthasarathi; Stefan Håkansson LK; rtcweb@ietf.org;
>>>> public-webrtc@w3.org
>>>> Subject: RE: [rtcweb] Use cases - recording and voicemail
>>>>
>>>> Partha,
>>>>
>>>> You are talking here about the metadata, I think. I assume the web page
>>>> / JavaScript has to deal with that - not the browser.
>>>>
>>>> John
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com]
>>>>> Sent: 19 August 2011 18:19
>>>>> To: Stefan Håkansson LK; Elwell, John; rtcweb@ietf.org;
>>>>> public-webrtc@w3.org
>>>>> Subject: RE: [rtcweb] Use cases - recording and voicemail
>>>>>
>>>>> Stefan,
>>>>>
>>>>> In case recording similar to SIPREC, it is little bit more
>>>>> than spanning two media (RTP stream) alone because recording
>>>>> has to include some context data about recording apart from
>>>>> the media stream.
>>>>>
>>>>> Thanks
>>>>> Partha
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>>>>> Behalf Of Stefan Håkansson LK
>>>>>> Sent: Friday, August 19, 2011 8:26 PM
>>>>>> To: Elwell, John; rtcweb@ietf.org; public-webrtc@w3.org
>>>>>> Subject: Re: [rtcweb] Use cases - recording and voicemail
>>>>>>
>>>>>>> However, I did suggest (in other text in my previous
>>>>> message) that one
>>>>>> possible solution might be to record locally and use a
>>>>> second RTC-Web
>>>>>> session to transmit from the local file to the>remote
>>>>> recorder. What I
>>>>>> failed to say was that in this case the local file would be
>>>>> a temporary
>>>>>> repository - just a buffer between the two sessions.
>>>>>> This makes sense. Also, if you look at the API proposals
>>>>> available, it
>>>>>> would be quite easy to forward (in real time) a stream
>>>>> being received
>>>>>> to another entity. There is no explicit recording, a stream being
>>>>>> received (via RTP) is just streamed to another entity (via
>>>>> a separate
>>>>>> RTC-Web session). I think this would solve this case.
>>>>>>
>>>>>> Stefan
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>> rtcweb@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>