- sg16-avd - lists.packetizer.com

FW: Use of RTCP statistics for estimating QoS of VoIP
by Alan Clark 08 Nov '02

08 Nov '02

For some reason recent messages seem not to be sent by the reflector (?) hence I am forwarding this directly Alan -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Friday, November 08, 2002 12:29 PM To: 'frank.derks(a)philips.com' Cc: 'ITU-SG16(a)echo.jf.INTEL.COM' Subject: RE: Use of RTCP statistics for estimating QoS of VoIP Frank I did suggest (via Mike Buckley) that the following be added to H.460.9 however don't know if it was actually included. " It should be noted that RTCP reports were not originally intended to provide accurate QoS metrics but for informative exchanges between endpoints to support possible dynamic configuration. According to RFC1889 (a) received packet count may include duplicate packets and hence it is possible to report negative packet loss (b) reported mean packet-to-packet delay variation (jitter) is averaged over the last 16 received packets and hence provides information only on the 160-480mS period immediately preceding transmission of the RTCP report." I do agree with you that potential implementors may well feel uncomfortable that the Recommendation in its initial form contains information that has little or no value. I am even more concerned that less well informed implementors may accept what is in the Recommendation as being "sufficient" and hence attempt to manage VoIP services with metrics that can be quite misleading. Regards Alan -----Original Message----- From: frank.derks(a)philips.com [mailto:frank.derks@philips.com] Sent: Friday, November 08, 2002 2:46 AM To: alan(a)TELCHEMY.COM Cc: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Alan, I certainly agree that, if the main body of the Recommendation covers metrics that are of little practical use of the recipient of these metrics, the Recommendation can be misleading. Only with the proper background information will the reader be able to distinguish the real value in the particular metrics. I feel somewhat uncomfortable when the main body of a Recommendation provides me with something that is of little value, but which can be extended to include more useful information. A possible way "out of this", is to include some text that clearly explains the situation and that reflects the concerns that were raised and agreed upon. Regards, Frank

1 0

Re: Use of RTCP statistics for estimating QoS of VoIP
by frank.derks＠PHILIPS.COM 08 Nov '02

08 Nov '02

