RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec
RFC 5686

[Ballot discuss]
Update discuss based on version 05, sorry for not catching this in the discussion about the proposed changes

Section 3.

  As a sub-layer, the core layer, i.e., "Layer a", MUST always be
  included.  It should be noted that the location of the core layer may
  not immediately follow MH field.  The decoder MUST always refer to
  the layer indices for proper decoding.

There seem to be a serious conflict or at least unclarity in the second sentence above. The sentence to me reads like that you are not allowed to have MH followed by SL(a) while MH|SL(b)|SL(a) is fine. However, I don't understand how you can send UEMCLIP frames in mode 0, which to my understanding only has SL(a) in them. Can you please write a more extensive description of which combinations of MH of one to 3 sublayers that are allowed and in which order.

[Ballot discuss]
This document makes significant references to G.711, yet there is no reference made to that Recommendation.

On the other hand, section 2 begins with...
  UEMCLIP is basically an enhanced version of u-law ITU-T G.711,
  otherwise known as PCMU [8].
If you would prefer to reference RFC 4856 instead of G.711, then you should do so throughout. Yet, RFC 4856 makes no mention of G.711.

The situation with these references needs to be resolved.

Furthermore, I would like to be clear on the relationship of this work to the ITU-T's work. Has the owning authority of G.711 been consulted? Are we comfortable that this development of G.711 meets with agreement from the ITU-T?

[Ballot discuss]
The Gen-ART Review by Vijay K. Gurbani on 6-Feb-2009 raised some
  concerns, and the authors agreed that changes should be made.
  However, the changes have not been made yet.

[Ballot discuss]
Section 3.

"It should be noted that the location of the core layer may
  not be located at the top"
 
What is the top, do you mean first in the payload, or first in the frame? Please clarify

Section 3.1:

For UEMCLIP streams, the
      RTP timestamp MUST advance based on a clock which is multiple of
      8000 (Hz).
     
I think this is in conflict with the Media type that says that the only valid rates are 8k and 16k. IF future updates are going to support additional rates like 32k then I recommend to update in that future document, rather than here. Any implementation needs to be updated anyway.

Section 3.1:

In cases where the audio sampling rate can change
      during a session, the RTP timestamp rate MUST equal to the maximum
      rate (in Hz) given in the mode range (see Section 6.2.1).  This
      implies that the RTP timestamp rate MUST NOT change during a
      session.  For example, during a session with 8-kHz audio sampling,
      where a transition to a 16-kHz audio sampling mode is allowed, the
      RTP time stamp must always advance using 16-kHz clock rate.
     
In the above requirement I don't think it is at all appropriate for this limitation to apply to the RTP session, only each specific RTP payload type that is using this RTP payload format. Please reformulate to restrict the scope of the rule and the explanation.

Section 3.3.1.1

The section lacks an explanation on what to do if one isn't a RTCP terminating-MCU topology. Is the values not valid? How does a client know which topologhy it is participating in. I think better explanation of this is required.

Section 3.3.1.1.

  Power #1 (PW1):  5 bits

      Signal power code of the current frame.

What is the interpretation of the 5 bits? If it is a code, where is that code defined. Please include relevant reference. If not available, please define.

Section 3.3.1.2:

  Pitch lag #1 (P1):  7 bits

      Pitch code of the current frame.  The actual pitch lag is
      calculated as P1+20 samples in 8-kHz sampling rate.  Pitch lag
      must be 20 <= pitch length <= 120.  Codes ranging between "0x65"
      and "0x7F" are not used.

Please include a reference to the definition of the pitch code.

Applies also to P2.

Section 2, and 3.3.2:

The support for multiple channels within a single bit-streams very poorly explained. I can't understand based on the explanation so far if this RTP payload format has multiple channel support or is only prepared for future extension for it. Can you please clarify this question.

If these strucutres exist to align with other format definitions then this is fine, but should be made clear. And if this already is defined, isn't it sufficient to simple reference the higher layer strucutre?

Section 4:

It should be noted that this media transcoding is useful
  only in RTP devices that terminate RTP and RTCP packets.
 
From an RTP persepctive an Translator, which include transcoders, they do not terminate RTP streams and the associated RTCP. It simply translates it. Thus the above formulation is very unfortunate.

