communications standards review - · pdf filecommunications standards review july 13 ......

July 13, 2001 Vol. 12.25 Copyright © CSR 2001 1

COMMUNICATIONS STANDARDS

REVIEW

Volume 12, Number 25 July 13, 2001

REPORT OF ITU-T SG16, MULTIMEDIA SERVICES, SYSTEMS ANDTERMINALS, MAY 28 – JUNE 8, 2001, PORTO SEGURO, BRAZIL

The following report represents the view of the reporterand is not the official, authorized minutes of the meeting.

SG 16, MultiMedia Services, Systems & Terminals, May 28 – June 8, 2001, Porto Seguro, Brazil.5Seminar - “Multimedia in the 21st Century”.......................................................................5Previous Approvals...............................................................................................................5Recommendations for Consent (AAP)..................................................................................5Recommendations for Determination via TAP (Traditional Approval Process using WTSA

Resolution 1)............................................................................................................6Other Approvals....................................................................................................................7New Question on Distributed Speech Recognition...............................................................7Joint Project with ISO/IEC on Video Coding.......................................................................7Interim Meetings and Next Meeting of Study Group 16......................................................7Other Highlights...................................................................................................................8

Working Party 1/16, Modems and Facsimile Terminals.............................................................9Cooperation in ITU Activities...............................................................................................9

Working Party 2/16, Multimedia - Platform and Interworking...................................................9Working Party 3/16, Signal Processing....................................................................................10Working Party 4/16, Multimedia Framework...........................................................................10Question A/16 WP4, Mediacom 2004......................................................................................10

Liaisons..............................................................................................................................10Mediacom 2004..................................................................................................................11Multimedia Glossary..........................................................................................................12

Question B/16 WP4, Multimedia Architecture..........................................................................12Incoming Liaisons..............................................................................................................13

Question C/16 WP4, Multimedia Applications and Services....................................................13Draft Recommendation F.IEMS.........................................................................................14Future Work on Services and Applications.........................................................................14E-commerce/E-business......................................................................................................14

Question D/16 WP2, Interoperability of Multimedia Systems and Services.............................15Question E/16 WP3, Media Coding.........................................................................................16

New Q15/16 WP3, Distributed Speech Recognition/Distributed Speaker Verification.......16Still-Image Coding..............................................................................................................17G.799.1, TIGIN..................................................................................................................18

Question F/16 WP2, Quality of Service & End-to-End Performance in Multimedia Systems..18Scope of QF/16..................................................................................................................19International Emergency Priority Services (Joint with Questions D, G, and Q1-5).............19Other Contributions............................................................................................................20

COMMUNICATIONS STANDARDS REVIEW


Coordination.......................................................................................................................21H.323 Annex N, End-to-End QOS and Service Priority Control and Signaling (Joint with

Q2/16)....................................................................................................................22Question G/16 WP2, Security of Multimedia Systems and Services........................................22Question H/16 WP1, Accessibility to Multimedia Systems and Services.................................22Question 1/16 WP2, Multimedia Systems, Terminals and Data Conferencing.........................23

H.320, Narrow-band visual telephone systems and terminal equipment..............................23H.324, Terminal for low bit-rate multimedia communication..............................................23T.120, Data Protocols for Multimedia Conferencing..........................................................24Future Work.......................................................................................................................24

Question 2/16 WP2, Multimedia over Packet Networks using H.323 Systems........................24Liaisons..............................................................................................................................25H.323-Series Implementers Guide......................................................................................25H.323 v.5, Packet-Based Multimedia Communications Systems........................................26H.225.0 Annex G v.2, Communication Between Administrative Domains..........................26H.323 Annex M.3, Tunneling DSS1 in H.323...................................................................27H.323 Annex N, End-to-End QoS......................................................................................27H.323 Annex O, Use of Complementary Internet Protocols with H.323 Systems..............28H.323 Annex Q, Far End Camera Control and H.281 / H.224...........................................28H.323 Annex R, Robustness Methods for H.323 Entities..................................................28H.450.12, Common Information Additional Network Feature for H.323 (ANF-CMN).....28H.GEF.1, Generic Extensibility Framework Usage............................................................28H.GEF.2, Number Portability Interworking Between H.323/SCN Networks.....................29H.GEF.3, Presence.............................................................................................................29Emergency Services............................................................................................................29Modem over IP...................................................................................................................30

Question 3/16 WP2, Infrastructure & Interoperability for Multimedia over Packet Networks..31Status of Recommendations................................................................................................31Liaisons (Joint with Q2/16, and some with QF/16).............................................................31H.246 Material for Implementers Guides...........................................................................38H.248 Material for Implementers Guides...........................................................................38H.245 v.8, Control Protocol for Multimedia Communication.............................................39H.246 Annex F, H.323 - H.324 Interworking.....................................................................39H.248 v.2, Gateway Control Protocol.................................................................................39H.248 Annex L, Error Codes and Service Change Reason Description..............................39H.248 Annex M.1, Advanced Audio Processing Packages.................................................40H.248 Annex M.2, Congestion Handling Package.............................................................40H.248 Annex M.3, Packages for Transmission of Data Over Analog Lines.......................40H.248 Annex M.4, Packages to Support Interworking Between H.324 and H.323............40New Supplement to H.248 to Capture Package Work........................................................41New Packages for H.248....................................................................................................41Other Question 3/16 Highlights..........................................................................................42

Question 4/16 WP2, Video and Data Conferencing using Internet-Supported Services...........43Future Activities..................................................................................................................44

Question 5/16 WP2, Mobility for Multimedia Systems and Services.......................................44H.MMS.1, Mobility for H.323 Multimedia Systems (former H.323 Annex H).................44H.MMS.2, Global Mobility Management Interoperability..................................................46H.MMS.3, Mobility Presence for MM Systems and Services............................................46

Question 6/16 WP3, Advanced Video Coding..........................................................................47Liaisons..............................................................................................................................47H.263, Video Coding For Low Bit Rate Communication....................................................47H.245 for H.263.................................................................................................................48H.26L, Video Coding Recommendation.............................................................................48Future work........................................................................................................................51



Question 7/16 WP3, Wideband Coding of Speech at around 16 kbit/s....................................51Agreed Milestones..............................................................................................................53

Question 8/16 WP3, Encoding of Speech Signals at Bit Rates Around 4 kbit/s......................53Global Analysis and Selection Process...............................................................................53Complexity Evaluation........................................................................................................53Subjective Test Plan............................................................................................................54Characterization..................................................................................................................55Future Work.......................................................................................................................55

Question 9/16 WP3, Variable Rate Coding of Speech Signals.................................................55EV, Embedded VBR...........................................................................................................55SCV, Specialized Codec VBR.............................................................................................56MVV, Multirate/VAD VBR................................................................................................57Agreements.........................................................................................................................57

Question 10/16 WP3, Software Tools for Signal Processing Standardization Activities andMaintenance of Existing Voice Coding Standards...........................................................58

Progress on Software Tools................................................................................................58Processing Framework.......................................................................................................59Software Tools User’s Manual...........................................................................................59Synchronous Reset of G.729..............................................................................................59

Question 11/16 WP1, Voiceband Modems: Specification and Performance Evaluation...........60V.moip................................................................................................................................61Joint Q11/16 and WP2 Session..........................................................................................63Ad Hoc on MoIP Gateway Architecture.............................................................................63Joint Q11/Q14 Meeting......................................................................................................64V.91, A Digital Modem Operating at 64 000 bit/s For Use on 4-Wire Circuits..................65V.92, Enhancements to Recommendation V.90...................................................................65V.59 (V.mmo), Modem Managed Objects..........................................................................66Other Q11/16 Highlights....................................................................................................66

Question 12/16 WP1, DCE-DCE Protocols for the PSTN and ISDN.....................................66Data Compression..............................................................................................................67V.42 Channel for Remote Modem Management Information.............................................67

Question 13/16 WP1, DTE-DCE Interfaces and Protocols......................................................67V.250 Supplement..............................................................................................................68V.250, Serial Asynchronous Automatic Dialing and Control..............................................68V.80, In-band DCE Control and Synchronous Data Modes for Asynchronous DTE.........68V.250 Amendment..............................................................................................................68Future Work.......................................................................................................................69

Question 14/16 WP1, Facsimile Terminals...............................................................................69T.30, Procedures for Document Facsimile Transmission in the General Switched

Telephone Network.................................................................................................69T.35, Procedure for the Allocation of ITU-T Defined Codes for Non-Standard Facilities..70T.37, Procedures for Transfer of Facsimile Data via Store-and-Forward on the Internet....70T.38, Procedures for Real-time Group 3 Facsimile Communication over IP Networks......71T.89, Application Profiles for Rec. T.88 - Lossy/Lossless Coding of Bi-level Images for

Facsimile Apparatus................................................................................................72T.870, Lossless and Near Lossless Compression of Continuous-Tone Still Images:

Extensions..............................................................................................................72SG16 Meeting Roster, May 28 – June 8, 2001, Porto Seguro, Brazil .......................................73

Acronym Definitions......................................................................................................................76Communications Standards Review Copyright Policy....................................................................80



CSR’s Fully Searchable CDs

CSR CDs are indexed for machine searching (Adobe Acrobat). They arevery useful for researching technical issues as well as for prior-art searches.Your company’s patent or legal departments may also find these CDs useful.

Quarterly CDs : 3 months of CSR reports on each CD, in an annual subscription$695 to non-subscribers but only $200 as an add-on to current subscribers

Annual CDs: 12 months of CSR reports on a CD for each calendar year 1990 to present$695 to non-subscribers, $200 to current subscribers

First Decade CD: all CSR reports from 1990 through 1999 on one CD$2,000 to non-subscribers; subscribers please take a $200 discount for each year ofsubscription during 1990 – 1999

2001 IEEE Conference onStandardization and Innovation in Information Technology

University of ColoradoBoulder, CO, USA

October 3-6, 2001

http://www.siit2001.org/

STANDARDIZATION and INNOVATION are fundamental processes in our technicaland increasingly global civilization, sometimes operating in tension and sometimes in concert with each other. The complex interplay between these two processes is still not well understood, in spite of being linked to nearly every facet of our economy, society, culture, and physical environment. In recognition of the crucial importance of improving our understanding of these processes and of their interrelationship, the SIIT International Conference was initiated in 1999 to bring together technology developers, standardization leaders, economists and social scientists from government, commerce and academia.

SIIT 2001 will explore standardization and innovation in information technology through eight sessions and a workshop with over 50 presentations.

Registration information is on the web site.



REPORT OF ITU-T STUDY GROUP 16, MULTIMEDIA SERVICES, SYSTEMSAND TERMINALS, MAY 28 – JUNE 8, 2001, PORTO SEGURO, BRAZIL

Study Group 16’s second meeting of the 2001 - 2004 study period was chaired by P. A. Probst(Swisscom, Switzerland), assisted by S. F. Campos Neto (Federative Republic of Brazil), J. Magill(Lucent), M. Matsumoto (Japan), F. Tosco (TILAB), and M. Y. Wreikat (Jordan). TD-39(Plen)contains the draft report of this meeting. The SG16 meeting was hosted by Anatel, the Brazilianregulator, in Porto Seguro, Bahia, Brazil. The meeting was attended by approximately 115delegates from 20 countries. TD-49(Plen) is a final list of participants. TD-07(Plen) (TSB)contains the list and attribution of the Delayed contributions.

The opening plenary included addresses from:

• L. F. Tenorio Perrone, Member of the Board, Anatel• A representative of the city of Porto Seguro• F. Bigi, Deputy Director TSB• P.A. Probst, Chairman of ITU-T SG16

The appointment of three new Rapporteurs was confirmed:Question D/16: T. Taylor (Nortel Networks, Canada)Question 5/16: P. Reddy (Intel, USA)Question 13/16: K. Chu (Conexant, USA)

SG16 expressed their thanks to outgoing Rapporteurs, Y. Robin-Champigneul (formerlyRapporteur for Question 1/16 – 1996-2000) and R-R. Damm (formerly Rapporteur for Question6/16 ) who have now confirmed that they are unable to continue with their ITU activities.

Seminar - “Multimedia in the 21st Century”

The hosts took the opportunity of the SG16 meeting to organize a Seminar on “Multimedia in the21st Century.” The intent was to build upon the IP Networking and Mediacom 2004 Workshopheld in Geneva in April, and to involve experts from Brazil and South America. About 100 extrapeople attended for this seminar, mainly from Brazil. Some SG16 delegates also attended althoughthere were some parallel meetings. The event was successful, and is clearly an event which wouldnot have taken place without the SG16 meeting. All the presentations from the seminar are availableat <http://www.itu.int/ITU-T/workshops/seminars/multimedia/index.html>.

Previous Approvals

TSB AAP-4 of March 16, 2001, reported on the Approval of the following ITU Recommendations:

• Corrigendum 2 to Annexes to G.729• Corrigendum 1 to H.222.0, ISO/IEC 13818-1• Annex L to H.323, Stimulus signaling• H.450.10, Call offer supplementary services• H.450.11, Call intrusion supplementary services• Amendment 3 to T.30• Amendment 2 to T.37• Corrigendum to T.82

Recommendations for Consent (AAP)

See <http://www.itu.int/itudoc/itu-t/rec/a/a8.html> for details of the AAP procedures.



Recommendations for Consent DocumentsFrom Working Party 1 – Modems and Facsimile TerminalsV.25 Corrigendum, Automatic answering equipment and generalprocedures for automatic calling equipment on the GSTN includingprocedures for disabling of echo control devices

TD-35(WP1/16)

V.59 Corrigendum, Modem Managed Objects TD-20(Plen)V.80 Amendment 1, In-Band DCE Control and Synchronous DataModes for Asynchronous DTE

TD-13(Plen)

V.91 Corrigendum, Digital Modem Operating at 64 000 bit/s For Useon 4-Wire Circuits

TD-27(WP1/16)

V.92 Amendment 1, Enhancements to Recommendation V.90 TD-21(Plen)V.250 Amendment 1, Serial Asynchronous Automatic Dialing andControl

TD-34(Plen)

T.30 Amendment 4, Document Facsimile Transmission in the GSTN TD-38(Plen)T.30 Corrigendum, Document Facsimile Transmission in the GSTN TD-30(Plen)T.38 Amendment 4, Procedures for Real-time Group 3 FacsimileCommunication over IP Networks

TD-32(Plen)

T.89 Amendment 1, Application Profiles for Rec. T.88 D.101From Working Party 2 – Multimedia Platforms and InterworkingH.324 Annex I, Usage of HTTP generic capability in H.324 terminals TD-22(Plen)

TD-23(Plen)H.223, Multiplexing protocol for low bit rate multimedia communication TD-29(Plen)H.323 Annex M3, DSS1 Tunneling TD-10(Plen)H.323 Annex Q, Far End Camera Control TD-17(Plen)H.323 Annex R, Robustness TD-19(Plen)H.GEF.2, Number portability TD-47(Plen) +

TD-50(Plen)H.450.12, Common Information Additional Network TD-11(Plen)H.245V8, Control protocol for multimedia communication TD-37(Plen)H.246 Annex F, Interworking of H.323 and H.324 Annex C TD-36(Plen)H.248 Annex L, Error Code and Service Change Reason Description TD-14(Plen)H.248 Annex M2, Congestion Control Package TD-16(Plen)H.248 Annex M.4, Interworking between H.324C and H.323 TD-41(Plen)From Working Party 3 – Media CodingNoneFrom Working Party 4 – Multimedia FrameworkF.706, Service Description for an International Emergency MultimediaService

TD-62(Plen)

Recommendations for Determination via TAP (Traditional Approval Processusing WTSA Resolution 1)

Recommendations for Determination DocumentsFrom Working Party 1 – Modems and Facsimile TerminalsT.35 revised * TD-33(Plen)

* Note it was agreed during the closing SG16 Plenary that the Annexes in T.35 would not beconverted to Appendices and would remain as Annexes.



Other Approvals

The following documents were approved by Study Group 16.

Texts for approval DocumentsFrom Working Party 1 – Modems and Facsimile TerminalsV.250 Supplement TD-12(Plen)Proposed Circular on V.92 modem spectrum usage TD-35(Plen)From Working Party 2 – Multimedia Platforms and InterworkingT.120 Series Implementer’s Guide TD-28(Plen)H.320 Series Implementer’s Guide TD-24(Plen)H.324 Series Implementer’s Guide TD-25(Plen)H.323 Series Implementer’s Guide TD-31(Plen)H.248 Implementer’s Guide TD-15(Plen)H.248 Supplement TD-26(Plen)From Working Party 3 – Media CodingH.263 Appendix II Revised TD-43(Plen)H.263 Appendix III TD-44(Plen)H.263 Implementer’s Guide TD-45(Plen)G.729 Appendix I TD-48(Plen)From Working Party 4 – Multimedia FrameworkMediacom 2004 Project Document (for publication on the ITU web site) TD-67(Plen)

New Question on Distributed Speech Recognition

In response to Delayed contribution D.142 from the USA, it was agreed to initiate a new Questionwith the subject “Distributed Speech Recognition (DSR) and Distributed Speaker Verification(DSV).” This will become Question 15/16 and is assigned to WP3/16. No Rapporteur has beenappointed at this time. The text of the Question is available in TSB Circular Letter No. 48. See QEreport, below, for details.

Joint Project with ISO/IEC on Video Coding

A proposal to establish a Joint Video Team with ISO/IEC JTC 1/SC 29 was agreed, and proposedTerms of Reference (TD-46[Plen]) for this Team will now be proposed to ISO/IEC JTC 1/SC 29.This work will combine the work of the Q6/16 Rapporteur Group with that of the Video Subgroupof WG11 of ISO/IEC JTC 1/SC 29, and will produce a new video coding Recommendation, takingover the work on H.26L, and a new ISO/IEC International Standard.

Interim Meetings and Next Meeting of Study Group 16

The next full Study Group 16 meeting will be February 5-15, 2002, in Geneva Switzerland. Theduration of the meeting has been reduced by one day; opening plenary sessions are intended to bevery short.

The following interim meetings were approved.



Questions Tentative Date Tentative Place Tentative Host7 July 23-27, 2001 Montreal, Canada6 September 4-7, 2001 TBD TBD

B, D, F, G, 1, 2, 3, 4, 5,11, 12

September 24-28, 2001 Santa Barbara, CA,USA

Cisco

11 week of October 29, 2001 TBD TBD7, 8, 9, 15 November 12-16, 2001 Geneva ITU-T

WP3* November 16, 2001 Geneva ITU-T6 November 27-30, 2001 TBD TBD6 Jan. 27 - Feb. 1, 2002 TBD TBD

SG16 February 5-15, 2002 Geneva ITU-T

* The meeting of WP3 has the intention of applying AAP Consent to G.WB16kbit/s

Additionally a joint workshop is proposed with ITU-T SG9 and ITU-R SG6, covering thefollowing projects:

• IP Cablecom (ITU-T SG9)• Mediacom 2004 (ITU-T SG16)• Interactivity in Multimedia (ITU-R SG6/WP6M)

The provisional dates for this workshop are March 25-28, 2002.

Other Highlights

TD-06(Gen) is a liaison from SG7 providing information on ASN.1 use of XML, encoding controlnotation, tools, and books on ASN.1. The ASN.1 standards group has made much progress inenhancing ASN.1 to allow its use in support of legacy applications, and to allow XML browsers todisplay values of types defined using ASN.1. Work is also underway to allow messages describedusing XML to be converted to ASN.1, thereby circumventing the verbosity of XML encodings andallowing them to be encoded very compactly. In conjunction with this work, ASN.1 tools are underdevelopment to support these new notations.

Free versions of both an ASN.1 syntax checker which supports XML markup, and anASN.1+ECN syntax checker, will be made available at <http://www.oss.com> around September2001. Commercial versions of both ASN.1 products with XML markup support and ASN.1+ECNtoolkits will start to become available at the same time. More information on ECN, including atutorial, can be found at <http://asn1.elibel.tm.fr/ecn>. Free copies of electronic books onASN.1:1997, and free copies of ASN.1:1997 validation tools, can be obtained from<http://asn1.elibel.tm.fr> and <http://www.oss.com>. Additionally, a list of commercial andfreeware ASN.1 products can be found at <http://asn1.elibel.tm.fr> and <http://www.asn-1.com>.

In discussion of TD-06(Gen), it was emphasized that the information it contains might prove usefulduring the development and debugging of products.

TD-03(Plen) is a liaison from ITU-T TSAG containing the draft revised Annex A toRecommendation A.23: Guide for ITU-T and ISO/IEC JTC 1 Cooperation. It also includes detailsabout the terms used, and operation and organization of both standards bodies. All involved SGsare invited to review the draft and make comments by the end of October 2001.

TD-04(Plen) is a liaison from WP3/TSAG to all ITU-T SGs requesting information on their EDHactivities, and informing of further information and developments regarding EDH. Of note, on theITU-T website, each SG home page now has a link to the official documentation for the 1997 –2000 period. The TDs that were available on the informal ftp area during the 1997 - 2000 period



are maintained in the iftp area. The “Author’s Guide for Drafting ITU-T Recommendations” isavailable on the ITU website on every SG home page. This liaison was presented for information.

TD-13(Gen) is a liaison from SG13 informing that the work plan related to ICG-SAT (satelliteissues) of ITU-T Study Groups is not up-to-date and that there are questions to be deleted and newquestions to be added. The electronic version of the ICG-SAT work program can be found onlineon the ITU-T web pages. TD-13(Gen)Add from the TSB contains the requested informationsupplemental to TD-13(Gen) regarding SG16 work items.

TD-05(Plen) is a liaison from TSAG informing that they have identified the promotion of ITU-T asa priority activity. The involvement of Study Groups is important to carry out this activity. Each SGis therefore invited to appoint a public relations coordinator to participate in a new correspondencegroup on the promotion of ITU-T activities.

A draft Public Relations (PR) Plan for the Study Group was drafted and is available in TD-68(Plen). M. Buckley (Lucent Technologies, UK) was appointed as PR Officer for the SG. Keyobjectives of the marketing plan include the promotion of H.323, the new speech recognitionquestion and the collaboration with MPEG in the area of video coding.

This was the final meeting of the SG16 Counselor and TSB Deputy Director, F. Bigi; presentationswere made wishing him well in his retirement.

In appreciation of the location, and the active social events, the Study Group decided to have aspecial “Dancing Award.” This was awarded to L. Brown (Conexant, USA).

Working Party 1/16, Modems and Facsimile Terminals

Working Party 1/16 had its first meeting of the study period 2001 - 2004 under the chairmanshipof M. Matsumoto (NTT/Waseda, Japan). TD-07(1/16) is the draft agenda and work plan. TD-61r1(Plen) is the WP1/16 meeting report, Part 1, General; TD-63r1(Plen) is the WP1/16 meetingreport, Part 2, Liaisons & Approval.

K. Chu (Conexant) was appointed to succeed R. Damm (Deutsche Telekom) as the Question 13/16Rapporteur.

Cooperation in ITU Activities

The following contributions received at this meeting contain useful information:

• TD-01(Plen), Revision of the lists of qualified organizations (ITU-T TSAG)• TD-02(Plen), Procedure for including references to documents of other organizations in ITU-T

Supplements (ITU-T TSAG)• TD-06(Gen), ASN.1 Encoding control notation, tools, and books on ASN.1 (O. Dubuisson,

France Télécom R&D, Q9/7 Rapporteur) See the Q3/WP2 meeting report for details.

Working Party 2/16, Multimedia - Platform and Interworking

F. Tosco (Telecom Italia Lab) is the WP2/16 Chair. TD-30(2/16) is the draft agenda and workplan. TD-71(2/16) is the report of the WP2 meeting. TD-52(2/16) lists the documentation for thismeeting. TD-42(Plen) shows the status report for the WP2/16 Recommendations. TD-51(Plen)shows the documents comprising the WP2/16 report.



All the WP2/16 Rapporteurs, and in particular the Rapporteurs for Questions D, F, G, and 5, wereinvited to cooperate with the WP4/16 Chair (J. Magill, Lucent) in updating the text of theMediacom 2004 Project and in preparing the documents related to the Project. The WP4/16 Chairwill contact the appropriate Rapporteurs for support (see the QA report, below).

It was confirmed that every effort will be made to continue and improve the cooperation with IETFin the development of H.248 and hopefully on other standardization activities of common interest.

Working Party 3/16, Signal Processing

S. Campos Neto (Comsat) is the WP3/16 Chair. TD-03r1 is the WP3 agenda. TD-58(Plen) is thedraft WP3/16 meeting plenary report; TD-57(Plen)r1 is the executive summary. TD-60(Plen)contains the status report for WP3/16 Recommendations as of this meeting. TD-16(3/16) containsthe opening list of documents for WP3/16. COM 16-R08 is the report of the November 2000WP3 meeting.TD-59(Plen) contains the final versions of WP3/16 liaisons which are discussed inthe Questions below. No Recommendations for Consent were produced at this meeting.

Working Party 4/16, Multimedia Framework

Working Party 4/16 met under the chairmanship of J. Magill (Lucent). TD-11(4/16) is the agendaand work plan for this meeting. TD-64(Plen) contains the WP4/16 meeting report. TD-30(4/16) isthe proposed WP4/16 work plan. TD-65(Plen) contains the liaison statements from WP4/16. TD-66(Plen) contains the WP4/16 work plan.

TD-02(4/16) is a liaison from SG15 concerning the revised versions of the Access NetworkTransport (ANT) Standardization Plan (Issue 4) and Work Plan (Issue 3). Study Group 15entrusted WP5/15, under Question 1/15, with the task to manage and carry out the Lead StudyGroup on Access Network Transport activities. The outcome of the activities is twofold, consistingof the Standardization Plan, containing ANT scenarios and a list of Standards andRecommendations from ITU and various Standardization Bodies, as well as an ANT Work Plan.The work plan provides an overview of various Standardization Groups and ongoing ANTactivities. Both documents were revised in the February 2001 meeting of SG15. The documents(antstandplan4.doc, antworkplan3.doc) can be found on <http://ties.itu.int/u/tsg15/sg15/ant>(username and password required).

Question A/16 WP4, Mediacom 2004

Working Party 4/16 addressed Question A under the chairmanship of J. Magill (Lucent). This wasthe first meeting of Question A/16. TD-15(4/16) is the meeting agenda. The meeting report iscontained in TD-29(4/16).

Liaisons

TD-01(4/16) is a liaison from SG11 informing that SG11 is currently developing a number of IPrelated recommendations that cover the work related to BICC (bearer independent call control)using an IP transport and the interworking of IN with IP networks; SG11 believes it would beuseful to include a session in the proposed Mediacom 2004 Workshop for SG11 to presentmaterial covering their activities.

TD-03(4/16) is a liaison from SG9 thanking SG16 for information on the Mediacom 2004 Project.SG9 also notes their willingness to review SG16’s multimedia standards issues list for overlappingor conflicting standardization work or required standards that are not being addressed.



TD-08(Gen) is a liaison from ISO addressing the following three matters related to MPEG-21issues:

1) Version 2 of the proposed draft Technical Report for MPEG-21, Vision, Technology andStrategy. Today, many elements exist to build an infrastructure for the usage of multimediacontent. There is, however, no “big picture” describing how the specifications of theseelements, either in existence or under development, relate to each other. The aim of startingMPEG-21 is to understand if and how these various elements fit together and to discuss whichnew standards may be required, if gaps in the infrastructure exist. Once this has been carriedout, MPEG-21 intends to develop new standards with, where appropriate, the involvement ofother bodies, and to accomplish the integration of different standards.

2) Updated version of the call for proposals for digital item identification and description3) A call for requirements for a rights data dictionary and a rights expression language

TD-14(Gen) is a liaison from SG13; Study Group 13 considers that activities related to NGN fallunder the umbrella of its GII related activities. It is therefore the intention of Study Group 13 toorganize its coordination and management role of project-oriented work accordingly.

TD-15(Gen) is a liaison from SG13 informing that they have completed their update of the ITU-TIP Project; it includes a current copy (version 5) of the Project. (For details, including the SG16response, see the Q3/16 meeting report, below.)

