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

From: Christian Groves <[email-masked]>
Date: Mon, 02 Dec 2013 12:04:14 +1100

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Robert Hansen <[email-masked]>
Date: Mon, 02 Dec 2013 16:29:15 +0000

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 03 Dec 2013 09:54:38 +1100

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Dec 2013 11:40:47 +0000

Hi,

I was at the design team meeting, but I would still like to express my support for the approach on the list - just for the record :)

Regards,

Christer

From: clue [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 29. marraskuuta 2013 23:25
To: CLUE
Subject: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling?

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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 3 Dec 2013 06:17:19 -0800

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:[email-masked]] On Behalf Of Christian Groves
> Sent: Monday, December 02, 2013 5:55 PM
> To: [email-masked]
> 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
> 
> >> 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
> >>
> >>> 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.
> >>>

---

From: Robert Hansen <[email-masked]>
Date: Tue, 03 Dec 2013 14:25:21 +0000

Hi Christian,

That's correct, though the group limits are somewhat orthogonal, and 
IIRC we agreed to remove them at IETF87.

Rob

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 3 Dec 2013 06:41:30 -0800

Just to be clear, a CLUE advertisement can still have encoding groups with a "max group bandwidth" parameter.  But all the individual encoding parameters are in SDP.

Mark

> From: clue [mailto:[email-masked]] On Behalf Of Robert Hansen
> Sent: Tuesday, December 03, 2013 9:25 AM
> To: [email-masked]
> That's correct, though the group limits are somewhat orthogonal, and IIRC
> we agreed to remove them at IETF87.
> 
> Rob
> 
> >> 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.
> >>
> >>>> using SDP for the encoding limits.  If anyone has any concerns
> >>>> about that approach, please post a note explaining why no later than
> Dec

---

From: Christian Groves <[email-masked]>
Date: Wed, 04 Dec 2013 09:50:28 +1100

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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 4 Dec 2013 09:15:42 -0800

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

> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, December 03, 2013 5:50 PM
> To: Duckworth, Mark; [email-masked]
> also shows maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth
> against individual encodes. So the framework isn't consistent on this.
> 
> Regards, 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 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
> >>>

---

From: Christian Groves <[email-masked]>
Date: Thu, 05 Dec 2013 10:43:08 +1100

Hello Mark,

Please see my response below.

Regards, 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…
[CNG] This is where I'm confused. You say CLUE has "encoding limits" but 
the decision is that SDP has the encoding limits. I would say CLUE 
references an encoding defined by SDP. It is up to SDP to define that 
encoding in whatever way. I.e. it may have a specific encoding and/or 
may also have attributes that define limits. CLUE groups the encodings.

> 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 considere…
[CNG] OK this is another thing I didn't understand from the proposal. 
Again I thought we just reference the SDP encoding, not the individual 
SDP parameters in the 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.  Whethe…
[CNG] I think the issue is that the start of the text of section 8.1 and 
the examples was when the encoding parameters were present in CLUE 
itself. If we now say SDP contains the encoding information its not up 
to CLUE to say how these SDP parameters are interpreted. i.e. section 
8.1 says "The parameters of an Individual Encoding represent the maximum 
values for certain aspects of the encoding." This is not the case for 
all SDP parameters/attributes. What they represent is up to the 
semantics of the SDP parameter itself.

Also when I look at the example it certainly implies that the parameters 
are part of CLUE i.e. associated with the encoding rather than CLUE 
referencing an encoding defined elsewhere.
E.g. CLUE has:
   encodeGroupID=EG0, maxGroupBandwidth=6000000
        encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
                       maxPps=124416000, maxBandwidth=4000000
        encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30,
                       maxPps=27648000, maxBandwidth=4000000
        encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30,
                       maxPps=15552000, maxBandwidth=4000000

Which to me at least implies they are all part of the same syntax 
definition.

Whereas to show that the parameters are defined outside CLUE I would 
expect something like:
Encoding Groups:
encodeGroupID=EG0, maxGroupBandwidth=6000000
        encodeID=ENC0
        encodeID=ENC1
        encodeID=ENC2

Encodings:
        m=video
        label=ENC0
        a=maxWidth:1920
        a=maxHeight:1088
        ...
        m=video
        label=ENC1
        a=maxWidth:1280
        a=maxHeight:720
        ...
        etc.

The above SDP isn't correct but I'm just try to illustrate that it would 
be good to show the define of the parameters separate from the 
definition of the encoding groups. It could be abstracted not to have SDP.

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 4 Dec 2013 16:03:59 -0800

Hi Christian,

I think we have same understanding about the concept, but are having trouble with terminology.  In any case, I think we are both agreeing on using SDP to express encoding limits, but are now discussing possible impact to the framework document.

Comments inline.

Mark