The following sentence:

This is
  equivalent to a Point to Multipoint Using RTCP Terminating MCU (Topo-
  RTCP-terminating-MCU) in [9] and all the requirements apply.
 
But, not the only case that might result in transcoding. Also regular mixers may be performing media transcoding and thus change an incoming G.711 stream into UEMCLIP. I would recommend to not talk about in which cases in relation to the topology that needs transcoding.

Section 6.1:

Encoding Considerations:
This type is defined for transferring
      UEMCLIP-encoded data via RTP using the payload format specified in
      Section 3 "Payload Format" of RFC xxxx (this RFC).
     
This text seems to belong to the "Restriction on usage" heading that is missing. It should also say "only defined" unless a file format fulfilling the requirements in RFC 4855 exit.
   
Section 6.1 and 6.2

"  Encoding parameters:  Since this is an audio stream, the encoding
      parameters indicate the number of audio channels, and this SHOULD
      default to "1", as selected from the ones defined in Table 2.
      This is OPTIONAL."

The Channels parameter isn't defined. Despite the indications that more than one channel can be supported. Depending on the answer to the earlier question about channels either texts needs changes.

Section 6.2:

Packet time:  A frame length of any UEMCLIP is 20 ms, thus the
      argument of "a=ptime" MUST be a multiple of "20".  When not listed
      in SDP, it should also default to the minimum size: "20".

This is an unnecessary hard requirement that actually there are reasons to break. I think a SHOULD is appropriate. The reason to break it is when one in SDP Offer/answer suggest multiple payload types and there is other audio codecs that has other frame lengths then 20 ms. This as ptime is not specified on a per payload type basis.

Section 6.3.1:

In this case, the offerer MUST use the default value for
      any deleted parameters.

I think this sentence is very unfortunate. In case one uses a parameter in the future to find out support, there might not be any default values. And parameters that are defined in this specification are not unknown/undefined. Suggest deleting the sentence.

Section 6.3.1:

Can you please clarify the meaning of the "mode" parameter when offered in a sendonly media stream. I assume that it is the list of willing to use modes. Also the answers "sendonly" line, should be clarified to indicate that answerer will only send in the indicated mode(s).

[Ballot comment]
The final clause of the first sentence doesn't quite parse: "This implies that confidentiality
of the media streams is achieved by encryption by other means." 

Perhaps the following would be clearer?

"This implies that confidentiality of the media streams is achieved by encryption unless the
applicable profile specifies other means."

Magnus Nystrom's secdir review included the following suggestion for the security
considerations section:

> The security consideration section notes the risk of memory attacks due to illegal layer
> indices etc. Maybe it could also be pointed out that decoders could be configured to
> reject layer indices etc. that are outside of some specified policy?

[Ballot comment]
Section 1:

  It should be noted that, generally speaking, codecs are negotiated
  and switched using SDP exchange.
 
I think the talk about "switched" in the above sentence is potentially missleading. In an negotiated RTP session whit more than one established RTP payload format, there is no need for any SDP signalling to switch between the different RTP payload types. Thus, switched is only correct in the case one are talking about the high level action of deploying a new codec and having it replace another. Please rephrase.

Section 3.3.1.2

Frame indicator
      is equal to the difference in the RTP sequence number when one
      UEMCLIP frame is contained in a single RTP packet.

It might be better to express this as the reference is to the UEMCLip frame that has the RTP timestamp value = This frames RTP TS - K*Timestamp_rate/50. This avoids the issues with packet losses or variable number of frames in the payloads.

Section 6.1:

Rate definition: If the intention is to allow for 32k in the future, I think the best is to be clear that this format doesn't define this and indicate how an implementation of this specification should handle such a case. Explanation probably needs to be split to both this section and SDP mapping part.

Section 6.2:

The mode specification
      parameters should be defined here (see Section 6.2.1).

This sentence seems strange. First of all there are only one "mode" parameter and it is defined in this RFC. I understand that you mean:
The "mode" parameter should be included and specify the desired modes for the session.

[Ballot discuss]
This is a discuss against the RFC-editor note:

I don't think the following text belongs to this document:

  Please add the followinf title page header lines:

    Obsoletes: 3978, 4748
    Updates: 2026