Alan, I certainly agree that, if the main body of the Recommendation covers metrics that are of little practical use of the recipient of these metrics, the Recommendation can be misleading. Only with the proper background information will the reader be able to distinguish the real value in the particular metrics. I feel somewhat uncomfortable when the main body of a Recommendation provides me with something that is of little value, but which can be extended to include more useful information. A possible way "out of this", is to include some text that clearly explains the situation and that reflects the concerns that were raised and agreed upon. Regards, Frank Bob I appreciate that a mechanism was provided to permit extension of H.460.9 and that it was agreed to incorporate the RTCP Extensions, once standardized. This does make a lot of sense and would definitely accomodate the new metrics when available. The reason behind my email yesterday was that we often find that equipment manufacturers, service providers and network managers don't understand this area as well as those who are actively conducting R&D in this area, and hence in this case they may assume that RFC1889 metrics are "good" for monitoring VoIP QoS since they are contained in H.460.9. This is already a continual re-education process with the metrics in RFC1889 .. their inclusion in H.460.9 will make the task even more difficult. People within the industry have great respect for the ITU, understand that there is an extensive process of technical discussion and review that is part of the process of developing ITU standards, and hence place considerable faith in the technical content of ITU Recommendations. In this specific case H.460.9 contains metrics which are known to be inadequate for the purpose of measuring VoIP QoS and hence there is a risk of deployment of an incorrect or inappropriate element due to its incorporation in an ITU Recommendation. I am not trying to be "difficult" but tried to input essentially the same viewpoints prior to the SG16 meeting and am genuinely concerned over the outcome. Regards Alan Clark -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Robert R. Gilman Sent: Wednesday, November 06, 2002 8:13 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Alan- Mike Buckley brought up the same questions you raise at the last SG16 meeting. I don't believe anyone objects to your arguments, and, in fact, the resulting work, H.460.9, was modified to permit extension to other measures and the exclusion of the current, IETF-standardized, measures. Once the IETF draft you reference becomes a standard, it will be easy to refer to the resulting RFC and to incorporate the resulting measures as appropriate. In the meantime, you have the option to use the existing measures and, through the definition of non-standard elements, any other measures you wish to implement on a permanent or trial basis. It seemed better to set the framework now, so that implementation and use can begin, and to do so in such a way that future improvements may be incorporated quickly and easily. Does this make sense? -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868 Alan Clark wrote: > > Paul > > I am responding to the recent SG16 email that encouraged direct input from > those not participating directly in the work of the Study Group. > > One particular recent issue relates to the recent addition of QoS reporting > based on RTCP statistics. We have spent the last three years analyzing and > modeling the effects of IP network impairments on VoIP and would like to > share our experience on this issue. > > RTCP statistics were intended to provide a "rough" real time feedback > between endpoints to give some sense of network quality and facilitate > potential adaptation. IP network impairments are transient in nature and > the "averaged" metrics that RFC1889 produces are as a result very > misleading. The addition of QoS reporting based on RFC1889 metrics is, in > our opinion, a backward step as it infers that these statistics are useful > for VoIP quality estimation whereas they are in fact almost meaningless. > > (i) Packet Loss - counts > RFC1889 counts of loss are not compensated for duplicate packets, hence it > is possible to have incorrect and even negative (!!) loss counts. > > (ii) Packet Loss- distribution > Voice quality is very sensitive to the distribution of packet loss - if 2% > loss occurs but the losses are spread out evenly then with PLC quality would > be affected only marginally, if 1% loss occurs but losses occur during short > intervals (typically the case) then quality can be affected quite > significantly. > RFC1889 does not consider the distribution of lost packets and hence packet > loss numbers can only grossly be equated to call quality (i.e. loss rate of > 20% is bad but you couldn't say for sure if 2% was bad or not) > > (iii) Jitter - metric > The average packet-to-packet delay variation used in RFC1889 does not > properly reflect the effects of congestion related delay changes. For > example > (a) if congesion occurs and a queue starts to fill then delay increases > however the packet-to-packet delay change may be small however the increase > in delay may cause the jitter buffer to resynchronize at some stage. > (b) LAN congestion can cause short term spikes in delay, and hence may lead > to packet discards. The average packet-to-packet delay variation will not > reflect this due to the smoothing effect of the averaging algorithm. > > (iv) Jitter - reporting interval > As jitter is reported as a running average with a scaling factor of 16, an > RTCP report only describes the jitter level during the 200mS or so prior to > the report being generated and says nothing about the jitter level during > the much larger period between reports. > > We have spoken to, and worked with, people in the industry that have been > looking at this issue in detail and have found general agreement with the > comments above. Unfortunately, there are also a fair number of people that > blindly accept that something must be "ok" because it is "in a standard" .. > this obviously raised the concern that incorporating these metrics into the > H series of standards further proliferates this viewpoint. > > Within the IETF AVT group this issue was discussed almost a year ago, and > the group agreed to develop a set of metrics that were more accurate and > appropriate for VoIP QoS reporting purposes. These include measures of > packet loss, packets discarded due to jitter, length and density of bursts > and gaps (of combined loss and discard), delay, call quality metrics... > This is contained in the following:- > > draft-ietf-avt-rtcp-report-extns-01.txt > > I would very much appreciate understanding the technical rationale behind > incorporating RFC1889 based metrics into VoIP QoS reports, given the > comments above. > > Regards > > Alan Clark > Telchemy > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

FW: new version of draft on additional x509 certificate schema fo r LDAP
by Euchner Martin ICN M SR 3 07 Nov '02

07 Nov '02

The following ID (and some referenced LDAP schemata IDs inside) may be related to the work of directory services architecture. I should note that I've not deeply looked into the document yet, but perhaps the H.LDAP experts may want to share an opinion? With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Peter Gietz [mailto:Peter.Gietz@daasi.de] Sent: Tuesday, November 05, 2002 2:12 PM To: Ietf-Pkix Subject: new version of draft on additional x509 certificate schema for LDAP Hello all, There is a new version of "An LDAPv3 Schema for X.509 certificates", which I sent to the Internet Drafts Editor. You can find the document at http://www.directory.dfn.de/docs/draft-klasen-ldap-x509certificate-schema-01 .txt The changes to version 00 are noted in Apendix C. You might remember my short presentation of the initial version at the pkix meeting at IETF 53. There are still some questions to handel: - Is it possible to get a short time-slot at thje Atlanta meeting for presenting the changes of this new version? - Can and should this draft be work of the pkix group and should the discussion about it be held on this list instead of in private email communications? - The draft introduces new naming attributes that should be included into David's Draft "LDAPv3 DN strings for use with PKIs" <draft-ietf-pkix-dnstrings-00.txt>. Besides x509issuer and x509serialNumber the allready widely used attribute emailaddress (email) should be taken into account. - The draft does not yet address the problem that there are "LDAPish" implementations that are not able to support multi-valueelds RDNs (e.g. x509serialNumber=1234+x509issuer=<dn of a CA>). Shall this be addressed by including a third name form with yet another naming attribute x509issuerSerial? - The draft does only describe fields described in RFC 3280. Should it also deal with Qualified certificates (RFC 3039)? - Should it also take into account things like userGroupName (draft-ietf-pkix-usergroup-01) - Should it also take into account things like Permanent Identifier (draft-ietf-pkix-pi-05.txt and draft-chadwick-pkix-pidn-00.txt)? I wanted to get some feedback on these questions before including respective language into the draft. Two more questions: - should revocation information be stored in a similiar fashion. And if so how: 1.) Metadata attributes for CRLs or 2.) revocation relevant attributes attached to the certificate entries. - should attribute certificates be stored in a similiar fashion? I would love to receive comments on all this from this group. Cheers, Peter -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 Tübingen email: peter.gietz(a)daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Re: Use of RTCP statistics for estimating QoS of VoIP
by Alan Clark 07 Nov '02

