Subject: [AVT] G.718, issue 2

From: "Glen Zorn" <[email-masked]>
Date: Tue, 7 Dec 2010 14:44:10 +0700

The L-ID (layer identifier) field of a transport block is 6 bits in length.
In the current draft, several suggestions are made on how to mitigate the
limitation of 63 layer types inherent in this length (see below).  My first
question, however, is if this is a real problem.  The draft allocates 21 or
33% of the possible types; is it really likely that new work in ITU-T will
create >42 new layers?  The existing suggestions are:

1) One suggested way to make sure we do not run out of L-ID values with the
extension modes has been to make the mapping between L-ID and layer
configuration dynamic (to be specified using SDP in session set-up).  While
this would provide effective usage of L-ID bits, it would require all
elements processing the payload to be signaling-aware. A compromise solution
would be to provide static mapping for selected layer configurations and
leave 'more exotic' cases to be dynamically mapped on session basis. The
usage of this type of approach is FFS.

2) Yet another possible way is to do similar as in the SVC RTP payload
format draft, i.e. to signal the bitrate etc. parameters for an operation
point, and signal dependency between sessions using the MMUSIC decoding
dependency draft. This way should be generic enough and applicable to future
versions of scalable codecs. However, the above methods (using detailed
layer configuration may provide more useful information as the bitrate etc.
of each layer is fixed, not as flexible as in SVC.)