Section 3.

"It should be noted that the location of the core layer may
  not be located at the top"
 
What is the top, do you mean first in the payload, or first in the frame? Please clarify

Section 3.1:

For UEMCLIP streams, the
      RTP timestamp MUST advance based on a clock which is multiple of
      8000 (Hz).
     
I think this is in conflict with the Media type that says that the only valid rates are 8k and 16k. IF future updates are going to support additional rates like 32k then I recommend to update in that future document, rather than here. Any implementation needs to be updated anyway.

Section 3.1:

In cases where the audio sampling rate can change
      during a session, the RTP timestamp rate MUST equal to the maximum
      rate (in Hz) given in the mode range (see Section 6.2.1).  This
      implies that the RTP timestamp rate MUST NOT change during a
      session.  For example, during a session with 8-kHz audio sampling,
      where a transition to a 16-kHz audio sampling mode is allowed, the
      RTP time stamp must always advance using 16-kHz clock rate.
     
In the above requirement I don't think it is at all appropriate for this limitation to apply to the RTP session, only each specific RTP payload type that is using this RTP payload format. Please reformulate to restrict the scope of the rule and the explanation.

Section 3.3.1.1

The section lacks an explanation on what to do if one isn't a RTCP terminating-MCU topology. Is the values not valid? How does a client know which topologhy it is participating in. I think better explanation of this is required.

Section 3.3.1.1.

  Power #1 (PW1):  5 bits

      Signal power code of the current frame.

What is the interpretation of the 5 bits? If it is a code, where is that code defined. Please include relevant reference. If not available, please define.

Section 3.3.1.2:

  Pitch lag #1 (P1):  7 bits

      Pitch code of the current frame.  The actual pitch lag is
      calculated as P1+20 samples in 8-kHz sampling rate.  Pitch lag
      must be 20 <= pitch length <= 120.  Codes ranging between "0x65"
      and "0x7F" are not used.

Please include a reference to the definition of the pitch code.

Applies also to P2.

Section 2, and 3.3.2:

The support for multiple channels within a single bit-streams very poorly explained. I can't understand based on the explanation so far if this RTP payload format has multiple channel support or is only prepared for future extension for it. Can you please clarify this question.

If these strucutres exist to align with other format definitions then this is fine, but should be made clear. And if this already is defined, isn't it sufficient to simple reference the higher layer strucutre?

Section 4:

It should be noted that this media transcoding is useful
  only in RTP devices that terminate RTP and RTCP packets.
 
From an RTP persepctive an Translator, which include transcoders, they do not terminate RTP streams and the associated RTCP. It simply translates it. Thus the above formulation is very unfortunate.

The following sentence:

This is
  equivalent to a Point to Multipoint Using RTCP Terminating MCU (Topo-
  RTCP-terminating-MCU) in [9] and all the requirements apply.
 
But, not the only case that might result in transcoding. Also regular mixers may be performing media transcoding and thus change an incoming G.711 stream into UEMCLIP. I would recommend to not talk about in which cases in relation to the topology that needs transcoding.

Section 6.1:

Encoding Considerations:
This type is defined for transferring
      UEMCLIP-encoded data via RTP using the payload format specified in
      Section 3 "Payload Format" of RFC xxxx (this RFC).
     
This text seems to belong to the "Restriction on usage" heading that is missing. It should also say "only defined" unless a file format fulfilling the requirements in RFC 4855 exit.
   
Section 6.1 and 6.2

"  Encoding parameters:  Since this is an audio stream, the encoding
      parameters indicate the number of audio channels, and this SHOULD
      default to "1", as selected from the ones defined in Table 2.
      This is OPTIONAL."

The Channels parameter isn't defined. Despite the indications that more than one channel can be supported. Depending on the answer to the earlier question about channels either texts needs changes.

Section 6.2:

Packet time:  A frame length of any UEMCLIP is 20 ms, thus the
      argument of "a=ptime" MUST be a multiple of "20".  When not listed
      in SDP, it should also default to the minimum size: "20".

This is an unnecessary hard requirement that actually there are reasons to break. I think a SHOULD is appropriate. The reason to break it is when one in SDP Offer/answer suggest multiple payload types and there is other audio codecs that has other frame lengths then 20 ms. This as ptime is not specified on a per payload type basis.