07 Nov '02

Paul, I have no doubt that the proper procedures were followed and am not questioning that aspect. I was active in one of SG16's predecessor committees for ten years and at various times an editor and rapporteur, and hence am sympathetic to the need to be fair, reasonable and "procedural". We have been studying the nature and source of IP network impairments and their effects on the performance of VoIP for over three years - basically that is all we do :-). We have done extensive analysis of the full range of G series CODECS, the various GSM codecs and a number of proprietary algorithms under a range of packet loss conditions. We've measured and modeled the behavior of fixed and adaptive jitter buffers of various types. We built a VoIP service modeling environment using NS2 with MMPP traffic models and used this for analyzing the precise behavior of individual calls under known traffic conditions or network faults. We have analyzed RTP traces from a wide variety of sources..... Our algorithms are in use by a number of major service providers - due in part to the way in which we view IP network behavior as time varying/ transient/ bursty and hence produce metrics in a way that reflects this. The result of this extensive research activity is (I hope) that we have a deep technical understanding coupled with field experience on the merits of different approaches. We have also discussed this topic with others working in the field - in both industry and academic research groups - and find that our observations match very well with those of other groups that have studies this issue deeply. As we discuss the issue of VoIP service quality monitoring with equipment vendors, enterprise network managers and service providers we often get asked the question "why aren't RTCP statistics good enough" and also see products on the market that use RTCP statistics to estimate VoIP service quality (and even try to estimate discard rates from jitter buffers!!). Obviously, from my comments on RFC1889 yesterday, we think that RTCP statistics are only adequate at a gross level - i.e. if average packet loss is 30% call quality must be bad but you could not determine if a call with an average loss rate of 2% was better or worse than one of 3%. I am sure that if anyone else were in our position then they would similarly feel very concerned at the idea that it was acceptable to incorporate the RFC1889 metrics into a new ITU Recommendation that was positioned as a VoIP QoS monitoring standard. Many manufacturers and service providers do not have the technical expertize to evaluate the merits and detailed content of international standards, particularly in a complex area such as this, and tend to assume that the content is ok "because it is in a standard". This would naturally tend to proliferate the use of these metrics as an acceptable approach - even though we know that they are inadequate. I hasten to add that I am not criticizing you, the Rapporteur's Group, the SG16 management or the ITU .. this (in my opinion) happens to be one of the complex issues in which what appears to be the correct and proper course of action can lead to a problematic result. Regards Alan Clark -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Thursday, November 07, 2002 1:05 AM To: alan(a)telchemy.com Cc: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Alan, This document (now H.460.9) first appeared about a year ago. After the author presented the paper, it was agreed without debate to create a new work item for it. At this last meeting, the author presented the paper, as scheduled, for approval. During interim meetings, there were no contributions against the document, which is the accepted procedure for raising technical issues and trying to make changes to progressing work items. During the last meeting, Mike Buckley did express concern over this document. I think Mr. Buckley's concerns were all valid and he pointed us to this Internet Draft. However, I had a decision to make: to hold progress on this document until the IETF produces an RFC or to allow the document to go forward as scheduled and as desired by the contributor. Given that this contributing company had made the document available about a year ago and received no formal contributions against it, it really was not my place to hold up progress at the last moment. While I certainly had the wherewithal to put the document on hold, I just didn't think that is the right thing to do and it certainly was not the desire of the contributor. With that said, though, we did make changes at the meeting to the document to prepare for this forthcoming RFC. It was agreed that we will create either an Annex or Amendment to add the necessary fields to the existing data structures so that the additional information can be reported once the RFC is available. Unfortunately, Mr. Buckley was not available during the second week at the meeting to discuss some of those decisions. Even some of my communication with him via e-mail was unsuccessful due to bounced messages. We hoped that the decisions we made would be acceptable to him. While I definitely value the input he provides and I hold his opinions in high regard, I felt like it was better to publish this document now with the aforementioned changes and plans, so as to meet the wishes of the contributor and try to address the concerns of Mr. Buckley at the same time. After all, there was no guarantee that the RFC would be published between now and the next SG16 meeting in May 2003 and we certainly cannot wait indefinitely on the IETF to complete work. Paul ----- Original Message ----- From: "Alan Clark" <alan(a)telchemy.com> To: <paulej(a)packetizer.com> Cc: <ITU-SG16(a)echo.jf.INTEL.COM> Sent: Wednesday, November 06, 2002 10:49 AM Subject: Use of RTCP statistics for estimating QoS of VoIP > > Paul > > I am responding to the recent SG16 email that encouraged direct input from > those not participating directly in the work of the Study Group. > > One particular recent issue relates to the recent addition of QoS reporting > based on RTCP statistics. We have spent the last three years analyzing and > modeling the effects of IP network impairments on VoIP and would like to > share our experience on this issue. > > RTCP statistics were intended to provide a "rough" real time feedback > between endpoints to give some sense of network quality and facilitate > potential adaptation. IP network impairments are transient in nature and > the "averaged" metrics that RFC1889 produces are as a result very > misleading. The addition of QoS reporting based on RFC1889 metrics is, in > our opinion, a backward step as it infers that these statistics are useful > for VoIP quality estimation whereas they are in fact almost meaningless. > > (i) Packet Loss - counts > RFC1889 counts of loss are not compensated for duplicate packets, hence it > is possible to have incorrect and even negative (!!) loss counts. > > (ii) Packet Loss- distribution > Voice quality is very sensitive to the distribution of packet loss - if 2% > loss occurs but the losses are spread out evenly then with PLC quality would > be affected only marginally, if 1% loss occurs but losses occur during short > intervals (typically the case) then quality can be affected quite > significantly. > RFC1889 does not consider the distribution of lost packets and hence packet > loss numbers can only grossly be equated to call quality (i.e. loss rate of > 20% is bad but you couldn't say for sure if 2% was bad or not) > > (iii) Jitter - metric > The average packet-to-packet delay variation used in RFC1889 does not > properly reflect the effects of congestion related delay changes. For > example > (a) if congesion occurs and a queue starts to fill then delay increases > however the packet-to-packet delay change may be small however the increase > in delay may cause the jitter buffer to resynchronize at some stage. > (b) LAN congestion can cause short term spikes in delay, and hence may lead > to packet discards. The average packet-to-packet delay variation will not > reflect this due to the smoothing effect of the averaging algorithm. > > (iv) Jitter - reporting interval > As jitter is reported as a running average with a scaling factor of 16, an > RTCP report only describes the jitter level during the 200mS or so prior to > the report being generated and says nothing about the jitter level during > the much larger period between reports. > > We have spoken to, and worked with, people in the industry that have been > looking at this issue in detail and have found general agreement with the > comments above. Unfortunately, there are also a fair number of people that > blindly accept that something must be "ok" because it is "in a standard" .. > this obviously raised the concern that incorporating these metrics into the > H series of standards further proliferates this viewpoint. > > Within the IETF AVT group this issue was discussed almost a year ago, and > the group agreed to develop a set of metrics that were more accurate and > appropriate for VoIP QoS reporting purposes. These include measures of > packet loss, packets discarded due to jitter, length and density of bursts > and gaps (of combined loss and discard), delay, call quality metrics... > This is contained in the following:- > > draft-ietf-avt-rtcp-report-extns-01.txt > > I would very much appreciate understanding the technical rationale behind > incorporating RFC1889 based metrics into VoIP QoS reports, given the > comments above. > > Regards > > Alan Clark > Telchemy > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Use of RTCP statistics for estimating QoS of VoIP
by Alan Clark 07 Nov '02

