Re: Registered payload types for G.723.1/G.729
I'd recommend that as SG16 defines new encoding types that it register them with IANA.
Theoretically, someone could register your codepoints for a different algorithm.
Chip
At 01:11 PM 2/23/00 -0800, Hutton, Charles wrote:
I have the same concerns for G.729E.
Charles (Chuck) Hutton Strategic Architecture Engineering Wireless Local Technology Group AT&T Wireless Services PO Box 97059 Redmond, WA 98073 (USPS only) 9461 Willows Road Redmond, WA 98052 (FEDEX/UPS) 425-702-2938 Voice 425-702-2518 FAX charles.hutton@attws.com
From: Frank Derks[SMTP:frank.derks@PHILIPS.COM] Reply To: Mailing list for parties associated with ITU-T Study Group 16 Sent: Wednesday, February 23, 2000 8:46 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Registered payload types for G.723.1/G.729
<<File: FILE0001>> Tom,
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.
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.
Whose responsibility would it be to do so? ITU-SG16?
Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com |
taylor@NORTELNETWORKS.COM@SMTP@MAILBAG.INTEL.COM on 23/02/2000 17:24:37 Please respond to ITU-SG16@MAILBAG.INTEL.COM@SMTP Sent by: ITU-SG16@MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: Registered payload types for G.723.1/G.729 Classification: Restricted 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.
-----Original Message----- From: Frank Derks [SMTP:frank.derks@PHILIPS.COM] Sent: Tuesday, February 22, 2000 10:30 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Registered payload types for G.723.1/G.729
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.
Frank
Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com |
Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------
On Wed, 23 Feb 2000, Chip Sharp wrote:
At 01:11 PM 2/23/00 -0800, Hutton, Charles wrote:
I have the same concerns for G.729E.
I'd recommend that as SG16 defines new encoding types that it register them with IANA.
Theoretically, someone could register your codepoints for a different algorithm.
No. As I mentioned in my previous response, the registration policy has been revised. There will be no more assignments of static payload type numbers because mechanisms are now in place in various control protocols to dynamically define payload type number bindings for each session. It should be clear that static assignments cannot continue indefinitely in a small number space. This rationale is explained further in section 3 of the draft revision of RFC 1890, which is
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.txt
My understanding is that H.245 provides a means to define dynamic payload types as part of the capability exchange using OIDs. This is necessary for non-standard encodings, for example. It should be used for future standard encodings as well to dynamically map from a larger encoding name space to the small payload type number space.
In addition to whatever namespace(s) may be needed for ITU protocols, several IETF protocols use the MIME namespace, including the "rtpmap" attribute used for dynamic payload type mapping in SDP. A few weeks ago, the IETF AVT working group sent a liaison statement to SG16 (or at least attempted to) via Joerg Ott to the Rapporteur of ITU SG16 Q.13 to describe the procedure for defining new RTP payload formats. In particular, we encourage the registration of new payload formats in the MIME namespace according to the procedures in
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mime-01.txt
I don't know the details of G.729E. If it requires a different payload format than G.729, then I would encourage you to let AVT review the payload format specification and that you register the payload format in the MIME namespace. -- Steve
Steve, Thanks for the clarification. Since I was busy in Q14, I must have missed Joerg's presentation. Since H.248 uses SDP for its text version, it should be covered.
I'd just like to avoid what happened with RADIUS if possible. :-)
Chip
At 06:20 PM 2/23/00 -0800, Stephen Casner wrote:
On Wed, 23 Feb 2000, Chip Sharp wrote:
At 01:11 PM 2/23/00 -0800, Hutton, Charles wrote:
I have the same concerns for G.729E.
I'd recommend that as SG16 defines new encoding types that it register them with IANA.
Theoretically, someone could register your codepoints for a different algorithm.
No. As I mentioned in my previous response, the registration policy has been revised. There will be no more assignments of static payload type numbers because mechanisms are now in place in various control protocols to dynamically define payload type number bindings for each session. It should be clear that static assignments cannot continue indefinitely in a small number space. This rationale is explained further in section 3 of the draft revision of RFC 1890, which is
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.txt
My understanding is that H.245 provides a means to define dynamic payload types as part of the capability exchange using OIDs. This is necessary for non-standard encodings, for example. It should be used for future standard encodings as well to dynamically map from a larger encoding name space to the small payload type number space.
In addition to whatever namespace(s) may be needed for ITU protocols, several IETF protocols use the MIME namespace, including the "rtpmap" attribute used for dynamic payload type mapping in SDP. A few weeks ago, the IETF AVT working group sent a liaison statement to SG16 (or at least attempted to) via Joerg Ott to the Rapporteur of ITU SG16 Q.13 to describe the procedure for defining new RTP payload formats. In particular, we encourage the registration of new payload formats in the MIME namespace according to the procedures in
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mime-01.txt
I don't know the details of G.729E. If it requires a different payload format than G.729, then I would encourage you to let AVT review the payload format specification and that you register the payload format in the MIME namespace. -- Steve
Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------
If my memory serves me right, the "codepoints" of 4 for G.723.1 and 18 for G.729 were added to H.225.0 a while ago to reflect text in the revised RFC 1890 mentioned by Steve Casner. At one point, the payload format descriptions also matched, but I haven't compared the 2 documents lately to see if that is still the case.
Glen
Stephen Casner wrote:
On Wed, 23 Feb 2000, Chip Sharp wrote:
At 01:11 PM 2/23/00 -0800, Hutton, Charles wrote:
I have the same concerns for G.729E.
I'd recommend that as SG16 defines new encoding types that it register them with IANA.
Theoretically, someone could register your codepoints for a different algorithm.
No. As I mentioned in my previous response, the registration policy has been revised. There will be no more assignments of static payload type numbers because mechanisms are now in place in various control protocols to dynamically define payload type number bindings for each session. It should be clear that static assignments cannot continue indefinitely in a small number space. This rationale is explained further in section 3 of the draft revision of RFC 1890, which is
http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.txt
My understanding is that H.245 provides a means to define dynamic payload types as part of the capability exchange using OIDs. This is necessary for non-standard encodings, for example. It should be used for future standard encodings as well to dynamically map from a larger encoding name space to the small payload type number space.
In addition to whatever namespace(s) may be needed for ITU protocols, several IETF protocols use the MIME namespace, including the "rtpmap" attribute used for dynamic payload type mapping in SDP. A few weeks ago, the IETF AVT working group sent a liaison statement to SG16 (or at least attempted to) via Joerg Ott to the Rapporteur of ITU SG16 Q.13 to describe the procedure for defining new RTP payload formats. In particular, we encourage the registration of new payload formats in the MIME namespace according to the procedures in
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mime-01.txt
I don't know the details of G.729E. If it requires a different payload format than G.729, then I would encourage you to let AVT review the payload format specification and that you register the payload format in the MIME namespace. -- Steve
-- Glen Freundlich ggf@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA
I don't know the details of G.729E. If it requires a different payload format than G.729, then I would encourage you to let AVT review the payload format specification and that you register the payload format in the MIME namespace. -- Steve
Payload is different because the rate is different. G.729E is 11.8kbps and there is even a G.729D at 6.4kbps
See http://www.sipro.com/licensing/g729pool.htm for the details
-=Francois=-
participants (4)
-
Chip Sharp -
Francois Menard List Account -
Glen Freundlich -
Stephen Casner