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

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

Andy,

I suggest we start from the top by having the use case describing why you
suggest adding this parameter since it is not explained in the original
email. We can discuss it afterwards since I think we may be looking at
different usages.

Roni

 

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

 

>Roni: 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)

 

The SSRC will certainly be "discovered" in all of these cases, though I'm
not sure that equates to "known" for the purposes of this discussion.

 

I'm assuming (please correct me if this isn't true!) that you're talking
about "imageattr" being conveyed via offer / answer SDP messages - I do not
believe a consumer at least would be able to signal this meaningfully until
after it has seen the provider's capture advertisement, which would occur
after at least the initial offer / answer (and tt would seem wrong to force
a new offer / answer on, say, the basis of a consumer-side layout change).
While it would seem feasible to adopt the imageattr syntax within the
provider advertisement and consumer choice messages, being forced to supply
this information in offer / answer does not (to my mind) seem to work well
for CLUE (unlike in webrtc, where it makes perfect sense as webrtc operates
within SDP and offer / answer rather than using an additional SCTP-esque
messaging channel).

 

>Roni: 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.

 

There are scenarios where a consumer *can* usefully ask for a certain aspect
ratio from an MCU just fine - I definitely agree that there are cases where
it wouldn't be possible (e.g. some switched cases) but I'm not sure that
necessarily leads on to your assertion that "the consumer cannot ask ahead
for a preferred value [that will be known by all providers] in the MCU
case".

 

Regards,

 

Andy

 



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

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.