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@es.net). As co-chair, I apologize that the IANA list is not up-to-date such that this confusion has arisen. -- Steve