Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling?

["Duckworth, Mark" <[e-mail]>]

Hi Christian,

Maybe there is confusion about "encoding limits" vs. "encoding parameters".  I think we have been talking about "limits" and "parameters" as being the same thing.  Here is my understanding.  A CLUE encoding has "encoding limits" (see draft-ietf-clue-framework-12 section 8.1 and draft-kyzivat-clue-signaling-05 section 4.2).  For the sender (encoder side), these are expressed in SDP (a=sendonly), and referenced in a CLUE advertisement.  Similarly, for the receiver (decoder side) the limits are expressed in SDP (a=recvonly) and referenced in a CLUE configure message.

Framework section 8.1 mentions the possibility of the codec actually using lower values for some of these parameters, and gives example of how certain parameters for certain codecs can be considered limits with possibility of using lower values.  It seems to me that in general this isn't CLUE specific.  This is just how these parameters are meant to be used in SDP offer/answer (and maybe also in H.323 protocol?).  CLUE isn't trying to change this, it is just adding the ability to reference these existing codec parameters in CLUE messages.

I disagree with you about the consistency of the framework examples.  The "maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth" parameters you mentioned are all still part of the framework.  Whether they are expressed directly in CLUE messages or references to SDP is not relevant to these examples.  If we eventually add more examples (in the signaling document?) for CLUE protocol and/or using the data model, then these lower level details should appear in those examples.

Regards,
Mark

> -----Original Message-----
> From: Christian Groves [mailto:[e-mail]]
> Sent: Tuesday, December 03, 2013 5:50 PM
> To: Duckworth, Mark; [e-mail]
> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling?
> 
> Hello Mark,
> 
> I guess what I found confusing is that the decision was with regards to
> "Encoding Limits" (i.e. maximums) not encoding parameters which I agree
> we've previously thought as being in SDP. The examples in the framework
> also shows maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth
> against individual encodes. So the framework isn't consistent on this.
> 
> Regards, Christian
> 
> On 4/12/2013 1:17 AM, Duckworth, Mark wrote:
> > Hello Christian,
> >
> > I agree with Rob, and even further, I think the Framework document is
> already consistent with this approach, because it has been our working
> understanding for quite a while.
> >
> > This text from section 8.1 sums it up nicely:
> >      "Individual Encoding parameters are represented in SDP [RFC4566],
> >      not in CLUE messages. For example, for a video encoding using
> >      H.26x compression technologies, this can include parameters such
> >      as:
> >      . Maximum bandwidth;
> >      . Maximum picture size in pixels;
> >      . Maximum number of pixels to be processed per second;
> >      The bandwidth parameter is the only one that specifically relates
> >      to a CLUE Advertisement, as it can be further constrained by the
> >      maximum group bandwidth in an Encoding Group."
> >
> > Mark
> >
> >> -----Original Message-----
> >> From: clue [mailto:[e-mail]] On Behalf Of Christian
> >> Groves
> >> Sent: Monday, December 02, 2013 5:55 PM
> >> To: [e-mail]
> >> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling?
> >>
> >> Hello Rob,
> >>
> >> So we'll keep the encoding group concept but there will be no CLUE
> >> encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps
> etc)?
> >>
> >> Regards, Christian
> >>
> >> On 3/12/2013 3:29 AM, Robert Hansen wrote:
> >>> Hi Christian,
> >>>
> >>> I don't think this affects Encoding Groups - that concept will still
> >>> be in the framework and will need to be expressed in CLUE
> >>> ADVERTISMENT messages, as that's something that isn't well
> >>> expressible in SDP. The encoding limits referred to are the per-encoding
> limits.
> >>>
> >>> This reflects what we had been taking as our working understanding
> >>> so far in things like the signalling document, so shouldn't involve
> >>> a radical rethink.
> >>>
> >>> Rob
> >>>
> >>> On 02/12/2013 01:04, Christian Groves wrote:
> >>>> Hello Mary, all,
> >>>>
> >>>> In general I'm OK with expressing coding limits in SDP. However I'm
> >>>> trying to understand what the impact is to the CLUE framework as a
> >>>> result of that decision. Does that then mean the entire encoding
> >>>> group concept (i.e. section 8 and 9 (and relevant examples)) are
> >>>> removed from the framework and that a Capture Encoding is now
> >>>> effectively a CaptureID and reference to an SDP m-line? or?
> >>>>
> >>>> Regards, Christian
> >>>>
> >>>> On 30/11/2013 8:24 AM, Mary Barnes wrote:
> >>>>> HI all,
> >>>>>
> >>>>> As mentioned in the email about the November 26th design team
> >>>>> meeting, there was consensus amongst those on the call that SDP
> >>>>> should be used for expressing encoding limits for CLUE.  Rob's
> >>>>> presentation had details as to how it could be done using the CLUE
> >>>>> protocol, but it was decided (amongst those on the call) that we
> >>>>> should go with the SDP approach for now and IF an issue is
> >>>>> encountered with that approach as details are worked we could go
> >>>>> back to the alternative proposal outlined in those charts.
> >>>>>
> >>>>> To move forward, we want to ensure that there is WG consensus for
> >>>>> using SDP for the encoding limits.  If anyone has any concerns
> >>>>> about that approach, please post a note explaining why no later than
> Dec
> >>>>> 9th, 2013.   If you weren't at the design team meeting and would like
> >>>>> to express your support for the approach, that's also a good idea.
> >>>>>
> >>>>> Regards,
> >>>>> Mary
> >>>>> As WG co-chair
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> clue mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/clue
> >>>> _______________________________________________
> >>>> clue mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/clue
> >>> _______________________________________________
> >>> clue mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/clue
> >>>
> >> _______________________________________________
> >> clue mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/clue