Mediacom 2004

The objective of the Mediacom 2004 project is to create a framework for the harmonized andcoordinated development of multimedia communication standardization for use across all ITU-Tand ITU-R Study Groups, and in close cooperation with other regional and international SDOs andindustry fora.

The first activities within the project, a joint Workshop with SG13, was held in Geneva in April2001. The themes were: IP Networking and Mediacom 2004. The report of this workshop iscontained in TD-06(Plen); the presentations and conclusions are available on the ITU website:<http://www.itu.int/ITU-T/workshops/ipnetwork_mediacom2004/index.html>. In association withthe Workshop, the Mediacom 2004 Steering Committee also held a meeting; the report of thismeeting is contained in TD-17(Gen). This report provides a detailed list of coordination activitiesand directions between SG16 and other Study Groups, Regional SDOs and fora.

TD-14(4/16) (J. Magill, Lucent) proposes revisions to the Mediacom 2004 Project document (Aframework for multimedia standardization, Project description [v.1.1]), intended to shorten andstreamline it, removing background and reference material. TD-14(4/16) also includes revisionsproposed by the QG/16 Rapporteur on security aspects. These proposals were accepted. TheRapporteur revised the document, as TD-24(4/16), which was further revised as a result ofdiscussion. The final version (v.2: TD-67[Plen]) was presented for Approval by SG16, for postingon the ITU website.

TD-25(4/16) is a liaison to ITU-D Study Groups, providing an update on the progress of theMediacom 2004 project.

TD-27(4/16) is a liaison to SGs 2, 7, 9, 11, 12, and 13 informing that the Mediacom 2004 Projectdocument has been revised and is available on the ITU website: <http://www.itu.int/itudoc/itu-t/com16/mediacom/projdesc.html>. SG16 welcomes comments on the information contained in“Analysis of MM Standardisation Roles” given in Table 4 of the project document; it identifies theactions of different SDOs and SGs in relation to MM work.



TD-28(4/16) is a liaison to ISO thanking them for their liaison concerning the work on MPEG-21,and informing them of the revision of the Mediacom 2004 document.

TD-26(4/16) (J. Bormans, MPEG-21 Editor; J. Magill, Mediacom 2004 Rapporteur) describes therelationship between the MPEG-21 and Mediacom 2004 Projects. It is intended to form the basisof a living document that will document areas of cooperation between the two Projects. Part of TD-26(4/16) will be included as an Annex in the Mediacom 2004 Project document.

Multimedia Glossary

QA reviewed TD-18(Gen), which contains information from ETSI Project TIPHON providingterms and definitions currently under review by TIPHON.

QA was informed that SG13 has agreed to a new Annex to I.112 referencing American NationalStandard T1.523-2000, Telecom Glossary 2000, which is a web-based, hyperlinked, search engine-equipped telecommunication terminology standard containing definitions for more than 8000 terms.It is available at <http://www.its.bldrdoc.gov/projects/telecomglossary2000>.

It was agreed to investigate whether there exist any multimedia related terms not covered by T1.523-2000, and if necessary develop a list of SG16 definitions.

Question B/16 WP4, Multimedia Architecture

The Rapporteur for QB/16, J. Vandenameele (Alcatel) was not available to attend the meeting;Working Party 4/16 addressed Question B under the chairmanship of M. Buckley (Lucent). Thiswas the first meeting of Question B/16. TD-16(4/16) is the meeting agenda. TD-29(4/16) is themeeting report.

QB considered the following contributions, which describe various architectures for multimediaapplications over packet network, in use within SG16 and in other Standards Bodies:

• TD-57(2/16), Overview of ETSI TIPHON architecture (M. Buckley, Lucent)• D.103, Framework of QoS and multimedia performance in multimedia systems (R. Roy,

AT&T). (See report of QF, below.)• TD-42(2/16), Application level control of end-to-end QoS (M. Buckley, Lucent). (See report of

QF, below.)• TD-59(2/16), Draft Recommendation H.MMS.1, Mobility for H.323 multimedia systems. (See

report of Q5/16, below)• TD-60(2/16), Draft Recommendation H.MMS.2, Mobility interoperability. (See report of

Q5/16, below.)• TD-61(2/16), Scope and terms of reference for H.MMS.3, Mobility presence for multimedia

systems and services (M. Paul, Trillium). (See report of Q5/16, below.)

It was agreed that the scope of QB should include the following objectives:

1) Act as a point within SG16 for considering new work items and collecting requirements for newworks items; also, assessing how new work items will impact on existing work underway inSG16.

2) To produce a general architecture, H.mmarch, for multimedia services and applications, whichshould encompass the following aspects:



– General architectural requirements– Emergency services– QoS– Mobility– Security– Addressing issues– Interworking (PSTN -ISUP, Q.931, SIP, BICC, etc.)

It was agreed to consider the ETSI TIPHON architecture as a basis for this general architecture, toidentify areas where further extensions to this are required, and to examine relevant architecturalwork taking place in other standards bodies.

Incoming Liaisons

TD-01(Gen) is a liaison from ITU-R Working Party 6M; it provides the fourth revision of theworking document for diagrammatic inter-relations of Recommendations for interactivebroadcasting services and their summaries. This working document explains the current status ofrelevant existing Recommendations as well as draft Recommendations under study. Interactivebroadcasting technology is one of the key factors necessary for multimedia broadcasting systems.QB noted this liaison, and agreed to send a liaison reply (TD-18[4/16]) asking WP 6M to keepthem informed of further developments in this work.

TD-03(Gen) is a liaison from SG4 concerning the MoU between ISO, IEC, UN/ECE, and ITU-Trelated to standardization on electronic business. SG4 informs that Q9/4 has been designated aslead question within SG4 for e-business. Their scope and mandate is for X-interfaceRequirements. The recommendations they are currently developing for managing communicationsresources employed in support of e-business include M.QoS, related to the managementrequirements for quality of service and management of the service level agreements, between TMNsrepresented as trading partners. Also, they are beginning a work program related to the use ofXML within the context of TMN. Initially they are developing M.33tML, which is focused on theuses of XML within the TMN to support pre-ordering, ordering, trouble administration, billing,provisioning, performance management, maintenance management, and VPN management.Currently, both these specifications are scheduled for Decision under AAP at the SG4 April 2001meeting.

TD-04(Gen) is a liaison from SG7 offering comments on GII projects M.1, M.3, M.4, M.6, M.7,N.3, and N.9. The SG7 comments on GII Project M.3, Technical framework for electroniccommerce, are against the updated project description SG7 received from Q1/16.

Question C/16 WP4, Multimedia Applications and Services

The Rapporteur for Question C/16, F. Lucas (3Com) was not available to attend the meeting;Working Party 4/16 addressed Question C under the chairmanship of J. Magill (Lucent). This wasthe first meeting of Question C/16. TD-17(4/16) is the meeting agenda. The meeting report iscontained in TD-29(4/16).

TD-23(4/16) (J. Magill, Lucent) is the proposed QC/16 text for the Mediacom 2004 Projectdocument.



Draft Recommendation F.IEMS

TD-10(Gen) (G. Kelley, Artel, Editor) is the draft Recommendation F.IEMS, Service descriptionfor an international emergency multimedia service. This draft was presented at the March 2001Rapporteurs meeting in Launceston (AVD-2089).

QC reviewed the following liaisons on this topic:

• TD-12(4/16) is a liaison from SG11 seeking clarifications concerning international emergencyservices. (This liaison is the same as TD-04[2/16]; see the Q3/16 meeting report, below.)

• TD-13(4/16) is a liaison from SG4 on M.IEPS. (This liaison is the same as TD-17[2/16]; seethe Q3/16 meeting reportt, below.)

An editing group convened to revise the draft text, taking into account these liaisons. The output ofthis editing work is contained in TD-18(Plen); this was proposed for SG16 Consent.

TD-62(Plen) contains the draft Recommendation F.706 (F.IEMS), Service description for aninternational emergency multimedia service; this was agreed by the SG for Consent.

TD-20(4/16) is the SG16 response to TD-13(4/16): SG16 notes that their new RecommendationF.IEMS is an extension of E.106 on IEPS to include requirements for multimedia services tosupport emergency communications over an IP-based packet network environment. Further aspectsof service management requirements will become better known as SG16 develops the architecturefor IEMS. SG16 suggests that SG4 reference F.IEMS for emergency multimedia communicationsin M.IEMS.

Future Work on Services and Applications

QC reviewed the following additional input documents related to the work on e-commerce:

D.95 (S. Okubo, Global Information and Telecommunication Institute, Waseda University)provides a number of basic scenarios for the utilization of Internet services to enhancevideoconferencing and videophone that could form a basis to derive technical requirements for theenhanced system.

TD-09(4/16) (Y. Robin-Champigneul, France Telecom/CNET) presents scenarios for services andapplications.

TD-10(4/16) (Y. Robin-Champigneul, France Telecom/CNET) contains a copy of ISO/IECJTC1/SC29/WG11/N3549, MPEG-21 Use case scenarios (v.0.2).

Taking the above documents into account, the QC action plan was revised.

E-commerce/E-business

The Associate Rapporteur for e-commerce/e-business in Question C/16, E. Blausten (USA) wasnot available to attend the meeting. QC reviewed the following liaisons relating to the work on e-commerce under the chairmanship of J. Magill (Lucent).

TD-04(4/16) is a liaison from SG11 informing that they are just starting work on a new Question(Q4/11), which will be studying API/Object interface and architecture for signaling. The APIsbeing studied will also include support for e-commerce and mobile e-commerce; hence, SG11believes, this new Question 4/11 should be included in SG16’s list of questions involved in e-



commerce. Also, SG11 is currently developing a number of Recommendations that concern theevolution of SS No. 7 and interworking with IP networks. It is this signaling infrastructure that willbe used to transport the e-commerce applications.

TD-05(4/16) is a liaison from the Special Study Group on IMT 2000 and Beyond, indicating theirinterest in the topic of m-commerce (mobile commerce), and asking that SG16 keep them informedof activities and progress in this area. SSG IMT 2000 provides an outline of the SG structure andQuestions, and a summary of the results of their first meeting. The Question under which theyhave an interest in m-commerce is Q5/SSG.

TD-06(4/16) is a liaison from SG7 announcing their establishment of WP3/7, E-commerce/E-business, with responsibilities for the following three Questions:

• Q12/7, Directory services and systems• Q13/7, Security services, mechanisms, and protocols• Q14/7, Open distributed processing (ODP)

SG7 includes the action plans for these Questions, and affirms their interest in a close collaborationwith SG16 as the lead SG on electronic commerce.

TD-08(4/16) is a liaison from SG2 referencing the SG16 November liaison (TD-94[2/16])concerning Project M3 on electronic commerce: currently, SG2 is not addressing any of the issuesSG16 specified, but will undertake to keep SG16 advised if they do. Q4/2 discussed this liaisonand considered that there might be human factors issues that should be studied under Q4/2 in thefuture. While no specific work is in progress at present, Q4/2 would like to be kept informed ofdevelopments.

QC reviewed the following additional input documents relating to the work on e-commerce:

• TD-07(4/16), liaison from the MoU Management Group (MoU/MG) on E-business containingthe minutes of the fifth meeting, held in Geneva, in November 2000.

• TD-09(4/16), Scenarios for services and applications (Y. Robin-Champigneul, FranceTelecom/CNET).

• TD-06(Plen), Final report of the Workshop on IP-Networking and Mediacom 2004 held inGeneva, in April.

• TD-17(Gen), Report of the Mediacom 2004 Steering Committee meeting.

Using these documents, the project plan for e-commerce/e-business was updated (TD-22[4/16]).However, the WP4 Chair expressed concern about the lack of active participation in this work area.

TD-21(4/16) is a liaison to SGs 4, 7, 11, 13, and SSG, informing that, in its capacity as lead SG one-commerce/e-business, SG16 is developing a work plan for this activity. The latest version of theirplan (TD-22[4/16]) is attached for information and comment.

Question D/16 WP2, Interoperability of Multimedia Systems andServices

T. Taylor (Nortel) is the Rapporteur. Question D/16 was discussed together with Questions 2/16and 3/16. The results are reported in the reports of those questions, below.



Question E/16 WP3, Media Coding

Working Party 3/16 addressed Question E under the chairmanship of S. Campos-Neto (Comsat).TD-13(3/16) is the agenda. TD-34(3/16) is the meeting report.

New Question 15/16 WP3, Distributed Speech Recognition/Distributed SpeakerVerification

D.142 (USA; L. Brown, Conexant) proposes that ITU-T SG16 open a new Question to develop aRecommendation for a distributed speech recognition system.

D.143 (USA; L. Brown, Conexant) provides a brief overview of the DSR (Distributed SpeechRecognition) concept, discusses its benefits, and explains the need for adopting standards forimplementing components of the system on a packet-based network such as the IP network.

