Dear colleagues,
For your information, the results of SG 16 meetings are posted on the WEB at
http://www.itu.int/ITU-T/studygroups/com16/results.html
Thanks to the rapporteurs who put together the executive summaries! There
you also find the list of (with links to) documents approved, etc.
Best regards,
Simao
=====================================================================
Simão Ferraz de Campos Neto Counsellor, ITU-T SG 16
International Telecommunication Union Tel: +41-22-730-6805
Place des Nations Fax: +41-22-730-5853
Geneva CH1211 - Switzerland E-mail: simao.campos(a)itu.int
=====================================================================
***** Practice random kindness and senseless acts of beauty *****
=====================================================================
Dear SG16 experts,
This is a posting from Q.4 Rapporteur. We discussed the subject matter in
Geneva and its outcome is contained in the WP2 meeting report:
http://standard.pictel.com/ftp/avc-site/0210_Gen/
WP2_Report_TD65_revised.zip -- report of the discussions
Q.4 report refers to the H.ladap workplan in TD-61 (WP2). This document is
now available at the above place as:
Directory_Services_Workplan.zip
Your contributions are welcome toward the next Rapporteur meeting planned
next February.
Best regards,
OKUBO Sakae
e-mail: okubo(a)giti.waseda.ac.jp
*******************************************************************
YRP Office
Global Information and Telecommunication Institute (GITI)
Waseda University
YRP Ichibankan 312 Tel: +81 468 47 5406
3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413
239-0847 Japan
GITI Headquarter
29-7 Waseda University Bldg. Tel: +81 3 5286 3831
1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832
169-0051 Japan
*******************************************************************
--
$BBg5WJ] (B $B\F (B
e-mail: okubo(a)giti.waseda.ac.jp
*************************************************************
$B") (B239-0847
$B2#?\2l;T8w$N5V (B3-4 YRP $B#1HV4[ (B312 Tel: 0468 47 5406
$BAa0pEDBg3X9q:]>pJsDL?.8&5f%;%s%?!< (BYRP $BJ,<< (B Fax: 0468 47 5413
$B") (B169-0051 $B!!!!!!!!!!!!!!!!!!!! (B
$BEl5~ET?7=I6h@>Aa0pED (B1-3-10 $B!!!! (BTel: 03 5286 3831
$BAa0pEDBg3X (B29-7 $B9f4[!!!!!!!!!!!! (B Fax: 03 5286 3832
$BAa0pEDBg3X9q:]>pJsDL?.8&5f%;%s%?!< (B
*************************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
Dear Mr. Bhargava,
At 14:49 -0500 02/10/28, Vivek Bhargava wrote:
>I have uploaded the H.323 Implementers Guide as submitted for
>approval to the incoming directory of the PictureTel site. Please
>move it to the appropriate directory - Geneva_0210.
It is now available at the following place:
http://standard.pictel.com/ftp/avc-site/0210_Gen/IG_H323-October2002.zip
--
Best regards,
OKUBO Sakae
e-mail: okubo(a)giti.waseda.ac.jp
*******************************************************************
YRP Office
Global Information and Telecommunication Institute (GITI)
Waseda University
YRP Ichibankan 312 Tel: +81 468 47 5406
3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413
239-0847 Japan
GITI Headquarter
29-7 Waseda University Bldg. Tel: +81 3 5286 3831
1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832
169-0051 Japan
*******************************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
Dear SG16 experts,
I have placed the WP2 reports at the following place:
http://standard.pictel.com/ftp/avc-site/0210_Gen/
WP2_Report_TD64_revised.zip -- list of consented and approved texts
WP2_Report_TD65_revised.zip -- report of the discussions
WP2_Report_TD66_plen.zip -- liaisons statements
WP2_Report_TD67_plen.zip -- interim Rapporteur meeting
Please note that the next Rapporteur meeting is planned during 11-14
February 2003. Its details are yet to be fixed.
Using this opportunity, I would request Rapporteurs and Editors to upload
the output documents at
ftp://standard.pictel.com/avc-site/Incoming/
Best regards,
OKUBO Sakae
e-mail: okubo(a)giti.waseda.ac.jp
*******************************************************************
YRP Office
Global Information and Telecommunication Institute (GITI)
Waseda University
YRP Ichibankan 312 Tel: +81 468 47 5406
3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413
239-0847 Japan
GITI Headquarter
29-7 Waseda University Bldg. Tel: +81 3 5286 3831
1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832
169-0051 Japan
*******************************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
Actually, all I meant to do was to provide a neutral summary. Consultations
within my organization seem to tend toward the point of view that the
discrepancy is not a big deal and it would be better to preserve backward
compatibility.
-----Original Message-----
From: Rajesh Kumar [mailto:rkumar@cisco.com]
Sent: Thursday, October 17, 2002 2:35 PM
To: Taylor, Tom-PT [CAR:B602:EXCH]
Cc: tsg11bicc(a)ties.itu.ch; tsg11q15(a)ties.itu.ch; ITU-SG16(a)echo.jf.INTEL.COM;
avt(a)ietf.org; mmusic(a)ietf.org; hwildfeu(a)cisco.com; mgarakan(a)cisco.com;
ddeliber(a)cisco.com; Michael Frendo; Cary FitzGerald; Richard Platt;
oran(a)cisco.com; mmostafa(a)cisco.com
Subject: Re: FW: [MMUSIC] Seeking input from G.726 ADPCM implementers
Steve and AVT/MMUSIC colleagues,
Our position, which has not changed since we brought up this issue to the
notice of the IETF, is similar to Tom's. We would like to see the
packetization of G.726 over RTP be made identical to what is defined for
AAL2 in the ITU I.366.2 recommendation. In this regard, we strongly
recommend that the audio MIME subtypes G726-16, G726-24, G726-32, and
G726-40 be aligned to the ITU I.366.2 recommendation. This alignment would
include the static payload type 2.
If there is a need to interoperate with the "other," non-ITU packing
scheme, we recommend that new MIME types be defined for those non-ITU
schemes rather than for ITU-compatible schemes, which we think should be
associated with the current MIME definitions.
Rajesh Kumar
Cisco Systems
At 08:33 AM 10/15/2002 -0400, Tom-PT Taylor wrote:
For your action if it affects you. There is a clash between the
packetization of G.726 over RTP and AAL2, and a proposal to adopt the AAL2
packetization universally. Comments are requested.
-----Original Message-----
From: Stephen Casner [mailto:casner@packetdesign.com]
Sent: Tuesday, October 15, 2002 1:31 AM
To: mmusic(a)ietf.org
Subject: [MMUSIC] Seeking input from G.726 ADPCM implementers
The IETF Audio/Video Transport working group is seeking input from any
implementers of systems using the G.726 ADPCM audio encoding, in particular
any that use the MIME audio subtypes G726-16, G726-24, G726-32, and G726-40
or the RTP static paylod type 2 for G726-32.
This notice is being sent to multiple mailing lists to reach as many
interested parties as possible; please reply only to avt(a)ietf.org.
Background:
The AVT working group is seeking to advance the Real-time Transport Protocol
(RTP) and its associated Profile for A/V Conferences (RFCs 1889 and 1890,
respectively) to Draft Standard status. Two drafts have been prepared to
revise these RFCs for advancement:
draft-ietf-avt-rtp-new-11.txt
draft-ietf-avt-profile-new-12.txt
These drafts have been "tentatively approved" for publication by the IESG.
In addition, a new companion draft has been approved for publication as a
Proposed Standard to specify MIME subtype registrations for all the encoding
names defined in the RTP Profile:
draft-ietf-avt-rtp-mime-06.txt
Issue:
The packetization of G.726 audio specified in the RTP Profile packs audio
samples into octets beginning with the least-significant bit of the octet.
This is at odds with the packetization of G.726 audio for ATM AAL2 transport
specified in ITU-T Recommendation I.366.2 Annex E, which begins with the
most-significant bit. Implementers of systems that operate with both
transports or gateway between the two have requested that the RTP
packetization be changed to match the I.366.2 packetization to avoid
requiring two different DSP implementations and/or translation between
packings.
Both specifications have existed for some time: I.366.2 has been an approved
standard since 1999, and the packing for the G726-32 rate has been part of
the RTP Profile drafts since 1997. Therefore, implementations of both
packings are likely to exist. Furthermore, since the RTP Profile did not
include packetizations for rates other than 32K until 2001, some RTP
implementations may have used the I.366.2 packings for those rates. As a
consequence, there is no course of action that will make everyone happy.
Proposal:
After consultation with the IETF Transport Area Directors, it is proposed
that the draft RTP Profile packetization be changed to be consistent with
I.366.2 Annex E before it is published as an RFC. The MIME subtype
registrations for G726-16, G726-24, G726-32, and G726-40 in
draft-ietf-avt-rtp-mime-06, which refer to the specification of the
packetizations in draft-ietf-avt-profile-new-12, would therefore apply to
the changed packetization. In addition, RTP static payload type 2, which is
bound to the G726-32 encoding and packetization by
draft-ietf-avt-profile-new-12, would also change its meaning.
Consequences:
We have already heard from one vendor that has implemented the
packetizations according to the current RTP Profile draft and therefore
objects to the change. Any such systems already in the field would produce
garbled audio when interoperated with RFC-compliant implementations, and not
detect the error. This is a significant consideration, although draft
specifications are not guaranteed to remain unchanged.
We have also been informed that the format for G.726 audio in the Voice
Profile for Internet Mail (RFC 2421/2) uses the same sample packing as
currently specified in the RTP Profile draft. This is consistent with ITU-T
Recommendation X.420 for X.400 mail. Since the VPIM systems use MIME type
audio/32KADPCM rather than audio/G726-32, there would not be conflict in
meaning if the latter were changed as proposed. However, voicemail systems
that transmit messages over RTP would be forced to reformat the data.
********************************************************************
* We are seeking statements from interested parties both for and *
* against this proposal, particularly with motivations. *
********************************************************************
_______________________________________________
mmusic mailing list
mmusic(a)ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
Steve and AVT/MMUSIC colleagues,
Our position, which has not changed since we brought up this issue to the
notice of the IETF, is similar to Tom's. We would like to see the
packetization of G.726 over RTP be made identical to what is defined for
AAL2 in the ITU I.366.2 recommendation. In this regard, we strongly
recommend that the audio MIME subtypes G726-16, G726-24, G726-32, and
G726-40 be aligned to the ITU I.366.2 recommendation. This alignment
would include the static payload type 2.
If there is a need to interoperate with the "other," non-ITU packing
scheme, we recommend that new MIME types be defined for those non-ITU
schemes rather than for ITU-compatible schemes, which we think should be
associated with the current MIME definitions.
Rajesh Kumar
Cisco Systems
At 08:33 AM 10/15/2002 -0400, Tom-PT Taylor wrote:
>For your action if it affects you. There is a clash between the
>packetization of G.726 over RTP and AAL2, and a proposal to adopt the AAL2
>packetization universally. Comments are requested.
>
>-----Original Message-----
>From: Stephen Casner
>[<mailto:casner@packetdesign.com>mailto:casner@packetdesign.com]
>Sent: Tuesday, October 15, 2002 1:31 AM
>To: mmusic(a)ietf.org
>Subject: [MMUSIC] Seeking input from G.726 ADPCM implementers
>
>The IETF Audio/Video Transport working group is seeking input from any
>implementers of systems using the G.726 ADPCM audio encoding, in
>particular any that use the MIME audio subtypes G726-16, G726-24, G726-32,
>and G726-40 or the RTP static paylod type 2 for G726-32.
>
>This notice is being sent to multiple mailing lists to reach as many
>interested parties as possible; please reply only to avt(a)ietf.org.
>
>Background:
>
>The AVT working group is seeking to advance the Real-time Transport
>Protocol (RTP) and its associated Profile for A/V Conferences (RFCs 1889
>and 1890, respectively) to Draft Standard status. Two drafts have been
>prepared to revise these RFCs for advancement:
>
> draft-ietf-avt-rtp-new-11.txt
> draft-ietf-avt-profile-new-12.txt
>
>These drafts have been "tentatively approved" for publication by the
>IESG. In addition, a new companion draft has been approved for
>publication as a Proposed Standard to specify MIME subtype registrations
>for all the encoding names defined in the RTP Profile:
>
> draft-ietf-avt-rtp-mime-06.txt
>
>Issue:
>
>The packetization of G.726 audio specified in the RTP Profile packs audio
>samples into octets beginning with the least-significant bit of the
>octet. This is at odds with the packetization of G.726 audio for ATM AAL2
>transport specified in ITU-T Recommendation I.366.2 Annex E, which begins
>with the most-significant bit. Implementers of systems that operate with
>both transports or gateway between the two have requested that the RTP
>packetization be changed to match the I.366.2 packetization to avoid
>requiring two different DSP implementations and/or translation between
>packings.
>
>Both specifications have existed for some time: I.366.2 has been an
>approved standard since 1999, and the packing for the G726-32 rate has
>been part of the RTP Profile drafts since 1997. Therefore,
>implementations of both packings are likely to exist. Furthermore, since
>the RTP Profile did not include packetizations for rates other than 32K
>until 2001, some RTP implementations may have used the I.366.2 packings
>for those rates. As a consequence, there is no course of action that will
>make everyone happy.
>
>Proposal:
>
>After consultation with the IETF Transport Area Directors, it is proposed
>that the draft RTP Profile packetization be changed to be consistent with
>I.366.2 Annex E before it is published as an RFC. The MIME subtype
>registrations for G726-16, G726-24, G726-32, and G726-40 in
>draft-ietf-avt-rtp-mime-06, which refer to the specification of the
>packetizations in draft-ietf-avt-profile-new-12, would therefore apply to
>the changed packetization. In addition, RTP static payload type 2, which
>is bound to the G726-32 encoding and packetization by
>draft-ietf-avt-profile-new-12, would also change its meaning.
>
>Consequences:
>
>We have already heard from one vendor that has implemented the
>packetizations according to the current RTP Profile draft and therefore
>objects to the change. Any such systems already in the field would
>produce garbled audio when interoperated with RFC-compliant
>implementations, and not detect the error. This is a significant
>consideration, although draft specifications are not guaranteed to remain
>unchanged.
>
>We have also been informed that the format for G.726 audio in the Voice
>Profile for Internet Mail (RFC 2421/2) uses the same sample packing as
>currently specified in the RTP Profile draft. This is consistent with
>ITU-T Recommendation X.420 for X.400 mail. Since the VPIM systems use
>MIME type audio/32KADPCM rather than audio/G726-32, there would not be
>conflict in meaning if the latter were changed as proposed. However,
>voicemail systems that transmit messages over RTP would be forced to
>reformat the data.
>
>********************************************************************
>* We are seeking statements from interested parties both for and *
>* against this proposal, particularly with motivations. *
>********************************************************************
>
>_______________________________________________
>mmusic mailing list
>mmusic(a)ietf.org
><https://www1.ietf.org/mailman/listinfo/mmusic>https://www1.ietf.org/mailman/listinfo/mmusic
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
There is a sample searchable directory that returns users and h323
dialing information at:
https://videnet.unc.edu/vide-dod/
This is a web-based application that searches an underlying LDAP server
that uses commObject. You can see how the commURI is used to link the
user to an endpoint. You can also see how the label in commURI is used
to allow users to create a friendly 'Endpoint Name' for their endpoint.
This also demonstrates how endpoints can be associated with users (like
'John') or resources (like 'Conference Room 212').
Try searching for 'Jo' or all users in the United States (this second
search will take a little while).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
Dear Christian and all,
At 19:57 +1000 02/10/17, Christian Groves wrote:
>I have uploaded a number of editor's drafts incoming to the SG16 meeting:
>ftp://standard.pictel.com/avc-site/Incoming/
>
> DC-xxx_semiperm_pkg.zip
> TD-xx_ExtH324_Packages.zip
> TD-xx_H223Multiplex.zip
> TD-xx_LineTest_Packages.zip (H.248.17)
> TD-xx_Packages_Supplement.zip
> TD-xx_Profile_Packages.zip
>
>These will be moved to the directory:
>ftp://standard.pictel.com/avc-site/0210_Gen/
>so if you can't find the files in Incoming theywill be the 0210_Gen directory.
They are now in the ultimate home.
Best regards,
OKUBO Sakae
e-mail: okubo(a)giti.waseda.ac.jp
*******************************************************************
YRP Office
Global Information and Telecommunication Institute (GITI)
Waseda University
YRP Ichibankan 312 Tel: +81 468 47 5406
3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 468 47 5413
239-0847 Japan
GITI Headquarter
29-7 Waseda University Bldg. Tel: +81 3 5286 3831
1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832
169-0051 Japan
*******************************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
G'Day,
I have uploaded a number of editor's drafts incoming to the SG16 meeting:
ftp://standard.pictel.com/avc-site/Incoming/
DC-xxx_semiperm_pkg.zip
TD-xx_ExtH324_Packages.zip
TD-xx_H223Multiplex.zip
TD-xx_LineTest_Packages.zip (H.248.17)
TD-xx_Packages_Supplement.zip
TD-xx_Profile_Packages.zip
These will be moved to the directory:
ftp://standard.pictel.com/avc-site/0210_Gen/
so if you can't find the files in Incoming they will be the 0210_Gen directory.
Regards, Christian
Terry L Anderson wrote:
>
> Packages for these and other line tests are being developed and will be
> published as H.248.17. Christian Groves is the editor and the lastest
> draft will be presented to the ITU SG16 meeting next week. I don't
> believe that Christian has uploaded a copy to the sg16 draft avc-site
> but perhaps he will send you a copy or upload one to the avc-site.
>
> Srinivasan Krishnamoorthy wrote:
>
> >Hi,
> > Need help with ISUP TEST calls..
> >
> > Do we have ways to do the following in MEGACO .. are there
> > any published extensions to tonegen..
> >
> > testline (105) - automatic transmission measurement test (MGCP T/tl)
> > milliwatt (102)
> >
> > and other testcall codes ..
> >
> >Thank you very much.
> >-Srini
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco(a)ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
>
> --
>
> ------------------------------------------------------------
> Terry L Anderson, CMTS mailto:tla@lucent.com
> Tel:732.949.5628 Fax:732.949.7016
> Lucent Technologies/INS/Voice Over IP Access Networks
> Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>
> _______________________________________________
> Megaco mailing list
> Megaco(a)ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco(a)ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
For your action if it affects you. There is a clash between the
packetization of G.726 over RTP and AAL2, and a proposal to adopt the AAL2
packetization universally. Comments are requested.
-----Original Message-----
From: Stephen Casner [mailto:casner@packetdesign.com]
Sent: Tuesday, October 15, 2002 1:31 AM
To: mmusic(a)ietf.org
Subject: [MMUSIC] Seeking input from G.726 ADPCM implementers
The IETF Audio/Video Transport working group is seeking input from any
implementers of systems using the G.726 ADPCM audio encoding, in particular
any that use the MIME audio subtypes G726-16, G726-24, G726-32, and G726-40
or the RTP static paylod type 2 for G726-32.
This notice is being sent to multiple mailing lists to reach as many
interested parties as possible; please reply only to avt(a)ietf.org.
Background:
The AVT working group is seeking to advance the Real-time Transport Protocol
(RTP) and its associated Profile for A/V Conferences (RFCs 1889 and 1890,
respectively) to Draft Standard status. Two drafts have been prepared to
revise these RFCs for advancement:
draft-ietf-avt-rtp-new-11.txt
draft-ietf-avt-profile-new-12.txt
These drafts have been "tentatively approved" for publication by the IESG.
In addition, a new companion draft has been approved for publication as a
Proposed Standard to specify MIME subtype registrations for all the encoding
names defined in the RTP Profile:
draft-ietf-avt-rtp-mime-06.txt
Issue:
The packetization of G.726 audio specified in the RTP Profile packs audio
samples into octets beginning with the least-significant bit of the octet.
This is at odds with the packetization of G.726 audio for ATM AAL2 transport
specified in ITU-T Recommendation I.366.2 Annex E, which begins with the
most-significant bit. Implementers of systems that operate with both
transports or gateway between the two have requested that the RTP
packetization be changed to match the I.366.2 packetization to avoid
requiring two different DSP implementations and/or translation between
packings.
Both specifications have existed for some time: I.366.2 has been an approved
standard since 1999, and the packing for the G726-32 rate has been part of
the RTP Profile drafts since 1997. Therefore, implementations of both
packings are likely to exist. Furthermore, since the RTP Profile did not
include packetizations for rates other than 32K until 2001, some RTP
implementations may have used the I.366.2 packings for those rates. As a
consequence, there is no course of action that will make everyone happy.
Proposal:
After consultation with the IETF Transport Area Directors, it is proposed
that the draft RTP Profile packetization be changed to be consistent with
I.366.2 Annex E before it is published as an RFC. The MIME subtype
registrations for G726-16, G726-24, G726-32, and G726-40 in
draft-ietf-avt-rtp-mime-06, which refer to the specification of the
packetizations in draft-ietf-avt-profile-new-12, would therefore apply to
the changed packetization. In addition, RTP static payload type 2, which is
bound to the G726-32 encoding and packetization by
draft-ietf-avt-profile-new-12, would also change its meaning.
Consequences:
We have already heard from one vendor that has implemented the
packetizations according to the current RTP Profile draft and therefore
objects to the change. Any such systems already in the field would produce
garbled audio when interoperated with RFC-compliant implementations, and not
detect the error. This is a significant consideration, although draft
specifications are not guaranteed to remain unchanged.
We have also been informed that the format for G.726 audio in the Voice
Profile for Internet Mail (RFC 2421/2) uses the same sample packing as
currently specified in the RTP Profile draft. This is consistent with ITU-T
Recommendation X.420 for X.400 mail. Since the VPIM systems use MIME type
audio/32KADPCM rather than audio/G726-32, there would not be conflict in
meaning if the latter were changed as proposed. However, voicemail systems
that transmit messages over RTP would be forced to reformat the data.
********************************************************************
* We are seeking statements from interested parties both for and *
* against this proposal, particularly with motivations. *
********************************************************************
_______________________________________________
mmusic mailing list
mmusic(a)ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
