Re: [clue] a few issues on data model draft

["Roni Even" <[e-mail]>]

Andy,

The SSRC will be known even if not declared in the SDP offer since it will conveyed in any mapping mechanism we are discussing now. (Static in SDP and Dynamic in RTP header extension) 

 

Note that in any case the consumer cannot ask ahead for a preferred value that will be known by all providers in the MCU case  since the media capture is from the MCU and the consumer will need to request it when the switch occurs and he sees a new SSRC.

 

 

Roni

 

From: Andrew Pepperell [mailto:[e-mail]] 
Sent: 01 August, 2012 3:53 PM
To: Andrew Pepperell
Cc: Roni Even; Allyn Romanow (allyn); Espen Berger (espeberg); CLUE
Subject: Re: [clue] a few issues on data model draft

 

Thanks to those of you who pointed out my totally non-Freudian slip - "webrtc dies" was meant to be "webrtc does" (!). Maybe I can blame Apple's auto-correct which also decided that "above mentioned" was better said as "entwined".

 

Andy

On 1 Aug 2012, at 14:05, Andrew Pepperell <[e-mail]> wrote:

Hi Roni,

 

While what you say seems to be applicable here to CLUE, a couple of things spring to mind:

 

- it's not clear that we'll be declaring SSRC values in SDP as webrtc dies, so being able to specify imageattr there might not be of use

 

- even if we were, there's no obvious defined SSRC <-> media capture mapping being considered. Specifically, at offer-time the provider wouldn't know which SSRCs were to be used for which captures and so wouldn't be able to determine which imageattr values to assign with which SSRC values.

 

I can understand how what you describe works fine for webrtc - did you have a scheme in mind for tackling the above entwined issues (especially the second one) ?

 

Regards,

 

Andy



On 1 Aug 2012, at 02:25, "Roni Even" <[e-mail]> wrote:

Andy,

The image attribute provides a better solution  to allow the consumer to ask for a preferred image size which is not only the aspect ratio but the resolution and pixel aspect ratio.  It can be specified per SSRC http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selection-03 

The consensus in RTCweb was to use this solution  based on http://tools.ietf.org/html/draft-alvestrand-rtcweb-resolution-00 

 

Roni

 

From: Andy Pepperell [mailto:[e-mail]] 
Sent: 01 August, 2012 1:41 AM
To: Allyn Romanow (allyn)
Cc: Espen Berger (espeberg); Roni Even; CLUE
Subject: Re: [clue] a few issues on data model draft

 

>>>Currently it is not possible to tell whether a remote video source is natively 4:3 or 16:9, for instance.
>>>If we have this, there might usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's stream selection message as part of the  (e.g. in "<stream-description> / <encoding>").

>>Roni: RE: No need, first of all it does not work with switched capture that may have different aspect ratios. Also this is available in the SDP as well as a way for receiver to ask for specific ratio using the SDP image attribute.

>AR – I’ll let Andy respond to this

Many apologies for not doing so until now...

Roni, I think you're right in that at least the native aspect ratio as potentially expressed in a provider's capture advertisement wouldn't work for the switched capture case (or at least wouldn't work all the time - for the endpoint case where the switched capture was a dynamic choice between one of the "real" cameras' image then it would be possible (and straightforward) to attach the same native aspect ratio to the switched capture as was applicable to the non-switched captures). Even if it were impossible to attach a "native aspect ratio" to the switched case, to my mind this doesn't necessarily take away from the validity in this scenario of the consumer supplying a "preferred aspect ratio" in its stream selection message.

re: use of "imageattr" in the SDP, it's definitely pertinent here; potentially this has some issues in relation to CLUE:

- it would have to be applied on a per m line basis (excluding payload type differences) rather than per capture - within CLUE there would be a need (or at least use) of the aspect ratio specification being more fine-grained and separately specifiable per capture (this may depend in part on how we eventually choose to manage main vs slides video in terms of RTP session association though).

- by being in SDP, it's presumably the case that to correctly signal to the consumer when, say, a 4:3 presentation source had been connected would require an additional offer / answer cycle (and similarly if that source were to be disconnected and a new 16:9 source attached) - this seems slightly less lightweight than the equivalent operation would be if its scope were restricted to just the CLUE provider capture advertisement. As a side point, it also seems more heavyweight than SIP without the use of imageattr too, where presumably the only impact of connecting such a presentation source would be a BFCP exchange.

I'm happy to own up here to not having seen this attribute being present in devices' SDP, so if any of the above are inaccurate due to my ignorance on this, I apologise. It would certainly be interesting to get some sort of picture of the adoption of "imageattr" within the vendor community - I don't recall seeing this in use, but most of my exposure has been to systems not necessarily running recent software versions. Obviously if the already-defined "imageattr" does all we'd like within CLUE, then we should use this already-defined scheme.

Regards,

Andy




On Sun, Jul 29, 2012 at 4:58 AM, Allyn Romanow (allyn) <[e-mail]> wrote:

Hi Espen,

Thanks for your comments- 

Please see below-

Also inline in response to your inline J

 

From: Espen Berger (espeberg) 
Sent: Monday, July 23, 2012 8:27 AM
To: Allyn Romanow (allyn); Roni Even; 'CLUE'


Subject: RE: [clue] a few issues on data model draft

 

I have two questions to the data model draft. 

 

The first questions is related to naming differences between the CLUE framework and the CLUE data model. Some examples of differences. the framework uses Description and the data model uses capture-scene-text, the framework uses capture and the data model uses capture-description . Isn’t it natural that both documents share the same vocabulary? 

 

AR – Christian also brought this up.   I believe that the documents will not have the same vocabulary – but the concepts are the same.     The framework was written first and it’s goal is to describe things as clearly as possible (we’re not done with that…). The data model is more formal and the language there is not casual. It was developed after the framework, so it sort of distils the ideas in the framework.  

 

If there is a discrepancy of meaning, that is an issue and we should definitely sort it out. But in terms of language, I think it’s fine to either leave it different or  change the framework at some point to be more in keeping with the data model.. but I think it’s a good idea to do that later when the data model is about agreed upon.                 

 

I’ve put this on the list for discussion at the IETF meeting on Weds.                                                                                                                        

 

The second questions is related to the concept of doing a data model as the basis for both advertisement and configuration messages. Playing around with some XML examples messages it’s not obvious that the two messages types share a common data model. I do see similarities between the initial advertisement, the current active configuration and the advantages of be able to describe the state of a running CLUE system. Assume this will be sorted out when we look at the details of how to do configuration in CLUE.