An ad hoc group (chaired by L. Brown, Conexant) convened to discuss the issue. It was agreedthat a Question dealing with speech recognition and speaker verification is urgently needed. Fivecompanies committed to support the effort: Alcatel, Conexant, France Telecom, Qualcomm, andTexas Instruments. In a session including WP2/16 experts, an initial text for the proposed newQuestion was agreed (TD-19[Gen]). In a subsequent session, a modified text was produced (TD-40[Plen); it was subsequently approved by SG16.

Two Rapporteur meetings are planned, for July and November 2001, to begin defining the nearterm work plan for the new Question. The WP3 Chair (S. Campos-Neto) will act as Rapporteurfor the Question until the next SG16 meeting.

Typically, in speech recognition systems currently deployed in commercial applications, the wholespeech recognition system is implemented in a central place to which all speech signals are routed.Along with speech recognition, speaker verification plays an important role as a biometricverification mechanism, as recognized in the IP Networking and Mediacom 2004 Workshop held inApril 2001 in Geneva (TD-06[Plen]).

Speech recognition and speaker verification systems need to perform a set of operations, such assignal pre-processing, some sort of front-end extraction of features or parameters, back-endprocessing, and higher layer control according to the constraints of the application.

With voice communication over packet-based digital networks becoming popular (such as voice-over-IP), elements sitting on the edge of the packet network are becoming more capable ofaccomplishing complex signal processing tasks, such as speech encoding and decoding. With thisevolution there is an opportunity to enhance the performance and efficiency of speech recognitionand speaker verification systems by moving some of the basic speech signal processing tasks to theedge of the packet network.

Components of a speech recognition or speaker verification system can be distributed between anedge element (such as a router, gateway, or IP telephone) and a remote application server in aflexible manner. For example, the front-end may be implemented on a gateway and the back-endon an application server. In this example, a gateway processor would perform pre-processing andfeature-extraction for speech recognition or speaker verification purposes. The features would becompressed, packetized, and sent to a speech recognition/speaker verification application server. Inturn, the server would perform the back-end processing and take the appropriate action.Alternatively, a portion of the front end such as the speech end-pointer may be implemented on agateway with the feature extraction and back end being implemented on a server.



One of the key issues to be resolved if DSR and DSV are to become successful is interoperabilitybetween system components at the edge of the packet network and those on the server, where theedge element and server are produced by different vendors. This is where standardization is critical.

Q15/16 will study which standards for DSR and DSV should be adopted for use over packet-baseddigital networks, such as IP or ATM networks. Study items include:

• Develop the overall system architecture for DSR and DSV systems.• Determine which sets of features are appropriate for DSR and DSV, taking into consideration

that the back-end processing should be left as open as possible to allow for improvements in thetechnologies.

• Study aspects of the front-end processing and feature extraction that should be standardized toensure interoperability between front-end and back-end components of DSR and DSV systems.

• Define the signaling requirements for communication among front-end, back-end, and anyintermediate processing elements of DSR and DSV systems, and develop a mechanism fornegotiating capabilities between these elements and selecting a mode of operation.

• Define the protocol requirements for transport of the extracted information over packet baseddigital networks, and either identify an existing or develop a new transport protocol.

• Consider interoperability issues with existing systems (examples: ETSI Aurora and proprietarysystems).

QE agreed to send a liaison (TD-20([Gen]) to inform TSAG of the creation of the new Question,and to request comments and inputs from SGs 12 and 15. It was also agreed to send this sameliaison as a communication to ETSI Aurora, which works on speech recognition systems forwireless networks. It was also agreed that the start of the speech recognition and speakerverification work should be publicized, including instructions on how to participate on the work;experts were invited to circulate the information to the relevant communities, including the IEEE.

Still-Image Coding

QE reviewed the situation of the JPEG2000 work between November 2000 and May 2001, basedon the information in the following documents:

• COM16 R-2 (SG16), Report for WP1/16, November 2000• TD-11(3/16), liaison from ISO/IEC JTC1/SC29/WG1 on the IPR status of draft ITU-T T.800

(JPEG2000 Part 1) and JPEG LS Extensions (Draft ITU-T T.870)• D.155 (Siemens), Status of ITU-T T.8XX (JPEG2000 and JPEG LS Ext) still-picture standard

work being done by the ISO/ITU Collaborative Team

QE also noted:

• COM 8-116 (ITU-T SG8), draft new Recommendation T.800• COM 8R-14 (ITU-T SG8), Report of the meeting of SG8 (Geneva, February 2000), Part II.1:

Draft Recommendations T.800 (ISO/IEC 15444-1), T.870 (ISO/IEC 14495-2)

ISO/IEC JTC1/SC29/ WG1 approved the JPEG2000 baseline and JPEG2000 LS extensions asInternational Standards, after ISO experts determined that some patent declarations that were in linewith ITU-T’s Patent Policy Item 2.3 were not essential to JPEG2000. The approval of JPEG2000Part 2 was postponed by a few months, and the final approval by ISO of Parts 3-6 (as well as oftwo amendments to Part 1) is expected to be distributed over time, the latest being March 2002.

Regarding T.800/T.870, QE agreed that the two texts should be Consented at this meeting, but notas common text, as was initially planned. Since the technical work in this item is solely performed



by ISO/IEC JTC1/ SC29/ WG1, SG16 considered that it will be more meaningful and efficient thatthe text be published and maintained by ISO. Furthermore, as pointed out by the SG16 Chair, theuse of the common text mechanism is becoming less common in the ITU-T. The ITU-T willprovide catalogue entry numbers that refer T.800 and T.870 to the respective ISO InternationalStandard. QE noted that the number of IPR statements provided to ISO is much larger than thenumber of statements submitted to the ITU. It was also agreed that since these ITU-T “pointer”Recommendations will have only formal reference to the ISO/IEC IS, and not any technical content,they should be made available for free to the public.

Regarding T.801 through T.806, since no final texts can be made available within eight weeks afterthis SG16 meeting, QE Consent considerations were postponed to the SG16 meeting in February2002, when it is expected that the final version of all texts will be available. Consistent withT.800/T.870, T.801 through T.806 are also planned for publication in the ITU-T not as commontext but as catalogue entry numbers pointing to the respective ISO International Standards.

TD-33(3/16) contains the liaison informing ISO/IEC JTC1/ SC29/ WG1 of the SG16 resolutionconcerning the publication of JPEG2000.

G.799.1, TIGIN

ITU-T Q7/15, Functionality and interface specifications for GSTN transport network equipment forinterconnecting GSTN and IP networks, is developing the new ITU-T Recommendation G.799.1,covering functionality, interfaces, performance requirements, and functional tests for voice gatewaysinterfacing GSTN to IP networks. The current text of draft G.799.1 is available on Q7/15’s IFAweb page at: http://ties.itu.int/u/tsg15/sg15/wp2/q7/q7_index.htm (user ID and pass word required).

In liaison TD-02(Gen), Q7/15 requests SG16 guidance on what text should be included in G.799.1regarding codec negotiation under conditions of congestion on the IP network to maintain a certainthroughput. In liaison TD-12(3/16), Q7/15 requests SG16 guidance on speech quality aspects ofthis equipment, and specifically, on what text and reference recommendations should be included inSection 4.2, Voiceband quality. They also request guidance concerning modem-over-IP matters(see the Q11/16 report, below). Additionally, they request guidance on the current status of silencecompression/comfort noise generation and lost packet concealment, under Section 4.1.3. In liaisonTD-08(3/16), Q7/15 requests guidance on the appropriateness of the following wording in G.799.1,Section 4.1.2, Voice Coding:

There should be a method of ensuring synchronous reset capability of a low-bit-rate voice coder.For a codec of this type, using an external synchronous reset will be beneficial to voice quality,particularly at the transient from silence to active speech when the codec is used in the DTXcondition. If generic SID comfort noise insertion is used with a low-bit-rate coder, synchronousreset between encoder and decoder should be employed.

QE reviewed with great interest parts of Sections 4.1 and 4.2 of G.799.1 v.5, and offeredconsiderable modifications (detailed in TD-33[3/16]) to the draft text.

Question F/16 WP2, Quality of Service and End-to-End Performancein Multimedia Systems

M. Buckley, (Lucent) is the QF/16 Rapporteur. TD-54(2/16) is the agenda. TD-92(2/16) is themeeting report. TD-77(2/16) lists the proposed work items for QF/16.



Scope of QF/16

QF considered the following two contributions jointly with Questions D, G, 2, 4, and 5:

D.102 (R. Roy, AT&T) proposes the scope of QF/16, and summarizes the information developedin D.103.

D.103 (R. Roy, AT&T) provides a generic model, architecture, and protocol for the applicationlayer QoS that can be used by any multimedia applications, considering inherent characteristics ofeach medium: audio, video, and data. It proposes a generic model for traffic and QoS parameters.The application layer QoS architecture it proposes shows what is common to all applications andwhat is not. It proposes a new approach for creation of both application-independent andapplication-dependent QoS signaling protocols. It also describes the value-added application layerQoS signaling protocol. It provides the fundamental basis of how the intelligence related to QoScan reside in different functional entities across the network and how the QoS signaling protocolscan be used for service creation by different functional entities. It outlines the scope forstandardization of QF/16 and H.323 Annex N in the light of the overall QoS frameworkarchitecture.

TD-42(2/16) (M. Buckley, Lucent) gives background to the application level QoS control techniquethat forms the basis of H.323 Annex N. This approach is sufficiently general to be also used forend-to-end QoS control in other packet-based multimedia systems.

A drafting group convened to propose work items (TD-77[2/16]) based on these threecontributions, which, it was agreed, contain various useful ideas. QF agreed to adopt TD-77(2/16),which postulates nine different recommendations (including Annex N) as the basis of their work.See also the Q2/16 report, below, for additional discussion.

International Emergency Priority Services (Joint with Questions D, G, and Q1-5)

D.98 (G. Thom, Delta Information Systems) proposes a change to H.246 Annex C to provide amapping between the calling party’s category number and the service class generic data messagedefined in H.GEF.4 (Service class designations for H.323 Calls). H.246 Annex C describes themethod to be used when interworking between Signaling System 7 - ISDN User Part (ISUP) andH.225.0. This is necessary in those systems in which the ISUP signaling is terminated at thegateway and converted to H.225.0 signaling on the packet network, and vice-versa. In some areas,particularly in the US, the Calling Party’s Category parameter within the Initial Address Message(IAM) in the ISUP signaling is used to indicate a high probability of call completion. In addition,the IAM message will have the message priority set to 1. Currently, H.246 Annex C indicates thatthe mapping of the Calling Party’s Category parameter is for further study, and thus is not mappedinto the H.225.0 SETUP message.

In discussion, it was pointed out that there is currently no code point in ISUP to indicate prioritycalls. There appears to be a code point in a U.S. variant, but nothing in the ITU ISUP. It is notclear if there is work currently under way to define this code point in ITU ISUP. Moreinvestigation into the use or definition of an appropriate code point is needed.

The proposed changes were not accepted, but it was recognized that the IEPS work is justbeginning. It will likely be necessary to address this topic (interworking IEPS between H.323 andISUP) in the future, when code points will have been added to H.225.

D.99 (G. Thom, Delta Information Systems) proposes that service classes be added to H.323 RASand call signaling. Currently there is no way to indicate the desired or approved class of service for



an H.323 call. It is necessary to signal the class of service during admission request and call setupsignaling for the gatekeepers, gateways, and other network elements to take appropriate action. Theaction to be taken is outside the scope of this proposal and would depend on service levelagreements between the user and the provider, but may include:

• Priority admission confirmation• Priority access to gateways• Approval of bandwidth requests• Request for QoS from network elements• Authentication of service level request• Other actions to assure a specific level of service

There are two methods that could be used to incorporate service class indications in the RAS andcall signaling messages. The first is to define and incorporate a service class parameter into eachaffected H.225.0 message. This approach provides the most compact message structure, but itcontinues the undesirable process of extending H.225.0 messages. The second approach is to usethe GenericData parameter added to H.323/H.225.0 v.4. This provides a method of extendingH.323/H.225.0 functionality without changing the H.323/H.225.0 documents. The proposed draftRecommendation H.GEF.4 in D.99 describes this second approach.

In discussion, the following comments and questions were raised: Should the priority and qualityparameters be combined? It seems logical to consider these together. Maybe these combine intosome QoS class parameter? But, a priority parameter indicates more than QoS; it also indicatestreatment and access to resources. A look should be taken at the different types of quality classesas currently under discussion in QF. QF is looking at signaling QoS parameters in the callsignaling plane (e.g., in H.225.0 or in H.225.0 Annex G) and in the media signaling plane (H.245);it might be necessary to do the same here. There may be a need to investigate how to use priorityfield in H.248 relative to priority and quality parameters in D.99, and add a QoS-style package.

The changes proposed in D.99 were not accepted; additional proposals were requested to helpcomplete the IEPS work. It was agreed that service priority, including international emergencyservices, should be taken into account in QoS signaling and control mechanisms. For H.323, thisshould be included in Annex N. QF also agreed to investigate a new work item, H.priority.

Other Contributions

QF noted the following contributions, which include details of how QoS should be taken intoaccount where mobility is involved. It was agreed that a common approach to accessing QoSinformation on servers together with other user profile parameters would be desirable. A newprotocol, H.policy, would be required. This work will be done by Q5/16 in the context of a generalprotocol for access to policy servers and back-end services. QF will feed requirements into theQ5/16 work item. See the Q5/16 meeting report, below, for disposition of the following:

• D.104, Problems for using H.225.0 Annex G Protocol for H.MMS.1 (H.323 Mobility) andProposed Solution (R. Roy, AT&T)

• D.105, Scope of Q15/16, Mobility for multimedia systems and services (R. Roy, AT&T)• D.106, Framework for extensions of multimedia applications/systems and services to support

mobility (R. Roy, AT&T)• D.107, Common mobility management protocol for all multimedia applications/systems and

services (R. Roy, AT&T)

TD-09(Gen) provides text for version 8 of Recommendation H.245, Control protocol formultimedia communication (this contribution is known as H245DELP). QF noted that extensions



to H.245, as well as other H.323 protocols, will be required to support the mechanisms in Annex Nof H.323.

TD-16(Gen) is a liaison from ITU-T SG13 informing that in their May 2001 meeting, SG13provisionally agreed to the new call processing QoS class structure, including four classes, for draftY.1530, Call processing performance for voice service in hybrid IP networks (Annex 9 in COM 13-R 7).

QF agreed that this work is very relevant to their work. The recommended times in Y.1530 forsession and media flow set-up, mid-session changes, session and media flow close down, and theirrelevance for multimedia applications and systems will be examined. A new work item, H.mmcp,Call processing performance in multimedia systems, was agreed; it will include these aspects, aswell as the implications for signaling latency and signaling reliability requirements.

Coordination

In liaison TD-02(Gen), Q7/15 requests SG16 guidance on what text should be included in G.799.1regarding codec negotiation under conditions of congestion on the IP network to maintain a certainthroughput. Jointly with QE, it was agreed to reply (see the QE report,above), drawing attention toParagraph 6.2.5.3 of H.323, Low bit rate operation. The reply also draws attention to the scope ofQF/16 for QoS procedures that may be adopted.

QF reviewed seven liaisons jointly with Questions 2 and 3 (See the Q3/16 meeting report, below,for details).

TD-50(2/16) is a liaison from SG13 noting Q6/13 progress on IP performance; it includes thelatest draft Recommendation Y.1541, output from the SG13 May meeting. The main changesinclude adoption of a normative reference path, with one or more network sections, and a minimumaccess link speed of T1 and higher. Q6/13 has recognized that the upper bound (in definition ofdelay variation) based on the 1-10-4 quantile is too high in light of evaluation intervals of about 60seconds and VoIP streams producing only 3000 packets during that interval. An upper quantile of1-10-3 is more reasonable. As a result, Q6/13 has augmented the text in 5.3.1 and AppendixII/Y.1541, and inserted a new Appendix IV/Y.1541 on delay variation. Q6/13 agreed that evaluationintervals should be supplied for the performance objectives. They introduced new text in5.3.2./Y.1541, recommending a one minute interval. The Q6/13 consensus was to leave availabilityobjectives and allocation of the performance objectives for further study, recognizing that the end-to-end QoS classes have value on their own.

In discussion, concerns were expressed about the approach adopted in draft Y.1541 to QoSclassification in the transport network. It was felt that this could lead to conflicts with theclassification work underway at the service level in QF/16 (H.mmclass) and SG12. The preferredapproach would be to leave transport QoS parameters flexible in each transport domain andnegotiate these between service providers and network operators either within SLAs or by dynamicsignaling (H.trans.control). It was agreed to send a liaison (TD-85[2/16] which is included in TD-54[Plen]) to SG13 suggesting that QF/16, SG12, and SG13 should work together in the context ofan agreed QoS architecture.

TD-51(2/16) is a liaison from SG13 informing that, in their May meeting, they found a study issuerelated to SIP. SG13 notes that SIP has a call set-up processing that is different from PSTN/ISDNand H.323. SG13 has agreed that the definition of call processing performance parameters of SIPis a study issue. SG13 requests information and comments from SG11 and other related SGs tomake more progress for SIP issues related to call processing performance.



It was agreed that QD/16 will take the lead in liaising with the IETF on SIP interworking matters;QF/16 will lead on call processing issues in general. It was agreed to send a liaison (TD-88(2/16]which is included in TD-54[Plen]) to SG13 informing them of the new work item, H.mmcp.

H.323 Annex N, End-to-End QOS and Service Priority Control and Signaling(Joint with Q2/16)

TD-43(2/16) (M. Buckley, Lucent, Rapporteur) is the new draft of H.323 Annex N, End-to-EndQOS and Service Priority Control and Signaling in H.323 Systems. In this draft, the scope of theAnnex has been extended to include the signaling and control of service priority. In review, theinclusion of service priority information was agreed. Changes would be required to H.225.0(Q.931 and RAS), H.245 and H.225 Annex G. The use of the GEF (Generic extensibilityframework) was a preferred approach to inclusion of the extra fields in these protocols. Theencoding proposals of D.98, Proposed change to H.246 Annex C to support service class, andD.99, Proposal to add service classes to H.323 RAS and call signaling, will be taken into account.

Question G/16 WP2, Security of Multimedia Systems and Services

There were no inputs to QG at this meeting other than TD-21(2/16), a liaison from SG9. Thediscussion of TD-21(2/16) appears in the Q3/16 meeting report.

Question H/16 WP1, Accessibility to Multimedia Systems and Services

G. Hellström (L.M. Ericsson), Rapporteur for Question H, could not be present at this meeting; inhis absence, T. Geary (Conexant) served as Interim Rapporteur. TD-34(1/16) is the meeting report.TD-22(1/16) is the agenda. TD-20(1/16) is the status report for QH/16 for this meeting. Therewere no documents from QH/16 to be considered for Consent.

TD-01(1/16) is a liaison from ITU-T SG15 thanking SG16 for their liaison on V.18 text telephoneand V.34 fax issues. It was considered by Questions H, 11, and 14, since the subject matter affectsthe performance of voiceband dial-up modems in general. SG15 informs that they addressed thesubject of text telephone transmission through network echo cancelers in their February 2001meeting. Contribution D.57 to SG16 (Feb. 2001) described a number of tests that evaluated theperformance of three different commercial echo cancelers on the transmission of V.18 testtelephone protocols. The protocols and modulation schemes tested were V.18, V.21, V.23, EDT,Baudot, Bell 103, and DTMF. See CSR Vol. 12.06, Q6/15 report, for further details. SG15strongly recommends that SG16 consider the use of 2100 Hz answer tone with phase reversals asmandatory in any modem and protocol Recommendations where the presence of a network echocanceler is likely to affect the performance of the modem transmission.

In review of this liaison, it was remarked that a large number of text telephone devices fromnumerous manufacturers exist in the field; making a mandatory change will not fully solve theproblem. It was agreed to add notes to existing Recommendations encouraging implementers totake special precautions regarding this issue.

Questions H, 11, and 14 jointly prepared and approved a response liaison to SG15 (TD-32[1/16];TD-42[1/16] is the final version). SG16 emphasizes to SG15 that, due to the environment of texttelephony and facsimile terminals, replacement of existing terminals will only occur over anextended period of time, if at all. SG16 does not have consensus to make the phase reversalsmandatory, but, they note, they have agreed to add a precautionary note to the appropriate ITU-TRecommendations. The following note was previously added to V.8:



“NOTE 2 – Experience in the field has indicated that, when connecting on circuits fitted withsome network echo cancelers, there is a potential for failure to connect if the phase reversaloption of ANSam is not used.”

Similar notes will be added to V.18 and V.25. SG16 notes that, while the phase reversals were notmade mandatory for support of V.34 FAX in T.30, V.34 relies on V.8. SG16 hopes that thesenotes will strongly encourage the use of phase reversals in Answer Tone transmission for futureequipment without mandating changes to existing equipment. SG16 also notes their pleasure thatSG15 has made similar notes in Recommendation G.168 concerning Test 14.

The Interim Rapporteur advised QH that there would likely be future work to add code points andlogic to V.18 and H.248 Annex F to support the use of the CTM modems as used in mobile voicechannels (ANSI and 3GPP standards). No action on this was taken at this meeting.

Question 1/16 WP2, Multimedia Systems, Terminals and DataConferencing

The Q1/16 meeting was chaired by the Rapporteur, P. Luthi (PictureTel). TD-69(2/16) is themeeting agenda. TD-93(2/16) is the report of this meeting. TD-33(2/16) is the report of the Q1/16Rapporteurs meetings held during the interim from the November 2000 SG16 meeting to thismeeting.

H.320, Narrow-band visual telephone systems and terminal equipment

Contributions were solicited to progress the harmonization of H.242 (System for establishingcommunication between audiovisual terminals using digital channels up to 2 Mbit/s) with AnnexX/H.263. Annex X of H.263 contains a list of preferred feature combinations, which arestructured into “profiles” of support. The intent is to have text available for review at the nextQ1/16 meeting (September 2001) for inclusion in a revision of the H.320 Implementers Guide.

TD-34(2/16) is a text revision of the Implementers Guide for H.320 series recommendations. Itincludes changes made against the May 1999 revision of H.221, H.230, and H.242, and theFebruary 2000 revision of H.224 and H.243. Q1/16 reviewed and accepted the content of thisdraft; it was submitted as TD-24[Plen]) and Approved at the closing Plenary.

H.324, Terminal for low bit-rate multimedia communication

TD-25(2/16) is the draft new Annex I to Recommendation H.324. This new annex defines theusage of HTTP in H.324 terminals as an optional data application protocol. Q1/16 accepted thecontent of this draft. The text of Annex I has not changed since the WP2/16 Rapporteurs Marchmeeting in Launceston.

TD-27(2/16) is the A.5 statement related to ISOC/IETF RFC 2616, Hypertext Transfer Protocol --HTTP/1.1, June 1999, which is included as a normative reference in Annex I. A.5 statements arerequired for references to documentation produced outside the ITU and referenced within an ITUrecommendation.

These TDs were submitted as TD-22(Plen) and TD-23(Plen), respectively and Approved at theclosing Plenary.

TD-44(2/16) is the draft revised Recommendation H.223, Multiplexing protocol for low bit ratemultimedia communication. Q1/16 accepted the content of this draft with the inclusion of someclarifications. This draft incorporates the existing Annexes A (low error-prone channels), B



(moderate error-prone channels), C (highly error-prone channels), and D (optional multiplexingover highly error-prone channels), along with the technical corrections and clarifications from thepublished IG. The sentence “b represents the distance…” in C.1.4.8 was considered to need someclarification; it was slightly reworded. The acting editor prepared a revised text (TD-29[Plen]).

TD-35(2/16) is the revised Implementers Guide for the ITU-T H.324 Recommendation series.Q1/16 accepted the content of this draft. It was submitted as TD-25(Plen) and Approved at theclosing Plenary.

T.120, Data Protocols for Multimedia Conferencing

TD-36(2/16) is the revised Implementers Guide for the ITU-T T.120 Recommendation series.Q1/16 accepted the content of this draft, with the inclusion of some corrections to the ASN.1 syntaxshown in Section 7.6.1. Commas needed to be added after the “…” for correctness. A revisedtext was prepared (TD-28[Plen]).

Some inconsistency with the ASN.1 syntax in 7.9.1 of the IG was pointed out. The syntax needsto be adjusted due to a previous addition of mbftID. It was agreed to contact the former editor ofT.127 to clarify the original intent of the T.120 experts; a contribution addressing this issue will besubmitted to the next Q1/16 meeting.

Q1/16 agreed to send a liaison (TD-27[Plen]) to Q7/7 in response to the Q7/7 liaison on TPDUcodes used in T.123. It informs that Q1/16 agreed to clarify the use of CNP TPDUs according tothe Q7/7 suggestion, but felt that it was more appropriate to do this in the section that describesCNP (B.9). Q1/16 agreed to add the following sentence to the overview of Section B.9, Connectionnegotiation protocol (CNP), in Annex B/T.123: “The CNP TPDUs defined in this Annex shall notbe used outside the context of T.120 communications.” This correction appears in the revisedT.120 IG (TD-28[Plen]) that was approved at the SG16 closing Plenary.

Future Work

Recommendation Editor Consent Approval CommentRevised H.320 Series IG P. Luthi Feb. 2002 H.242 harmonization with Annex

X/H.263Revision of H.221 P. Luthi Nov. 2002 This work will be synchronized with

approval of H.26LRevision of H.230 P. Luthi Nov. 2002 This work will be synchronized with

approval of H.26LRevision of H.242 P. Luthi Nov. 2002 This work will be synchronized with

approval of H.26LRevision of H.324 D. Lindbergh Feb. 2002 IG + annexes inclusionRevised T.120 Series IG TBD Feb. 2002 ASN.1 corrections in 7.9.1New H.222.0 AMD1 S. Okubo Feb. 2002 Common text with ISO/IECH.324 Annex Security TBD TBD

Question 2/16 WP2, Multimedia over Packet Networks using H.323Systems

P. Jones is the Q2/16 Rapporteur. TD-49(2/16) is the Q2/16 meeting agenda. TD-99(2/16) is themeeting report. TD-100(2/16) shows the Q2/16 document status:



Recommendation Approval EditorH.323 Annex M.3 (DSS1 tunneling) 2001 R. Callaghan (Siemens)H.323 Annex Q (FECC) 2001 R. Even (Accord)H.323 Annex R (Robustness) 2001 T. Anderson (Lucent)H.450.12 (Common information additional network) 2001 R. Callaghan (Siemens)H.GEF.2 (Number portability) 2001 L. Modahala (Cisco)H.225.0 Annex G v.2 (Inter-domain) 2002 M. Fortinsky (VocalTec)H.GEF.1 (Generic extensibility framework) 2002 P. Cordell (BT)H.GEF.3 (Presence) 2002 M. Paul (Trillium)H.GEF.4 (Emergency services) 2002 G. Thom (Delta)H.323 Annex I (Packet based MM telephony over errorprone channels)

2002 A. Li (Samsung)

H.323 Annex N (QoS) 2002 M. Buckley (Lucent)H.323 Annex O (Internet protocols and technologiescomplementary to H.323)

2002 O. Levin (RADVision)

H.323 Annex P (Modem relay) 2002 D. Wolfstein (Surf)H.225.0 v.5 2003 V. Bhargava (Cisco)H.323 v.5 2003 R. Even (Accord)

Liaisons

(Q2/16 addressed a number of liaisons in a joint session with Q3/16; please refer to the Q3/16meeting report for the outcome of those discussions.)

Q2/16 noted two liaisons from SG11 which were addressed at the March Rapporteurs meeting:TD-09(2/16) to SG9 (copy to SG16) concerns the IPCablecom draft Recommendations; TD-12(2/16) thanks SG16 for the information on the new activity in SG16 on draft H.GEF.2, Numberportability interworking between H.323 and SCN networks.

TD-91(2/16) is a liaison to ISO/IEC JTC1/SC29/WG11 acknowledging receipt of their liaison onMPEG-4 on IP. SG16 points out that codepoints for describing the parameters of MPEG-4elementary streams exist in H.245 v.7, and that H.245 is a common control protocol used by H.323,H.324, and H.310 systems. In response to ISO’s statement that their new payload format iscompatible with RFC 3016 for video, SG16 notes that H.225.0 currently specifies followingRFC3016 for MPEG-4 audio and video payload formats. SG16 asks: When ISO’s draft becomesan RFC, should SG16 modify H.225.0 to specify the use of the new payload format for video, orwould that be unnecessary because of its compatibility with RFC 3016? SG16 assumes thatH.225.0 will specify the use of the audio payload format defined in the ISO draft instead of RFC3016 once the draft becomes an RFC. SG16 has noted in the meeting report that implementersshould be aware of this intended change to H.225.0.

H.323-Series Implementers Guide

TD-48(2/16) (V. Bhargava, Cisco, Editor) is the Implementers Guide for H.323, H.225.0, H.245,H.246, H.283, H.235, H.450 Series, and H.341 Recommendations. Q2/16 review yielded a numberof editorial and technical corrections.

The Editor also elected to remove Section 6.1.3 (Using RFC 2833 for DTMF in H.323 FastConnect); upon review, it was considered that it was unnecessary and might result in inconsistenciesin the H.323 specification. This may be addressed again in a future meeting. The Editor alsoadded the contents of 6.2.4 (Addition to release complete reasons) to 6.2.3 (Annex H H.225.0Message Syntax [ASN.1] Corrections) to keep all of the ASN.1 changes together.



Q2/16 agreed to the following changes:

• Make changes to CircuitIdentifier ASN.1 definition to allow both CIC Info and the Group IDformat in H225 and Annex G messages (D.111, L. Modahala, Cisco).

• Add a “hopCountExceeded” LocationRejectReason Code to H.225.0 to handle the case whenan LRQ is rejected to due the hop count being exceeded (D.112, M. Gleason, Cisco).

• Add to LRJ Reason Code incompleteAddress to support overlap dialing (D.114, V. Bhargava,Cisco).

• Make a correction to ReleaseCompleteReason code to Q.931/Q.850 cause value mapping(D.118, S. Gogineni, Cisco).

An updated draft of the H.323-Series Implementers Guide (WD-01) was produced. It was notedthat Section 6.1.3 was missing the section number for the modified text; it should be 7.3. It wasfurther noted that the sections in 6.9.11 should be C.6 and C.7. Then, with all the agreed changes,the Implementers Guide (TD-31[Plen]) was put forward for Approval at this meeting.

H.323 v.5, Packet-Based Multimedia Communications Systems

D.115 (T. Floryanzia, Cisco) proposes to add media forking to H.323. Media forking allows agateway to duplicate a media stream and send it to multiple destinations without the overhead of amultipoint conference. A slight difference exists between forking and normal conferencing.Typically in both forking and conferencing, the gateway has two media peers/parties (referred tohere as A and B) associated with a single TDM channel. When conferencing, the gateway sends Aaudio from itself and B, and sends B audio from itself and A. When forking, the gateway sends Aand B audio from itself only.

In discussion, the following questions were raised: what if it is desired that the duplicate streamsuse different media types? What about using multi-unicast? What about using multicast? Howdoes it relate to H.332, H.323 extended for loosely coupled conferences? Would it be applicable toH.332 or similar to H.332? It was felt that a system diagram explaining the purpose of thisproposal is needed.

It was pointed out that for this to work over ATM, an additional sequence of integers that are portnumbers is needed. H.323 Annex C (H.323 on ATM) provides a discussion. It was suggested touse the communication mode command, so that an entity can signal that a new channel should beopened. It was also pointed out that H.245 includes a capability to indicate that the media can beencrypted; the contributors should consider adding something similar to indicate the ability to forkthe media. This work should be extended to other media types beyond just audio, so that it is moregeneric. It needs further development.

D.119 (P. Jones, Cisco) proposes to change the definition of an H.323 zone. This currentdefinition serves well, with the one exception: it includes a sentence that says in part, “a Zoneincludes at least one terminal.” In reality, this is not necessary and, in practice, it is often not thecase. Also, is a zone not a zone if endpoints are not registered? The possibility of a zone notcontaining any endpoints should be allowed. D.119 proposes that the entire sentence be deleted.This was accepted toward H.323 v.5.

H.225.0 Annex G v.2, Communication Between Administrative Domains

TD-45(2/16) (M. Fortinsky, VocalTec, Editor) is draft H.225.0 Annex G v.2, Communicationbetween administrative domains, for Approval. It was noted, but not presented. There were nochanges made since the last SG16 meeting. It was agreed to postpone approval of this documentuntil additional contributions are received; the document does not have enough new material to



warrant issuing a revised recommendation. It is expected that additional work will be done in areasof intradomain communication, H.323 mobility, and presence.

D.110 (M. Gleason, Cisco) proposes to add additional AccessReject reason codes to H.225.0Annex G. This was accepted for Annex G v.2. H.225.0 Annex G describes communicationbetween Annex G Border Elements, but does not specify how a Border Element interacts with otherelements in an H.323 network. However, several possible implementations are suggested, with theBorder Element residing/interacting with either a Gatekeeper or a Gateway.

For the case in which the Border Element is coupled to a Gatekeeper, the H.225.0 LocationRequestmessage sequences are a logical communication method. The problem with this approach is thatthe set of reject reasons defined for the Annex G AccessReject message do not adequately cover thepossible LocationReject reasons, making it difficult in such implementations to carry the rejectreason information end-to-end.

H.323 Annex M.3, Tunneling DSS1 in H.323

TD-23(2/16) (R. Callaghan, Siemens, Editor) is H.323 Annex M.3, Tunneling DSS1 in H.323. Itwas noted that the second paragraph in Section 3 contains an exclamation mark, rather than thenumber one. The text “DSS!” should be changed to “DSS1”. This was put forward forApproval as TD-10(Plen).

H.323 Annex N, End-to-End QoS

In discussion of D.102 and D.103 (see the QF meeting report, above), it was suggested thatQuestion B should take this work as input toward their development of the general architectureframework for end to end QoS, mobility, security, and other areas; it can then be referenced by allQuestions. The proposed Annex to address end-to-end QoS over the network layer was not wellunderstood, and was therefore not accepted. The contributor was asked to provide additionalsupporting proposals in this area.

The QF Rapporteur presented TD-42(2/16), which gives background to the application level QoScontrol technique that forms the basis of Annex N of H.323 (TD-43[2/16]). A question was raisedconcerning which messages need to be enhanced to signal the bandwidth that is necessary tocomplete the call. This is an area that still needs to be addressed. RAS, H.225.0 call signaling, andH.225.0 Annex G messages will necessarily have to be enhanced. It may also be necessary toenhance H.245, as well.

TD-43(2/16) (M. Buckley, Lucent, Editor) is the new draft of H.323 Annex N. In this draft, thescope of the Annex has been extended to include the signaling and control of service priority. Inreview, the inclusion of service priority information was agreed. Changes would be required toH.225.0 (Q.931 and RAS), H.245 and H.225 Annex G. The use of the GEF was a preferredapproach to inclusion of the extra fields in these protocols. The encoding proposals of D.98,Proposed change to H.246 Annex C to support service class (G. Thom, Delta InformationSystems), and D.99, Proposal to add service classes to H.323 RAS and call signaling, (G. Thom,Delta Information Systems), will be taken into account.

The intent of TD-43(2/16) is to utilize the generic extensibility framework to carry QoS informationin RAS, H.225.0 call signaling, and Annex G/H.225.0. Enhancements to H.245 may also benecessary. Additional work will proceed on this draft, toward Approval in February 2001,assuming that some of the procedures can be addressed in the context of the GEF.



H.323 Annex O, Use of Complementary Internet Protocols with H.323 Systems

TD-40(2/16) (O. Levin, RADVision, Editor) is draft H.323 Annex O; it defines procedures forusing Internet protocols and technologies in the context of H.323. This document is unchangedfrom the March, 2001 Launceston, Australia meeting (CSR 12.11), and does not incorporatecomments from that meeting. A revised draft is expected at the next meeting. It was noted thatsome of the material is more of an informative rather than normative nature, and should therefore beintroduced in the form of an appendix instead of an annex. As work progresses, Q2/16 will take upthat issue and decide where to insert the material.

H.323 Annex Q, Far End Camera Control and H.281 / H.224

TD-01(2/16) is (R. Even, Accord, Editor) contains the draft new H.323 Annex Q, which will defineH.281/H.224 (H.281 = A far end camera control protocol for videoconferences using H.224;H.224 = Real time control protocol for simplex applications using H.221) channels based far endcamera control (FECC). The protocol described in this Annex may be used to support Far EndCamera Control (FECC) in H.323 using the stack IP/UDP/RTP/H.224/H.281. This protocolsupports both point-to-point and multipoint scenarios. This annex was presented at the MarchRapporteurs meeting in Launceston. This draft was put forward for Approval as TD-17(Plen).

H.323 Annex R, Robustness Methods for H.323 Entities

TD-26(2/16) (T. Anderson, Lucent, Editor) is H.323 Annex R, Robustness methods for H.323entities. TD-56(2/16) is an update of TD-26(2/16). This draft of Annex R contains minor changesfrom AVD-2079, from Launceston:

• The ASN.1 has been parser verified and corrected• An alternative way to implement the ASN.1 robustness data was been added; the method to

be included in the final annex needs to be determined• Appendix changed to Informative Note• Editors notes removed• CallIdentifier for multiplexed channels changed to 0 rather than omitted

It was pointed out that there are two options for encoding the robustness data: using the ASN.1 andencoding that and storing it in the “raw” data type, or using the ASN.1 value notation. Thepreference was to choose the ASN.1 option wherein the data will be stored in the raw data type. Itwas agreed to use the numeric value “1” to identify the Annex R Generic Data. This draft H.323Annex R was put forward for Approval as TD-19(Plen).

H.450.12, Common Information Additional Network Feature for H.323 (ANF-CMN)

TD-24(2/16) (R. Callaghan, Siemens, Editor) is draft new Recommendation H.450.12, Commoninformation additional network feature for H.323 (ANF-CMN). It was noted that the text inSection 8.2 reading “…far end or to received service…” needs to be corrected for grammar. Also,it was proposed that the fields “reserveFeatureXX” and “reserveControlXX” be removed and newfields added after the extension marker. With these changes, this draft new Recommendation wasput forward for Approval as TD-11(Plen)

H.GEF.1, Generic Extensibility Framework Usage

TD-32(2/16) (P. Cordell, Tech-Know-Ware, Editor) is draft Recommendation H.GEF.1,Guidelines for the use of the generic extensible framework. GEF provides a low overhead way of



adding functionality to H.323 without adding to the H.225.0 Annex H ASN.1 base specification.GEF provides a common feature negotiation mechanism, and the ability to carry opaque data in allH.225.0 and Annex G messages. Thus it allows application specific extensions to be made to theH.323 suite of recommendations without burdening all implementations of H.323 with all specifiedextensions.

In discussion of H.GEF.1, it was noted that Section 7 (Examples of GEF Negotiation) should beclearly marked as informative. Section 6.3 (Specifying GEF Modules, Syntax Based Method)raised some concern: Should Q2/16 be introducing yet another syntax? If Q2/16 is unable toaccurately produce a syntax they will spend effort in trying to refine it. They should consider usingASN.1 value notation as an alternative. Perhaps a syntax definition is not needed at all.

It was proposed that the Editor consider removing or replacing Section 6.3. Perhaps only tables or“raw” with ASN.1 PER are needed. It was suggested that the data types could be expanded toprovide more flexibility, as opposed to using “compound” or “nested.” Q2/16 will review thisdocument again at the next Rapporteurs meeting.

H.GEF.2, Number Portability Interworking Between H.323/SCN Networks

TD-28r1(2/16) (R. Nadimpalli, Cisco, Editor) is draft Recommendation H.GEF.2, Numberportability interworking between H.323/SCN networks. A few minor editorial (non-technical)changes were proposed and agreed in the r1 version. This Recommendation describes theprocedures and the signaling protocol for Service Provider and Location Portability, whileinterworking with SCN (using SS7 signaling) interfaces in a H.323 network. Service ProviderPortability allows subscribers to keep their existing phone numbers/addressing scheme even whenchanging from one service provider to another without changing their location, and withoutchanging the nature of the service offered. Location Portability allows subscribers to retain theirexisting phone numbers/addressing scheme even when moving from one location to another. Thisrecommendation makes use of the “Generic Extensibility Framework” specified in H.323v4.

TD-68(2/16) is a liaison from SG11 proposing a number of changes to H.GEF.2. Q2/16 agreed toall of the changes, with the exception of the removal of “originating network info.” The editor wasinsistent that that field not be removed, but others wanted to accept the position proposed by SG11.After some discussion, it was agreed that, since the field in question is an optional field, it would beacceptable to leave it within H.GEF.2. A means of clarifying that this field is used regionally couldbe considered.

The Rapporteur, Editor, and interested parties worked off-line to produce TD-47(Plen), an updateddraft of H.GEF.2. TD-50(Plen) contains corrections to TD-47(Plen). With the exception of thecompliance statement, all these changes are purely of an editorial nature.

H.GEF.3, Presence

For the discussion of H.GEF.3 (Presence), refer to the meeting report for Question 5/16.

Emergency Services

The topic of Emergency Services was addressed in a joint meeting of Questions D, F, G, 2-5; referto the Q3/16 meeting report.



Modem over IP

Q2/16 met jointly with Q3/16 and Q11/16 to discuss modem over IP (MoIP) issues to progress thework on H.323 Annex P and other recommendations necessary for MoIP within WP2.

Q11/16 asked:– What reliable transport protocol should be used?– What network characteristics can be expected?– What is the impact on MoIP?– What signaling changes are needed between two MGCs? How should those changes be

made?

A question was raised as to whether any thought had been given to situations where there may besimultaneous voice and modem data. It was responded that the current focus of this work assumesthat there will be a PSTN line to the customer’s home/business. The fact that MoIP is used withinthe core of the network should be transparent to the user. It was suggested to consider thepossibility that IP will exist at one end and PSTN at the other end. The current study has focusedonly on PSTNàIPàPSTN scenarios.

TD-24(1/16) lists the issues under consideration in Q11/16 and shows the various scenarios beingstudied. It was noted that WP2/16 might need to examine call discrimination issues (Section 7).WP2 also needs to develop the protocol for carrying MoIP data over the IP network. Another pointraised was that acoustic echo cancellation needs consideration, especially when using multimediamodems.Q11/16 MoIP work is carried out on two e-mail reflectors:

ITU-T mailing list: <[email protected]>TIA TR-30.1: <[email protected]>

To subscribe to the TIA list, send e-mail to <[email protected]>, Chair of TR-30.

Questions 2, 3, and F are the most appropriate SG16 Questions related to Q11/16. The discussionsrelating to those Questions take place on this list:

<[email protected]>To subscribe, send e-mail to <[email protected]> with the words “subscribe itu-sg16”in the body.

To start the discussion on the protocol issue, PCM01-006 (H. Wildfeuer, M. Garakani, Cisco), wasexamined. This document appeared at the January 2001 Q11/16 Rapporteurs meeting, and at theQ2/16 March Rapporteurs meeting in Launceston as AVD-2099. It also appears as a workingdocument PCM01-006(WP1/16). It contains a proposed protocol called “simple packet relaytransport” (SPRT), which provides a reliable, lightweight protocol for transporting data over UDP.

The author noted that TCP and SCTP are not acceptable, as they do not provide the necessary flowcontrol mechanisms needed for real-time modem relay. The author also suggested that RTP wasnot acceptable, as it does not provide the necessary reliability; for modem relay, accurate data isabsolutely needed end-to-end.

Some experts expressed the view that using RTP would be preferable and that the use of forwarderror correction (FEC, RFC-2733) along with RTP should be examined. It was further noted thatthere are valuable ideas in both SPRT and RTP/FEC. It was also noted that an RTP retransmissiondraft is currently in progress within the IETF. A concern was raised that the SG16 effort wouldresult in competing protocols.



In conclusion, the interested parties agreed to collaborate to produce requirements documents forthe transport protocol, to draft a critique of the existing protocols explaining why they are notsuitable and, finally, to produce a first draft of the proposed new transport protocol. The interestedparties will work via the Q11/16 and SG16 e-mail reflectors in the interim to the July TR-30.1meeting. The goal will be to approve those documents for submission to the August IETF meeting.

A joint Q2/3/11 meeting is planned for the week of September 24, 2001 (subject to approval). Thegoal of that meeting will be to review the output of the IETF meeting, to refine the protocol asnecessary, then to submit it to the IETF December meeting. The ultimate goal is to put thedocuments for MoIP (including the transport protocol) forward for Consent at the February SG16meeting.

It was also recommended that a look be given at improving T.38 transport as well.

Contributions were solicited to the next Rapporteurs meeting regarding changes necessary toH.245, H.248, etc., to signal the opening of the media channels.

Question 3/16 WP2, Infrastructure and Interoperability for Multimediaover Packet Networks

G. Freundlich (Avaya) is the Q3/16 Rapporteur. TD-55(2/16) is the Q3/16 meeting agenda. TD-101r1(2/16) is the Q3, QG meeting report. TD-102r1 (2/16) is a simplified Q3/16 meeting report.

Status of Recommendations

Recommendation AAPLast Call

Editor

H.245 v.8 (Control protocol) June 2001 M. Nilsson (BT)H.246 Annex D (Interworking of H series terminals onGSTN and ISDN)

??/??

H.246 Annex F (H.323 - H.324 interworking) June 2001 T. Suzuki (NTT DoCoMo)H.248 Implementers Guide June 2001 T. Anderson (Lucent)H.248 v.2 (Gateway control protocol) ??/?? M. Pantaleo (Ericsson)H.248 Annex L (Error codes & service change reasons) June 2001 C. Groves (Ericsson), A.

Heidermark (Ericsson)H.248 Annex M.1 (Advanced audio processingpackages)

??/?? T. Taylor (Nortel)

H.248 Annex M.2 (Congestion control package) June 2001 C. Groves (Ericsson)H.248 Annex M.4 (Package to support interworkingbetween H.324C and H.323)

June 2001 C. Sayre (Lucent)

H.248 Packages Supplement (Coordination of packagesamong various standards bodies)

June 2001 M. Brown (Nortel), C. Groves(Ericsson)

H.341 v.2 (Multimedia management information base) ??/??

Liaisons (Joint with Q2/16, and some with QF/16)

TD-02(2/16) is a liaison from SG13 from their November 2000 meeting concerning their draftRecommendation Y.1530, Call processing performance for voice service in hybrid IP networks.According to SG2 suggestion, SG13 corrected the mistake in the definition of CPSD. Also, SG13added E.671, Post-selection delay in PSTN/ISDN networks using Internet telephony for a portionof the connection, to the “Reference” of Y.1530. TD-88(WP2/16), included in TD-54(Plen), is theresponse liaison to SG13 informing them of the new work item, H.mmcp; it indicates SG16’swillingness to collaborate with SG13 on matters related to multimedia.



TD-03(2/16) is a liaison from SG9 to SG16 and ITU-R WP6M on their draft newRecommendation J.qweb, Quality control protocol for webcasting. This Recommendation providesa scheme based on RTCP where a quality report is sent from a client to the server, and the serverperforms optimum data distributions according to the client’s report. Recommendation J.qwebdefines parameters that a client should report to the server, and a transmission protocol that is usedfor sending the report from the client to the server. It also defines transmission of supportingparameters that are useful for the server to analyze the client’s report. In discussion, it was notedthat QB/16 would like to take the lead in drafting a reply.

TD-05(2/16) is a liaison from SG15 requesting guidance concerning what text should be includedregarding support of text telephones connecting to such a gateway in their new RecommendationG.799.1. In their response liaison (TD-79[2/16]), Q3/16 refers SG15 to H.248 Annex F, whichdescribes a number of packages that could be used together to provide service for text telephones.

TD-13(2/16) is a liaison from SG11 concerning interworking between H.323 systems andintelligent network systems. SG11 acknowledges the SG16 liaison on the relationships betweenH.323 systems and Intelligent Network systems. SG11 welcomes the SG16 proposal forcooperation in this area and would like to share with SG16 their views on the topics to be addressedwhen considering inter-working between H.323 and IN. SG16 Rapporteurs will investigate thepossibility of meeting jointly with SG11 at one of the upcoming Rapporteurs meetings. A wishwas expressed for a joint Rapporteurs meeting before the next SG16 meeting.

TD-14(2/16) is a liaison (copy to SG 16) from SG13 thanking SG9 for the information onIPCablecom. SG13 offers SG9 the following comments on their IPCablecom work:

A PSTN gateway specification should be common to all cases where a PSTN gateway isrequired; both SG9 (J.tgcp, IPCablecom trunking gateway protocols) and SG16 (H.248) appearto have two different solutions. Some convergence to a single solution would seem to bedesirable, if possible at some future date. It would be advantageous that applications carriedover IP be common, irrespective of the underlying transport technology used to carry the IPlayer.

In TD-20(2/16), SG9’s liaison response, SG9 notes that in their future work they will modifyRecommendation J.tgcp (J.171) to include a separate option that will be based on RecommendationH.248. They intend to retain the current option in the Recommendation as it focuses onapplications and countries where they have found that the use of H.248 would not be the mostappropriate at this time, and where a legacy problem does not exist. Eventually, market forces willdecide which option is utilized. Also, SG9 emphasizes that the schedule for this Recommendationis tight; vendors and cable television operators are committed to go to market in the very near future.

TD-15(2/16) is a liaison from SG2 forwarding copies of seven E.TE series of draftrecommendations on Traffic Engineering & QoS Methods. The E.TE series of recommendationsdescribes, analyzes, and recommends traffic engineering (TE) methods that control a network’sresponse to traffic demands and other stimuli, such as link failures or node failures. It was notedthat much of the QoS work in SG16 is at a higher layer than what appears to be covered in the draftE.TE recommendations.

TD-16(2/16) is a liaison from SG2 requesting SG16 comment on SG2’s draft RecommendationE.inra.ip, Interworking of routing addresses and IP-names/addresses. This work incorporatesconcepts and proposals discussed in the January-February 2001 SG2 meeting in Geneva. It wasnoted that the issues raised in E.inra.ip should be covered in QB.



TD-17(2/16) is a liaison from SG4 informing that in their January 2001 meeting they initiated workon a requirements document for international emergency priority services (M.IEPS). ThisRecommendation is scheduled for Decision under the AAP at the April 2002 meeting. SG4 notesthat the work currently proceeding in SG16 on F.IEMS also recognizes the managementrequirements that are being detailed in M.IEPS(Q9/4).

QF agreed to send a reply (TD-87[2/16]) in TD-54(Plen) to inform SG4 of their new work itemsH.priority and H.qos.m and to express SG16’s desire for collaboration in these areas. When workto support IEPS becomes more concrete, Q2/16 and Q3/16 will correspond with SG4.

TD-18(2/16) is a liaison from SG12 addressing optimum packet size for VoIP packets. AppendixI of ITU-T Recommendation G.114, One-way transmission time, provides information on how tocalculate the amount of delay introduced by a particular combination of codec and frames perpacket (FPP), but the SG12-suggested maximum values for number of FPP come from SG12expertise on this issue.

Q12/12 is currently investigating the impact of FPP, codec, and the pattern of packet losses onperceived speech quality. It is expected that a new recommendation, Transmission performanceparameters of IP networks affecting perceived speech quality and other voiceband services, will beavailable in 2002. This recommendation will provide further guidance on the optimum number ofFPP. Q12/12 will keep SG16 informed on this issue.

It was agreed that this work is very relevant to QF/16. It was agreed to send a reply (TD-86[2/16],also in TD-54[Plen]) to SG12 affirming SG16 support for this work, and asking that QF,specifically, be informed of the progress. This is valuable implementation material, but it is not yetknown if the material will appear in a normative fashion in H.323 or H.248. Questions 2 and 3indicated that they wanted this liaison to show as coming from them also.

TD-19(2/16) is a liaison from ISO/IEC JTC1/SC29/WG11 on MPEG-4 on IP. The specificationof the transport of MPEG-4 content on IP networks is now complete. This improved specificationis compatible with RFC 3016 for video elementary streams but not for audio elementary streams;compatibility with RFC 3016 for audio elementary streams would have significantly impaired theefficiency of the solution. ISO requests that SG16 include the proper references to this IETFspecification in their H.323 framework as soon as RFC status is reached, and that SG16 updatetheir H.225 and H.323 specifications as rapidly as possible to favor development of interoperablesolutions.

In their reply to ISO (TD-103r1[2/16]), SG16 notes that codepoints for describing the parametersof MPEG-4 elementary streams exist in H.245 v.7, and that H.245 is a common control protocolused by H.323, H.324, and H.310 systems. H.225.0 specifies the use of RFC 3016, RTP PayloadFormat for MPEG-4 Audio/Visual Streams. There is an Internet Draft which defines a videopayload format that is compatible with RFC 3016. However, the audio format in the Internet Draftis not compatible with RFC 3016. Implementers should also note that H.225.0 may change tospecify the use of the new payload formats instead of RFC 3016 once the Internet Draft becomesan RFC. SG16 also notes that, while ISO states that their new payload format is compatible withRFC 3016 for video, it seems there is no description about how to treat other MPEG-4 systemsstreams (e.g., object descriptors streams) in compatible cases.

SG16 would like to understand if ISO is suggesting the use of H.323 for delivering MPEG-4 videoor audio over MPEG-4 systems streams. If this is the case, it is not clear how this would work inan H.323 system. SG16 requests ISO guidance on this, and perhaps an indication of how thiswould be specified in H.225.0. SG16 suggests that ISO could refer to H.225.0 Annex F, whereH.222 (MPEG-2 systems), and H.223 MUX-PDU packetization are defined.



TD-21(2/16) is a liaison from SG9 thanking SG16 for their liaison regarding harmonization onsecurity. SG9 welcomes SG16 comment on their Recommendation J.sec. SG9 requestsclarification of the SG16 comment regarding the relevance of draft Rec. J.sec to H.235. SG9understands that H.235 addresses security for H.3xx-based systems, whereas the IPCablecomarchitecture utilizes security requirements specific to IPCablecom networks. SG9 welcomes SG16cooperation on IPCablecom.

In their response liaison (TD-08[Plen], modified as TD-78[2/16]), SG16 notes that, to proceed withthe harmonization of security, they depend on the general interworking scheme between H.323 andIPCablecom. The communications aspects for inter-domain interworking between H.323multimedia systems and IPCablecom systems have not yet been sufficiently addressed. A clearinterworking architecture should be developed before proceeding to the harmonization of thesecurity aspects. Communication between H.323 and IPCablecom will not be possible if the mediastreams are not compatible due to differing security schemes. Apart from IPCable specific networkaspects such as BPI+ for example, SG16 sees large overlap with H.235 and multimedia securityissues in the deployment of general security techniques to such topics as signaling and mediaprotection.

For further harmonization and collaboration, network independent, multimedia security issues ofJ.170 should be addressed by SG16, the lead study group for multimedia. This will better enablethe technical discussions among the experts and the opportunity to correlate and harmonize bothsecurity architectures. SG16 assumes that the IPCablecom-specific security parts, such as BPI+,would not originally fall within the scope of SG16; they would continue to be part of SG9’s work,but would be aligned with the work and outputs of SG16. SG16 invites SG9 security experts tocontribute and participate in the multimedia security work within SG16 Question G.

TD-22(2/16) contains a communication from IETF providing information on concerns with theAdler-32 checksum algorithm that was selected for the SCTP and appears in RFC 2960, Streamcontrol transmission protocol. It appears that the existing Adler-32 algorithm may provide weakererror-detection capabilities than was originally thought, especially when applied to short messages,as are typical for signaling. It is likely that the SCTP specification will be reissued as a new RFCwith an improved error check mechanism in the very near future. Assuming that this occurs, thenew RFC will obsolete RFC 2960 and will, in all likelihood, not be backward compatible with RFC2960 for interpretation of the error check field.

Candidate error checks that have been suggested include a modified Adler-32, a TCP-32, and aCRC-32. These will be studied and compared to determine the best approach. The discussions willbe taking place on the SIGTRAN mailing list <[email protected]> and theTSV (Transport Area) mailing list <[email protected]>.

TD-46(2/16) is a communication from the ECMA TC32-TG17 March 2001 meeting in Seville,Spain, forwarding the draft ECMA standard on basic call interworking between H.323 and QSIG.This is an update of the draft submitted to the March Rapporteurs meeting as AVD-2080. Workon this standard will continue at the next TC32-TG17 meeting in June; it is due to be completed inSeptember 2001.

In discussion, it was noted that the ECMA QSIG-H.323 interworking spec contains a note thatseems to state that H.225.0 allows only a transfer rate of 64 kbit/s in the bearer capability IE of theSetup message. A liaison (TD-96[2/16]) was drafted to clarify the matter. SG16 informs ECMAthat they may have misrepresented their intentions when they advised that ECMA use 64 kbit/s forthe information transfer rate value in the bearer capability IE of H.225.0. In making thatrecommendation, SG16 was considering previous ECMA proposals to use 10010 for 16 kbit/s and10100 for 8 kbit/s. Their intent was to avoid the introduction of those values into the H.323network, as most equipment will simply assume 64 kbit/s, anyway. In the current draft, they found



text that suggested that H.323 systems always set this value to 64 kbit/s. That is not the case;H.323 systems do use other values, including multirate, as specified in H.225.0.

TD-63(2/16) is a liaison from SG11 informing that they have initiated discussion on the idea ofhaving multiple call control protocols, like H.323, SIP, and BICC, operating in parallel and thusleveraging the strong points of each. Discussion is already under way in SG11 regarding thepossible implications for the BICC call control protocol. The SG11 contribution, Parallel use ofBICC with other call control protocols, considers three approaches: convergence, tunneling andparallel. TIES users can find it at: <http://www.itu.int/itudoc/itu-t/com11/dcontr/01-04/dc-may01/213.html>.

TD-64(2/16) is a liaison from SG11 informing that at their May 2001 meeting they initiated workon signaling requirements for an International Emergency Preference Scheme (IEPS) according toRecommendation E.106. Their discussions on the IEPS functional requirements resulted in theassumptions listed below; SG11 requested SG16 confirmation of their understanding to proceedtheir work on IEPS:

1) E.106 references public telecommunications networks, specifically PSTN, ISDN, and PLMN.SG11 understands that SG16 is working on multimedia IEPS requirements; it is therefore theirunderstanding that besides PSTN, ISDN, and PLMN, advanced telecommunicationsnetworks/technologies, e.g., IP, multimedia, must also support IEPS.