07 Nov '02

Paul I am responding to the recent SG16 email that encouraged direct input from those not participating directly in the work of the Study Group. One particular recent issue relates to the recent addition of QoS reporting based on RTCP statistics. We have spent the last three years analyzing and modeling the effects of IP network impairments on VoIP and would like to share our experience on this issue. RTCP statistics were intended to provide a "rough" real time feedback between endpoints to give some sense of network quality and facilitate potential adaptation. IP network impairments are transient in nature and the "averaged" metrics that RFC1889 produces are as a result very misleading. The addition of QoS reporting based on RFC1889 metrics is, in our opinion, a backward step as it infers that these statistics are useful for VoIP quality estimation whereas they are in fact almost meaningless. (i) Packet Loss - counts RFC1889 counts of loss are not compensated for duplicate packets, hence it is possible to have incorrect and even negative (!!) loss counts. (ii) Packet Loss- distribution Voice quality is very sensitive to the distribution of packet loss - if 2% loss occurs but the losses are spread out evenly then with PLC quality would be affected only marginally, if 1% loss occurs but losses occur during short intervals (typically the case) then quality can be affected quite significantly. RFC1889 does not consider the distribution of lost packets and hence packet loss numbers can only grossly be equated to call quality (i.e. loss rate of 20% is bad but you couldn't say for sure if 2% was bad or not) (iii) Jitter - metric The average packet-to-packet delay variation used in RFC1889 does not properly reflect the effects of congestion related delay changes. For example (a) if congesion occurs and a queue starts to fill then delay increases however the packet-to-packet delay change may be small however the increase in delay may cause the jitter buffer to resynchronize at some stage. (b) LAN congestion can cause short term spikes in delay, and hence may lead to packet discards. The average packet-to-packet delay variation will not reflect this due to the smoothing effect of the averaging algorithm. (iv) Jitter - reporting interval As jitter is reported as a running average with a scaling factor of 16, an RTCP report only describes the jitter level during the 200mS or so prior to the report being generated and says nothing about the jitter level during the much larger period between reports. We have spoken to, and worked with, people in the industry that have been looking at this issue in detail and have found general agreement with the comments above. Unfortunately, there are also a fair number of people that blindly accept that something must be "ok" because it is "in a standard" .. this obviously raised the concern that incorporating these metrics into the H series of standards further proliferates this viewpoint. Within the IETF AVT group this issue was discussed almost a year ago, and the group agreed to develop a set of metrics that were more accurate and appropriate for VoIP QoS reporting purposes. These include measures of packet loss, packets discarded due to jitter, length and density of bursts and gaps (of combined loss and discard), delay, call quality metrics... This is contained in the following:- draft-ietf-avt-rtcp-report-extns-01.txt I would very much appreciate understanding the technical rationale behind incorporating RFC1889 based metrics into VoIP QoS reports, given the comments above. Regards Alan Clark Telchemy

4 4

AW: Use of RTCP statistics for estimating QoS of VoIP
by Horvath Ernst 07 Nov '02

07 Nov '02

Alan, I fully agree with Bob's reply below. In my view H.460.9 is now sufficiently open to be used for transporting also advanced statistical data, even if the initial choice reflects the content of today's RTCP reports. The information content of QoS reports is only one part of the standard. Another - maybe the major - part is the mechanism for conveying these reports from endpoints to gatekeepers and between gatekeepers. And this part does not change if improved QoS statistics become available. It was the unanimous opinion of the experts at the SG16 meeting that H.460.9 will be used for extended QoS reports as soon as the relevant work in IETF has finished. How this is best done will be decided when the RFC is available. Any input from your side is certainly welcome. Regards, Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Robert R. Gilman [mailto:rrg@AVAYA.COM] > Gesendet am: Donnerstag, 07. November 2002 02:13 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: Re: Use of RTCP statistics for estimating QoS of VoIP > > Alan- > Mike Buckley brought up the same questions you raise at the > last SG16 meeting. > I don't believe anyone objects to your arguments, and, in > fact, the resulting > work, H.460.9, was modified to permit extension to other > measures and the > exclusion of the current, IETF-standardized, measures. Once > the IETF draft > you reference becomes a standard, it will be easy to refer to > the resulting > RFC and to incorporate the resulting measures as appropriate. > In the meantime, > you have the option to use the existing measures and, through > the definition > of non-standard elements, any other measures you wish to > implement on a > permanent > or trial basis. It seemed better to set the framework now, so that > implementation > and use can begin, and to do so in such a way that future > improvements may be > incorporated quickly and easily. Does this make sense? > -Bob > ---------------------------------------------------- > Bob Gilman rrg(a)avaya.com +1 303 538 3868 > > > Alan Clark wrote: > > > > Paul > > > > I am responding to the recent SG16 email that encouraged > direct input from > > those not participating directly in the work of the Study Group. > > > > One particular recent issue relates to the recent addition > of QoS reporting > > based on RTCP statistics. We have spent the last three > years analyzing and > > modeling the effects of IP network impairments on VoIP and > would like to > > share our experience on this issue. > > > > RTCP statistics were intended to provide a "rough" real > time feedback > > between endpoints to give some sense of network quality and > facilitate > > potential adaptation. IP network impairments are transient > in nature and > > the "averaged" metrics that RFC1889 produces are as a result very > > misleading. The addition of QoS reporting based on RFC1889 > metrics is, in > > our opinion, a backward step as it infers that these > statistics are useful > > for VoIP quality estimation whereas they are in fact almost > meaningless. > > > > (i) Packet Loss - counts > > RFC1889 counts of loss are not compensated for duplicate > packets, hence it > > is possible to have incorrect and even negative (!!) loss counts. > > > > (ii) Packet Loss- distribution > > Voice quality is very sensitive to the distribution of > packet loss - if 2% > > loss occurs but the losses are spread out evenly then with > PLC quality would > > be affected only marginally, if 1% loss occurs but losses > occur during short > > intervals (typically the case) then quality can be affected quite > > significantly. > > RFC1889 does not consider the distribution of lost packets > and hence packet > > loss numbers can only grossly be equated to call quality > (i.e. loss rate of > > 20% is bad but you couldn't say for sure if 2% was bad or not) > > > > (iii) Jitter - metric > > The average packet-to-packet delay variation used in > RFC1889 does not > > properly reflect the effects of congestion related delay > changes. For > > example > > (a) if congesion occurs and a queue starts to fill then > delay increases > > however the packet-to-packet delay change may be small > however the increase > > in delay may cause the jitter buffer to resynchronize at some stage. > > (b) LAN congestion can cause short term spikes in delay, > and hence may lead > > to packet discards. The average packet-to-packet delay > variation will not > > reflect this due to the smoothing effect of the averaging algorithm. > > > > (iv) Jitter - reporting interval > > As jitter is reported as a running average with a scaling > factor of 16, an > > RTCP report only describes the jitter level during the > 200mS or so prior to > > the report being generated and says nothing about the > jitter level during > > the much larger period between reports. > > > > We have spoken to, and worked with, people in the industry > that have been > > looking at this issue in detail and have found general > agreement with the > > comments above. Unfortunately, there are also a fair > number of people that > > blindly accept that something must be "ok" because it is > "in a standard" .. > > this obviously raised the concern that incorporating these > metrics into the > > H series of standards further proliferates this viewpoint. > > > > Within the IETF AVT group this issue was discussed almost a > year ago, and > > the group agreed to develop a set of metrics that were more > accurate and > > appropriate for VoIP QoS reporting purposes. These include > measures of > > packet loss, packets discarded due to jitter, length and > density of bursts > > and gaps (of combined loss and discard), delay, call > quality metrics... > > This is contained in the following:- > > > > draft-ietf-avt-rtcp-report-extns-01.txt > > > > I would very much appreciate understanding the technical > rationale behind > > incorporating RFC1889 based metrics into VoIP QoS reports, given the > > comments above. > > > > Regards > > > > Alan Clark > > Telchemy > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)lists.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

