- sg16-avd - lists.packetizer.com

AAP comments during last call on H245v9
by Terry L Anderson 13 Dec '02

13 Dec '02

A new version of H.245 (version 9) was consented at the October Study Group 16 meeting in Geneva. One official comment was submitted by Avaya against H.245 V9 during the last call period. According to ITU procedures we need to resolve this issue and then have an "additional review" (a second last call) before it can be considered approved. The issue raised by Avaya concerned the use of encrypted media channels for MoIP and included specific suggestions for additional ASN.1 items and … [View More]description in H.245 to support this. The changes are not extensive. From the comment: > Introduction > As it now stands, version 9 of H.245 does not permit the specification > of encryption of media channels using the new Modem-over-IP (MoIP) > data types RedundancyEncoding, MultiplePayloadStream, and FECdata. > Inasmuch as these types of channels can be subject to eavesdropping, > and can carry the same information as other audio or data channels, it > seems appropriate to provide the means to encrypt them. The issue and suggested changes have been discussed by several of parties involved with the MoIP work (Paul Jones, Cisco, Martin Euchner and Sasha Ruditsky along with Bob Gilman from Avaya) and they support the suggested changes. As rapporteur, I am proposing that adopt the suggested changes and submit the revised version for the Additional Review at the next review period (I believe in January) unless there are objections from others. Any discussion should be sent to the ITU-SG16(a)mailbag.cps.intel.com reflector. I am including the tsg16q3 and tsg16wp2 lists in this message so that all interested parties are aware of the process. If I do not see any objections by 17:00 UT a week from today, Dec 20, we will proceed with the additional review of the text as revised. For those with TIES logins, the Avaya comment document can be accessed at: http://www.itu.int/itudoc/itu-t/aap/sg16aap/recaap/h245v9/lcc/index.html For any that may not, I will summarize the changes below: 1. Annex A (page 47) Add the new data types RedundancyEncoding, MultiplePayloadStream, and FECdata to H235Media. This will permit the specification of encryption for these data types in the same way it is specified for other media types. As follows: H235Media ::=SEQUENCE { encryptionAuthenticationAndIntegrity EncryptionAuthenticationAndIntegrity, mediaType CHOICE { nonStandard NonStandardParameter, videoData VideoCapability, audioData AudioCapability, data DataApplicationCapability, ..., redundancyEncoding RedundancyEncoding, multiplePayloadStream MultiplePayloadStream, fec FECData }, ... } ---------------------------------------- 2. Annex B, Section B.3.1 (page 108) Add a description of the use of H235Media in DataType to indicate that the channel is to be encrypted. As follows: A dataType of h235Media is used to specify encryption of the logical channel; the actual data type is indicted within H235Media, along with the encryption specification. ----------------------------------------- 3. Annex B, Section B.3.1 (page 111) Add a description of the use of redundancyEncoding for media encryption when the dataType specifies multiple payload types within the channel. As follows: When encryption is specified for a channel carrying multiple payloads, redundancy encoding using RFC 2198 is used to preserve the actual payload types transmitted. The Encapsulating payload type is set to the value specified in the syncFlag field of the encryptionSync element. -- ------------------------------------------------------- Terry L Anderson tlatla(a)verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com [View Less]

1 0

Re: Rapporteur meeting in February 2003
by Even, Roni 08 Dec '02

08 Dec '02

Mr Okubo, Is the meeting Tuesday till Friday? Thanks Roni Even Polycom > -----Original Message----- > From: OKUBO Sakae [mailto:okubo@MXZ.MESH.NE.JP] > Sent: Saturday, December 07, 2002 9:23 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Rapporteur meeting in February 2003 > > > Dear Q.D,F,G,1-5/16 experts, > > At 01:18 +0900 02/10/26, OKUBO Sakae wrote just after the October > SG16 meeting ended: > >Please note that the next Rapporteur meeting is … [View More]

2 1

Rapporteur meeting in February 2003
by OKUBO Sakae 07 Dec '02

07 Dec '02