3) Yet another approach is to allocate L-ID according to different mode. For
example, the mode with L1 being present and the AMR-WB compatible mode (with
L1' being present) use different value spaces of L-ID.

Can we come to consensus on the appropriate approach to take (if any)?

---

From: "Allison, Art" <[email-masked]>
Date: Tue, 7 Dec 2010 09:34:08 -0500

Perhaps another alternative is to define the value "111111" to be the escape value, which is defined now to mean that a new structure with extended space is signaled. If the code space is used, then the escape syntax is defined then.  If not, no complexity impact occurs.
Art

Art Allison
Senior Director Advanced Engineering, Science and Technology
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981
www.nab.org
Advocacy  Education  Innovation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
Sent: Tuesday, December 07, 2010 2:44 AM
To: [email-masked]
Subject: [AVT] G.718, issue 2

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 8 Dec 2010 16:17:43 +0700

Allison, Art [mailto://[email-masked]] writes:

> Perhaps another alternative is to define the value "111111" to be the
> escape value, which is defined now to mean that a new structure with
> extended space is signaled. If the code space is used, then the escape
> syntax is defined then.  If not, no complexity impact occurs.

Since the authors have expressed a concern WRT the size of the NF field as
well, might a simpler approach be to just double the size of both the L-ID &
NF fields to 12 & 4 bits respectively?  In a similar vein, the draft
currently states that values of the L-ID field > 21 are reserved but doesn't
specify any way to assign them.  This sounds like a job for IANA to me...

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 08 Dec 2010 08:46:20 -0600

On 12/08/2010 03:17 AM, Glen Zorn wrote:
> well, might a simpler approach be to just double the size of both the L-ID&
> NF fields to 12&  4 bits respectively?  In a similar vein, the draft
> currently states that values of the L-ID field>  21 are reserved but doesn't

'reserved' would mean they have no current assignments, but that those 
values should not be used; future RFCs may assign values from the 
reserved space. This is different from having a space allocated for 
assignments and an IANA registry to assign them in.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 8 Dec 2010 23:39:31 +0100

An IANA registry is primarily about ensuring that codepoints are allocated in a structured way, in particular when allocations are requested from multiple different sources.

Conversely, there is absolutely no point in an IANA registry if all the assignments in a space are made by one specification, or by revisions of that specification in the future.

Where on that scale do you believe we are?

Are there likely to be any future allocations?

regards

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Kevin P. Fleming
> Sent: Wednesday, December 08, 2010 2:46 PM
> To: [email-masked]
> Subject: Re: [AVT] G.718, issue 2
> 
> >> extended space is signaled. If the code space is used, then the 
> >> escape syntax is defined then.  If not, no complexity 
> impact occurs.
> >
> > Since the authors have expressed a concern WRT the size of the NF 
> > field as well, might a simpler approach be to just double 
> the size of 
> > both the L-ID& NF fields to 12&  4 bits respectively?  In a similar 
> > vein, the draft currently states that values of the L-ID field>  21 
> > are reserved but doesn't specify any way to assign them.  
> This sounds like a job for IANA to me...
> 
> 'reserved' would mean they have no current assignments, but 
> that those values should not be used; future RFCs may assign 
> values from the reserved space. This is different from having 
> a space allocated for assignments and an IANA registry to 
> assign them in.
> 
> --
> Kevin P. Fleming
> skype: kpfleming | jabber: [email-masked] Check us out 
> at www.digium.com & www.asterisk.org

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 9 Dec 2010 11:18:22 +0700

DRAGE, Keith (Keith) [mailto://[email-masked]] writes:

> An IANA registry is primarily about ensuring that codepoints are
> allocated in a structured way, in particular when allocations are
> requested from multiple different sources.
> 
> Conversely, there is absolutely no point in an IANA registry if all the
> assignments in a space are made by one specification, or by revisions of
> that specification in the future.
> 

That depends upon the alacrity with which we wish to publish this spec as an
RFC.

> Are there likely to be any future allocations?

According to the authors' notes in the draft, there is ongoing work in ITU-T
WRT enhancements to G.718.  The authors seem to think (please correct me if
I'm wrong!) that the draft should just wait for the ITU to finish their work
& then publish the draft as an RFC.  That's fine, assuming that there's
little or no need for G.718 support in RTP w/o those enhancements; however,
if the codec is useful now then it would seem to make sense to publish the
draft ASAP.  In that case, allocation of new layer types for the enhancement
layers would be necessary.  Of course, that could be accomplished by
publishing a new RFC obsoleting the old, but unless something else has
changed that seems like a bit of a waste.

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 9 Dec 2010 05:58:08 -0500

In that case, allocation of new layer types for the enhancement layers
would be necessary.
I don't see the need for an IANA registry. We have the "all assignments in a
space are made by one specification, or by revisions of that specification
in the future" scenario here.

All layers are defined in G.718 in the ITU-T (and perhaps future revisions
to it), and this spec is limited to provide packetization and SDP signaling
for that particular codec.

Regards
Stephen Botzko

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 9 Dec 2010 19:44:54 +0700

Stephen Botzko [mailto:[email-masked]] 
I don't see the need for an IANA registry. We have the "all assignments in a
space are made by one specification, or by revisions of that specification
in the future" scenario here.
So, are you saying that a new RFC should be published every time (+2-3 years
;-) that the ITU-T revises its spec?
All layers are defined in G.718 in the ITU-T (and perhaps future revisions
to it), and this spec is limited to provide packetization and SDP signaling
for that particular codec.  
I don't understand: the Layer Identifiers defined in the draft have only a
loose relationship to the layers defined in G.718.  Are you saying that we
should, instead, just use the layers defined in whatever version of ITU-T
G.718 that is current?

Regards
Stephen Botzko

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 9 Dec 2010 07:56:19 -0500

So, are you saying that a new RFC should be published every time (+2-3
years ;-) that the ITU-T revises its spec?
No, just saying that IANA registration doesn't seem to be necessary for
this.

Certainly some changes to the ITU recommendation will also require revision
to the packetization, but not all.   For instance, once the RFC is published
the ITU-T will almost certainly revise G.718 to make a normative reference
to the RFC for use with H.323 signaling.

Adding additional layers or new functionality might require revision of the
RFC anyway, as it is could affect the SDP signalling even if it doesn't
change the packetization.

   the Layer Identifiers defined in the draft have only a loose relationship
to the layers defined in G.718.  Are you saying that we should, instead,
just use the layers defined in whatever version of ITU-T G.718 that is
current?
Are you saying that you are carrying layers that aren't compliant with
G.718?  Or just that the layer identifiers have room for future expansion?

Stephen Botzko

On Thu, Dec 9, 2010 at 7:44 AM, Glen Zorn <[email-masked]> wrote:

> I don't see the need for an IANA registry. We have the "all assignments in
> a space are made by one specification, or by revisions of that specification
> So, are you saying that a new RFC should be published every time (+2-3
> years ;-) that the ITU-T revises its spec?
>
> I don’t understand: the Layer Identifiers defined in the draft have only a

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 9 Dec 2010 20:32:17 +0700

Stephen Botzko [mailto://[email-masked]] writes:

OK; as it sits, though, the SDP signaling seems to be a dead simple mapping
from the MIME type.

Here is the list from the draft:

                 Table 3: Layer Identification (L-ID) Values

                             L-ID    Encoded data

                           --------------------------

                               0     Empty frame

                               1     L1

                               2     L1-L2

                               3     L1-L3

                               4     L1-L4

                               5     L1-L5

                               6     L2

                               7     L2-L3

                               8     L2-L4

                               9     L2-L5

                              10     L3

                              11     L3-L4

                              12     L3-L5

                              13     L4

                              14     L4-L5

                              15     L5

                              16     L1'

                              17     L1', L3'

                              18     L1', L3', L4

                              19     L1', L3', L4-L5

                              20     G.718 SID

                              21     AMR-WB SID

                              22-63  Reserved

There is room for expansion.  As I said before, the original authors
expressed concern that 63 L-IDs might not be enough due to some work going
on in ITU-T regarding stereo and so-called Super Wideband support (which
implies that the set will change to me).  It seems a lot easier (and far
less time consuming) to me to just request a few new numbers from IANA (if
possible) than to publish an RFC (even one that is merely an update.  OTOH,
I don't really care, since I will almost certainly not be the person doing
either J.   

.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Dec 2010 14:47:34 +0100

Would some expert like to summarise to the list what work is currently ongoing on G.718 in ITU-T (if any), and what time schedules are expected to be met in those revisions.

It would be good for the working group to agree a specific version to work to, current or near future.

I've a vague recollection we may have set some longer term dates on the milestone for this because of some upcoming IYU-T revision.

Keith 

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Botzko
	Sent: Thursday, December 09, 2010 12:56 PM
	To: Glen Zorn
	Cc: DRAGE, Keith (Keith); [email-masked]
	Subject: Re: [AVT] G.718, issue 2

	   So, are you saying that a new RFC should be published every time (+2-3 years ;-) that the ITU-T revises its spec?
	No, just saying that IANA registration doesn't seem to be necessary for this.  
	
	Certainly some changes to the ITU recommendation will also require revision to the packetization, but not all.   For instance, once the RFC is published the ITU-T will almost certainly revise G.718 to make a normative reference to the RFC for use with H.323 signaling.  
	
	Adding additional layers or new functionality might require revision of the RFC anyway, as it is could affect the SDP signalling even if it doesn't change the packetization.
	
	   the Layer Identifiers defined in the draft have only a loose relationship to the layers defined in G.718.  Are you saying that we should, instead, just use the layers defined in whatever version of ITU-T G.718 that is current?
	Are you saying that you are carrying layers that aren't compliant with G.718?  Or just that the layer identifiers have room for future expansion?
	
	Stephen Botzko

		 In that case, allocation of new layer types for the enhancement layers would be necessary. 
		I don't see the need for an IANA registry. We have the "all assignments in a space are made by one specification, or by revisions of that specification in the future" scenario here.
		
		So, are you saying that a new RFC should be published every time (+2-3 years ;-) that the ITU-T revises its spec? 

		All layers are defined in G.718 in the ITU-T (and perhaps future revisions to it), and this spec is limited to provide packetization and SDP signaling for that particular codec.  
		
		I don’t understand: the Layer Identifiers defined in the draft have only a loose relationship to the layers defined in G.718.  Are you saying that we should, instead, just use the layers defined in whatever version of ITU-T G.718 that is current? 

		Regards
		Stephen Botzko