AW: [h323forum] Participating in H.323/H.248 standardization meet ings
by Sebestyen Istvan ICN M SR 3 06 Nov '02

06 Nov '02

Folks, maybe what I could add to this, while what Paul has written is completely correct: 1) You can participate as "expert" in a Rapporteur Meeting, if the Rapporteur (e.g. Paul) feels that it contributes to the progress of work. The implementation of an "open door" policy - if he feels that is the right way to go - is up to him as a Rapporteur. 2) However, while you may provide there key contributions to the progress of H.323 Standardization, in the end you have no power to participate in the official commenting and approval process. Those can be done only by ITU-T members and ITU-T Associates (the later can officially comment, but not "vote"). However, since changes from the "top" - I mean on SG level are not frequent, your contribution at the "bottom" can be still very powerful for the shaping of the standard. Kind regards, Istvan -----Ursprüngliche Nachricht----- Von: Paul E. Jones [mailto:paulej@packetizer.com] Gesendet: Mittwoch, 6. November 2002 05:38 An: ITU-SG16(a)echo.jf.INTEL.COM; imtch323implementors(a)mail.imtc.org; h323forum(a)mail.imtc.org Betreff: [h323forum] Participating in H.323/H.248 standardization meetings Folks, I have received questions from a number of people asking if or how people can participate in the standardization activities related to H.323, H.248, etc. Most people have been under the impression that, since they are not members of the ITU, they do not have a voice and do not have a means to contribute to the work related to H.323 and H.248. While it is true that the ITU meetings are generally closed to members, we do have a much more "open door" policy at Rapporteur's meetings and definitely encourage participation from members and non-members alike. Rapporteur's meetings are where much of the real work gets done, so your participation would definitely be beneficial. In February 2003, we will hold the next Rapporteur's meeting for Questions 2, 3, 4, 5, D, F, and G of Study Group 16. The meeting announcement will be posted to the ITU-T SG16 mailing list (see http://www.packetizer.com/iptel/h323/lists.html <http://www.packetizer.com/iptel/h323/lists.html> for information on joining the list), which is the official mailing list for work related to those Questions. I would encourage any interested person to contribute to the work going on related to those Questions, regardless of his/her association with the ITU. While being present at the meeting is really beneficial to the work going on, it certainly is not mandatory. Even if you are not present, if you have a feature you want to propose or propose a new work item, you could simply submit the proposal in writing and it will be considered. With that said, though, as folks who do participate in these meetings know, it is generally better to be present to make your point and help drive the work. If you have a contribution you want to make in the area of H.323, H.248, etc., you are definitely welcome! In addition, I'll be happy to answer any questions you might have related to procedural matters. Best Regards, Paul --- You are currently subscribed to h323forum as: istvan.sebestyen(a)icn.siemens.de To unsubscribe send a blank email to leave-h323forum-27338W(a)mail.imtc.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Participating in H.323/H.248 standardization meetings
by Paul E. Jones 05 Nov '02