Dear Q.D,F,G,1-5/16 experts, At 01:18 +0900 02/10/26, OKUBO Sakae wrote just after the October SG16 meeting ended: >Please note that the next Rapporteur meeting is planned during 11-14 >February 2003. Its details are yet to be fixed. Rapporteurs have been seeking the best place to hold this meeting. This is to report the progress. 1/ As default, we will meet in Geneva to handle video related topics with Q.6 experts who will meet there for WP3 consent of H.264. 2/ In case Q.6 and WP3 … [View More]

1 0

Thanks to Greg Meyer and Chris Hansen
by OKUBO Sakae 07 Dec '02

07 Dec '02

Dear all the subscribers of this mailinglist, This is to announce that the administrator of this mailinglist has changed from Mr. Greg Meyer to Mr. Chris Hansen due to the change of Mr. Meyer's job in Intel. Using this opportunity, I would like to thank Greg for all of his efforts to manage this indispensable tool for the activities of ITU-T SG16 WP2 Questions D,F,G,1-5. Thanks are also to Chris who has kindly undertaken to take care of the mailinglist. Appreciation is extended to Intel … [View More]

1 0

FW: [AVT] Resolution of G.726 payload format endian-issue
by Campos, Simao 15 Nov '02

15 Nov '02

Dear colleagues, for your information. Best regards, Simao -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: 15 November 2002 02:30 To: AVT WG Subject: [AVT] Resolution of G.726 payload format endian-issue This is a summary of the mailing list discussion regarding the packetization of G.726 audio in RTP. This topic is also on the agenda for the AVT meeting next week. Background Based on a request to align the sample packing order with that of ATM AAL2 … [View More]transport, it was proposed that the draft RTP Profile packetization be changed to be consistent with ITU-T Recommendation I.366.2 Annex E before the draft 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. The request for input was distributed to the following mailing lists (and perhaps elsewhere): ietf(a)ietf.org avt(a)ietf.org mmusic(a)ietf.org sip(a)ietf.org vpim(a)lists.neystadt.org packetcable-test-codecs(a)cablelabs.com packetcable-codecs(a)cablelabs.com tsg11bicc(a)ties.itu.ch (Study Group 11 Q. 11 (BICC signaling)) tsg11q15(a)ties.itu.ch (Study Group 11 Q. 15 (AAL2 signaling)) ITU-SG16(a)echo.jf.INTEL.COM (Study Group 16) Nortel internal distribution list Summary of Comments All the comments received on the AVT mailing list both when the issue was first raised and in response to the request for input are included below, edited for brevity. The number of comments was surprisingly small, which indicates that there may not be many implementations of G.726 transport in RTP. Only one mentions an implementation of the G726 payload format as specified in draft-ietf-avt-profile-new-12.txt, although there are at least two other implementations: the publicly available RAT audio tool, and one by Magnus Westerlund which was interop tested with RAT. Two comments (from one company) suggest that the existing G726-* payload format specifications remain as is and that new MIME types be defined for the ITU I366.2 packetization. This possibility was discussed at the last IETF meeting in Yokohama. Another comment requested that the payload format remain as it is in the RTP Profile draft because the Voice Profile for Internet Mail (RFC 2421/2) uses the same sample packing. This is consistent with ITU-T Recommendation X.420 for X.400 mail, which means there is an existing inconsistency within ITU-T recommendations. One comment was neutral, but leaning toward preserving backward compatibility (i.e., not changing the payload format). There was one comment in favor of making the change, from the original requester. Conclusion The primary justification for changing the existing MIME types and the static payload type 2 for G726-32 to indicate the ITU I366.2 packetization would be existence of multiple implementations that had implemented the RTP payload format as if it were the same as ITU I366.2. No such implementations were mentioned, even though the original request did say that "many vendors had taken a cue from the AAL2 specifications (approved in 1999) and have designed DSPs that use the I.366.2 ADPCM code word packing rules for RTP". (The G726-32 mode has been in the draft RTP Profile since 1997, but the other rates were added more recently and the draft is not yet published as a standard.) Based on the feedback received, the working group chairs and Area Directors have agreed that the proposed change should NOT be accepted and that the G726-* payload formats specified in the RTP Profile draft should remain as they are. We will specify a new set of RTP payload formats designated by MIME subtypes AAL2-G726-16, -24, -32 and -48 which specify the sample packing in the order of I.366.2 Annex E. If the IESG is willing to have these new payload formats added to the draft RTP Profile in the form of an "RFC Editor note" when the IESG sends its approval of the draft RTP Profile to the RFC Editor, then we will do so. One problem would be that the RTP Profile is to be published as a Draft Standard, which means there should first be two interoperable implementations. Alternatively, a separate draft can be produced quickly to be published as a Draft Standard. At a minimum, we will request that the IESG add the following RFC Editor note in Section 4.5.4 which defines the G726-* formats: Note that the order in which samples are packed into octets in the G726-16, -24, -32 and -48 payload formats for RTP is consistent with ITU-T Recommendation X.420, but it is the opposite of what is specified in ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport. A second set of RTP payload formats matching the packetization of I.366.2 Annex E and identified by MIME subtypes AAL2-G726-16, -24, -32 and -48 will be specified in a separate document. The description of the new AAL2-G726-* payload formats will include a similar but complementary note. Interoperability would have been optimized if there was a single packetization that all agreed to use, but that is not the case. If there are some systems already in the field that use static payload type 2 to indicate packetization according to the draft RTP Profile, and other systems in the field that use static payload type 2 with packetization according to I.366.2 Annex E, then we already have the situation that those systems will produce garbled audio when they interoperate, and the problem won't be detected when the session is established. We can't fix that problem without upgrading those systems. Therefore, we will also deprecate the use of static payload type 2, such that all systems should negotiate a dynamic payload type using the MIME subtypes G726-32 or AAL2-G726-32 depending upon which packetization they want to use. Vendors may be able to ease the transition within their own implementations by offering the dynamic payload type as the preferred value and the static payload type as the secondary value. An upgraded system that implements only G726-32 and receives an offer of a dynamic payload type bound to AAL2-G726-32 along with static payload type 2 but no dynamic payload type bound to G726-32 may want to assume that type 2 also indicates the AAL2 format and reject the call, and vice versa. To implement this deprecation, we will request another RFC Editor note changing the assignment of static payload type 2 in Table 4 of the RTP Profile to be "reserved" rather than "G726-32" and to add the following note in the first paragraph of Section 6: Payload type 2 was assigned to G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is marked reserved. Similar instructions will go in the IANA Considerations section so that the assignment in IANA's registry is marked as deprecated. Steve Casner Colin Perkins AVT Co-Chairs -------------------------------------------------------------------- Comments received (edited): Date: Wed, 10 Jul 2002 13:58:27 +0200 From: Eli Shoval <elish(a)audiocodes.com> I am sending this as a response to the recent request to change the G.726 packetization in ietf avt profile. We at Audiocodes implemented the G.726 packetization according to ietf avt profile. We object to removing the original G.726 packetization from this standard because it will cause us to change our implementation. Why can't the ITU I366.2 packetization be added as additional vocoder to the ietf avt using dynamic payload type ? In this case if it will have MIME registration with a different name than the regular G726 and if both gateways support it they will be able to communicate. Date: Wed, 17 Jul 2002 22:20:39 -0400 From: Glenn Parsons <gparsons(a)nortelnetworks.com> In response to the G.726 agenda item, I just wanted to chime in VPIM (RFC2421/2) and the current AVT profile are aligned (with little endian). VPIM (and use of G.726) is widely deployed by voice mail vendors. Some of these systems support RTP as well. So I would suggest maintaining this alignment. Date: Tue, 15 Oct 2002 09:47:48 +0200 From: Oren Peleg <OrenP(a)audiocodes.com> Another Proposal could be: For the I.366.2 packetization, make a new MIME registration & Use a Dynamic Payload Type value. Date: Thu, 17 Oct 2002 14:47:59 -0400 From: Tom-PT Taylor <taylor(a)nortelnetworks.com> 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. Date: Thu, 17 Oct 2002 11:34:39 -0700 From: Rajesh Kumar <rkumar(a)cisco.com> 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. [end] _______________________________________________ Audio/Video Transport Working Group avt(a)ietf.org https://www1.ietf.org/mailman/listinfo/avt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com [View Less]

1 0

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 … [View More]

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. … [View More] 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 [View Less]

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...............… [View More]......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 [View Less]

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 … [View More]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 [View Less]

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 … [View More]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 [View Less]

4 4