2) According to E.106, in national systems IEPS features may be permanently enabled. SG11understands that the need to activate/deactivate IEPS, either to enable IEPS only in the case ofdisaster or only locally for the disaster area, is a national matter.

3) E.106 does not require preemption of established calls by IEPS calls. SG11 understands,however, that there might be a need to preempt non-IEPS calls in disaster situations if sufficientnetwork resources are not available.

TD-81(2/16) is the SG16 response to these three assumptions:

1) SG16 informs that their work on the development of an international emergency multimediaservice (IEMS) is contained in their new proposed Recommendation F.IEMS, which is anextension of E.106 on IEPS to include requirements for multimedia services to supportemergency communications over an IP-based packet network environment.

2) SG16 agrees that the issue of enabling of IEPS/IEMS features either permanently or only incase of disaster likely is a national matter. Perhaps SG2 can provide further views of thisoperational and administrative issue.

3) While E.106 identifies that preemption of established calls is not required, F.IEMS hasrecognized that preemption of existing non-emergency communications to free operationalresources for supporting emergency communications could be applied optionally in countriesand networks where preemption is allowed. The concept of how preemption is to be applied ina connectionless packet network environment is a subject of further study.

TD-65(2/16) is a liaison from SG11 proposing joint activity on a generic protocol mechanism forend-to-end QoS service control and signaling protocol development based on IP transfercapabilities and IP QoS classes. It was agreed to support the proposed joint activity to seek ageneric protocol mechanism for QoS signaling and control, but some difficulties were noted in thearea of definition of transport plane and the role of H.248 and the relationship of this work with theclassification system in Y.1541. It was agreed to send a liaison response (TD-90r1[2/16])indicating SG16’s interest in this proposed joint activity, and drawing attention to the list of newwork items for QF/16.



TD-66(2/16) is a liaison from SG11/Q10 informing that they have modified their proposed H.248package for SPNE control according to SG16 suggestion. Q10/11 has deleted reference to A-Law/µ-Law conversion in this package; thus, the proposed package does not have any proceduresfor determining how a media gateway would assign an A-law or µ-law converter in a termination.The development of this procedure is outside the scope of Q10/11, as coders are not considered tobe SPNEs in the context of this question. Q10/11 accepts the SG16 offer to request a PackageIDfrom IANA on their behalf. Q10/11 has identified two alternatives concerning the documentationof this package: 1) as a new Annex in the future version of SG16’s Recommendation H.248, or 2)as a future Annex to SG11’s Recommendation Q.56 (Signaling between SPNE and ISC over an IPnetwork). SG11 asks that SG16 consider alternative 1).

In response (TD-83[2/16]), SG16 suggests that it might be most appropriate to define the SPNEpackage as an extension of the existing TDM package found in Annex E of H.248. The TDMpackage has an echo cancellation and gain control properties. Basing the SPNE package on theTDM package might eliminate duplication of codepoints and create less confusion of whichpackage to use for echo cancellation. Thus, for an application to control an ECD device via H.248,it should realize the TDM package and the SPNE package. This should be specified in any annexon the subject.

As for whether the package is defined in SG16 as an annex to H.248 or in SG11, it appears thetradeoffs are:

• If SG16 standardizes the package, it would be grouped with other H.248 annexes, possiblygiving it more visibility. If this approach is preferred, the earliest possible approval would beafter the February 2002 SG16 meeting, and handoff should occur prior to the next jointRapporteurs meeting planned for late September 2001.

• If SG11 standardizes the package, it would be created and maintained by the SPNE experts,reducing the need to communicate between study groups and incur the delays generallyassociated with liaisons.

TD-67(2/16) is a liaison from SG11/Q11 CBC group noting their appreciation that SG16 hasadded its packages as defined in Q.1950 to the H.248 Packages Implementers Guide. SG11 alsonotes that the IETF is currently working on a draft (<draft-boyle-megaco-tonepkgs-04.txt>) thatrelates to the packages defined in Q.1950.

TD-74(2/16) is a liaison statement from SG9 concerning their draft new Recommendation J.tgcp.This liaison contains the same information as TD-20(2/16), the SG9 liaison to SG13 on J.tgcp. InTD-75(2/16), SG16 responds, noting their pleasure that SG9 may create an H.248 option forJ.tgcp. Addressing the market pressures noted by SG9, SG16 emphasizes that H.248/Megaco is amature protocol. Products have been fielded using H.248, other standards organizations have madeit a part of their architectures, and many groups are creating packages to specialize it to theirapplications.

TD-11(Gen) is a liaison from the SG12/WP3 Chair with copies to SG2, SG9, and SG16. Itconcerns packet delay and packet loss guidelines in draft Recommendation Y.1541. During theWP3/12 February 2001 meeting, the liaison from SG13 regarding draft Rec. Y.1541 was thesubject of much discussion. SG12 acknowledges that the inclusion in Y.1541 of a QoS class thatcan support interactive applications is completely consistent with the guidance provided by G.114.However, SG12 finds it difficult to understand the material included in the new class 0 for IPTD asspecified in Table 1. Perhaps some extra text can be inserted, in the main body of Y.1541, to clarifythat the SG12 requirement for interactive speech of 150 ms mouth to ear will be met when all delaysin a connection, including IPTD and terminal processing delays, are included.



SG12 has previously indicated that packet loss objectives for QoS classes have little meaningunless such losses are specified over a limited interval of time. SG13 interpreted this issue to beone of measurement, rather than specification. Accordingly, SG12 does not see SG4 as theresponsible party; rather, they strongly feel that in the QoS definitions themselves, the time periodover which packet loss can occur must be specified.

An active topic of discussion in SG12 was the intent of Y.1541 to allocate delay values amongnetwork segments in a static fashion. Such a static allocation suffers from the inability to re-useunused delay from one network segment in another segment, and is also likely to be too restrictiveon some network segments anyway. SG12 questions the application of this traditional allocationapproach for dynamic networks such as those to which Y.1541 applies. New approaches, of whichdynamic allocation is an example, may be more applicable rather than a static, circuit-orientedallocation.

Finally, SG12 informs SG13 that it has approved a new Question 13, MultimediaQoS/Performance Requirements, which may be of interest to SG13. This Question is intended toidentify the key performance parameters and suitable ranges of values of these parameters formultimedia applications and services, for which QoS control mechanisms can be designed andapplied intelligently. Also, work on a new Recommendation G.QoSRQT, aimed at providingmultimedia QoS requirements, is underway, with a target for Approval by the end of 2001.

TD-14(Gen) is a liaison from SG13; it provides information concerning the work of SG13 inrelation to NGNs and the need/desire for collaboration among interested parties.

TD-15(Gen) is a liaison from SG13 informing that they have completed their update of the ITU-TIP Project, and including a current copy (version 5) of the Project as of the SG13 May meeting.Discussion emphasized that this project is entirely relevant to IP telephony work in SG16.

In their liaison response (TD-97[2/16]), SG16 takes exception to a comment in Section 1 of theProject document that, in effect, implies that the ITU-T does not have strength in protocoldevelopment or application areas. Further, SG16 suggests that SG13 might want to add, underAreas 2 (Impact to telecommunications access infrastructures of access to IP applications) and 3(Interworking between IP based network and switched-circuit networks, including wireless basednetworks), H.GEF.x under related work for Q2/16. SG16 notes that current documents are indevelopment in the areas of number portability, presence, and emergency services. Under Area 4(Multimedia applications over IP), SG13 might also want to add the work of Q4/16. SG16 notesthat this Question does not yet have any recommendations, but the scope of their work seems toalign with this area. Under Areas 7 (Signaling support, IN, and routing for services on IP-basednetworks) and 8 (Performance), SG13 may want to list QF/16 and H.323 Annex N, as they arerelated to QoS aspects. Under Area 10 (Security aspects), SG13 may want to list QG/16.

The following liaisons presented or noted at this meeting were also reviewed at the March 2001Joint Rapporteurs meeting in Launceston (For disposition of the Launceston liaisons, see CSR12.11).

TD-04(2/16) is a liaison from SG11/Q9 addressing International emergency services. (This liaisonwas considered by QD/16, as TD-17, in Launceston; it was considered jointly at this meeting byQuestions F, 2, and 3.) QF felt that QC/16 should take the lead in replying to this request forinformation. QF agreed to report the scope of their new work item, H.priority.

In their response liaison to SG11 (TD-82r1[2/16]), SG16 reports that their work on thedevelopment of provisions to support emergency multimedia communications is in the early stagesof consideration; it is too early for them to be able to provide specific answers to SG11’s questions.The issues of authentication and relationships to call control signaling and traffic management



controls will be addressed in the IEMS work in SG16. The issue of who will police compliance isan administrative matter that perhaps SG2 can answer. TD-82r1(2/16) includes a copy of the newproposed Recommendation F.IEMS that was agreed for Consent under the AAP at this meeting.

TD-06(2/16) (TD-13, Launceston) is a liaison from SG11 on their development of the call bearercontrol protocol, Q.1950 (Q.CBC), based on H.248. Discussion at this meeting yielded thefollowing: QF felt that although this is a vertical protocol it will differ from the new work item,H.trans.control, as Question CBC is within the application and not involved in signaling to thetransport domain. QF is pursuing the idea of a vertical interface to carry QoS information; thework of SG11 might be applicable. The CBC work might also be applicable to the IETF Midcomwork. Q.1950 does not yet contain any QoS information. BICC CS3 might be looking at QoSissues. SG11 and SG16 should work together on the QoS issues. BICC CS2 set is scheduled forConsent in July, so SG16 has little opportunity to contribute at this time. SG16 should also workwith SG13 regarding QoS issues.

TD-07(2/16) is a liaison from SG11 regarding the proposed clarifications to H.246 Annex C. Itaddresses two issues: 1) the rules for setting the M bit in the backward call indicators in the ACM,and 2) the rules for cut-through operation (that is, when media paths exist and media is flowingbetween elements). This liaison was reviewed in Launceston (AVD-2038), but no comment wasprovided at that time. TD-47(2/16) is the SG16 response to SG11; it represents the Q3/16Rapporteur’s detailed views and proposed solutions as discussed with experts from SG11.

TD-08(2/16) (TD-19, Launceston) is a liaison from SG11 concerning H.248 package on echocancellation. The proposed package was reviewed and a number of comments were provided in areply to SG11 in TD-83(2/16, also in TD-54[Plen]).

H.246 Material for Implementers Guides

See above, TD-07(2/16) and TD-47(2/16).

H.248 Material for Implementers Guides

D.130 (C. Groves, Ericsson, Editor) is the proposed Implementers Guide for the H.248 Series. Itwas agreed to remove the proposed Section 6.82; consensus did not exist for this change assufficient time had not passed to collect comments. TD-15(Plen) is the final H.248 Series IG forApproval.

TD-41(2/16) is a communication from the IETF Megaco working group Chair on descriptors forMegaco/H.248 Annex C properties. Megaco/H.248 Annex C defines a set of properties relating tomedia streams. These properties may appear in the LocalControl descriptor, if they are localinterest only, or in the local and remote descriptors, if their values must be known at both the localand the remote Media Gateway functional elements. Annex C currently fails to indicate whichalternative applies to each of the properties it specifies. The H.248 Implementers Guide should beupdated to reflect such assignment. Furthermore, with very few exceptions, the properties in AnnexC all belong in the local and remote descriptors. TD-41(2/16) proposes, on that basis, that theexceptions be deprecated in favor of properties in packages, and that Annex C be reserved forproperties that would be placed in the local and remote descriptors only.

It was agreed that the clarifications proposed in TD-41(2/16) are beneficial and should bedocumented, but it was felt that a specific proposal should be presented to the Megaco mail list toallow time for implementers to comment on the changes. This should be targeted for either v.2 orthe next implementers guide. Any proposal to deprecate code points should be accompanied with a



package that would allow setting these properties in the MG, unless the property in Annex C istruly unused. No new Annex C codepoints will be added until this issue is resolved.

H.245 v.8, Control Protocol for Multimedia Communication

TD-09(Gen) (M. Nilsson, BT, Editor) is Recommendation H.245 v.8 (known as H245DELP),Control protocol for multimedia communication. It shows changes relative to the Decided version(v.7, known as H245NCMO). It has been created from H245NCMO, TD-95(2/16) from the SG16November 2000 meeting, and from various AVD documents from the March 2001 LauncestonRapporteurs meeting of Questions D, F, G, 2-5. The version number in the syntax was changedand Annex D was updated to reference the new version.

There were no comments or objections to moving v.8 forward (through AAP) for Approval at thismeeting. The final text appears in TD-37(Plen).

H.246 Annex F, H.323 - H.324 Interworking

TD-29(2/16) (T. Suzuki, NTT, DoCoMo) Editor) is the draft new Annex F to H.246: H.323 -H.324 interworking. There were no comments or objections to moving Annex F forward forApproval (through AAP) at this meeting. TD-36(Plen) contains the final text.