05 Nov '02

Folks, I have received questions from a number of people asking if or how people can participate in the standardization activities related to H.323, H.248, etc. Most people have been under the impression that, since they are not members of the ITU, they do not have a voice and do not have a means to contribute to the work related to H.323 and H.248. While it is true that the ITU meetings are generally closed to members, we do have a much more "open door" policy at Rapporteur's meetings and definitely encourage participation from members and non-members alike. Rapporteur's meetings are where much of the real work gets done, so your participation would definitely be beneficial. In February 2003, we will hold the next Rapporteur's meeting for Questions 2, 3, 4, 5, D, F, and G of Study Group 16. The meeting announcement will be posted to the ITU-T SG16 mailing list (see http://www.packetizer.com/iptel/h323/lists.html for information on joining the list), which is the official mailing list for work related to those Questions. I would encourage any interested person to contribute to the work going on related to those Questions, regardless of his/her association with the ITU. While being present at the meeting is really beneficial to the work going on, it certainly is not mandatory. Even if you are not present, if you have a feature you want to propose or propose a new work item, you could simply submit the proposal in writing and it will be considered. With that said, though, as folks who do participate in these meetings know, it is generally better to be present to make your point and help drive the work. If you have a contribution you want to make in the area of H.323, H.248, etc., you are definitely welcome! In addition, I'll be happy to answer any questions you might have related to procedural matters. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: final docs
by OKUBO Sakae 01 Nov '02