> Sent: Wednesday, December 04, 2013 6:43 PM
> > 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.
> [CNG] This is where I'm confused. You say CLUE has "encoding limits" but the
> decision is that SDP has the encoding limits. I would say CLUE references an
> encoding defined by SDP. It is up to SDP to define that encoding in whatever
> way. I.e. it may have a specific encoding and/or may also have attributes that
> define limits. CLUE groups the encodings.
[Duckworth, Mark] Sorry, I wasn't clear.  I meant the CLUE framework includes  encoding limits.  A CLUE encoding has encoding limits.  These encoding limits are expressed in SDP and referenced by CLUE protocol messages.  Does that make more sense?

> > 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.
> Again I thought we just reference the SDP encoding, not the individual SDP
> parameters in the CLUE messages?
[Duckworth, Mark] I didn't mean there are references to individual parameters.  I think your first idea is correct, a CLUE message associates a CLUE encoding with an SDP m-line and other information in SDP included with the m-line, and this includes the encoding parameters.

> > 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.
> [CNG] I think the issue is that the start of the text of section 8.1 and the
> examples was when the encoding parameters were present in CLUE itself. If
> we now say SDP contains the encoding information its not up to CLUE to say
> how these SDP parameters are interpreted. i.e. section
> values for certain aspects of the encoding." This is not the case for all SDP
> parameters/attributes. What they represent is up to the semantics of the
> SDP parameter itself.
[Duckworth, Mark] Okay, I understand that.  Further down in section 8.1 I think it explains it better, but maybe we can clean it up further.

> Also when I look at the example it certainly implies that the parameters are
> part of CLUE i.e. associated with the encoding rather than CLUE referencing
> an encoding defined elsewhere.
> E.g. CLUE has:
> Which to me at least implies they are all part of the same syntax definition.
> 
> The above SDP isn't correct but I'm just try to illustrate that it would be good
> to show the define of the parameters separate from the definition of the
> encoding groups. It could be abstracted not to have SDP.
[Duckworth, Mark] I understand.  I guess it depends on how much "syntax detail" you want to show in the examples, even though it isn't really proper CLUE data model or protocol or SDP syntax at all.  My view is the example is okay as is, without adding more syntax detail.  I thought the working group agreed in general these framework examples should be fairly high level and not get bogged down in syntax.
[Duckworth, Mark] Does anybody else have input about this?

> >> 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
> >> already consistent with this approach, because it has been our
> >> working understanding for quite a while.
> >>>>> I don't think this affects Encoding Groups - that concept will
> >>>>> still be in the framework and will need to be expressed in CLUE
> >>>>> so far in things like the signalling document, so shouldn't
> >>>>> involve a radical rethink.
> >>>>>
> >>>>> Rob
> >>>>>
> >>>>>> 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
> >>>>>>
> >>>>>>> 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

---

From: Christian Groves <[email-masked]>
Date: Thu, 05 Dec 2013 12:17:11 +1100

Hello Mark,

Yes it seems we're on the same page. With regards to the examples I 
agree that we decided to keep the framework at a higher level. Perhaps 
we could show the encoding information in a table based structure as we 
do elsewhere in CLUE?, i.e.

+=======================+=================================+
| EncodingGroup #1 | ENC0,ENC1 |
+=======================+=================================+

+=======================+=================================+
| Encodings | Parameters|
+-----------------------|---------------------------------+
| ENC0 | Media=Video |
| | maxWidth=1920|
| | maxHeight=1088|
+-----------------------|---------------------------------+
| ENC1 | Media=Video |
| | maxWidth=1200|
| | maxHeight=720 |
+=======================+=================================+

We could have a note at the start of the examples indicating that the 
information in the "encoding group" table is carried by CLUE and the 
information in the Encodings tables are expected to be carried outside 
CLUE (e.g. via SDP). I think that would make it clear.

Regards, Christian

---

From: Mary Barnes <[email-masked]>
Date: Wed, 4 Dec 2013 19:32:07 -0600

On Wed, Dec 4, 2013 at 7:17 PM, Christian Groves <
[email-masked]> wrote:

> Hello Mark,
>
> Yes it seems we're on the same page. With regards to the examples I agree
> that we decided to keep the framework at a higher level. Perhaps we could
> show the encoding information in a table based structure as we do elsewhere
> in CLUE?, i.e.
>
> information in the Encodings tables are expected to be carried outside CLUE
> (e.g. via SDP). I think that would make it clear.
>
[MB] As an individual I do not believe we want this note in the framework
document. This level of detail should be reflected in the signaling
solution document.
[/MB]