H.248 v.2, Gateway Control Protocol

D.93 (M. Pantaleo, Ericsson) proposes the definition of a new mechanism to prevent an entity(either an MGC or an MG) from sending an infinite number of TransactionPendings. Currently,H.248 does not specify any such mechanisms. There were no objections to this proposal; it wasaccepted for H.248 v.2. The new error code will not appear in Annex L (which is up for Consent atthis meeting); it will appear later, possibly in an implementers guide.

D.129 (C. Groves, Ericsson) proposes extendable context properties for H.248. H.248 v.1currently supports a number of context attributes that apply to a context as a whole. Unfortunately,in H.248 v.1 the ASN.1 must be modified every time a new attribute is added. D.129 proposes toinclude the ability to define context attributes in packages so that they may be definedindependently from the base protocol. There were no objections to this proposal; it was acceptedfor H.248 v.2. There is a possibility that the context property could benefit from the “reservegroup” or “reserve value” semantics.

TD-31(2/16) (M. Pantaleo, Ericsson, Editor) is the new draft text for Recommendation H.248 v.2,as input to this meeting; it includes changes agreed during the March Rapporteurs meeting inLaunceston. TD-84(2/16) is the latest draft of Recommendation H.248 v.2; it includes theadditions agreed at this meeting. The current plan is to present H.248 v.2 for Consent at the SG16February 2002 meeting.

H.248 Annex L, Error Codes and Service Change Reason Description

D.128 (A. Heidermark, C. Groves, Ericsson) contains the proposed text for the H.248 Annex L,Error codes and service change reason description. There was some discussion about the need forAnnex L to cover cases such as where a piece of equipment (e.g., an analog line or a BRI station) isnot connected or is not powered. The feeling was that this case could be interpreted appropriatelyby the MGC and the appropriate cause value sent along. Also, specific faults can be covered inerror codes defined in packages that describe the special behavior. There were no objections tomoving Annex L forward for AAP. The final text appears in TD-14(Plen) (C. Groves, Ericsson,Editor).



H.248 Annex M.1, Advanced Audio Processing Packages

There were no contributions for H.248 Annex M.1 (Advanced audio processing packages); it iscurrently in an unfinished state.

H.248 Annex M.2, Congestion Handling Package

D.131 (C. Groves, Ericsson, Editor) contains the proposed text for H.248 Annex M.2, Congestionhandling package. Comments suggested that the name might be confusing: there may be otherpackages related to congestion control. To avoid confusion, the name was changed to “Mediagateway resource congestion handling package.” There were no other objections; it was agreed tomove Annex M.2 for Approval at this meeting. The final text appears in TD-16(Plen).

H.248 Annex M.3, Packages for Transmission of Data Over Analog Lines

During the March Rapporteurs meeting in Launceston (CSR 12.11), it appeared that twocontributions, H.248 Annex O (current Annex M.3) from the ITU and draft-boyle-megaco-alertingfrom the IETF, proposed packages covering the same need: transmission of data over analog lines.The contributors of both documents have agreed to merge their respective proposals into a singledocument, to be submitted as an IETF draft for “last call” by the beginning of June 2001. Thatdocument is presented in TD-38(2/16), H.248 packages for transmission of data over analog lines(J.-E. Chapron, France Telecom, Editor). Thus, it was agreed to withdraw the H.248 Annex O(current Annex M.3) so that only one set of packages dealing with transmission of data over analoglines is standardized.

H.248 Annex M.4, Packages to Support Interworking Between H.324 and H.323

D.108 (C. Sayre, Lucent) is a follow up to the discussion at the Launceston meeting (CSR 12.11)on contributions AVD-2056 (“New annex to H.246: Interworking H.323 and H.324 Annex C”)and AVD-2057 (“New H.248 packages to support interworking between H.323 and H.324 AnnexC”). The material in AVD-2057 is the basis for the proposed H.248 packages of Annex M.4 ofH.248. The terminology used in this paper for gateway, media gateway (MG), and media gatewaycontroller (MGC) is based on the gateway and gateway decomposition terminology found insection 6.3, “Gateway Characteristics,” of H.323 v4.

The initial work behind AVD-2056 and AVD-2057 focused on the scenario of multimediainterworking between H.324 Annex C terminals and H.323 terminals. Both the monolithic gatewayarchitecture and the decomposed gateway architecture (using the H.248 packages defined in AVD-2057) were considered. Their analysis of the issues shows that these are complicated interworkingscenarios and that a single decomposed gateway architecture is not the optimum architecture for allapplications. Consequently Lucent proposes that the gateway implementation will select thedecomposed gateway architecture that is the best fit based on the focus of the interworkingapplication. The gateway architectures can roughly be divided into architectures terminating H.245control in the MG and architectures terminating H.245 control in the MGC. Both of thesearchitectures have a role to play in multimedia interworking.

D.127 (T. Suzuki, NTT DoCoMo) proposes an additional description to the draft H.248 AnnexM.4, Packages to support interworking between H.324 and H.323. The packages proposed in thisdocument are used to support the H.324 multimedia call with the H.245 control in the MGC,anding also used to support IP tunneling of H.324 bitstream. There was no objection to adding thismaterial into M.4, provided the editorial comments noted are addressed.



TD-39(2/16) (C. Sayre, Lucent, Editor) is draft H.248 Annex M.4, H.248 packages for H.323 andH.324 Annex C interworking; it includes the results of the March Rapporteurs meeting inLaunceston. A number of comments from this meeting were provided.

TD-72r1(2/16) is the updated M.4; it contains changes to address the above comments and toincorporate D.127. The Editor reported that he had not yet received a reply from IANA to hisrequest for package identifier values. There were no comments or objections to moving M.4forward for Consent and Approval via AAP. The final text appears in TD-41(Plen).

New Supplement to H.248 to Capture Package Work

TD-76(2/16) (M. Brown, Nortel, Editor) contains the text of the proposed H. series Supplement 2,H.248 Packages Guide Release 1. This guide summarizes packages that have been standardizedfrom 06/2000 to 06/2001. This guide identifies packages that meet H.248 requirements forpackage definition and are for general use by the wider standards community. This supplementwas reviewed with no comment on its content; it was considered ready to publish. The final textappears in TD-26(Plen).

New Packages for H.248

D.109, Basic H.248 packages for support of external signal sources (B. Gilman, Avaya), proposesa method for allowing a termination’s media stream to be designated as a signal source. In thisscheme, a termination is designated as a signal source prior to the use of that signal. The MGC caninstruct the MG to play the signal by using the designation assigned to the termination. Thetermination would not generally be added to a context, the exception being when the signal contentis to be modified (such as recording an announcement). The designation step essentially allows theMG to create a table binding a signal name with the location of the signal source. The location forthe signal source can be a physical termination or an ephemeral termination. Discussion suggestedthat this proposal does not appear to fit the intent of H.248. Also, more information is needed onscenarios and architecture. D.109 was not accepted as the basis for a standard package at this time.A better explanation is needed to justify this proposal.

D.156 (S. Schaffer, MOC-Israel) proposes a list of requirements for an H.248 aggregate loadcontrol package. The main purpose of the proposed package is to avoid aggregate bearercongestion. The package may also be used for traffic management purposes. Comments andquestions on this included:

• Do these requirements primarily define the operation of the Aggregate Bearer AdmissionControl (ABAC)? These are background for basic requirements of the package.

• Can media types be mixed within the aggregate bearer? If so, what is a proposal for QoSparameters? An aggregate with stringent QoS parameters could be defined, then multiple mediatypes could be allowed within that aggregate bearer. But, it would be simpler to put each mediatype in its own aggregate bearer. Requirements do not disallow the use of separate aggregatebearers for each media type. It is unclear how to request different QoS parameters for mediastreams within an aggregate bearer.

• A similar proposal was accepted in principal at the last TIPHON meeting (CSR 12.15), but therewas not enough time to close on bandwidth reports.

• The requirements should be captured in the actual package text.• Review of the architectural implications in QB and QF should be considered.

D.157 (S. Schaffer, MOC-Israel) proposes a load control mechanism and information elements foran H.248 aggregate load control package. The load control mechanism is based on a load controlflag activated by the Aggregate Bearer Measurement (ABM) function in the media gateway. The



ABAC in the media gateway controller is informed about the change of the load control flag.Activation/de-activation of the load control flag by the ABM is based on load thresholds that arepre-programmed by the management plane. The connection admission control to the aggregatebearer is first performed by the ABAC. If the connection is admitted to the aggregate by theABAC, the media layer is also interrogated if it admits the connection to the aggregate (to avoid raceconditions).

There were no objections to this proposal. Proponents of the aggregate bearer control are expectedto produce the packages for review at future meetings.

Other Question 3/16 Highlights

D.94 (R. Even, Polycom, Israel) describes decomposition architecture for the MCU (multipointcontrol unit) to a control subsystem (H.323-defined multipoint controller [MC]) and mediaprocessing subsystem (H.323-defined multipoint processor [MP]). The general decompositionmodel described is not limited to H.323 but will also work for H.320, H.324, and other multimediastandards. The design is based on the Megaco/H.248 architecture and assumes that the controlprotocol between the MC and MP is H.248/Megaco. The MGC will have the MC functionalitywhile the MCU MP will be an MG. Discussion yielded the following comments and questions:

• Could audio and video mixers be modeled as context properties rather than separateterminations?

• It is necessary to understand how a video or audio property relates to a termination rather thanto a mixer.

• More details on modeling the various scenarios are needed to help determine the best solution.• Solutions need to address transcoding.• Any difference in approach whether using H.323 or SIP?• Need to see scenarios to help determine the best model.• What kinds of controls will be available to service providers?• Control somewhat the split between MC (MGC) and MP (MG) – video switching decisions

made in MG.

An ad hoc group convened to work out an understanding of modeling (H.248 vs. the model inD.94), and discuss a possible way forward. R. Even (Polycom) will consider D.129 (Extendablecontext properties for H.248 v.2, above) and the approach to represent mixers as context resources.More material is expectd in the future.

Q3/16 discussed the proposed new Question 15. WP3 approved opening of a new Question, toinclude work on distributed speaker verification. A Q3/16 ad hoc discussion to further explore thiswork yielded the following comments and questions:

• Has any analysis been done to determine savings on bandwidth? One of the documentreferences in D.143 addresses this issue. Savings might not be significant. WP2 should beable to provide some study of efficient protocols.

• Will this work address speaker-dependence (learning the individual and applying features tothat)? The intent of the Question is not yet known; a good approach would seem to be to notlimit the scope yet.

• QB should assist in drafting requirements and should comment on architectural issues.• Q5/16 also has some interaction in this work.• It would be good to associate distributed speech recognition with applications; user scenarios

are needed to illustrate applications and architectures.• A list of requirements and a statement of the problem to be solved are needed.



See the QE meeting report, above, for more details on the proposed new Question 15.

D.148 (O. Levin, RADVision, Israel) outlines requirements for a call control protocol for real-timemultimedia support over IP. It is a first attempt to present and summarize issues needed for videoservices support in SIP/SDP/RTP/RTCP systems. Part of the solutions may be defined in a shortperiod of time. More advanced features or complicated problems will be resolved in the future bySDPng and SIP extensions related to it. An alternative possible approach might be the definition ofconventions for certain SIP-based multimedia systems. D.148 was provided for information, but itgave rise to some discussion, including the following comments:

• SDPng will not be compatible with current SDP; it will create interoperability problems.• More requirements exist than are listed here; other requirements need to be listed.• Concerns exist over the use of XML in SDPng because of message size.• D.148 is really more of an analysis than a requirements document.• Parties interested in being involved should contact the MMUSIC WG Chair (IETF).• Why contribute to a competing protocol? Is it a benefit to industry to create two parallel

protocols, rather than allow one to specialize in multimedia?• As the lead multimedia group, SG16 should be interested in improving multimedia protocols in

general; interworking is a key issue, and SDPng will apply to H.248 as well.• It would be nice to have media flow between systems without a need for transcoding or any

other manipulation.

There was some discussion about whether to draft requirements and send a communication to theIETF; there was no consensus to draft such a communication.

Question 4/16 WP2, Video and Data Conferencing using Internet-Supported Services

S. Okubo (Global Information and Telecommunication Institute, Waseda University) is the Q4/16Rapporteur. TD-53(2/16) is the Q4/16 meeting agenda. TD-70(2/16) is the report of this meeting.TD-37(2/16) is the report of the March Rapporteurs meeting in Launceston.

In review of the Launceston discussion, the following actions were agreed:

• Start with application scenario descriptions, current practices, issues• Continue study on system model configuration and its analysis• Produce problem description to solicit technical contributions, and participation of experts from

related industries

D.95 (S. Okubo, Global Information and Telecommunication Institute, Waseda University)provides some scenarios for the utilization of Internet services to enhance videoconferencing andvideophone that would form a basis to derive technical requirements for the enhanced system.

Q4/16 discussed the relationship of their work with H.323 Annex O, Use of complementaryInternet protocols with H.323 systems (TD-40[2/16]). Annex O addresses the use of Internetprotocols as multi-media network infrastructure; Q4/16 addresses higher layer Internet services ontop of the network. Some of the scenarios can be achieved with H.323 Annex K, HTTP-basedservice control transport channel in H.323; its extension may be a way forward for Q4. The Mbuswork is closely related to Q4; J. Ott (University of Bremen, Germany) should be consulted, both asits proponent and as the IETF MMUSIC WG Chair. A concrete time schedule for the targetRecommendation should be set up as soon as possible, based on members’ interests. H.323Annex O and Q4/16 work can be complementary. CPL in Annex O might be more closely relatedto the Q4/16 work. CPL is the Call Processing Language from the IETF iptel working group by



Lennox J., Schulzrinne H. See “A Language for User Control of Internet Telephony Services,”draft-ietf-iptel-cpl-03.txt, April, 2001.

Future Activities

Q4/16 will continue their service scenario and problem description work. They plan to hold jointRapporteur meetings with Questions D, G, F, 2, 3, and 5 to progress the work, with the objective ofdescribing service scenarios and technical requirements, and elaborating the work plan.

Question 5/16 WP2, Mobility for Multimedia Systems and Services

P. Reddy (Intel) is the Q5/16 Rapporteur. TD-94(2/16) is the meeting report.

H.MMS.1, Mobility for H.323 Multimedia Systems (former H.323 Annex H)

E. Horvath (Siemens) is the editor of H.MMS.1. Q5/16 considered D.104 and D.105 jointly withQF.

D.104 (R. Roy, AT&T) describes the following fundamental problems that have been created bythe present proposal made in H.MMS.1 (TD-17[2/16], November, 2000) and AVD-2053a(Proposed updates for draft H.MMS.1, Mobility for H.323 multimedia systems, WP2 RapporteursLaunceston, March 2001):

• Consideration of HLF, VLF, and AuF as further sets of H.323 functional entities• Use of H.225.0 ANNEX G as mobility management protocol among HLF, VLF, and AuF• Creation of a separate set of HLF/VLF/AuF protocol for each application• No interoperability between H.MMS.1 and H.MMS.2. This makes it impossible to use or

extend the H.MMS.1 (H.323 Mobility) for solving the global mobility (H.MMS.2)

D.104 proposes the following solutions, and identifies the necessary changes to be made to theH.MMS.1 proposals to effect these solutions:

• Not to consider HLF, VLF, and AuF as specific entities of the application only, rather allapplications including H.323 will be able to use all those entities

• Not to name the protocol used among HLF, VLF, and AuF entities as H.225.0 Annex G or itsextensions, rather a new name (e.g., M.management) needs to be used so that all applicationsincluding H.323 can use this protocol to have the mobility-related services

It was agreed to accept the general concepts of this proposal with some modifications. The generalagreement of Q5/16 mobility work concentrates on vertical areas of mobility for multimediasystems, terminals, and services. It was also agreed to create a common mobility architecture,protocol recommendation as H.MMS.0 to cover H.323, H.324 systems, etc. A note was created tochange the H.MMS.1 Recommendation for H.323 mobility to consider extension for H.225.0Annex G for inter-domain network configurations along with the H.MMS.0 Recommendationprotocol and procedures. It was considered premature to accept the proposed changes toH.MMS.1.

D.105 (R. Roy, AT&T) proposes the scope of Q5/16, including H.MMS.1 (H.323 mobility),H.MMS.2 (Global mobility), and H.MMS.3 (Presence/instant messaging mobility). Q5/16 agreedto accept the following points of this proposal:

The scope of Q5/16 will be modified to include the following:



• A general mobility management protocol shall be developed for distributed multimedia systemsand services as new recommendation H.MMS.0. This includes a general mobility servicesrequirements, architecture, protocol, and procedures recommendation to cover H.323, H.324systems, etc.

• Global mobility management interoperability recommendation H.MMS.2 shall include commonparameters and userIDs, terminalIDs, service provider SystemIDs, etc., between 2G, 3G mobilenetworks, and mobility for multimedia systems Recommendations H.MMS.0, H.MMS.1, etc.

• Also to provide recommendations H.MMS.4 for interoperability between current presence andinstant messaging services and H.MMS.3 (Mobility presence and instant messaging formultimedia systems and service).

TD-58(2/16) (E. Horvath, Siemens) presents some comments on several issues raised by AT&T incontributions to Q5. Q5/16 accepted the following two points contained in the conclusion section:

(1st point:) “A major requirement is that introduction of mobility in parts of an H.323 system mustnot disturb other non-mobility-aware entities (e.g., it must not enforce an upgrade of all entities inthe system). It must be possible for mobile and non-mobile entities to co-exist in the samesystem.”

(4th point:) “We should avoid the maintenance overhead of two nearly identical protocols specifiedin different places. It may be possible to extend the existing H.225.0 Annex G protocol withfunctionality required for mobility management and define mobility management as a profile of thisprotocol. The name of the protocol is less important for the time being.”

In discussion of the 4th point, there was disagreement about the statement concerning extending theexisting H.225.0 Annex G protocol. But it was agreed to have a general mobility protocol and notto restrict enhancing the H.225.0 Annex G for H.323 mobility systems.

TD-59(2/16) (E. Horvath, Siemens, Editor) is the draft Recommendation H.MMS.1, Mobility forH.323 multimedia systems. This contribution was reviewed. It is expected to be ready forApproval in February 2002.

The discussions and proposal for separating the common mobility requirements, architecture,protocols, and procedures from H.MMS.1 Recommendation into H.MMS.0 Recommendationwere approved in this meeting. F. Bougant (France Telecom) was approved as Editor of the newH.MMS.0 Recommendation. It was also agreed to solicit for co-editorships for thisRecommendation.

TD-73(2/16) (G. Thom, Delta Information Systems) discusses requirements for the support ofservice classes in the mobility work. It requests that the service class parameter be able to be carriedin the various mobility protocol messages to allow authorization and service class information to becommunicated between the various mobility elements (HLF, VLF, AuF, etc). The service classparameter is currently defined using the generic extensibility function. A draft H.GEF.4 is availablein D.99 and contains the proposed definition of this parameter. TD-73(2/16) requests that themobility messages support the genericData and genericDataReason parameters.

Discussion addressed the importance of adding a class of service parameter like genericData as it isused in H.225.0 messages and procedures for all mobility recommendations (H.MMS.0,H.MMS.1, and H.MMS.2). For example: services like emergency services, priority emergencyservices, and priority value added services, etc., while roaming between home and visiting networkswithin the same country or internationally, would be included in this class of service parameters.TD-73(2/16) was accepted as proposed. The editors of the respective mobility recommendations



will add the proposed parameters. G. Thom was asked to make further contributions on proceduresfor handling class of service parameters while roaming between home and visiting networks.

H.MMS.2, Global Mobility Management Interoperability

D.106 (R. Roy, AT&T) describes a framework for how the multimedia applications and systemscan be extended to support mobility. It proposes a common mobility management protocol that canbe used by all applications and will optimize the system architecture to have the common functionalentities like HLF, VLF, and AuF. The framework includes system criteria for application of thesame common mobility management protocol in all architectural configurations among the mobilitydatabases (HLF, VLF, AuF): hierarchical/centralized and distributive. Q5/16 discussed D.106 in ajoint meeting with Questions F, 2, and 4.

D.107 (AT&T) proposes a common mobility management protocol for all multimediaapplications/systems and services. A joint meeting of Questions F, Q1-5 reviewed it, and acceptedthe general principle to develop the proposed new management protocol as new RecommendationH.MMS.0. It includes a general mobility services requirements, architecture, and protocolrecommendation to cover H.323, H.324 systems, etc.

TD-60(2/16) is draft Recommendation H.MMS.2, Global mobility management interoperability.Due to the dependency of this Recommendation on H.MMS.0 and H.MMS.1, F. Bougant (FranceTelecom) agreed to take the editorship of H.MMS.0 and make progress on it first, and then workon the H.MMS.2 Recommendation. H.MMS.0 is expected to be ready for Approval in Feburayr2002, with H.MMS.2 following in October 2002.

The Editor requested a liaison communication between 3GPP2, 3GPP CN TSG, and SA1 TSG, andQ5/16 to obtain information on the Mobile Applications Part data for all 3G services. TD-95(2/16)is a liaison to ETSI (3GPP2) and TD-98(2/16) is a liaison to TIA (3GPP), both requesting 3Gservices mobility management interworking requirements information.

H.MMS.3, Mobility Presence for MM Systems and Services

M. Paul (Trillium) is the H.MMS.3 editor. A joint meeting of Questions 1-5 considered thefollowing two contributions:

D.149 (E. Orr, RADVision, Israel) discusses the imperative need for presence functionality invarious H.323 systems. This contribution was agreed as informative because the proposed work onpresence is already in progress in Q2/16 and Q5/16 as Recommendations GEF.3, H.MMS.3, andH.MMS.4. It was pointed out that the presence server should support a distributed architecture toprovide presence and IM services in H.323 multimedia systems.

D.150 (E. Orr, RADVision, Israel) proposes alternatives for the delivery of presence informationfrom and to H.323 end users. The following points were raised in discussion:

Recommendations for presence work should consider IETF IMPP work (Instant Messaging andPresence Protocol ) RFC 2778 (A Model for Presence and Instant Messaging) and RFC 2779(Instant Messaging / Presence Protocol Requirements) as the presence model and requirements.Presence server functionality in standalone or integrated with gatekeeper architecture should notrestrict using RAS messages with presence services extensions in H.323 systems. Protocol forpresence and IM services shall be general to enhance the features in the future networks. Q2/16has identified Recommendation GEF.3 for H.323 presence and IM features. Q5/16 hasRecommendations H.MMS.3 and H.MMS.4 for mobile presence and IM features like mobileH.323 systems, etc.



D.150 was accepted as the general principle of using general extension framework with registration,authentication and security (RAS) extensions for non-mobile H.323 systems.

TD-61(2/16) (M. Paul, Trillium) contains a proposed Scope and Terms of Reference for Rec.H.MMS.3. “The scope of H.MMS.3 is to address the network architecture to support Presenceand Instant Messaging (IM) in mobile H.323 systems. It will identify the extensions to H.MMS.1(H.323 Mobility) protocol to make mobile H.323 systems Presence and IM capable. It will alsoaddress the need for any new logical and functional entities in H.323 mobile network to supportthese features.” This contribution was reviewed for information only for this meeting. D.105 alsoproposes some changes to the scope of Q5/16 that impact the scope of Rec. H.MMS.3. TheH.MMS.3 Editor will make appropriate changes to the scope of Rec. H.MMS.3 with respect to thecomments noted under the D.105 comment disposition (above). H.MMS.3 is expected to be readyfor Approval in October 2002.

The 3GPP SA1 TSG ad hoc group document 3G TS 22.141, Stage 1 Presence Service (Release 5)(TD-62[2/16]) was reviewed as input to Rec. H.MMS.3. It was agreed to extract from it thepresence services requirement. The H.MMS.3 Editor will take this contribution as the technicalinput for Rec. H.MMS.3 work. Q5/16 agreed to continue their liaison relationship with 3GPP SA1TSG regarding the presence services standardization work. It was also agreed to propose a liaisoncommunication to 3GPP to request the updated Stage 1 Presence Service document to avoidduplicating the work in Q5.

Question 6/16 WP3, Advanced Video Coding

Working Party 3/16 addressed Question 6 under the chairmanship of G. Sullivan (Microsoft).TD-17(3/16) is the agenda. TD-42(3/16) is the meeting report. TD-27(3/16) is the report of theQ6/16 January 2001 meeting (Meeting L) in Eibsee, Bavaria. TD-40(3/16) is the report of theQ6/16 April meeting (Meeting M) in Austin, Texas. The Q6/16 discussion was held in parallelwith the speech coding-related questions (QE, Q7-10/16).

Liaisons

TD-07(Gen) is a liaison from the ITU-R SG6 new Question 6, Standards for digital high definitiontelevision. The ITU Radiocommunication Assembly has decided to study the following Question:What methods should be used for the digital coding of high definition television picture signals:

• Inside the studio complex, including the recording interfaces?• In broadcasting from terrestrial transmitters, by cable television and from satellites?

H.263, Video Coding For Low Bit Rate Communication

TD-43(Plen) (G. Sullivan, Microsoft; T. Wiegand, Heinrich-Hertz-Institute, HHI) containsreplacement text for H.263 Appendix II. Appendix II of H.263 (approved as part of H.263 v.2)defined, in a non-normative manner, several preferred mode combinations of operation with thehope that option-enhanced terminals would have a higher probability of connecting to each otherusing some syntax better than the “baseline.” Appendix II has now been superseded by thenormative Annex X, which defines not only an extended set of profiles and levels, making use offurther optional modes added in H.263 v.3, but also defines a means to signal capability and the useof these profiles and levels using the generic capability mechanism of H.245. This revisedAppendix II to H.263 was approved by SG16.



TD-44(Plen) (G. Sullivan, Microsoft; T. Wiegand, HHI) contains the test model description ofRecommendation H.263. It was approved by SG16 as Appendix III to Rec. H.263.

TD-45(Plen) (G. Sullivan, Microsoft; T. Wiegand, HHI) is the first Implementers Guide forRecommendation H.263; it was approved by SG16.

H.245 for H.263

In view of the recent Approval of H.263 Annex X, an interoperability issue exists regarding new vs.old ways of signaling H.263 capabilities in H.245. Q6/16 experts recommended a note be added toH.245 calling attention to this issue. It was suggested that perhaps normativemodification/implementers guide content for H.323, H.324 etc., might be advisable.

H.26L, Video Coding Recommendation

Q6/16 is currently developing a new video coding recommendation in a project known as H.26L.That project is the primary video coding effort currently under way in ITU-T SG16. The H.26Lproject has, to date, concentrated primarily on low and medium bit-rate coding and lower-resolutionpictures sampled with 4:2:0 sampling at 8 bits per sample. Q6/16 believes that their current designreflects the state-of-the-art for those applications. Recent studies show preliminary indications thatthe H.26L draft design is also capable of superior performance for high-resolution pictures such ashigh definition television picture signals.

TD-26(3/16) is a liaison (April 13, 2001) from ISO/IEC JTC1/SC29 to Q6/16 and SC29/WG11Collaborative Team proposing the establishment of a ITU-T SG16 Q6 and SC 29/WG 11Collaborative Team to align the development of the next generation video coding standards.

Q6/16 agreed on the need for a strong cooperative and collaborative relationship with ISO/IECJTC1 committee MPEG. Toward that goal, the concept of the formation of a collaborative teamproject with MPEG was endorsed, pending approval of a suitable new work item in thatorganization. This new cross-organizational team effort would subsume the scope of the currentH.26L project into a joint project for the production of a new ITU-T Recommendation and a newISO/IEC International Standard. A proposed plan for this team effort was drafted (TD-46[Plen]),and was subsequently approved by SG16. A liaison to ISO/IEC JTC1/SC29 was drafted to conveythis approved plan, toward the formation of the joint project.

TD-43(3/16) contains three liaison statements from Q6/16, one each to ISO/IEC JTC1/SC29, toISO/IEC JTC1/SC29/WG11, and to ITU-R SG6 concerning collaboration on video coding topics.

