W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2011

Re: Query: What does "context" mean in the context (sic) of requirement A15? [ACTION-6]

From: Cullen Jennings <fluffy@cisco.com>
Date: Tue, 23 Aug 2011 16:17:54 -0600
Cc: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <2014B96E-BD04-4EA4-8EC2-C42C428E90E5@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>

On Aug 21, 2011, at 6:01 AM, Harald Alvestrand wrote:

> On 08/21/2011 01:46 PM, Stefan Håkansson LK wrote:
>> Harald Alvestrand wrote:
>>> Hello,
>>> 
>>> this is a promised action from Quebec:
>>> 
>>> in draft-ietf-rtcweb-use-cases-and-requirements-02, the following
>>> sentence occurs:
>>> 
>>>    ----------------------------------------------------------------
>>>    A15             The web application MUST be able to identify the
>>>                    context of a stream.
>>>    ----------------------------------------------------------------
>>> 
>>> I indicated I had problems seeing a definition for the word "context",
>>> and found it hard to suggest implementations for it when I didn't know
>>> what it was.
>> I think the word "context" is probably badly chosen, better proposals are welcome.
>>> The driving scenarios are the hockey game viewer, the multiparty on-line
>>> game with voice communication, the distributed music band and the video
>>> conferencing system with central server.
>>> 
>>> One of the possible interpretations of "context" is that the Web
>>> application MUST be able to associate an identifier with the stream
>>> (label, CNAME or "something else") that can be shared over a channel
>>> outside the media channel (for instance over the signalling path), so
>>> that  both ends of the media stream know that they're talking about "the
>>> same stream".
>> This is exactly what was intended from the Author's. If this part is lacking, the only way in cases where several cameras are used to keep track of them is to set them up one by one (e.g. start with the fron facing camera, and once that stream is established and shown in the right display of the receiver add the rear facing cam). This would delay the start of a session.
>> 
>> In terms of the current API proposal, this is handled by the "label". Note that if there was no label, it could still be managed by having a separate PeerConnection peer stream, but this would still give some extra delay at set up since you would have to establish connection 1 before starting connection 2 to be able to keep track. IMHO the "label" or something similar is very useful.
> Then I suggest that we rephrase the requirement as "The Web application MUST be provided with an identifier for the stream that can be communicated to the other party of the communication, and which the other party can associate with its end of the same stream". More words, but hopefully clear enough. Wordsmithing welcome.
> 
> Everyone: Does this make sense to the WG?
>>> Another interpretation is that there has to be a set of information that
>>> one can gather from the media stream (for example - remote partner,
>>> format, identifier and so on) that together forms the context.
>> This is not what the Author's had in mind if I recollect correctly. But it is an interesting idea.
> It leads into interesting directions, but I would prefer to think about this as "once I have the identifier, I can look up the stream object; once I have the stream object, I can get all sorts of interesting information from it".
> 
> Then we'll see what requirements there are for "interesting information".
> 

I'm on board with the intent but I think we probably need to start getting a bit more specific. It seems like the useful thing things are SSRC, CNAME, and the Label as defined in 4574. Both CNAME and SSRC are hard to use so I want to make sure we at least have support for Label and and SSRC. CNAME I don't find much use for but if others do, no objection to it. 
Received on Tuesday, 23 August 2011 22:18:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC