Registered payload types for G.723.1/G.729

Stephen Casner casner at CISCO.COM
Wed Feb 23 16:59:02 EST 2000


Replies inline to 4 messages on this topic.

On Tue, 22 Feb 2000, Frank Derks wrote:

> H.225.0 specifies that the payload types for G.723.1 and G.729 are 4
> and 18 respectively.  When I take a look at the registered payload
> types at the IANA, these two codecs are not listed.
>
> Does this mean that the IANA list is not up-to-date or that these
> codecs are not officially registered.

Correct, the IANA list is not up-to-date.  I have provided an update
to IANA, but it has not been put into place.

The updated information is in the Internet-Draft which revises RFC
1890 for transition from Proposed to Draft Standard status.

http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.txt
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.ps

(The PostScript version has changebars.)

IANA may be waiting until the publication of this draft as an RFC,
though I would prefer that it be done now.



On Tue, 22 Feb 2000, Nancy-M Greene wrote:

> Quoting from H.248 Appendix A, middle of the 2nd paragraph:
> "For example, G.711A-law is called PCMA in the SDP, and
> is assigned profile 0. G.723 is profile 4, and H263 is
> profile 34. See also
> http://www.isi.edu/in-notes/iana/assignments/rtp-parameters "
>
> The URL above is supposed to be an up to date list, it has G.723.1 but it
> does not have info on
> the G.729 profile.

The use of the word "profile" in the above does not match the RTP
terminology.  It should be "payload type" in the first paragraph when
referring to the number assignments.

The main RTP spec, RFC 1889 and the Internet-Draft revision of it
(draft-ietf-avt-rtp-new-06.txt, .ps), specifies that profiles will be
needed to adapt RTP to specific classes of applications.  So far, only
one profile has been published, namely RFC 1890 (and the draft
revision mentioned above).

In addition to profiles, the RTP spec specifies that "payload format"
will be defined to specify how particular kinds of information (e.g.,
media encodings) will be carried in RTP.  The A/V Profile, RFC 1890,
specifies some audio payload formats, including G.723.1 and G.729, and
it refers to separate documents for others.  In addition, RFC 1890 and
its draft revision assign static payload type numbers to some of the
payload formats, including 0 for PCMU (G.711), 4 for G723 (G.723.1),
and 18 for G729 (G.729 and Annex A).



On Wed, 23 Feb 2000, Tom-PT Taylor wrote:

> As I understand it (and I'd better be right, because I have to do similar
> things for H.248!) the stuff initially defined in the RFC that sets up the
> registration process (RFC 1890) does not go into the IANA database -- only
> subsequent registrations.

Well, actually, the IANA database was populated initially from RFC
1890, and a few additions have been made to the database.  Those
additions, plus some more, have been incorporated into the draft
updated of RFC 1890, draft-ietf-avt-profile-new-08.txt (see URL
above).

Please also note that this draft revises the registration policy.
There will be no more assignments of static payload type numbers
because mechanisms are now in place in various control protocols
(including, I believe, H.245) to dynamically define payload type
number bindings for each session.  The rationale is explained in the
draft.


On Wed, 23 Feb 2000, Frank Derks wrote:

> section 3 of RFC1890 indeed specifies how additional payload types
> have to be registered with the IANA.  Table 2 in section 7 specifies
> the assigned (and unassigned) payload types at the time of
> publication of the RFC (presumably). This table is no longer in line
> with the table that can be found at the IANA Web site
> (http://www.isi.edu/in-notes/iana/assignments/rtp-parameters),
> however.

Yes, the IANA database does update RFC 1890, but as explained above,
the IANA database is not up to date with the further assignments that
have been made by the IETF AVT working group.  IANA has been informed
of these assignments.  (Note that IANA is the authority to make the
assignments, but relies on experts, such as AVT, for guidance in
deciding what assignments should be made).

> Since G.729 is not present in either of these tables, it would seem
> that somebody will need to undertake the action to do so. Especially
> because H.225.0 _does_ specify a payload type for G.729 and I think
> it is desirable that the code that is being used is not assigned
> (inadvertently) to some other codec.

It is already done.

> Whose responsibility would it be to do so? ITU-SG16?

The IETF AVT working group requests that such issues be brought to our
attention (mailing list rem-conf at es.net).  As co-chair, I apologize
that the IANA list is not up-to-date such that this confusion has
arisen.
                                                        -- Steve



More information about the sg16-avd mailing list