In one, Q6/16 notes their concurrence with ISO/IEC JTC1/SC29 on the potential and opportunityfor the formation of a joint team with ISO/IEC JTC1/SC29/WG11 for future work on videocoding. Q6/16 informs SC29 that they have drafted a proposed plan (TD-46[Plen]) for a jointproject that would subsume the current scope of the ITU-T H.26L project.

In another, Q6/16 expresses their strong and continuing interest in a close collaboration withWG11 on future video coding activities. Q6/16 intends to participate in WG11 upcoming plannedtest efforts for video compression efficiency improvement; they believe their H.26L design is readyfor evaluation in such tests. Q6/16 expects the H.26L design to show a significant performanceadvantage relative to MPEG-4 video in those tests.

With regard to the testing plans for the Digital Cinema application, Q6/16 has performed someinitial work toward studying the suitability of the current draft H.26L design for that application aswell. A few initial experiments indicate that the H.26L design has a significant rate-distortion



performance advantage relative to the sample MPEG-4 studio profile sequences that weredistributed with the test sequence data for these tests (measured in PSNR terms after adjusting forcolor space distortion in those sample sequences). But Q6/16 cannot meet the WG11 deadline forparticipation in these tests. If WG11 decides, based on its upcoming test results, that thedevelopment of a new standard is necessary for the Digital Cinema application, or that furtheranalysis is needed before making such a decision, Q6/16 hopes that the technology design found inH.26L can be evaluated for suitability in future experiments for addressing that application as well.

In the third, Q6/16 thanks ITU-R for their liaison regarding the new ITU-R Question 6/6 on HDTVvideo coding, and informs ITU-R of their new Recommendation H.26L. Q6/16 emphasizes theirinterest in continuing to receive further information regarding the progress of the ITU-R Q6/6 workand in being able to aid in and collaborate on that work.

TD-02(3/16) is a liaison from ISO/IEC JTC1/SC29/WG11 on video coding standardizationactivities. SG16 had previously indicated an interest in participating in the MPEG-4 videoperformance tests that WG11 had planned to conduct in February, 2001. WG11 has found itdifficult to obtain the necessary volunteer efforts from its members to be able to move forward withthese tests on the planned schedule. As a result, appropriate MPEG-4 reference anchor material isnot yet available. WG11 has therefore decided to re-issue their Call for Proposals with a delayedtest plan to allow time for generation of MPEG-4 anchor references. Their new test plan calls forsubmissions of coded test material on July 1.

D.146 (H. Schwartz, T. Wiegand, HHI) describes a method of optimizing the performance ofH.26L encoding. The method uses Lagrange multiplier techniques, including some short-cuts forreducing computation time. Approximately 0.2 to 0.3 dB of improvement was typically found,sometimes more. It was noted that these measurements were not made by Q6’s preferred method,but were supported by plots. It was reported that if the motion vector search range is increasedbeyond the +/-16 range using today’s software, the current test model performance can actuallyworsen. It was asserted that the increase in the complexity of the encoding process as a result ofusing this optimization technique is less than 10%.

Q6/16 decided to adopt this rate-distortion optimization technique into the test model and thus tocreate an H.26L Test Model Long-term number 8 (TML-8) design reflecting this alteration. Theuse of the technique will be identified as a high-complexity form of the test model operation.

D.151 (D. Marpe, G. Baettermann, T. Hinz, G. Heising, T. Wiegand, HHI) discusses improvingcoding efficiency of H.26L using context-based adaptive binary arithmetic coding (CABAC). Anumber of previous contributions have shown that the CABAC method can significantly improvethe coding efficiency of the current H.26L test model. (See CSR 12.09 VCEG-L13, Adaptivecodes for H.26L, D. Marpe, G. Blättermann, T. Wiegand, HHI, Q6/16 Eibsee, January 2001;VCEG-M59, Further results for CABAC entropy coding scheme, D. Marpe, G. Blättermann, G.Heising, T. Wiegand, HHI, Q6/16 Austin, April, 2001). The advantages of this approach arethreefold compared to entropy coding using a fixed, universal table of variable length codes(UVLC):

Context modeling provides estimates of conditional probabilities of the coding symbols. Utilizingsuitable context models, given inter-symbol redundancy can be exploited by switching betweendifferent probability models according to already coded symbols in the neighborhood of the currentsymbol to encode.

Arithmetic codes permit non-integer number of bits to be assigned to each symbol of the alphabet.Thus the symbols can be coded almost at their entropy rate. This is extremely beneficial forsymbol probabilities much greater than 0.5, which often occur with efficient context modeling. In



this case, a variable length code has to spend at least one bit in contrast to arithmetic codes, whichmay use a fraction of one bit.

Adaptive arithmetic codes permit the entropy coder to adapt itself to non-stationary symbolstatistics. For instance, the statistics of motion vector magnitudes vary over space and time as wellas for different sequences and bit-rates. Hence, an adaptive model taking into account thecumulative probabilities of already coded motion vectors leads to a better fit of the arithmetic codesto the current symbol statistics.

Preliminary results show that increasing the number of models used for coding the binarized runsyields an overall 1% bit rate reduction for different QPs (8,18,28). Another 0-1% bit rate savingscould be achieved by using a context model for coding the Level information such that the selectionof a model is triggered by a threshold decision with respect to the sum of the magnitudes of Levelsseen so far in a given block. These preliminary results indicate that there is still room for furtherimprovements without increasing the computational complexity.

D.153 (Telefon AB, LM Ericsson) discusses the use of constrained intra prediction for H.26L.The current TML intra prediction modes use neighboring macroblocks in their prediction evenwhen the latter are inter-mode macroblocks. This means that (packet) losses in such areas willpropagate also to intra macroblocks. Hence, an intra macroblock does not work as a true refresh.This is a serious problem for channels with losses. By ruining intra refresh, a concealed area willpropagate and cause major drift problems with large impacts on quality. D.153 proposes to limitintra prediction of macroblocks, such that it is only allowed to predict from neighboringmacroblocks that are intra coded and within the same slice. This way one or several intramacroblocks will always be self-contained with no indirect references to previous frames. This isthe method used in H.263 (Annex I).

Simulation results show that the degree of improved performance obtainable depends on the natureof the losses and the intra-refresh scheme. For an error-free environment, the new intra predictionmethod leads to a small coding penalty.

Q6/16 agreed that a method is needed for preventing error propagation for good error resilienceperformance. It was agreed to adopt the method of stopping error propagation, with a switch at thesequence header level regarding whether to allow such prediction or not, and not sendingunnecessary prediction direction information for first blocks. Further investigation of the need forspatial prediction across macroblock boundaries for intra macroblocks in P and B pictures forerror-free environments was encouraged. This alteration was considered the second feature adoptedfor the formation of TML-8.

D.154 (Telefon AB, LM Ericsson) presents the results of an experiment on S frames performed toinvestigate the characteristics of alternative techniques that do not require any changes to thebitstream syntax or decoding algorithms. (See N. Färber and B. Girod, “Robust H.263Compatible Video Transmission for Mobile Access to Video Servers”, in Proc. IEEE Int.Conference on Image Processing (ICIP), Vol. 2, pp. 73-76, Santa Barbara, Oct. 1997.)

H.263 was chosen for the experiments because of its intra refresh characteristics with regard to lackof error propagation. Performance improvement might be obtained with use of S frames byoptimizing the choice of intra mode; these experiments did not optimize for that. It was noted thatwith SP frames even the possibility of a switch causes a decrease in coding efficiency and anincrease in decoding complexity. Results on the test set appear to show that, in the H.263 baselinecontext, S frames are one effective means of switching between streams. At higher quality theremay be more of a switching penalty than what is shown in these experiments (although at higherquality more intra refresh can be afforded). Error tracking and optimized mode selectiontechniques may help.



D.154 appears to show that there may be one or more effective alternatives for stream switchingwithout the need for the extra decoder complexity and intra-stream quality loss of SP frames, atleast for lower bit rate streaming. Further investigation of the need for SP frames was encouraged.

Future work

Three Q6/16 Rapporteur meetings are planned for the interim to the next SG16 meeting inFebruary 2002. Q6/16 also intends to submit materials for planned testing to be done in ISO/IECSC29/WG11; the plans and dates of these tests may depend on the progress of the potentialformation of the collaborative joint team with ISO/IEC JTC1/SC29.

Question 7/16 WP3, Wideband Coding of Speech at around 16 kbit/s

Working Party 3/16 addressed Question 7/16 under the chairmanship of R. Drogo De Iacovo(TILAB S.p.A.). TD-37(3/16) is the meeting report. TD-20(3/16) is the agenda. Currentobjectives of Question 7 are to plan for the selection phase for the wideband speech codingalgorithm at around 16 kbit/s.

The Rapporteur presented the report of the interim activities (TD-20[3/16]). After the last SG16meeting in November 2000, the ad hoc group on selection matters prepared the draft widebandselection test plan and the processing plan considering three candidate proponents: Motorola,Nokia, and NTT.

The selection test plan was presented and approved at the SG12 meeting in February, 2001. Duringthat meeting, the pricing and work allocation were also established. After that meeting, oneproponent withdrew its candidate algorithm. A new version of the test plan was prepared in March2001 for the two remaining candidates. Due to the reduced number of candidates, the total numberof sub-experiments in the selection test plan was also reduced from ten to six.

According to the time schedule, the listening laboratory received (by May 14, 2001), with blindmapping, the processed (already cross checked) material for the candidate algorithms. The listeninglaboratories will send out the deliverables, raw data, and test results by June 20, 2001.

TD-04(3/16) is version 3.3 of the subjective selection test plan for the ITU-T wideband (7 kHz)speech coding algorithm around 16 kbit/s.

TD-10(3/16) is version 1.0 of the processing functions for the ITU-T wideband (7 kHz) speechcoding algorithm around 16 kbit/s – Selection phase.

Three sets of demonstration material will be made available: music conditions, BER conditions, andfrequency response material. Each set of demonstration materials will be provided with a differentblind mapping. Those blind mappings will also be different from the blind mapping used for thelistening laboratories. The following dates were agreed:

• June 20, 2001 - demonstration material provided to the candidate proponents• June 27, 2001 - demonstration material uploaded to a password-protected FTP site provided by

host laboratories (password will be divulged through the WP3 email reflector)

Demonstration material can be subject to further analysis and the result of this analysis can beprovided for information at the selection meeting. The candidate proponents will allow such areview of the demonstration material solely for the purpose of the ITU-T selection process.



Q7/16 agreed on the following procedure to evaluate the selection test results. The goal of thisprocedure is to select the winner candidate in a blind manner.

1) The crosscheck and host laboratory reports cannot provide information (compiled platform, dateof received code, possible execution problems, etc.) that would reveal the identity of candidates.

2) The candidate proponents will receive the test results from each test laboratory with blindmapping (same mapping for all experiments).

3) The three sets of demo material (music, BER conditions, frequency response) will use differentmappings, also different than the subjective test mapping.

4) The discussion on the selection test results should be made without divulging either the blindmapping of the subjective tests or the blind mappings of the demo material. Other information(coder complexity, delay, etc.) contained in the high level descriptions of the candidatealgorithms is not used at this stage.

5) If there is no clear winner from the subjective test results, additional information (codercomplexity, delay, etc.) may be examined and used as eliminating rule.

6) If there is no clear winner, the mapping between the codec labels used in the subjective tests andthe codec labels used for the demo material may be revealed. Should this happen, it is possiblethat the candidates will be able to break the blinding. Demo material information can be used asa basis for written contributions.

The global analysis laboratory (as reported in the signed MoUs) will perform, for each listeninglaboratory and sub-experiment:

• T-tests• Analysis of talker dependency• Analysis of variance (ANOVA). For codecs under test and reference codecs, a four-way

ANOVA will be performed including as factors: coder, impairment, talker, listener.

The appointed Global Analysis Laboratory (ARCON) was asked to check, for each experiment, ifthe results differ across listening laboratories (i.e., across languages) and, in case it is statisticallyallowed, to combine the subjective data across listening laboratories. Although this additional stepis not specifically included in the MoUs, ARCON will determine if it is able to provide suchinformation at the selection meeting of Q7/16 in July 2001.

TD-21(3/16) is the call for proposals for new tools for audio coding issued in March 2001 byISO/IEC JTC1/SC29/WG11 (MPEG).

In discussion of this, Q7/16 noted that, at this stage of the work within SG16, the two widebandcoding algorithms under consideration in ITU-T are not able to provide forward and backwardcompatibility with existing MPEG-4 technology. This feature would need additional work to beimplemented, possibly leading to coding schemes very different from those currently under study inITU-T. Moreover, it should be verified that the ITU-T selected algorithm fits in one of the twocategories identified by MPEG: bandwidth extension and parametric coding.

From the timetable and procedures contained in the call for proposals, it was noted that theregistration date (May 15, 2001) and the submission date (June 1, 2001) could not be fulfilled; theITU-T candidate algorithm was to be selected after this meeting. The time schedule for Q7/16shows a meeting in July, when, it is hoped, the experts group will converge on a selected algorithm.

Considering the test results already made available during the ITU-T qualification phase, the feelingof Q7/16 was that the speech quality provided by the winner candidate algorithm will be very high,making more likely the possibility of the inclusion of such technology in the MPEG framework.



It was agreed to send a liaison (TD-36[3/16]) to the MPEG group informing them about the above-mentioned topics and about the Q7/16 time schedule.

Agreed Milestones

The AAP procedure will be followed for this new Recommendation. Q7/16 agreed on thefollowing milestones:

• Selection at the next Rapporteurs meeting (July 24-25, 2001)• At the next WP3 meeting (November 12-16), provision of the C-source code to ITU-T TSB,

and possibly Consent (based on the selection test results)• Consent at the next SG16 meeting (February 2002), if Consent is not reached in the November

WP3 meeting

Question 8/16 WP3, Encoding of Speech Signals atBit Rates Around 4 kbit/s

Working Party 3/16 addressed Question 8 under the chairmanship of P. Barrett (BT). TD-19(3/16) is the agenda. TD-35(3/16) is the draft meeting report. TD-05(3/16) is the report of the(formerly Q21/16) November 2000 meeting. The current objective of this question is to select analgorithm (or algorithms) that is (are) likely to meet the terms of reference for the future ITU-T 4-kbit/s speech coding standard (G.4k).

The Rapporteur summarized the main decisions made at the last meeting. The main interimactivities were performed by Q7/12 (SQEG), which produced the draft subjective test plan andidentified organizations able to perform the listening laboratory, host laboratory, and global analysisfunctions. The MoU for the fixed-point selection phase were stable prior to the meeting. Revisedversions will be issued to reflect the decision to submit results to SG12 in October and the decisionto include complexity evaluation into the host laboratory work. The Rapporteur clarified that thestatistical analysis of the subjective test results is the responsibility of Q7/12.

In D.132, Siemens announced their participation in the ITU-T 4kbit/sec fixed-point selection phaseas an additional member of the consortium currently comprised of AT&T, Conexant/Mindspeed,Deutsche Telekom, France Telecom, Matsushita, and NTT Cyber Space Laboratories.

Global Analysis and Selection Process

TD-18(3/16) (presented by A. Sharpley, Dynastat) describes the analysis of variance (ANOVA)procedure to be used in global analysis of the fixed-point selection results. It was revised (as TD28r1[3/16]) to take into account the Q8/16 discussion, and includes a decision tree showing howthe requirements and objectives will be used in the global analysis. TD 28r1(3/16) will be postedon the Q7/12 (SQEG) email reflector for final Approval.

The blind mapping will be disclosed to the experts via the WP3 audio email reflector on MondayOctober 29 (immediately after SG12).

Complexity Evaluation

D.152 (Deutsche Telekom) proposes that the complexity evaluation of the two candidate codecs beperformed by an independent organization using source code, to avoid problems caused by anyerrors found in the complexity estimation after codec selection. For logistical reasons, Q8/16 didnot adopt the proposal to use source code, but it was suggested that such a procedure should be



built into future exercises. D.152 represents the opinion of all the consortium members, i.e.,AT&T, Conexant, Deutsche Telekom, France Telecom, Matsushita, NTT and Siemens.

To maximize the accuracy of the complexity evaluation process, Q8/16 agreed to the followingapproach:

First, an ad hoc group convened (chaired by P. Bloecher [Ericsson]; reported in TD-29[3/16]) andidentified a need to clarify the correct usage of the ITU-T fixed-point operators in the STL. It wasagreed to better define usage of the dummy operators (such as test(), move()) through a setof examples; the current chapter in the STL documentation leaves room for interpretation. The adhoc proposed that a set of examples be prepared and agreed by the codec proponents of the 4kselection phase. This will ensure that both parties measure complexity of their 4k codecs in thesame way.

The ad hoc agreed that clarification of the output of the complexity counting tools is needed. Theproponents will ensure that the WMOPS printout will include indication of the codec componentbeing analyzed (coder or decoder). This will enable the host laboratories to report individualcomplexity figures for encoder and decoder. The computational complexity figure measured andreported for the 4k selection candidates will be the worst observed encoder complexity and theworst observed decoder complexity. To avoid ambiguities, a file containing the allowable basicoperators will be distributed on the WP3 audio e-mail reflector.

Then, to ensure that the correct basic operators are used, the candidate proponents agreed toproduce a new version of the G.191 basic operators library with the non-G.729 operators removed.

On the first day after SG12 (Monday, October 29, 2001), the candidates will deliver a secondversion of their candidate executable to the host laboratories, which, for each input file, prints thehighest WMOPS figure measured for a frame. Separate figures will be provided for the encoderand decoder. The host laboratories will use a subset of their existing fixed-point selection phaseprocessing scripts to measure the worst-case WMOPS figure for each candidate codec. Thesefigures will be provided to the Q8/16 experts on the email reflector on Monday November 5. Thehost laboratories will also check that the encoded output of the second executable is bit-exact withthe original.

The Rapporteur will provide a file to the candidate proponents containing non-speech input signals,such as digital silence and tones. The proponents will report the complexity measured over this file.

Finally, a request was made that a complexity figure be provided under high rates of bursty frameerasures. It was agreed that this figure should be provided as part of the verification phase afterselection.

Subjective Test Plan

Q8/16 reviewed the initial draft of the subjective test plan for the fixed-point selection phase (TD-07[3/16]). It was approved with minor corrections and raised to version 1.0 for inclusion in theMoU.

Q8/16 reviewed the draft (v.0.1) processing plan for the fixed-point selection phase (TD-06[3/16]).It was approved and raised to version 1.0 for inclusion in the MoU.

TD-22(3/16) contains the technical schedule for the standardization of the 4-kbit/s speech codec;TD-58(Plen) Annex Q8.A contains a revised list of the deliverables to be provided by the candidateproponents.



Characterization

Q8/16 agreed to ask Q7/12 to prepare a subjective test plan for a characterization phase. Q8/16 willdevelop, via correspondence, a list of conditions to be tested. An initial discussion identified thefollowing areas to be tested in the characterization phase:

• Objectives not tested in the selection phase, e.g., higher noise levels and three tandem encodings• Tandeming with other standards• Bursty bit errors

It was agreed that the exact content of the characterization phase and the need for availability ofresults prior to Consent will depend on the performance of the algorithm in the selection phase.The candidate proponents agreed to the principle that the proponents of the selected algorithm willfund the characterization phase. The candidate proponents will be asked to confirm thiscommitment at the start of the selection meeting when the cost of the characterization phase will beavailable from Q7/12. Non-speech quality issues, such as idle noise and DTMF transparency, willbe verified prior to the Consent meeting.

TD-30(3/16) is a liaison to Q7/12 requesting the following actions:

• Analysis of the results of the fixed-point selection phase• Preparation of a test plan for the characterization phase• Identification of organizations to perform the host laboratory, listening laboratory, and global

analysis functions• Provision of a cost breakdown for the characterization phase.

Future Work

A Q8/16 Rapporteurs meeting is scheduled for November 12-16 in Geneva. The main objective ofthis meeting will be to review the results of the ITU-T 4-kbit/s fixed-point selection phase, to selectone algorithm, and to complete the planning of the characterization phase.

Question 9/16 WP3, Variable Rate Coding of Speech Signals

Working Party 3/16 addressed Question 9 under the Rapporteurship of Y. Naito (MitsubishiElectric). TD-23(3/16) is the agenda. TD-41(3/16) is the meeting report. TD-24(3/16) is the listof documents. TD-25(3/16) is the report of the (former Q24/16) November 2000 meeting.

The current objectives of Q9/16 are to achieve consensus on the development target, identifying theapplication area, user needs, and trend of the technology for new variable bit-rate speech codingalgorithm and draft the ToR. At the November meeting three ad hoc email discussions wereinitiated for three potential approaches: Multirate/VAD VBR (MVV), Specialized Codec VBR(SCV), and Embedded VBR (EV).

EV, Embedded VBR

TD-09(3/16) (S. Ramprashad, Agere) provides a summary of the discussion held on the embeddedvariable bit-rate (EV) reflector from December 2001 to May 2001. In general, comments on the EVreflector demonstrated that more discussion about the use of embedded coding and the types ofembedded coders is likely necessary before the goal of drafting a proposed ToR can be achieved.The EV discussion did however make important first steps in defining concepts for consideration inany future embedded (speech) coding effort in the ITU-T.



The EV discussions identified the definition, types of layering, embedded functionalities, andapplications. Some proposed definitions and potential options were clarified, but consensus wasnot achieved to draft the ToR for the EV approach. The report includes the agreements: to focusprimarily on speech, to have bit-rate scalability and, additionally, to have bandwidth scalability.Agreed applications include congestion control, multicasting and differentiated services, andeliminating the need for tandems and signaling.

SCV, Specialized Codec VBR

D.145 (H. Su, Conexant) summarizes the discussions carried out on the VBR email reflector by theSpecialized Codec VBR ad hoc group. The agreed target includes developing the low averaged bit-rate speech codec with high speech quality, and developing the codec applicable for videoconferencing, video streaming/broadcasting, IMT2000, VoIP, voice storage and voice-mail store-andforward. The report also suggests the potential merging of SCV approach and MVV approach.The ad hoc discussion considered three main categories:

1) General definition of SCV (or VBR)2) The fundamental reason to have a new ITU-T VBR standard3) Terms of Reference for the ITU-T VBR standard development

The ad hoc agreed that the SCV and the other type of VBR, the Multirate/VAD VBR (MVV), aretwo slightly different implementations of a more generalized global coding scheme. It furtherconcluded that the SCV approach requires relatively less building blocks which facilitates thedesign and reduces the overall complexity of the system, while achieving a lower average bit-rate(ABR) for the same quality and/or better quality for the same ABR.

In the reflector discussion, it was suggested that if an MVV were to be developed based on anexistent multirate standard, like the G.729 Annex I, then the reuse of code space might offset thatoriginal complexity as compared to the SCV approach. On the other hand, SCV might requiremuch more orthogonal codec implementations that would increase the complexity count. Also thesignal classification (rate determination algorithm, in the original SCV contribution [D.72, Technicalmerits of VBR coding system and SMV, H. Su, Conexant; M. Recchione, Lucent, SG16 November2000]) might be a high complexity module.

It was also suggested that the complexity issue would better be left to algorithm proponents, sincethere are tradeoffs to be made. For example, since SCV can always be implemented as a subset ofthe MVV, it is likely that it would result in a lower complexity system, using the same buildingblocks. But, to achieve optimum performance, it might be desirable to increase certain complexityin some areas.

The motivation of VBR is to achieve the lowest ABR for a given speech/audio quality target, or toachieve the highest quality with a given target ABR. Since lower bit-rate and/or higher quality is theprimary objective and advantage of a VBR system, any applications with shared availabletransmission or storage bandwidth would benefit from such a standard. Also, MVV is covered bythe latest G.729 Annex I standard, while SCV is not. Furthermore, the existence of an ITUstandard that provides the bandwidth efficiency for 3GPP2 applications will facilitate industrydecisions on 3G wireless and contribute to a quicker acceptance of 3G systems.

The ad hoc discussion agreed that the imperative issue is the need to have a common standardenabling the interoperability of products from different vendors. In general, more elaboration isrequired, but, some common requirements for any late ITU-T speech coding standards are



applicable, such as BER, FER, level variation, tandem performances, robustness against backgroundnoise, low complexity, low delay, low memory usage, etc.

D.144 (H. Su, Conexant) proposes the ToR for the future ITU-T VBR speech coding standard.The content of the ToR proposal is based, to a large extent, on the terms of reference used by theprevious ITU-T exercises on 8-kbit/s and 4-kbit/s speech-coding efforts, with some modificationswhere appropriate.

MVV, Multirate/VAD VBR

P. Barrett (BT) reported that there was no significant discussion of the MVV approach.

Agreements

Q9/16 reviewed the reports of the interim ad hoc activities over the email reflector, and continued thediscussion of the potential approaches to identify the application areas for the development and theurgency. Comments supporting the SCV approach emphasized the wide coverage of applicationareas including wireless application, and the urgency of the market needs. It was agreed to mergethe SCV approach and the MVV approach under the new name, Multi-mode Source ControlledVariable Bit-Rate (MSC-VBR) approach. Support of the EV approach emphasized the potentialextension in bandwidth scalability, and the possibility of developing the new coding algorithm inappropriate time for future needs. Q9/16 recognized that the discussions on both SCV and EV arestill premature for determining in which direction (or both) to proceed.

Two ad hocs convened, one (under the leadership of V. Viswanathan, Texas Instruments) to developideas for EV approach, and the other (under the leadership of H. Su, Conexant) to develop the draftToR for the MSC-VBR approach.

These ad hoc discussions yielded the following agreements:

• Comments from other SGs and recognized bodies are also necessary to achieve consensus onthe direction of development. A liaison (TD-38[3/16]) was drafted to ITU-T SG 15 WP2,ETSI TIPHON, 3GPP SA4, 3GPP2 TSG-C 1.1, ITU-T SSG, and IMTC asking for review andcomments on the current status of the work.

• The ToR for the development of new VBR speech coding algorithm needs to include theidentity of ITU-T.

• Discussions will continue via the email reflector <[email protected]> to brush up the ideasfor both the MSC-VBR approach and the EV approach, toward a potential merger of two ToR.

• The outcome of the MSC-VBR ad hoc discussion was agreed as the very preliminary ToR forthe approach; this preliminary ToR needs further review.

• Results of further email discussions and any responses to the liaison statement will be reviewedat a planned Rapporteurs meeting in November.

• The ideas for two approaches will be progressed toward consensus on a single draft ToR,hopefully at the Rapporteurs meeting.

• Approval of the ToR at the November WP3 meeting, if consensus is achieved at theRapporteurs meeting.



Question 10/16 WP3, Software Tools for Signal ProcessingStandardization Activities and Maintenance of Existing Voice

Coding Standards

S. Campos-Neto (Comsat) is the acting Q10/16 Rapporteur. TD-32(3/16) is the meeting report.TD-14(3/16) is the agenda and report of the Q10/16 interim activities from November 2000 to May2001.

Question 10/16 is the merger of parts of Q19/16, Extension of existing speech codingrecommendations, and Q22/16, Software and Hardware Tools, from the 1997 - 2000 study period.Q10/16 will deal with software tools and maintenance aspects of existing voice-codingrecommendations. Currently Q10/16 is dealing with the maintenance and future enhancements ofthe STL2000 (which was Decided in the SG16 November 2000 meeting, and which was formallyreflected as a revision to G.191, Software tools for speech and audio coding standardization, AnnexA), and with the maintenance of existing speech coding standards.

Progress on Software Tools

The following are the changes to the STL2000R3 approved in December 2000. Themodified/additional code is available as an electronic attachment in Annex B of TD-14(3/16) as wellas in the SG16 informal ftp area for Q10/16.

EID Module

No functional changes were performed in the module core (eid.c). A demo program was added(called bs-stats.c) which extracts information from encoded bitstreams (including efficiencyfor VAD-enabled encoded bitstreams). The makefiles were also updated to compile and performportability test of the new program. A sample printout of the program is shown in Figure 1, below.