Section 6.3.1:

In this case, the offerer MUST use the default value for
      any deleted parameters.

I think this sentence is very unfortunate. In case one uses a parameter in the future to find out support, there might not be any default values. And parameters that are defined in this specification are not unknown/undefined. Suggest deleting the sentence.

Section 6.3.1:

Can you please clarify the meaning of the "mode" parameter when offered in a sendonly media stream. I assume that it is the list of willing to use modes. Also the answers "sendonly" line, should be clarified to indicate that answerer will only send in the indicated mode(s).

[Ballot discuss]
This is not a discuss on the document. There seems to be a problem with the data tracker tool and I am holding a discuss to make sure that positions get correctly entered for this document.

IANA Last Call comments:

Upon approval of this document, IANA will make the following
assignment in the "Audio Media Types" registry located at
http://www.iana.org/assignments/media-types/audio/

UEMCLIP [RFC-avt-rtp-uemclip-04]

We understand the above to be the only IANA Action for this document.

RFC 4485 requires new registration such as this to provide a specification. The text says

    Published specification:
          A description of the media encoding and a specification of the
          payload format must be provided, usually by reference to an
          RTP payload format specification RFC.

This is required so that an implementer can build interoperable devices that can receive and send this media type. This draft does not provide a reference to something that describes how the encoder or decoder of the lower or upper band information works. The draft need to reference to a specification that describes this to move forward.

Document Shepherd Write-Up

    (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The document shepherd is Roni Even. I have reviewed the document, 
and believe it is ready for publication.

    (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document is a payload specification. The document went through two
WGLC (on 02 and 03 versions). The document shepherd has no concerns
about the review process.

    (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No concerns.

    (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the  document,
          or has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this
          document been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No concerns. There is no disclosed IPR on this document.

    (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The document has good consensus from the WG.

    (1.f)  Has anyone threatened an appeal or otherwise indicated 
          extreme discontent?  If so, please summarize the areas of
          conflict in separate email messages to the Responsible Area
          Director.  (It  should be in a separate email because this
          questionnaire is entered into the ID Tracker.)

No.

    (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the 
          document  met all formal review criteria it needs to, such as
          the MIB Doctor, media type and URI type reviews?

The idnits tool reports no nits.

Media type review was conducted starting February 26th 2008, with no
objections.

    (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents 
          that  are not ready for advancement or are otherwise in an
          unclear state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative 
          references that are downward references, as described in
          [RFC3967]?  If so, list these downward references to support
          the Area Director in the Last Call procedure for them
          [RFC3967].

References have been split. There are no normative references to 
internet-drafts, and no normative down-references.

    (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, and appears consistent with
this document, and the media type registration rules.

    (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

SDP examples appear to be correct.

    (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
              Relevant content can frequently be found in the abstract
              and/or introduction of the document.  If not, this may be
              an indication that there are deficiencies in the abstract
              or introduction.

This document describes the RTP payload format of a mU-law Embedded
Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec
of ITU-T G.711.  The bitstream has a scalable structure with an embedded
u-law bitstream, also known as PCMU, thus providing a handy  transcoding
operation between narrowband and wideband speech.

          Working Group Summary
              Was there anything in WG process that is worth noting? 
              For example, was there controversy about particular
              points or were there decisions where the consensus was
              particularly rough?

This is a reasonably standard RTP payload format. The document has been
reviewed by the AVT working group and all open issues were addressed

          Document Quality
              Are there existing implementations of the protocol? 
              Have a significant number of vendors indicated their plan
              to implement the specification?  Are there any reviewers
              that merit special mention as having done a thorough review,
              e.g., one that resulted in important changes or a
              conclusion that the document had no substantive 
              issues?  If  there was a MIB Doctor, Media Type or other
              expert review, what was its course (briefly)?  In the case
              of a Media Type review, on what date was the request posted?

Media type review was conducted starting 26 February 2008, with no
objections raised. There is at least one implementation.

          Personnel
              Who is the Document Shepherd for this document?  Who is 
              the Responsible Area Director?

Roni Even is the document shepherd.

The responsible area director is Cullen Jennings.