01 Nov '02

Dear Gary and all, At 11:14 -0500 02/11/01, Gary Thom wrote: >H.460.4_final.doc has been uploaded to the incomming directory. This has been moved to the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/H4604_Final.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

1 0

Unknown files at /Incoming
by OKUBO Sakae 01 Nov '02

01 Nov '02

Dear subscribers, I have deleted Ba_XP9.004 and Ba_W98B.pqi at /Incoming. If they are yours, please re-post them with an announcement on the reflector. -- 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

1 0

Re: Uploaded document
by OKUBO Sakae 01 Nov '02

01 Nov '02

Dear Mr. Horvath and all, At 12:09 +0100 02/10/31, Horvath Ernst wrote: >I have uoloaded H.460.9 final draft to /Incoming. This has been moved to the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/h-460-9-QoSMon-final-draft… -- 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

1 0

Uploaded documents
by OKUBO Sakae 31 Oct '02

31 Oct '02

Dear SG16 experts, At 11:07 +0100 02/10/30, Euchner Martin ICN M SR 3 wrote: >The latest draft H.235V3 (as in TD-28r1 WP2/16)has been uploaded to the >Incoming directory. > >Any review, or even contributions against that documents are highly >appreciated... At 12:20 -0500 02/10/30, Paul E. Jones wrote: >I uploaded several draft documents to the Incoming directory on the >avc-site: > AnnexGv2.zip > DraftH460.3.zip > H323AnnexP.zip > H460-7-Digitmap.zip > H460-8-ReQuery.zip > h460-6plen.zip They have been moved to the following place: http://standard.pictel.com/ftp/avc-site/0210_Gen/ 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