# Bitstream file: ........... voice.bs# Frame lengths saved in: ... voice-bs-stats.txt# Bitstream format (G.192 header) ...... : g192# Frame size count summary (total 3 frame sizes found):# -Frame length 0 count is 30# -Frame length 50 count is 5# -Frame length 80 count is 15# Total number of frames: 50# (MMR) Ratio between longest and shortest frame count is 0.500# (Act) Ratio between longest and total frame count is 0.300# (Efc) Ratio between shortest and total frame count is 0.600

Figure 1: Sample printout of the bs-stats.c demonstration program.

Also in the EID module, TI found a bug in the gen-patt.c demonstration program when theoption -start is used, and an error in logic in the calculation of number of frames skipped.Corrections to the problems were identified and implemented.

Unsupported Tools

An option was added in concat.c to save separation commands to an ASCII file. This can beuseful in preparation of separation scripts in host lab activities.



Processing Framework

D.133 (S. Campos-Neto, LMGT) contains an initial proposal of a processing framework for use inhost laboratory processing activities. The proposal organizes the processing in three layers ofscripts that go from an abstract level (“high level scripts”) to specific “low level” scripts. Theglue between high and low level scripts is performed by the middle level scripts, which translate themore abstract syntax of the high level scripts into the codec- and platform-specific syntaxes. D.133contains a hypothetical example.

D.133 was well received by Q10/16 experts, and there was agreement that this approach should beconsidered as a starting point to organize future host laboratory efforts. It was also agreed thatwhen developing such an approach, care must be taken in properly debugging the middle levelscripts in a first development stage, and the high-level scripts in the final deployment stage.

Software Tools User’s Manual

TD-15(3/16) is the editorially updated version of the STL2000 User’s Manual. Q10/16 agreed thatthe current version of the Manual should be made available as soon as possible, maybe with a caveaton its level of accuracy. It was suggested that the Manual be included either in the current STLdistribution or on the ITU website in a page logically connected to the G.191/STL2000. ThisManual is available for download from:

<ftp://ftp.ctd.comsat.com/pub/sg16/q10/stl2kman-2001-02-25.pdf>, or from<http://ties.itu.int/u/tsg16/sg16/wp3/q10/stl2kman-2001-02-25.pdf>

Synchronous Reset of G.729

D.147 (C. Lamblin, France Telecom) provides information on the advantages of resetting the G.729algorithm when the native VAD/DTX/CNG algorithm of G.729 Annex B is not used. AlthoughG.729 Annex B defines a VAD/DTX/CNG mechanism that is optimized for the G.729 CS-ACELPalgorithm, some applications require that a different algorithm be used, because of system orcomplexity constraints. In these cases, when a “non-native,” or “external,” VAD/DTX/CNGalgorithm is used, there is the possibility that the state of the encoder and decoder will differsignificantly, which will degrade quality. Hence, synchronous reset of the encoder and decoder canbe beneficial to the overall quality when such external VAD/DTX/CNG algorithms are used. Thisappendix deals with external synchronous reset capability in systems using externalVAD/DTX/CNG, such as CME (circuit multiplication equipment) in conjunction with G.729 mainbody, G729 Annex A, and G.729 Annex C.

TD-01(3/16) is a liaison from ITU-T SG15(2/15) thanking SG16 for their past cooperation on thesynchronous reset of G.728 and G.729 codecs in CME. It suggests that an informational sectionbe added to G.729.

After discussion, Q10/16 agreed to prepare an informative Appendix to G.729 with the availableinformation on synchronous reset for G.729. An editorial group convened, chaired by C. Lamblin(France Telecom). The outcome of the drafting group is G.729 draft Appendix I, Externalsynchronous reset performance for G.729 codecs in systems using external VAD/DTX/CNG (TD-31[3/16]). It was reviewed and approved by WP3 with the amendments found in TD-48(Plen).WP3 forwarded this text for Approval at this meeting.

Q10/16 approved a liaison (contained in TD-33[3/16]) to SG15 reporting their intent to prepare anAppendix to G.729 on the synchronous reset operation when external VADs are used.



Question 11/16 WP1, Voiceband Modems: Specification andPerformance Evaluation

Working Party 1/16 addressed Question 11 under the chairmanship of L. Brown (Conexant). TD-23(1/16) is the agenda. TD-43(1/16) is the meeting report. TD-26(1/16) is the report of theQ11/16 Rapporteurs January meeting in Las Vegas, Nevada. TD-25r1(1/16) is the report of theQ11/16 Rapporteurs April meeting in Nice, France.

It was reported that the following companies had previously indicated they may have intellectualproperty pertaining to V.moip: 3Com, Broadcom, Cisco, Conexant, Lucent, Nortel, SurfCommunication Solutions, and Texas Instruments. These companies were asked to submit theappropriate written IPR statement to the TSB before the Approval of V.moip. No further verbalIPR declarations were made at this meeting.

TD-01(1/16) is a liaison from SG15 concerning text telephone and V.34 fax transmission throughnetwork echo cancelers (see also the QH meeting report, above, for more information). Based ondiscussion of this liaison, it was agreed to prepare a Corrigendum to Recommendation V.25 (TD-35[1/16]) for Approval at this meeting, containing a note similar to the one recently added toRecommendation V.8 (Procedures for starting sessions of data transmission over the publicswitched telephone network). The V.25 Recommendation is titled, “Automatic answeringequipment and general procedures for automatic calling equipment on the general switchedtelephone network including procedures for disabling of echo control devices for both manuallyand automatically.” It was also agreed to work with Q14/16 and QH/16 to prepare a liaison replydetailing the actions taken by SG16. See the Joint Q11/14 meeting report, below.

TD-02(1/16) is a liaison from Q7/15 to SG12 and SG16. Q7/15, Functionality and InterfaceSpecifications for Transport Network Equipment for Interconnecting GSTN and IP Networks, isdeveloping new ITU-T Recommendation G.799.1, covering functionality, interfaces, performancerequirements and functional tests for voice gateways interfacing GSTN to IP networks. Q7/15seeks the guidance of SG16 concerning modem-over-IP matters. This was briefly presented inQ11/16 and also discussed in the joint sessions. TD-21(Gen) contains the Q2/Q11 liaisonresponse to Q7/16: SG16 plans to complete their work on proposed new Recommendation V.moipby their February 2002 meeting. Currently, the work is not sufficiently mature for SG16 to provideQ7/15 any guidance at this time. SG16 asks that Q7/15 send a follow-up liaison to the SG16February 2002 meeting.

TD-05(Gen) is a liaison from the Q9/7 Rapporteur (O. Dubuisson, France Télécom R&D)providing information on the ASN.1 module database. As part of the new SG7 ASN.1 Project,SG7 is establishing an electronic database (website) containing up-to-date, machine-processable(ASCII or UTF8 text) copies of all ASN.1 modules in ITU-T Recommendations. This is the firstof a number of initiatives of the ASN.1 Project that will enable better support by SG7 to other SGsusing or wishing to use ASN.1, its encoding control notation (ECN), its ability to generate XMLdocuments, and its ability to encode XML-defined data. See also TD-06(Gen) in the Plenaryreport for additional information.

TD-30r1(1/16) is the proposed Q11/16 liaison response thanking Q9/7 for the information aboutthe formation of Q9/7’s ASN.1 Project. Q11/16 advises Q9/7 that they have incorporated ASN.1for the definition of modem-managed objects in the recently approved Recommendation V.59, andalso in Annex A of Recommendation T.38.

TD-32(1/16) is the joint QH/11/14 liaison to SG15 on V.18 text telephone, V.34 fax, and other datamodem transmission issues. TD-42(1/16) is the final version of this liaison (see the QH meetingreport, above).



V.moip

TD-08(1/16) (K. Chu, Conexant, Editor) is the proposed skeleton document structure for V.moip.

TD-24(1/16) (L. Brown, Conexant, Rapporteur) is the issues list for V.moip; it is an update of TR-30.1/01-05-029 (same as PCM01-007R3). It includes issues raised and agreements reached at theMay 2001 TIA TR-30.1 meeting in Wilmington, Delaware, USA. It includes a new “CallDiscrimination” section, and some figures showing connection scenario types that are beingconsidered, as well as a preliminary comparison table. This list was approved with minor revision.TD-40(1/16) is an update of TD-24(1/16). The issues list also provides as an appendix thedescriptions of the different configurations discussed below.

D.113 (M. Garakani, Cisco) provides test results and discussion showing the impact of IPimpairments on voice and modem connections running in various configurations of VoIP/MoIPnetworks. It concludes that modem IP type 0 (end-to-end modulation) is the most sensitive topacket losses (tolerates 0.1% without redundancy). Modem IP type 1 (modulation only over PSTNlinks) is less sensitive to packet loss, but still shows significant degradation of throughput withinthe range of operability of G.711. SPRT-based schemes that can support V.MoIP types 2 through5 scenarios (which distribute HDLC, ARQ and data compression functions in different ways overthe PSTN and packet links) are least sensitive to IP impairments, and can operate within the rangeof impairments acceptable to voice codecs (with standard concealment techniques). D.113proposes that SPRT be adopted to handle V.MoIP scenarios 2 through 5, which would require areliable transport.

D.137 (K. Chu, Conexant Systems) provides test result data on end-to-end error correctionperformance through an IP network for various connection scenarios. During MoIP type 2b(unreliable data over the packet link) connections, IP packets contain single and complete V.42frames. During MoIP type 1 (unreliable data over the packet link) connections, IP packets maycontain multiple, partial, or multiple and partial V.42 frames. The loss of a single IP packet mayresult in the loss of multiple V.42 frames. The performance of MoIP type scenario 1a can at bestbe expected to equal MoIP type 2b and will probably be worse. D.137 concludes that support forconnection scenarios 1a and 2b should not be included in V.moip.

D.121 (J. Renkel, 3Com) discusses explicit flow control for V.moip; it proposes that all otherentities in an MoIP connection should respect explicit flow control (e.g., V.42 RNR [receiver notready]) from one modem. Specifically, the modem’s gateway, its remote gateway, and the remotemodem should all respect explicit flow control exerted by a modem.

D.141 (K. Chu, Conexant Systems) discusses flow control for non-controlled links. It providestwo mechanisms by which, if no protocol is negotiated between the gateway/modem pairs, thethroughput problem can be significantly mitigated:

1) After full data mode is established, the gateways examine the data rates and rate renegotiate (orretrain if necessary) such that the M1 transmit data rate is less than or equal to the M2 receivedata rate and the M2 transmit data rate is less than or equal to the M1 receive data rate.

2) Flow control between modems can be achieved by using rate renegotiations as a mechanism toslow down a remote transmitter.

Both of these techniques can be used either independently or together to mitigate the net effects ofno flow control. If no data compression is negotiated across the link, the simplest solution is tomaintain this status quo. There does not seem to be any additional advantage of adding



compression just for the gateway-to-gateway portion, and it only adds to the latency, which isagainst the intent for not enabling it in the first case.

D.122 (J. Renkel, 3Com) discusses the coding of the ANS and CM (defined in V.8) families ofsignals using IETF RFC 2833 (RTP Payload for DTMF Digits, Telephony Tones and TelephonySignals). RFC 2833 defines codings for these signals for use with RTP but does not address theissues involved in reliably detecting, coding, and regenerating these signals, which is necessary inMoIP operations. D.122 addresses these issues and proposes to minimize latency by encodingCM / JM / CJ messages not a bit at a time nor an entire message at a time, but rather a character(octet) at a time.

D.124 (J. Renkel, 3Com) discusses the automatic detection of analog modems and facsimilemachines. PCM01-021 (J. Renkel, 3Com, Q11&12/16 Rapporteurs, Nice, France, April 2001)outlines a procedure for how a call may be switched between VoIP, FoIP, and MoIP. Itrecommends that xoIP gateways start in VoIP mode and when modem/fax signals being sent inboth directions indicate that it is a modem or fax call, that the gateways switch from VoIP to MoIPor FoIP. D.124 explicitly defines the fax and modem signals to use, and when and how to switch.It proposes using RTP packets based partly on RFC 2833, but expanding on RFC 2833, which isincomplete. D.124 is roughly related to H.248 Annex F, which defines how fax and V.18 signalsmay be detected, but H.248 Annex F procedures are inadequate. The procedures defined in D.124will likely supersede those defined in H.248 Annex F. It was agreed to include these signals in themain body of the draft text for V.moip.

D.125 (J. Renkel, 3Com) proposes to limit the scope of the work on the first release of V.moip toinclude only connection scenarios 4 and 5, along with the already agreed fallback connectionscenario 0. Evidence was presented at the May meeting of TR-30.1 that there are performanceproblems with types 1, 2b, and 2c, which use V.42 over the entire PSTN-IP-PSTN session. Thereare also issues with how to reliably negotiate types 2a and 3.

D.139 (K. Chu, Conexant Systems) shows that significant simplification and other benefits can beachieved in all of the type 1 to type 5 MoIP connection scenarios if the constraint on the M1/G1and M2/G2 gateway/modem pairs to use the same modulation is removed. The benefits ofsupporting asymmetric modulations are improved throughput, maximized connection reliability,increased flexibility, and simplification of the procedures; these benefits are feasible. V.moipshould not mandate that the same modulation be used for the on-ramp and off-rampgateway/modem pairs.

D.140 (K. Chu, Conexant Systems) provides examples of type 4 scenarios in conjunction withallowing gateway/modem pairs to connect with dissimilar modulations. It supports the premise thatallowing the gateway/modem pairs to connect without the constraint of forcing the same modulationtypes simplifies the process of MoIP. The only constraint on this is the need to allow for end-to-end transfer of the end point modems’ V.8 call function and modulation code points. D.140depicts a consistent, three-phase method that accommodates MoIP as well as FoIP:

• Phase 1: voice mode. This is the native voice coded mode of the connection. The voice bearerchannel is configured to any of the allowable codecs.

• Phase 2: discrimination mode. On the detection of a non-voice type signal, the gateways enterthe MoIP discrimination mode. In this mode the gateways jointly or separately determine thetype of call after first interrupting the voice bearer channel. Once a call type is determined, thegateways transition into relay mode.

• Phase 3: relay mode. In this mode the call can then be one of three types: modem, facsimile orvoice. The result of this discrimination is for the gateways to switch to the appropriate mode ofoperation. For modem, it is the procedures that will be described in V.moip, for facsimile it will



be as defined in ITU-T T.38, and for voice it will reconnect back to the initial mode, restoring allchannel parameters.

Joint Q11/16 and WP2 Session

A joint Q11/16 and WP2 session was held to discuss IP transport protocol issues for V.moip andto develop a plan for progressing the work on defining a protocol. As a result of discussion on theabove contributions on V.moip and discussions in the joint Q11/16 and WP2 meeting, a few newissues were raised and agreements reached. These are included in the updated issues list (TD-40[1/16]).

Ad Hoc on MoIP Gateway Architecture

TD-39(1/16) contains the report of an ad hoc session (chaired by J. Renkel, 3Com) that discussedgateway architectures/functionality and its relationship to connection scenarios.

The ad hoc began with a short presentation of Section 1 of PCM01-017, Taxonomies of MoIPgateways and inter-gateway communications (J. Renkel, 3Com), originally presented to the Q11/16Rapporteurs April meeting in Nice, France. The ad hoc then agreed to enumerate functionalitiesand capabilities that would be required in MoIP gateways, categorizing the functionalities andcapabilities by MoIP scenario (and gateway position if the scenario is not symmetric) and gatewaylayer.

The ad hoc examined the functionalities and capabilities of the gateway types under considerationfor V.moip; it was seen that there is no difference between gateway framing layer functionalities andcapabilities for gateways that have identical ARQ layer functionalities and capabilities. It wastherefor agreed to combine the ARQ and framing layers into a single error control layer; and torecommend to Q11/16 that this combination be adopted in all further considerations of V.moip.

Next, in discussing gateway functionalities and capabilities, the ad hoc found it useful to organizean MoIP call into six phases. The phases and the events or conditions that mark the end of eachphase are as follows:

MoIP call phase Terminating event or conditionPre-establishment Call requestedEstablishment Audio path cut through in both directionsVoice 1st “modem-like” signal detectedDiscrimination MoIP scenario selectedTraining Both PSTN links in data transfer phaseData relay Call terminated

Then, in considering the data compression layer, the ad hoc identified and discussed the followingMoIP gateway data compression layer functionalities and capabilities. It was found useful toidentify the call phase in which the functionality or capability was used, and necessary to identifythe gateway type in which it was found (indicated enclosed in parentheses):

• Negotiate PSTN link data compression parameters, including compression algorithm(s)between gateways, during:– Pre-establishment, determine parameters (2a)– [Not at all] (3b, 3c)– Establishment through discrimination, exchange initial parameter values (4, 5L, 5R)– Training, notify other gateway of negotiated parameter values (4, 5L)



• Negotiate PSTN link data compression parameters, including compression algorithm(s)between one gateway and its connected modem, during:– Training, negotiate values (2a, 3b, 3c, 4, 5L, 5R)

• Pass frames through with no processing (2a, 5L)• Compress or decompress (or both) frames in one or both directions for one or both sides of the

connection, as appropriate to the scenario (3b, 3c, 4, 5R)

Finally, in considering the error control and modulation layers, the ad hoc found that all gatewaytypes have the same functionalities and capabilities in the error control and modulation layers.

The ad hoc formulated the following proposed MoIP issue agreements for presentation to Q11/16:

• In all remaining scenarios under consideration for V.moip, the ARQ and HDLC framing layersshall be combined into a single error control layer.

• V.moip shall not provide the capability to negotiate any error control layer parameters end-to-end. (Note: this requires gateways to, for example, possibly split frames received from the farmodem before transmission to the near modem in the case of unequal PSTN link error controlmaximum frame sizes.)

• V.moip shall recommend, in a note contained in the recommendation, that a gateway should, tominimize end-to-end latency, immediately and without delay forward to the other gatewayframes correctly received from its near modem.

• V.moip shall provide a mechanism for one gateway (“gateway A”) to request that the othergateway (“gateway B”) inform it (gateway A) of its (gateway B’s) PSTN link data signalingtransmit and receive rates upon initial determination of them and thereafter upon every changeof them.

• V.moip shall not mandate any action by a gateway upon notification of the other gateway’sPSTN link data signaling transmit and receive rates.

Q11/16 agreed to defer Approval of the ad hoc report until their next interim Rapporteurs meeting.

Joint Q11/Q14 Meeting

The joint Q11/Q14 meeting discussed the issue of commonalities within V.34 HDX in T.38 andV.34 MoIP. An ad hoc chaired by L. Brown (Conexant) convened to address this issue. Thefollowing guidelines for the ad hoc for harmonization with a focus on call discrimination wereagreed:

1) Hold a technical interchange to understand current FoIP and MoIP (COM 16-R2 Annex D,D.96, and D.134, may be of interest)

2) Define an architecture applicable for both applications3) The goal is to define a transition that is seamless

The ad hoc drew no conclusions at this meeting. This work will continue in future meetings ofQ11/16; Q14/16 experts were invited to attend.

In discussion of the liaison from SG15 on echo canceler issues (TD-01[1/16]), it was commentedthat a note has been added to V.8 concerning this issue (Note 7.2 of V.8 [2000]). The joint meetingalso agreed that it did not support mandating phase reversal at this time. It was agreed to add a noteto V.25 similar to that in V.8. It was not felt that such a note was needed in T.30 at this time. It ishoped that these notes will strongly encourage the use of phase reversals in Answer Tonetransmission for future equipment without mandating changes to existing equipment.



During review of the joint QH/11/14 response liaison to SG15 on echo canceler issues (TD-32[1/16]), the following sentence was added: “While the phase reversals were not made mandatoryfor support of V.34 FAX in T.30, it is noted that V.34 relies on V.8.” TD-42(1/16) is the finalversion of this liaison. See also the QH report above.

V.91, A Digital Modem Operating at 64 000 bit/s For Use on 4-Wire Circuits

TD-27(1/16) (L. Brown, Conexant) contains the proposed Corrigendum to Recommendation V.91;it was approved by SG16. See CSR 12.17 for details.

V.92, Enhancements to Recommendation V.90

TD-28(1/16) (L. Brown, Conexant) is draft 2 of the proposed Implementers Guide forRecommendation V.92.

D.116 (USA) proposes that a reason for denial be added to the modem-on-hold sequence,information bits field (Table 32/V.92). This reason for denial will convey to the modem thatsubsequent requests will be denied. This will avoid retrains or network disconnects, as the modemwill know not to place another modem-on-hold request during the current session. This featurewould give ISPs the ability to control the total (cumulative) on-hold time during a V.92 modemsession. The current V.92 modem-on-hold design does not provide a clean server-client handshaketo handle this feature properly. Tests have shown that a denial of a modem-on-hold request doesnot prevent the client modem from placing subsequent continuous requests. This procedure alsoapplies to the opposite case: server modem requesting a modem-on-hold event.

D.117 (A. Urquizo, Cisco) proposes that the current modem-on-hold procedure be clarified so a70 ± 5 ms silence period is transmitted before sending Tone RT (if present) followed by aninitiating MH sequence. It is unclear in the V.92 document whether a silence period shall precedethe initiation of a modem-on-hold event when generated by the user. The absence of this silenceperiod might make it hard for the responding modem to initially detect the Tone RT so as to replyto the request in a timely fashion.

It was agreed to produce an Amendment to Recommendation V.92 (TD-21r1[Plen]), instead of anImplementers Guide, containing the material from TD-28(1/16), D.116, and D.117. (TD-21r1[Plen] is enhanced TD-29[1/16].)

Based on discussion of these contributions, an issue was brought forward that may need resolutionat a future meeting. Specifically, if modem-on-hold is disabled, does the modem respond withMOH denied or does it not respond to the request for MOH?

D.135 (K. Chu, Conexant Systems) proposes a method for negotiating and communicating earlydata for V.34, V.90, and V.92. The method proposed is to use the V.92 SUV mechanism and adaptit to V.90 and V.34, providing a consistent method and implementation across the three modulationsproposed. There is no common reserved bit for V.34 MP, V.90 CP, and V.92 CPd, CPu, SUVd,and SUVu sequences to indicate early data. But each of these sequences contains enough reservedbits to accomplish the intended function, and the functionality is the same in all cases. Except forV.92 SUV sequences, one reserved bit is used to identify SUV sequences. In all cases one reservedbit is used to request early data (“User Data request”), and another is used to identify whetherearly data is present. After transmitting and receiving a SUV sequence with the “User Datarequest” bit set, early data sequences can be transmitted. D.135 proposes that 64 bits of user databe contained in each early data sequence as 4 16-bit words. In the case of legacy modems, thereshould be no confusion between MP and CP sequences on one hand and early-data relatedsequences on the other as the sequences are of different length.



D.126 (J. Magill, Lucent; Analog Devices, ESS Technologies, PCTel) opposes the definition ofearly data transmission in Recommendations V.34, V.90 and V.92, for the following reasons:

• Recommendations V.34, V.90, and V.92 are mature, and products complying with theseRecommendations are already widely used in the market

• The concept of early data was already considered during the discussions on V.92 and wasrejected

• The full benefit of early data is not clear: some relatively small reduction in the time to sendsome data at a low data rate is achieved at the expense of a delay in achieving the full data rate

• If it is clearly demonstrated that early transmission of data is important, then considerationshould be given to transmission of user data during V.8/V.8bis

• The addition of such features to these Recommendations would require extensive furtherinterworking testing involving considerable time and resources

• What will be the impact on error recovery processes?

After discussion, the four source companies of D.126 remained opposed to progressing this work.3Com, Cisco, and Panasonic would like to see test results before formulating an opinion. Conexantstated that they plan to bring a contribution addressing the benefits of early data to a future meeting.

V.59 (V.mmo), Modem Managed Objects

TD-09(1/16) (K. Chu, Conexant, Editor) contains the proposed Corrigendum to RecommendationV.59. See CSR 12.17 for details. This was approved by SG16. TD-20(Plen) contains the Editor’sclean version.

Other Q11/16 Highlights

The report of the April Rapporteurs meeting in Nice (TD-25[1/16]) (CSR 12.17) contains a requestto the SG16 Chair to write a letter to Administrations encouraging national standardization bodiesto consider updating their spectral limits to support V.92, and encouraging regulatory authorities toissue waivers for modem manufacturers in the interim. After discussion with the TSB and theSG16 Chair, Q11/16 prepared a Circular Letter (TD-35[Plen]) to be sent by the TSB to ITU-TMember States.

In addition to the planned Q11/16 meetings, TIA TR-30.1 will meet on the following (tentative)dates to progress the work on V.moip:

• Week of July 16, Baltimore, Maryland, USA• Week of September 17, California (tentative)• Week of December 3, Orlando, Florida (tentative)• Week of January 14 2002 (very tentative), location TBD

Question 12/16 WP1, DCE-DCE Protocols for the PSTN and ISDN

B. Pechey (UK), Rapporteur for Question 12, could not be present at this meeting; Working Party1/16 addressed Question 12 under the temporary chairmanship of K. Chu (Conexant). TD-15(1/16) is the draft agenda. TD-44r1(1/16) is the meeting report. TD-12(1/16) is the report of theQ12/16 Rapporteurs April meeting in Nice, France.

TD-03(1/16) is a liaison from Q13/7 on amendments to X.272 ( Data compression and privacyover frame relay networks). Previously, Q12/16 had asked that the two data compressionRecommendations, V.42.bis and V.44, be referenced in the text of X.272, and perhaps for V.44 to



be the default. Q13/7 notes they have investigated this matter and found that there are many otherdata compression standards already used in the market. Some implementations are already usingthe LZS algorithm as the default, which is reflected in X.272 and is backward compatible withimplementation agreement FRF.9 of the Frame Relay Forum. It is therefore not appropriate tochange the default to V.44. Q13/7 suggests that X.272 could be updated to include references toV.42.bis and V.44, but this would require numbers to be assigned and possibly also informativeappendices to show frame formats for implementation of these algorithms. Q13/7 is willing toconsider contributions on this at their next meeting.

Q12/16 considered this liaison at the April Rapporteurs meeting (CSR 12.17) and chose not torespond.

Data Compression

D.123 (J. Renkel, 3Com) proposes text to amend V.44 XID exchange procedures. In theNovember 2000 SG16 meeting, a paragraph was added to the V.44 Recommendation to clarify theprocedures to follow should one modem support XID negotiation and the other parameter modenegotiation. Unfortunately, that added text is incomplete and suggests a process that may be inviolation of the ITU-T V.42 protocol.

Q12/16 expressed some concerns about the clarity of the proposed text. The interested partiesagreed to collaborate on a mutually acceptable text to be added to a V.44 Implementers Guide, butwere unable to achieve an agreed text during the meeting. They agreed to continue their dialogueafter the meeting, toward producing a revised text for submission at the next Q12/16 meeting.

It was noted that an erratum document containing the typographical changes and clarifications to thepre-published version of V.44 was posted to the pre-published website. The Editor (N. King,Infineon) reported that the correction to an additional identified typographical error will beseamlessly incorporated into the erratum document by the TSB.

V.42 Channel for Remote Modem Management Information

TD-13(1/16) (B. Pechey, UK, Rapporteur) is the issues list for work on modem managementchannel. It was reviewed and approved as being representative of the agreements made thus far.

D.136 (L. Brown, Conexant) proposes a structure for a diagnostics channel under V.42 to be usedas a basis for work in this area. It presents a system level specification of a mechanism that enablesthe transfer of a secondary data stream between a server and a client modem. Q12/16 accepted thistext for use as the basis for future work on remote modem management information. The issueslist was updated (TD-36[1/16]) to reflect this agreement.

Further, it was noted that some attributes of V.59, as suggested by D.136 as the diagnosticinformation format, might need to be changed. The Rapporteur agreed to ask Q11/16 to examinewhat changes are necessary for V.59 to be made suitable for use in remote modem managementinformation.

Question 13/16 WP1, DTE-DCE Interfaces and Protocols

Working Party 1/16 addressed Question 13 under the chairmanship of K. Chu (Conexant). TD-16(1/16) is the agenda. TD-37r1(1/16) is the meeting report.



