Re: [rtcweb] Use cases

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.

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.

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