1 0

Re: Draft H.235v3 uploaded
by Euchner Martin ICN M SR 3 30 Oct '02

30 Oct '02

Olivier, thank you for the assistance. Please note, that H.235v3 is not yet approved and depending on further contributions, text and even ASN.1 may change. So it is perhaps a bit too early to make these parts public on the ITU-T webpage. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: DUBUISSON Olivier [mailto:olivier.dubuisson@francetelecom.com] Sent: Wednesday, October 30, 2002 2:18 PM To: Euchner Martin ICN M SR 3 Cc: ITU-SG16(a)echo.jf.INTEL.COM; Julien BARBEAU Subject: Re: Draft H.235v3 uploaded Euchner Martin ICN M SR 3 wrote: > > The latest draft H.235V3 (as in TD-28r1 WP2/16) has been uploaded to the > Incoming directory. FYI the ASN.1 modules of the 2000 edition of H.235 are available in the module database of the ITU-T ASN.1 Project at: http://www.itu.int/ITU-T/asn1/database/itu-t/h/h235/2000/index.html We will check and compile H.235V3 and upload the modules to the ITU-T website ASAP. -- Olivier DUBUISSON (ITU-T ASN.1 Project leader) france telecom R&D DTL/TAL - 22307 Lannion Cedex - France t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Draft H.235v3 uploaded
by Euchner Martin ICN M SR 3 30 Oct '02

30 Oct '02

The latest draft H.235V3 (as in TD-28r1 WP2/16) has been uploaded to the Incoming directory. Any review, or even contributions against that documents are highly appreciated... With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

2 1

Re: Outcome of the SG16 meeting just finished
by OKUBO Sakae 30 Oct '02

30 Oct '02

Dear Mike and all, At 15:55 +0000 02/10/29, mike.nilsson(a)bt.com wrote: >I have uploaded the file H245wcmr.zip to the incoming directory. > >This is the same as the file H245wcmr5.zip thatI sent on Thursday at >4:32PM (UK time). I am assuming this was accepted by the plenary without >any changes, and is technically the same as TD-92R1(PLEN). Yes, TD-92R1(PLEN) was accepted at the beginning of SG16 session last Friday. The file has been moved to /0210_Gen directory. 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

1 0

Results of SG 16 posted on the web
by simao.campos＠itu.int 29 Oct '02

29 Oct '02

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 ***** =====================================================================

1 0

H.ldap - Directory Services Architecture
by OKUBO Sakae 29 Oct '02

29 Oct '02

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

1 0

Fwd: Re: Fw: SG16 meeting closure
by OKUBO Sakae 28 Oct '02

28 Oct '02

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

1 0

Outcome of the SG16 meeting just finished
by OKUBO Sakae 25 Oct '02

25 Oct '02

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

1 0

Re: FW: [MMUSIC] Seeking input from G.726 ADPCM implementers
by Tom-PT Taylor 17 Oct '02

17 Oct '02

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

1 0

Re: FW: [MMUSIC] Seeking input from G.726 ADPCM implementers
by Rajesh Kumar 17 Oct '02

17 Oct '02

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

1 0

example commObject directory
by Tyler Johnson 17 Oct '02

17 Oct '02

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

1 0

Re: [Fwd: Re: [Megaco] 105/102 Test calls..]
by OKUBO Sakae 17 Oct '02

17 Oct '02

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

1 0

Re: [Megaco] 105/102 Test calls..
by Christian Groves 17 Oct '02

17 Oct '02

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

1 0

FW: [MMUSIC] Seeking input from G.726 ADPCM implementers
by Tom-PT Taylor 15 Oct '02

15 Oct '02

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

1 0