There were no Q13/16 interim meetings between the November 2000 and the May 2001 meetingsof SG16. A meeting was planned but cancelled due to a lack of contributions. This was reflectedin TD-11(1/16), the status report for Q13/16.

V.250 Supplement

With the approval of the new commands in the V.250 Implementers Guide, there was a need toupdate the V.250 Supplement 1. In accordance with the agreement from the last meeting, draft textfor a revised supplement was presented (TD-10, K. Chu, Conexant, Rapporteur). This text wasaccepted, and agreed to be forwarded for SG16 Approval (as TD-12[Plen]).

V.250, Serial Asynchronous Automatic Dialing and Control

D.120 (J. Renkel, 3Com) proposes amendment to the V.250 Implementers Guide V.44 defaultsettings. In creating the V.250 Implementers Guide, the ITU-T V.44 “default values” wereincorporated as the “Recommended default settings” without considering the different usage of theword “default.” The implication is that modems implementing the V.250 Implementers Guide willhave as a default max_codewords of 1024, resulting in poorer compression performance than couldotherwise be achieved. Q13/16 agreed that this proposed change to the +DS44 corrects theproblem; this was accepted as revised text to the description of the +DS44 command.

D.138 (L. Brown, Conexant) recommends that a connect message from a modem be modified tosupport early data and the market conditions that require “truth in advertising.” This connectmessage should contain an adjective, proposed here as “Expected,” to optionally appear with theconnect message. This option would be turned on by a command to be defined in a V.250 annex.In discussion, it was noted that if the early data mode were to be accepted, then it might be desirable,in principle, to consider a mechanism to report estimated signaling rates in a CONNECT message.No action was taken as this item is dependant upon the approval of early data mode. Furthermore,details of implementation and effects upon interoperability will also be necessary.

Q13/16 noted D.116, the addition approved by Q11/16 for indicating a reason to indicate a modem-on-hold denial in V.92. It was agreed that a new response to the +PMHR command is necessary tosupport this function in APCM DTE. This new response code was agreed and modification madeto the +PMHR command as documented in the V.250 Implementers Guide.

V.80, In-band DCE Control and Synchronous Data Modes for Asynchronous DTE

At the November SG16 meeting, it was proposed (D.58, A. Pitkämäki, Nokia) that threesynchronous data rates be added to Table 10/V.80 to support 3GPP video telephony using V.80(CSR 11.11). At that time, (then) Q7/16 agreed not to take action until the proposed changes couldbe reviewed with respect to existing implementations. Having received no concerns to the proposedchanges, (now) Q13/16 agreed to incorporate the proposed change to Table 10/V.80 as Amendment1 to V.80 (TD-13[Plen]).

V.250 Amendment

V.250 was last published in 1999 and significant changes have been made since then. Thesechanges were maintained within the V.250 Implementers Guide. It was agreed to move all of thesechanges into an Amendment 1 to V.250 (TD-34[Plen]), to withdraw the Implementers Guide, and torequest that V.250 be considered for re-publication at the next SG16 meeting.



Future Work

Additional V.250 command support may be necessary if requirements come from the V.moip andremote modem diagnostics work that has been undertaken in Q11/16 and Q12/16.

Question 14/16 WP1, Facsimile Terminals

Working Party 1 addressed Question 14 under the chairmanship of T. Geary (Conexant,Rapporteur). TD-17(1/16) is the draft agenda. TD-46(1/16) is the meeting report. TD-19(1/16) isthe Q14/16 status report.

T.30, Procedures for Document Facsimile Transmission in the General SwitchedTelephone Network

TD-21(1/16), Proposed corrigenda to T.30 (T. Geary, Conexant, Rapporteur) proposes thefollowing correction to the text of Recommendation T.30 to correct an error inadvertentlyintroduced during the last update:

In Figure A.1/T.30, Note 1 in the column headed FCF2, the second line shall be “1111 0001”.

This was agreed; it was presented (TD-30[Plen]) for Approval at the WP and SG meetings.

D.97 (Canon, Matsushita Electric, Oki Electric, Ricoh, Toshiba, CIAJ) proposes an amendment inT.30 to address color/gray-scale higher resolution communication. Recently, some manufacturerslaunched color facsimile equipment which conform to T.30 Annex E Recommendation into amarket. Most products transfer color documents that have a default value of resolution, or200x200pels/25.4mm. Sooner or later, color facsimile equipment that has a capability of highercolor resolution communication will be launched. In order to make sure of compatibleinterconnection between color facsimile equipment this proposes clarification of capabilitiesexpression using DIS/DTC bits related with higher resolutions in T.30 Recommendation. It wasagreed to include this change in Amendment 4 to T.30 for Approval at this meeting.

During the work to create the necessary documentation to support T.30 Amendment 4, it was notedthat the editor had not completed necessary, previously identified T.30 Amendment 2 editorial workrelative to the explicit enumeration of bits referred to by use of alpha characters as “placeholders.”Q14/16 emphasized the need for this information; the interim T.30 editor met and coordinated withmembers present to select and define the bits (by number) and enumerate the notes to support thepreviously agreed work. Q14/16 reviewed the work; there were no objections to the assignments asdefined. These changes and the changes agreed from TD-21(1/16) and D.97 are included in AnnexA of TD-46(1/16).

D.100 (L. McIntyre, Xerox) proposes amendment of reserved Recommendation T.30 Table 2DIS/DCS bit assignments to accommodate the proposed Amendment 1 of T.89. SG16 approvedT.30 Amendment 2, which includes assignment of three new bits designated as T.89, Applicationprofiles for Recommendation T.88, for negotiation of JBIG2 application profiles (000 = T.89 notused, plus seven other states). The meanings of four of the seven states of the associated bits wereassigned and the remaining three states were reserved for future use. D.100 proposes definition oftwo of the reserved values for Profiles 4 and 5. Q14/16 reviewed this and agreed that it wasappropriate to consider for Consent at this SG16 meeting. TD-38(Plen) is the complete documentfor T.30 Amendment 4 for Consent (per the A.8 procedure).



T.35, Procedure for the Allocation of ITU-T Defined Codes for Non-StandardFacilities

TD-05(1/16) (TSB) is a draft list of country or area codes for non-standard facilities in telematicservices. It is based on Annex A to Recommendation T.35 (February 2000), and incorporates thechanges of codes announced in the ITU Operational Bulletin, in accordance with the Paragraph 4“Disclosure of ITU-T defined codes” in Rec. T.35. After final review by this meeting, the TSBplans to publish this List as an Annex to the ITU Operational Bulletin and make it available on theTSB website: <http://www.itu.int/itu-t/inr/index.html>; it will replace the Annex A to Rec. T.35.

The Rapporteur prepared a revision to T.35 to re-define Annexes A and B to be Appendices 1 and 2(TD-33[Plen]). The purpose of this revision is to allow immediate approval of the addition of newcodes during any SG16 meeting. T.35 is used in many ITU Recommendations; there is nointention to change T.35 in any technical way, only to simplify the publication of updated codeassignment tables. Additionally, Appendix A is revised to reflect the latest code assignments.Q14/16 reviewed TD-33(Plen) in their closing session. There was consensus that it be presentedfor Determination by TAP at this meeting, but the German Administration asked that the followingcomments be included in the Q14/16 report:

The Administration of Germany objects to the Determination of ITU-T T.35 for the reasonsthat, a) to put the country codes into an informational part of the Recommendation increases thelevel of instability and uncertainty that is harmful both to Regulators and the Industry; b) thefrequency of change in the country codes does not justify any change in the current practice(i.e., T.35 with mandatory country codes and TAP).

T.37, Procedures for the Transfer of Facsimile Data via Store-and-Forward onthe Internet

TD-06(1/16) is a communication from the IETF FAX WG in response to concerns raised by SG16in their November 2000 communication on the Internet fax full mode (TD-64(1/15), Ifax Ad Hoc,SG16 Geneva, November, 2000). In response to SG16 concerns that FFPIM may no longer bediscussed in IETF, FAX WG notes that they have posted the new version (draft-ietf-fax-ffpim-01.txt.) to the IETF website. Addressing SG16 concerns that Item b) in Section 2, Response onfull mode, is insufficient for the ITU-T request, FAX WG notes that they have begun discussion.There are two internet drafts: 1) draft-maeda-faxwg-terminal-mode-goals-01.txt, and 2) draft-maeda-faxwg-terminal-mode-protocol-01.txt. They include almost the same proposal as the one inITU-T. With regard to adding it in the WG’s charter, some items under discussion could beagreed without modifying the WG’s charter. FAX WG is not sure that all of them can be included;this will depend on future discussion. TD-06(1/16) also includes a summary of FAX WG currentactivities related to T.37. Of note, an issue has been raised with regard to intellectual property in theuse of “TIFF” in TIFF-FX (RFC 2301). Also, the I-D draft-ietf-fax-implementers-guide-07.txt,which addresses implementation guidance for published RFCs, is at the final stage.

In their response communication to FAX WG (TD-38[1/16]), Q14/16 asks for a speedy andfavorable resolution to this intellectual property issue regarding TIFF. Q14/16 is concerned thatissuing of Draft Standard status to “draft-ietf-fax-tiff-fx-09.txt (revised RFC 2301)” is in doubt.RFC 2301 is a critical component of Recommendation T.37; it has been deployed in a significantnumber of Internet Fax products, with many more deployments planned. Q14/16 is pleased tolearn of FAX WG progress in development of the IETF Fax Implementers Guide. ITU-T plans toreference the Guide subsequent to the IETF issuing it as an Informational RFC.



T.38, Procedures for Real-time Group 3 Facsimile Communication over IPNetworks

TD-14(1/16) (D. Duehren, Brooktrout, Editor) proposes texts for the draft T.38 Amendment 4; itcomprises the following changes:

• The T.30 indicator is mandatory• Support for V.34 is added• Annex B is modified to clarify the TCP start-up• The ASN.1 text in Annex B is removed; a reference to H.245 v.7 replaces it• The T.38 version number is 2, and the table introduced in Amendment 3 is updated

Q14/16 agreed that V.34 HDX in T.38 be removed from this Amendment. It was agreed that theversion number should be incremented to version 2 because of the addition of the mandatory T.30indicator. The Editor prepared a revision of this text for Q14/16 review (TD-32[Plen]);subsequently, a few editorial and spelling corrections were identified and made. TD-32(Plen) wasagreed to be submitted for Consent (per A.8) at this meeting.

COM 16-R2 Annex D is the draft Amendment to Recommendation T.38 to support the use of V.34modulation.

D.96 (Canon, Matsushita, Oki, Ricoh, Toshiba) requests a clarification to the draft Amendment toRecommendation T.38 to support the use of V.34 modulation as contained in TD-49(Plen) fromthe November 2000 QFax1/16 ad hoc meeting. At that meeting, the phrase “Finish ControlChannel Handshake” was added to figures 5 – 8 in TD-49(Plen), but no descriptions to clarify thiswere included. Q14/16 agreed to defer action pending completion of call discriminationdiscussions for harmonization of V.34 HDX in T.38 and V.moip.

D.134 (K. Chu, Conexant) identifies several issues that need to be considered before the text forT.38 is submitted for A.8. The first, and primary, concern is that approval of the text in TD-49(Plen) will make MoIP and FoIP call-type discrimination by the gateways much more difficult.This text was constructed without any knowledge of the existence of MoIP. It is important forreasons of interoperability and inter-working that T.38 and V.MoIP utilize a common means todiscriminate call-types without interfering with each other. The text is incomplete; it is missing anumber of connection scenarios that are common in real facsimile applications. It does not specifythe amount of inevitable leakage of the ANSam signal transmitted by Facsimile terminal F2 beforethe voice path is broken, which is necessary, taking into account the time need to detect and validateANSam to avoid unnecessary voice interference. Also, the proposed text does not indicate what todo in the case where messages exchanged between the gateways either fail to arrive or are out oforder. Finally, the text does not include field trials and interoperability tests.

Q14/16 considered that the issues identified in D.134 fall into three categories, two related to V.34FDX and the third related to IP transport protocol. Q14/16 agreed to harmonize this work withQ11/16 on the call discrimination aspect of MoIP. It was agreed that the lack of field trials andinteroperability tests should be considered; Q14/16 strongly emphasized the importance of data toindicate the proof of concept for this work. The possibility was raised that there may beopportunity to reconsider IP protocols more optimal for use in T.38.

TD-33(1/16) is a liaison thanking Q9/7 for informing SG16 of the formation of their ASN.1Project. SG16 advises Q9/7 that they have incorporated ASN.1 for the definition of modem-managed objects in the recently approved Recommendation T.38.



In the interim to the February 2002 SG16 meeting, the Q14/16 work for V.34 HDX in T.38 willfocus on the call discrimination, messaging, and protocol, in conjunction with Q11/16 and possiblyQ2/16.

T.89, Application Profiles for Rec. T.88 - Lossy/Lossless Coding of Bi-levelImages for Facsimile Apparatus

D.101 (L. McIntyre, Xerox) proposes Amendment 1 of Recommendation T.89, defining twoadditional application profiles for JBIG2. These two new profiles accommodate enhancedArithmetic and Huffman-based JBIG2 functionality, such as lossy or lossless coding provisionsand halftone region coding with compression performance comparable to or somewhat better thanthat of JBIG1 (Rec. T.82 and T.85). Their definition is consistent with the designated future studyitems documented in Rec. T.89.

Q14/16 agreed to send a copy of D.101 (in TD-41[1/16]) to ISO/IEC to inform them of the statusand request their review. Q14/16 requested that D.101 be submitted for Consent (per A.8).Additionally, Q14/16 requested that TSB distribution for Last Call (LC) await conclusion of theISO/IEC July 9 - 13 2001 meeting to accommodate their review of D.101. Any ISO/IEC-recommended edits will be submitted to the TSB as a LC comment contribution.

T.870, Lossless and Near Lossless Compression of Continuous-Tone StillImages: Extensions

TD-04(1/16) is a draft liaison from ISO/IEC JTC1/SC29/WG1 on draft ITU-T T.800 (JPEG2000Part 1) and JPEG LS Extensions - Draft ITU-T T.870 – IPR status. TD-04(1/16) includesinformation on IPR holders and IPR relevance to JPEG 2000 Part 1. Q14/16 reviewed this; noaction was required.



SG16 Meeting Roster, May 28 – June 8, 2001, Porto Seguro, Brazil

Pierre-André Probst (SUI) SG16 ChairMitsuji Matsumoto (Japan) SG16 Vice Chair, WP1/16 ChairFederico Tosco (Italy) SG16 Vice Chair, WP2/16 ChairSimao F. Campos Neto (Brazil) SG16 Vice Chair, WP3/16 ChairJohn Magill (UK) SG16 Vice Chair, WP4/16 ChairMahmoud Wreikat (Jordan) SG16 Vice ChairFabio Bigi (ITU) SG16 Secretary

Host: Anatel, the Brazilian regulator, Porto Seguro, Bahia, Brazil

Austria Telekom Austria Klaus Sambor [email protected] Joanna Alencastro [email protected] Simao Campos-Neto [email protected] Luiz Fernando Ferreira [email protected] Raphael Garcia De Souza [email protected] Fabiano F. Mendes [email protected] Fabiano Naves Vieira [email protected] Ulisses Sousa Vilarinho [email protected] Albert Kamga [email protected] Tom Taylor [email protected] Mitel Daniel Amyot [email protected] Bin ChenChina Xiao Hui DaiChina Lin Tao Jiang [email protected] Xing Ming LiChina Zhengkun Mi [email protected] Guo Wen SongChina Aihua Wang [email protected] Wei Wang [email protected] Linjie ZhangChina Linhui ZhengFinland Jari Hagqvist [email protected] Jean Pierre Blin [email protected] Alcatel CIT Abdelkrim Moulehiawy [email protected] France Telecom François Bougant franç[email protected] France Telecom Jean-Emmanuel Chapron jeanemmanuel.chapron@francetelecom

.comFrance France Telecom Claude Lamblin [email protected] France Telecom Laurent Pose [email protected] Rolf Ruggeberg [email protected] Istvan Sebestyen [email protected] Deutsche Telekom Joachim Stegmann [email protected] HHI Thomas Wiegand [email protected] Infineon Technologies Neal King [email protected] Ramesh Kumar Siddharta [email protected] Ron Even [email protected] Silvain Schaffer [email protected] Oren Somekh [email protected] Massimo Amendola [email protected] Roberto Flaiani [email protected] TILAB Rosario Drogo De Iacovo [email protected]



Italy TILAB Federico Tosco [email protected] TSB Fabio Bigi [email protected] TSB Greg Jones [email protected] Mitsuji Matsumoto [email protected] Yushi Naito [email protected] Hiroyuki Ohno [email protected] Canon Oru Maeda [email protected] Canon Masanao Suzuki [email protected] Canon Yoshio Yoshiura [email protected] Matsushita Electric

IndustrialYoshinori Aoki [email protected]

Japan Matsushita ElectricIndustrial

Hiroyuki Ehara [email protected]

Japan Matsushita ElectricIndustrial

Yoshishiro Noguchi [email protected]

Japan NTT Hideaki Kimata [email protected] NTT Naoki Kobayashi [email protected] NTT Kazunori Mano [email protected] NTT DoCoMo Masashi Morioka [email protected] NTT DoCoMo Shahid Mr. Shoaib [email protected] NTT DoCoMo Takashi Suzuki [email protected] NTT DoCoMo Muhammad Tariq [email protected] Oki Electric Industry Satoshi Minono [email protected] Ricoh Hiroshi Tamura [email protected] Toshiba Ryuji Iwazaki [email protected] Waseda University Sakae Okubo [email protected] Mahmoud Wreikat [email protected] ETRI Seong-Ho Jeong [email protected] Samsung Electronics Bum Jun Kim [email protected] Enrique Diaz Ceron [email protected] Enrique Berrojalviz [email protected] L.M. Ericsson Peter Bloecher [email protected] L.M. Ericsson Christian Groves [email protected] L.M. Ericsson Marcello Pantaleo [email protected] L.M. Ericsson Richard Sjoberg [email protected] Swisscom Pierre-André Probst [email protected] John Magill [email protected] BT Paul Barrett [email protected] BT John Boucher [email protected] BT Mike Nilsson [email protected] BT Joseph Pointer [email protected] BT George Skorkowski [email protected] BT Christopher David Wilmot [email protected] Doc. Tech. Research

Laboratory EuropeAkira Atsuta [email protected]

USA Harold Folts [email protected] Paul Gatewood [email protected] Paul Jones [email protected] Granger Kelley [email protected] Stephen Perschau [email protected] Clifford Sayre [email protected] Alan Sharpley [email protected] David Thompson [email protected] 3Com Jim Renkel [email protected]



USA Avaya Glen Freundlich [email protected] Brooktrout Tech. David Duehren [email protected] Cisco Systems Animesh Patel [email protected] Cisco Systems Herbert Wildfeuer [email protected] Conexant Systems Les Brown [email protected] Conexant Systems Keith T. Chu [email protected] Conexant Systems Tom Geary [email protected] Conexant Systems Huan-Yu Su [email protected] Delta Info. Systems Gary Thom [email protected] ESS Technology Inc. Ping Dong [email protected] ESS Technology Inc. Hong Yao [email protected] Intel Paul K. Reddy [email protected] LMGT Suat Yeldener [email protected] Lucent Technologies Terry Anderson [email protected] Microsoft Gary Sullivan [email protected] PictureTel Patrick Luthi [email protected] Qualcomm Khaled El-Maleh [email protected] Sprint Corporation James Lord [email protected] Telcordia Tech. Angela Faber [email protected] Texas Instruments Vishu Viswanathan [email protected] WorldCom Robert Freilich [email protected] Xerox Lloyd McIntyre [email protected]



Acronym Definitions

3GPP Third Generation Partnership Project (ETSI)AAP Alternative Approval ProceduresABAC Aggregate Bearer Admission ControlABR Average Bit RateACELP Adaptive Code Excited Linear PredictionACM Address Complete MessageAMD AmendmentANS Answer ToneANSam Answer Tone, amplitude modulated (V.8)ANSI American National Standards InstituteAPCM Analog PCM ModemAPI Application Programming InterfaceARQ Automatic Repeat RequestASN Abstract Symbol NotationATM Asynchronous Transfer ModeAuF Authentication FunctionAVD Alternating Voice DataBER Bit Error RateBICC Bearer Independent Call ControlBRI Basic Rate InterfaceCBC Call Bearer ControlCIC Circuit Identifier CodeCJ CM terminatorCM Call MenuCME Communications Management EntityCN core networksCNG Comfort Noise GeneratorCRC Cyclic Redundancy CodeCS-ACELP Conjugate Structure ACELPCTM Cordless Terminal MobilityDCE Data Circuit terminating EquipmentDIS Digital Identification SignalDSR Distributed Speech RecognitionDSR Distributed Speech RecognitionDSV Distributed Speaker VerificationDTC Digital Transmit CommandDTE Data Terminal EquipmentDTMF Dual Tone Multi FrequencyDTX Discontinuous TransmissionECMA European Communications Manufacturers AssociationECN Encoding Control Notation (ASN.1)EDH Electronic Document HandlingETSI European Telecommunications Standards InstituteEV Embedded VBRFDX Full DuplexFECC Far End Camera ControlFFPIM Full-mode Facsimile Profile of Internet MailFPP Frames Per PacketFTP File Transfer ProtocolGEF Generic Extensibility FrameworkGII Global Information Infrastructure



GSTN General Switched Telephone Network (i.e., PSTN)HDLC High level Data Link ControlHDTV High Definition TelevisionHDX Half DuplexHLF Home Location FunctionHTTP HyperText Transport ProtocolIANA Internet Assigned Number AuthorityID IdentificationIE protocol discriminator Information ElementIEC International Electrotechnical CommissionIEEE Institute of Electrical and Electronic EngineersIEMS International Emergency Multimedia ServicesIEPS International Emergency Preference Scheme (ITU-T E.106 [2000])IETF Internet Engineering Task ForceIFA Informal FTP AreaIFTP Informal FTP areaIG Implementer’s GuideIMT International Mobile Telecommunications (IMT-2000)IMTC International Multimedia Teleconferencing ConsortiumIN Intelligent NetworkingIP Internet ProtocolIPR Intellectual Property RightsIPTD IP Packet Transfer DelayIS International Standard (ISO)ISDN Integrated Services Digital NetworkISO International Organization for StandardizationISP Internet Service ProviderISUP ISDN User PartITU International Telecommunication UnionITU-R ITU Radiocommunications SectorITU-T ITU Telecommunications SectorJBIG Joint Binary Image GroupJM Joint MenuJPEG Joint Photographics Expert GroupJTC Joint Technical CommitteeLRJ Location RejectLRQ Location RequestLS Lossless and near LosslessMegaco MEdia GAteway Control (IETF)MG Media GatewayMGC Media Gateway ControllerMM MultiMediaMMUSIC Multiparty Multimedia Session ControlMOH Modem on HoldMoIP Modem over Internet ProtocolMOPS Million Operations Per SecondMoU Memorandum of UnderstandingMP Modulation ParameterMP Multipoint Processor (H.323)MPEG Motion Picture Experts GroupMSC-VBR Multi-mode Source Controlled Variable Bit-RateMVV Multirate/VAD VBRng Next GenerationNGN Next Generation Network



PDU Protocol Data UnitPER Packed Encoding RulesPLMN Public Land Mobile NetworkPSNR Peak Signal to Noise RatioPSTN Public Switched Telephone NetworkQoS Quality of ServiceQP Quantization Parameter (H.262)RAS Registration, Administration, and StatusRFC Designation for an IETF StandardRT Remote TerminalRT Round TripRTCP Real-time Transport Control ProtocolRTP Real Time Transport Protocol (IETF)SA1 Systems Aspects - Services (3GPP Committee)SCN Switched Circuit NetworkSCTP Stream Control Transmission ProtocolSCV Specialized Codec VBRSDO Standards Development OrganizationSDP Session Description ProtocolSDPng SDP Next GenerationSG Study Group (ITU)SID Silence Insertion DescriptorSIGTRAN SIGnaling TRANsport (IETF)SIP Session Initiation Protocol (IETF)SLA Service Level AgreementSP Switchable-P [frames]SPNE Signal Processing Network EquipmentSPRT Simple Packet Relay TransportSQEG Speech Quality Expert GroupSS7 Signaling System 7SSG Special Study Group (ITU)STL Software Tool LibraryTAP Traditional Approval Process (ITU, via Resolution 1)TBD To be DeterminedTCP Transmission Control ProtocolTDM Time Division MultiplexTIA Telecommunications Industry AssociationTIFF-FX Tagged Image File Format-Fax (RFC 2301)TIPHON Telecommunications and Internet Protocol Harmonization Over Networks (ETSI

Project)TML Test ModelTMN Telecommunication Management NetworkToR Terms of ReferenceTPDU Transport Protocol Data Unit (X.224)TSAG Telecommunication Standardization Advisory Group (ITU)TSB Telecommunications Standardization Board (ITU)TSG Technical Specification GroupUDP User Datagram Protocol (IETF)UN/ECE United Nations Economic Commission for EuropeVAD Voice Activity DetectorVBR Variable Bit RateVLF Visitor Location FunctionVoIP Voice Over Internet ProtocolVPN Virtual Private Network



WG Working GroupWMOPS Weighted MOPSWP Working Party (ITU)XID eXchange IDentificationXML eXtended Markup LanguagexoIP FoIP, MoIP, VoIP

The CSR LibrarySubscribers may order copies of documents shown in boldface type from CommunicationsStandards Review, where not controlled. $50.00 for the first document in any order, $40.00for the second, and $25.00 for each additional document in any order. Volume discountsavailable. Please contact CSR.

Documents listed with © are controlled documents. These documents are not for sale, but wecan provide you with the author’s contact information. ITU and ETSI meeting documents arealso not for sale, but we can provide you with the author’s contact information.

We have a large library of standards work in process and can help you locate otherinformation you may need.

CSR recommends that you obtain published standards from Global Engineering Documents.Tel: 800 854-7179, +1 303 792-2181, Fax : +1 303 397-7935, http://global.ihs.com



Communications Standards Review Copyright Policy

Copying of individual articles/reports for distribution within an organization is not permitted, unlessthe user holds a multiple copy license from CSR. The single user electronic version may bemounted on a server whose access is restricted both to a single organization and to one user at atime. You are welcome to forward your single user electronic copy (deleting it on your system) toanother user in your organization. CSR offers an Intranet subscription which permits unlimitedcopies to the subscribing organization.

Year 2001 Standards Committee Meeting SchedulesPlease see the updated calendar at http://www.csrstds.com/mtgs.html.

Visit the CSR Web Pages: http://www.csrstds.comThe Web Pages include an on-line store (order subscriptions and reports), an updatedTelecom Acronym Definitions list, updated meeting schedules, background material ontelecom standards and CSR (the company), data sheets on both CSR technical journals, andmore.

Communications Standards Reviewregularly covers the following committee meetings:

TIA TR-30 Data Transmission Systems &Equipment

TR-41 User Premises Telephone EquipmentRequirements

ITU-T SG15 WP1 Network AccessSG15 WP2 Network Signal ProcessingSG16 Multimedia

ETSI AT Access and TerminalsTIPHON Voice over InternetTM6 Transmission & Multiplexing

DSL Forum xDSL, Access Technologies

Communications Standards Review (ISSN 1064-3907) reports are published within days after the relatedstandards meetings. Publisher: Elaine J. Baskin, Ph.D. Technical Editor: Ken Krechmer. Subscription Manager:Denise Hylen Lai. Copyright © 2001, Communications Standards Review. All rights reserved. Subscriptions:$795.00 per year worldwide, electronic format; $995.00 paper format. Corporate Intranet subscriptions (Corporatelicense for unlimited copies) are $2,150.00. Submit articles for consideration to: Communications StandardsReview, 757 Greer Road, Palo Alto, CA 94303-3024 USA. Tel: +1-650-856-9018. Fax: +1-650-856-6591.e-mail: [email protected]. Web: http://www.csrstds.com. 12643