>> I think we have same understanding about the concept, but are having
>> trouble with terminology.  In any case, I think we are both agreeing on
>> using SDP to express encoding limits, but are now discussing possible
>> impact to the framework document.
>>
>> Comments inline.
>>
>> Mark
>>
>>> the
>> [Duckworth, Mark] Sorry, I wasn't clear.  I meant the CLUE framework
>> includes  encoding limits.  A CLUE encoding has encoding limits.  These
>> encoding limits are expressed in SDP and referenced by CLUE protocol
>> messages.  Does that make more sense?
>>
>> [Duckworth, Mark] I didn't mean there are references to individual
>> parameters.  I think your first idea is correct, a CLUE message associates
>> a CLUE encoding with an SDP m-line and other information in SDP included
>> with the m-line, and this includes the encoding parameters.
>>
>>> the
>>> all SDP
>> [Duckworth, Mark] Okay, I understand that.  Further down in section 8.1 I
>> think it explains it better, but maybe we can clean it up further.
>>
>>> are
>>> be good
>> [Duckworth, Mark] I understand.  I guess it depends on how much "syntax
>> detail" you want to show in the examples, even though it isn't really
>> proper CLUE data model or protocol or SDP syntax at all.  My view is the
>> example is okay as is, without adding more syntax detail.  I thought the
>> working group agreed in general these framework examples should be fairly
>> high level and not get bogged down in syntax.
>>>>>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE
>>>>>>>
>>>>>> signaling?
>>>
>>>> Hello Rob,
>>>>>>>
>>>>>>> encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps
>>>>>>>
>>>>>> etc)?
>>>>>
>>>>>> Regards, Christian
>>>>>>>
>>>>>> 9th, 2013.   If you weren't at the design team meeting and would
>>>>>>>>>>
>>>>>>>>> like
>>>

---

From: Christian Groves <[email-masked]>
Date: Thu, 05 Dec 2013 13:12:02 +1100

Hello Mary,

But doesn't the note reflect the decision we're making to define 
encoding information in SDP i.e. outside of CLUE?

I would think its important for the framework to provide this 
delineation, its also in-line with what is already in the framework in 
section 8.1 " Individual Encoding parameters are represented in SDP 
[RFC4566], not in CLUE messages." Are you suggesting that we remove that 
line?

Regards, Christian

On 5/12/2013 12:32 PM, Mary Barnes wrote:
> On Wed, Dec 4, 2013 at 7:17 PM, Christian Groves 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello Mark,
>
>     Yes it seems we're on the same page. With regards to the examples
>     I agree that we decided to keep the framework at a higher level.
>     Perhaps we could show the encoding information in a table based
>     structure as we do elsewhere in CLUE?, i.e.
>
>     We could have a note at the start of the examples indicating that
>     the information in the "encoding group" table is carried by CLUE
>     and the information in the Encodings tables are expected to be
>     carried outside CLUE (e.g. via SDP). I think that would make it clear.
>
> [MB] As an individual I do not believe we want this note in the 
> framework document. This level of detail should be reflected in the 
> signaling solution document.
> [/MB]
>
>
>     Regards, Christian
>
>
>         I think we have same understanding about the concept, but are
>         having trouble with terminology. In any case, I think we are
>         both agreeing on using SDP to express encoding limits, but are
>         now discussing possible impact to the framework document.
>
>         Comments inline.
>
>         Mark
>
>             From: Christian Groves
>             [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             To: Duckworth, Mark; [email-masked] <mailto:[email-masked]>
>         [Duckworth, Mark] Sorry, I wasn't clear. I meant the CLUE
>         framework includes encoding limits. A CLUE encoding has
>         encoding limits. These encoding limits are expressed in SDP
>         and referenced by CLUE protocol messages. Does that make more
>         sense?
>
>         [Duckworth, Mark] I didn't mean there are references to
>         individual parameters. I think your first idea is correct, a
>         CLUE message associates a CLUE encoding with an SDP m-line and
>         other information in SDP included with the m-line, and this
>         includes the encoding parameters.
>
>         [Duckworth, Mark] Okay, I understand that. Further down in
>         section 8.1 I think it explains it better, but maybe we can
>         clean it up further.
>
>         [Duckworth, Mark] I understand. I guess it depends on how much
>         "syntax detail" you want to show in the examples, even though
>         it isn't really proper CLUE data model or protocol or SDP
>         syntax at all. My view is the example is okay as is, without
>         adding more syntax detail. I thought the working group agreed
>         in general these framework examples should be fairly high
>         level and not get bogged down in syntax.
>                     From: Christian Groves
>                     [mailto:[email-masked]
>                     <mailto:[email-masked]>]
>                     <mailto:[email-masked]>
>                         I agree with Rob, and even further, I think
>                         the Framework document
>                         is
>
>                             From: clue [mailto:[email-masked]
>                             <mailto:[email-masked]>] On Behalf
>                             Of Christian
>                             Groves
>                             To: [email-masked] <mailto:[email-masked]>
>                                 expressible in SDP. The encoding
>                                 limits referred to are the
>                                 per-encoding
>
>                     limits.
>
>                                         As mentioned in the email
>                                         about the November 26th design
>                                         team
>                                         CLUE protocol, but it was
>                                         decided (amongst those on the
>                                         call)
>                                         is encountered with that
>                                         approach as details are worked
>                                         we could
>                                         to express your support for
>                                         the approach, that's also a
>                                         good idea.
>
>                                         Regards,
>                                         Mary
>                                         As WG co-chair
>
>
>                                         <mailto:[email-masked]>
>                                     [email-masked] <mailto:[email-masked]>
>                                 [email-masked] <mailto:[email-masked]>
>                             [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>