Re: [rtcweb] Use cases - recording and voicemail

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Mon, 22 August 2011 19:01 UTC

Return-Path: <pravindran@sonusnet.com>
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 4D3A221F8C18 for <rtcweb@ietfa.amsl.com>; Mon, 22 Aug 2011 12:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level:
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 gQX280B5gSyH for <rtcweb@ietfa.amsl.com>; Mon, 22 Aug 2011 12:01:18 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B36FC21F85FE for <rtcweb@ietf.org>; Mon, 22 Aug 2011 12:01:16 -0700 (PDT)
Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p7MJ2h7H003285; Mon, 22 Aug 2011 15:02:49 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 14:56:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Aug 2011 00:25:58 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF51064183@sonusinmail02.sonusnet.com>
In-Reply-To: <4E5279A5.8010308@alum.mit.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Use cases - recording and voicemail
Thread-Index: Acxg4pcdL3t3VlWKQySNkUcykmXC8gAGgejQ
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><4E525734.80209@alum.mit.edu><A444A0F8084434499206E78C106220CA0B00FDAEA5@MCHP058A.global-ad.net> <4E5279A5.8010308@alum.mit.edu>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Paul Kyzivat" <pkyzivat@alum.mit.edu>, "Elwell, John" <john.elwell@siemens-enterprise.com>
X-OriginalArrivalTime: 22 Aug 2011 18:56:03.0214 (UTC) FILETIME=[23E58AE0:01CC60FD]
Cc: rtcweb@ietf.org
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 19:01:19 -0000

Please read inline

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of Paul Kyzivat
>Sent: Monday, August 22, 2011 9:16 PM
>To: Elwell, John
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Use cases - recording and voicemail
>
>On 8/22/11 11:15 AM, Elwell, John wrote:
>>
>>
>>> -----Original Message-----
>>> From: rtcweb-bounces@ietf.org
>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat
>>> Sent: 22 August 2011 14:19
>>> To: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] Use cases - recording and voicemail
>>>
>>> On 8/22/11 2:28 AM, Elwell, John wrote:
>>>> Partha,
>>>>
>>>> You are talking here about the metadata, I think. I assume
>>> the web page / JavaScript has to deal with that - not the browser.
>>>
>>> I don't understand your point John. The javascript is executed by the
>>> browser.
>> [JRE] My point is that in the same way as SIP signalling (at least in
>some people's minds) is a matter for JS, the inclusion of a metadata
>body part in that SIP signalling is also a matter for the JS. Of course,
>if SIP is included in the browser, this is a different matter.
>>
>> John
>
>OK. Now I get it.
>
>Well, then again this takes on a different cast based on whether, or
>not, you think the browser should have a sip stack that is "driven" by
>JS.
>
>If so, then probably the JS will also need to establish the SIP
>Recording Session, and send the metadata in the sip signaling.
>Presumably that would have to be part of the JS API for dealing with the
>sip stack.
>
[Partha] This is my understanding. Here, it is possible to complete reuse SIPREC work with minor extensions specific to RTCWeb like codec profile.

>OTOH, if you don't think the browser and JS should be doing sip
>signaling, then the web server is probably establishing the Recording
>Session, and sending the metadata. But the media streams may not flow
>through the web server. So in that case, the web server, via the JS that
>it provides, will require the capability to provide a forked media
>stream that the server can then reference in its SDP for the RS. And
>also, the JS will need *some* way to provide to the server the info that
>should go into the metadata.
>
>There had better be *some* standards for how to do it or else it will be
>a high bar for supporting recording. Perhaps the metadata could be
>provided by the JS to the web server using the same XML schema being
>defined by siprec, but conveyed differently, using http. But I expect it
>will be at least a little more complicated than that.
[Partha] I agree with you that two way for passing metadata & media is more complicated which is avoided in SIPREC protocol design.
>
>	Thanks,
>	Paul
>
>> John Elwell
>> Tel: +44 1908 817801 (office and mobile)
>> Email: john.elwell@siemens-enterprise.com
>> http://www.siemens-enterprise.com/uk/
>>
>> Siemens Enterprise Communications Limited.
>> Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15
>0DJ.
>> Registered No: 5903714, England.
>>
>> Siemens Enterprise Communications Limited is a Trademark Licensee of
>Siemens AG.
>>
>>>
>>> The actual awareness of information that is to become siprec metadata
>>> may well be distributed - some of it in the client/browser,
>>> and some of
>>> it in the server. That will somewhat complicate getting it
>>> all together.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> 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