Re: [rtcweb] Use cases

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