COMMUNICATIONS STANDARDS REVIEW - Linda Hall Library · AVC-2196 , Transmitting Draft...

July 30, 2002 Vol. 13.26 Copyright © CSR 2002 1

COMMUNICATIONS STANDARDS

REVIEW

Volume 13, Number 26 July 30, 2002

REPORT OF SG 16 WP2 RAPPORTEURS MEETINGS: Q.D, Q.F, Q.G, Q.2,Q.3, Q.4 AND Q.5, JUNE 24 – 28, 2002, BRUGES, BELGIUM

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

SG16 WP2 Rapporteurs Meetings: Q.D, Q.F, Q.G, Q.2, Q.3, Q.4 and Q.5, June 24 – 28, 2002,Bruges, Belgium.......................................................................................................3

Question G/16, Security of Multimedia Systems and Services...................................................6H.235 Version 3, for AAP Consent......................................................................................7Security Topics, Including H.235.........................................................................................8Liaisons................................................................................................................................9Q.G/16 Work Program.......................................................................................................10

Question 2/16, MM over Packet Networks using H.323 Systems............................................10H.323-Series Implementer’s Guide....................................................................................12H.323 Annex O, Internet Protocols.....................................................................................13H.323 Annex P, Modem Relay...........................................................................................13Ad Hoc Meeting on Requirements for MSBs and Other H.245 Syntax.............................15H.225.0 Annex Gv2, Communication Between and Within Administrative Domains.........16H.460.Presence...................................................................................................................17H.460.4, Service Class Designations..................................................................................17H.460.6, Extended Fast Connect.........................................................................................18H.460.ReQuery..................................................................................................................18H.225.0v5, Call Signaling Protocols and Media Stream Packetization for Packet-Based

Multimedia Communication Systems.....................................................................19H.323v5, Packet-Based Multimedia Communications Systems..........................................21H.235, Security and Encryption for H-Series (H.323 and Other H.245-Based) Multimedia

Terminals................................................................................................................21Miscellaneous.....................................................................................................................22Q.2/16 Document Status.....................................................................................................23Q.2/16 MoIP ad hoc Meeting.............................................................................................23

Question 3/16, Infrastructure and Interoperability for Multimedia Over Packet Networks........24Liaisons..............................................................................................................................24H.248 Material for the Implementer’s Guide......................................................................24H.246 Annex C Material for the Implementer’s Guide.......................................................24H.245v9, Control Protocol for Multimedia Communication...............................................25H.248, Gateway Control Protocol.......................................................................................25H.248.11, Media Gateway Overload Control Package........................................................26H.248.16, Enhanced Digit Collection Packages..................................................................26H.248.17, Line Test Packages.............................................................................................26H.248.18, Profile Package..................................................................................................26

COMMUNICATIONS STANDARDS REVIEW

2 Vol. 13.26 Copyright © CSR 2002 July 30, 2002

Supplement x to H.248 Packages Guide.............................................................................27New Material......................................................................................................................27Future Q.3/16 Meetings......................................................................................................28Q.3/16 Work Program / Document Status..........................................................................28

Question 4/16, Video and Data Conferencing Using Internet-Supported Services....................29Q.4/16 Future Directions....................................................................................................29

Question 5/16, Mobility for Multimedia Systems and Services................................................30Q.5/16 Work Items.............................................................................................................30

SG16 Rapporteurs Meeting Roster, June 24 – 28, 2002, Bruges, Belgium...............................31Acronym Definitions......................................................................................................................32Communications Standards Review Copyright Policy....................................................................34

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.

Twelve Year CD: all CSR reports from 1990 through 2001 on one CD$2,400 to non-subscribers; subscribers receive a $200 discount for each year ofsubscription during 1990 – 2001

Quarterly CDs : 3 months of CSR reports on each CD, in an annual subscription$695 as a standalone subscription, $200 as an add-on to current subscriptions

Annual CDs: 12 months of CSR reports on a CD for each calendar year 1990 topresent

$695 to non-subscribers, $200 to current subscribers

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



REPORT OF SG16 WP2 RAPPORTEURS MEETINGS: Q.D, Q.F, Q.G, Q.2,Q.3, Q.4 AND Q.5, JUNE 24 – 28, 2002, BRUGES, BELGIUM

TD-01 is the meeting agenda and logistics of this meeting of MOST of the questions in WP2/16,Multimedia Platform and Interworking. TD-02 is the document list. Questions D, 4 and 5 did nothold individual meetings. Separate reports from Questions D (Interoperability of MultimediaSystems and Services) and F (Quality of Service and End-to-end Performance in MultimediaSystems) were not available.

AVD-2185, Response to Study Group 16 Liaison on Draft New Question Q.ets/16 for EmergencyTelecommunications Service (ETS) (SG4), welcomes receiving the new draft umbrella questionaddressing the development of global standards for an ETS to support recovery operations fromnatural and man-made disasters. It provides references to two proposed draft Recommendationswhich are in the early stages of development in SG4. Draft Recommendation M.ets<http://ties.itu.int/u/tsg4/sg4/td/020408/plen/T01-SG04-020408-TD-PLEN-0062!!MSW-E.doc>(TIES logon and password required) identifies the functional requirements of interchange of criticalmanagement information between service customers and service providers, and between serviceproviders in support of disaster recover operations. Draft Recommendation M.qos<http://ties.itu.int/u/tsg4/sg4/td/020408/plen/T01-SG04-020408-TD-PLEN-0065!!MSW-E.doc>(TIES logon and password required) identifies the functional requirements for interchange ofquality of service management information across the TMN X-interface between TMN domains.M.ets is scheduled for AAP consent in January 2003. M.qos is scheduled for AAP consent inOctober 2003.

AVD-2186, another liaison from SG4 in response to a SG16 liaison, also presents the same twodocuments in progress in SG4.

AVD-2190, International Emergency Services (SG11) is a liaison informing of SG11’s work onthe development of signaling requirements and protocol to support International EmergencyServices. SG11 is proceeding on the basis of the requirements as specified in E.106 (in particularthat no preemption in the international network is required) with some urgency for a short-termsolution application to the telephony service, as well as for a long-term solution. Work isprogressing on a proposed new parameter “International Emergency Priority Indication” to beused in the Initial Address Message in both ISUP and BICC. SG11’s intention is to publish thesignaling protocol to support the International Emergency Service as an amendment to the existingISUP protocols including ISUP 2000 and BICC CS2.

AVD-2227, Reply to the Liaison Statement on Draft New Question Q.ETS/16 on EmergencyTelecommunications Service (SG12), informs SG16 that some questions of SG12 could give somehelp in developing new Recommendations related to performance thresholds with respect toEmergency Telecommunications Service, and provides a table of SG12 activities.

TD-2182 (Working Party 1/4, Designations, Performance and Test Equipment) announces Consentof draft new Recommendation M.2301 (ex-M.23ip) - Performance Objectives and Procedures forProvisioning and Maintenance of IP-based Networks, and provides a copy for SG16 WP2. TD-29, the response, thanks Question 3/4 for their results achieved in the draft M.2301. It notes thatQ.F/16 intends to refer to values of the classes of service defined in Y.1541 and M.2301 ITU-TRecommendations in the H series Recommendations dealing with End to End QoS for Multimediaservices. Class 0 is of major interest when defining conversational services. Q.F also notes that, asfar as the network performance objectives are concerned, they didn’t see any reference to themeasuring period of the network performance objectives. This measuring period is of majorinterest for conversational services since burstiness behavior on the network performance may havea strong impact on the user perceived quality. The access network needs further consideration since



Q.F feels that the end-to-end objectives will be strongly weighted by the access network and by thecorporate networks for business customers. Comments and roadmap indications on this fieldwould be appreciated.

AVD-2187, Response to SG16 on Use of the CORBA in the TMN (WP 4/4, Geneva, 8 – 19 April2002), notes that WP 1/4, Questions 3/4 and WP2/4 Question 9/4 will consider WP2/16’squestions about IP QoS.

AVC-2196, Transmitting Draft Recommendation E.QSC For Information and Comment (ITU-TSG2 Q.2/2, Geneva, 7-16 May 2002), provides draft Recommendation E.QSC, Signaling ofProposed QoS Service Classes for IP-, ATM-, and ATM-Based Multiservice Networks (TD WP1-24), for SG16’s review and comment. QSCs (QoS Classes) are defined as aggregations ofindividual service classes. Instead of having per-class parameters being configured and propagatedon each network interface, classes are aggregated into QSCs having common per-QSC parameters(e.g., maximum bandwidth) to satisfy required performance levels. The main motivation for QSCsis to improve the scalability of QoS routing protocols by propagating information on a per-QSCbasis instead of on a per-class basis, and also to allow better bandwidth sharing between classes inthe same QSC. Recommendation E.QSC proposes to define a specific set of QSCs, and theirassociated signaling requirements, as follows:

a) Limit the number of QSCs to 6b) Generalize the notion of QSCs to include:i) DiffServ/queuing priority per-hop-behaviors (PHBs)

ii) QoS classes (e.g., as specified in [Y.1541])iii) Admission-control priority classesiv) Restoration priority classes at both the virtual path/label switched path and transport link

level

E.QSC proposes extensions to signaling protocols such as SIP and RSVP-TE to support signalingof QSCs within and across networks, consistent with the E.360 proposed means of signaling theseclasses across networks employing IP-, ATM-, and TDM-based routing technologies.

TD-31 is the response liaison to AVC-2196. SG16 Q.F intends to refer to values of the classes ofservice defined in Y.1541 and M.2301 ITU-T Recommendations in their H seriesRecommendations dealing with End to End QoS for Multimedia services. Class 0 is of majorinterest when defining conversational services. As far as the network performance objectives areconcerned, Q.F didn’t see any reference to the measuring period of the network performanceobjectives. This measuring period is of major interest for conversational services since burstinessbehavior on the network performance may have a strong impact on the user perceived quality. Forinstance, burst of packets losses often lead to clipping effect on the audio and jerky pictures forvideoconference since Q.F uses UDP for the audio and video streams. Retransmission of themissing packets is not used for the conversational streams since this would lead to extra delays.The access network needs further consideration since the end-to-end objectives will be stronglyweighted by the access network and by the corporate networks for business customers. There is noITU-T Recommendation or other standard available for the time being on packet access networkperformance objectives. When Voice over IP and PSTN/ISDN are used simultaneously, the delaysadded by the gateway should be taken into account in the end-to-end delay budget. The previousitems point out only one part of the complexity, which is addressed by draft E.QSC. The othertopics of the Q.2/2 document widen the scope. However, the intended services targeted by the draftE.QSC don’t appear explicitly even if signaling indicates that telephony is one of the objectives.

As far as the Emergency Telecommunications Services are concerned, SG16 has drafted F.706ITU-T Recommendation that is the service description. However, the protocols and the QoSparameter objectives for this ETS are not ready yet.



The above considerations show that the draft E.QSC needs extra clear indications on these topics.If the scope of E.QSC is to allow the use of various high speed transport connections forsimultaneous telephony service and data transfers, clear statements should be added to avoidmisleading understanding or, even worse, strong disappointment of the customers. At least, if Q.2/2intends to start the approval process, the addition of provisional limits (by number of occurrencesfor a given time and number of packet loss par occurrence) on bursts of packet losses is highlyrecommended.

AVC-2226, Response to liaison requesting information on QoS thresholds for EmergencyTelecommunications Service degradation (SG12), notes that in terms of thresholds of QoS for thethree traffic classes defined in H.priority, at this time SG12 can only offer material on QoSthresholds related to Class 2. For this case, specifically for a voice call, Study Group 12recommends a QoS threshold in terms of the Transmission Rating R (see Rec. G.109) no lowerthan R = 50 as providing quality acceptable for emergency purposes, regardless of the type ofimpairment. It should be noted that, depending on the specific type of impairment, values of Rlower than 50 may also provide usable voice quality for emergency purposes. For example, aconnection might have clear voice quality but a long transmission delay that would be intrusive inconversation. Such a connection might provide adequate communication in an emergency situationeven though it could have an R value of less than 50.

TD-32 is the response liaison from Q.F/16 noting similar issues as in the previous liaisonresponses. Q.F/16 didn’t see any reference to the measuring period of the network performanceobjectives. This measuring period is of major interest for conversational services since burstinessbehavior on the network performance may have a strong impact on the user perceived quality. Forinstance, burst of packets losses often lead to clipping effect on the audio and jerky pictures forvideoconference since Q.F uses UDP for the audio and video streams. Retransmission of themissing packets is not used for the conversational streams since this would lead to extra delays.Since the effect of burst of packet losses might have a strong impact on the perceived quality by theend user, Q.F would appreciate that SG12 start work on this field. There is no measuring perioddefined for the time being. A 1 second measuring period could be chosen. However, routermanufacturer might prefer a larger period such as 10 seconds for their implementation of MIBs.The effect of the number of bursts, measured on a per hour or a per day basis, is of a great interestfor Q.F/16 in H.priority. Q.F/16 would like to specify a maximum end-to-end number of burstsfor packets losses.

AVD-2228, Call for model submission for the assessment of voice transmission quality fromprotocol analysis information in IP networks (SG12), notes that a call for a model submission hasbeen produced. This model will work in conjunction with revised Recommendation P.561consented on May 31, 2002 by Study Group 12. The response, TD-33, was sent from Q.F/16. Itnotes that Q.F/16 intends to refer to the results of the SG12 work and to values of the classes ofservice defined in Y.1541 and M.2301 ITU-T Recommendations in SG16’s H seriesRecommendations dealing with End-to-End QoS for Multimedia services.

AVD-2229, Cooperation on measurement/monitoring of end-to-end Quality (SG12), notes thatITU-T Study Group 12 has produced a number of Recommendations with respect to subjective andobjective end-to-end quality measurement techniques. These Recommendations have been used byother ITU-T Study Groups and are well accepted in the market. In some cases, however,measurements were performed without consideration of the complete technical context, andconsequently the results were misleading. This may cause confusion across the ITU-T includingthe use of recommendations of other Study Groups. Study Group 12 is currently consideringwhether these risks of misuse of measurement techniques and misinterpretation of results can beminimized by taking joint effort with other Study Groups involved in these subjects. Therefore it is



requested of each involved Study Group to identify and to communicate those measurement issuesthat can best be resolved by joint activities.

AVD-2180, Liaison statement on the User Requirements Notation - URN (SG17), contains alanguage for capturing and analyzing user requirements, which is being standardized as Z.150(User Requirements Notation), Z.151, Z.152 and Z.153. Z.150 presents general requirements andcontext for URN, Z.151 focuses on URN for Non-Functional Requirements (URN-NFR), Z.152on URN for Functional Requirements (URN-FR), and Z.153 on a methodological approach(including the relationships between URN-NFR and URN-FR, and between URN and otherlanguages defined in the SG 17 family of languages). URN might be useful for the requirementscapture work of Q.4 and other Questions. TD-24 is the short response of acknowledgement,indicating that the SG16 Rapporteurs groups have received this liaison, and expect to comment atthe next SG16 meeting in October.

AVD-2184 (SG4) announces that the telecommunications Markup Language (tML) Frameworkdocument M.3030 has been approved for Consent under the Alternative Approval Process (AAP) atthe plenary of ITU-T SG-4 on 19 April 2002. The draft tML Recommendation M.3030 is aFramework containing Rules, Guidelines, and Objectives for developing telecommunicationsindustry standard tML-based WorldWide Web Consortium (W3C) Schemas for operations,administration, maintenance, and provisioning (OAM&P) applications. The tML language is anapplication of the W3C XML 1.0 (Second Edition) Recommendation. Also included in theM.3030 tML Framework are procedures to develop new telecommunications vocabularies and touse/reuse existing vocabularies. ITU-T SG4 also approved generic procedures, the documentexchange basis, and the qualifying criteria for the communications process between ITU-T andW3C, including making references to W3C Recommendations in any ITU-T draftRecommendations, including M.3030.

AVD-2188, SG4 Report and Request in its role as Lead SG on TMN (SG4), requests updates oninformation in SG16 related to TMN. It also contains the report of the most recent TMN PMT(Project Management Team) meetings. The reply liaison is in TD-25. It was uncertain whether thework that SG16 has done on MIBs is of interest to SG4. However, TD-25 details the work onH.341v2, H.341 MIB, and the H.248/Megaco MIB. SG4 can decide whether or not they willinclude these recommendations in their tables.

Question G/16, Security of Multimedia Systems and Services

M. Euchner (Siemens, Germany) is the Q.G/16 Rapporteur. TD-12 is the Q.G/16 meeting report.TD-05 is the meeting agenda. The goals of the meeting were to:

• Progress work on H.235v3 (Security and encryption for H-Series [H.323 and other H.245-based] multimedia terminals)

• Progress work on MM emergency security H.SETS• Progress work on H.235 Annex C/ H.324 security

AVD-2216, Final Report Multimedia Convergence (IPCablecom / MEDIACOM 2004 /Interactivity in Multimedia), March 12-15, 2002, Geneva (Rapporteur Q.G/16), was presented forinformation from the Q.F and Q.G perspective. This report notes the emerging popularity ofBroadcast-based Multimedia (BMM) which is a commercially available service in Europe, Japanand North America as part of regular broadcasting operations. In Europe all the BMM services areinvariably based on Digital Video Broadcasting (DVB) technology. Regarding lawful interceptiondevelopment, it was commented that national security concerns should be considered in handlingthe results.



TD-20, Results of the 3rd meeting of ITU-T TSAG (Sharp Corp.), reports on the outcome of therecent TSAG meeting; the organization of security and its relationship with SG17 was one of theissues. ITU reform discussions are continuing and proposals for a more project-orientedorganization, moving away from the current technology oriented structure, were made by Japan andChina.

TD-21, ITU Workshop on Creating Trust in Critical Network Infrastructures - Chairman’s Report(May 20-22, 2002, South Korea), was presented for information. It includes a tutorial on nationalinfrastructure protection issues from Dr. B. Hancock, Vice President, Security of Exodus, thebackbone provider group within Cable and Wireless.

TD-22, Joint Security Session - ITU-T SG16 Q.G - ETSI TIPHON WG8 (Rapporteur Q.G/16),reports on the joint session between Q.G and ETSI TIPHON WG8 (also see report in CSR13.24). The current security activities in both groups were identified and issues of joint interestwere identified. Issues of joint interest include:

• Lawful Interception: TIPHON is working on an “Interception profile for H.323” (will be madeavailable when stable).

• Security Profiles within TIPHON will be updated.• Security Interworking H.323-SIP and H.323-Cablecom.• Emergency Telecommunications Services Security: speedy authentication of users is important.

Assuming authorization of WG8 by SG17, TIPHON will develop a general architecture withrecommendations for the authentication issues. This should guide other groups inincorporating ETS into their work.

• Advanced Encryption Standard (AES): it was mentioned that 3GPP-SA3 has considered AESusage and deployment (establishing AES, applicability of AES in 3G).

• Kerberos: WG8 has already considered this issue. Their findings are roughly that Kerberosmight be suited to handle the authorization issue but it is believed to provide only “weak”authentication. However, there are barely any other available alternatives. TIPHON WG8 isconsidering work on something improved.

• WG8 seeks input from Q.G regarding H.530 and the keying mechanisms (Draft H.235v3).

H.235 Version 3, for AAP Consent

AVD-2217, DTMF Encryption, (jointly with Q.G, Q.2, Q.3) (M. Euchner, Siemens AG), describesextensions to H.245 (Control Protocol for multimedia communication) and H.235 allowingencrypting out-of-band H.245 DTMF. It was asked if this feature comprehensively covers all e-commerce applications. The main use cases for this features are solely secure signaling of userDTMF pins or e-payment through the VoIP phone with credit card numbers or VoIP-telebanking,but secure e-commerce might demand more comprehensive security framework than this singlefeature.

It was pointed out that the current character set does not support national special characters such asaccents; the ISO Unicode character set would allow this. Contributions are needed for suchextensions.

The author should consult with the H.245 editor to clarify the purpose ofUserInputSupportIndication. The 1st bullet in section 8.7 should be corrected toencryptedAlphanumeric.

The contribution was accepted to be part of H.245v9 and H.235v3 (see also the Q.3 report, below).



AVD-2218, Enhanced Output Feed Back (EOFB) mode in H.235v3, (jointly with G, 2, 3) (EditorH.235), provides text for the OFB mode that is enhanced by a salting key and features an implicitpacket index for computing the IV. A question was raised how OFB relates to SRTP, as both arestream ciphers and what the value of OFB is against SRTP. This should be clarified. Some furtherclarification might be necessary with Avaya regarding the use of a counter-based IV. Technicaleditor’s note: See APC-1904, CSR 11.08, for background information on OFB.

AVD-2221, Improved Diffie-Hellman Signaling (Editor H.235), provides some clarifying text forthe Diffie-Hellman Operation and describes some flexibility for various signaling purposes. Onecomment was made regarding the use of “shall” in an appendix, as this indicates more mandatoryintention. It should be considered if the text could be moved into the main body of H.235. Anothercomment asked for the source of the prime number; they originate from the Internet KeyExchange/OAKLEY Key Determination Protocol, RFCs 2409 and 2412, but the reference shouldbe checked.

AVD-2219, Improved Key Transport in H.235v3 (Editor H.235), identifies a weakness in thesession key transport mechanism of H.235. As an improvement, an alternative session keytransport is proposed that does not face the weakness and supports secure transmission of a saltingkey. All Version 3 or higher H.235 systems should use the new key transport, if applicable. It wasagreed to rename NewKeySyncMaterial as V3KeySyncMaterial.

AVD-2220, Secure Fast Start Clarifications in H.235v3, (jointly with Q.G, Q.2, Q.3) (SiemensAG), clarifies the use of fast start security in a new section by re-using text from various places.No comments have been received; further review of the section appears useful.

AVD-2208, H.323 Implementer’s Guide Update (jointly with Q.2) (Editor IG), contains technicaland editorial changes to the H.323 Implementer’s Guide. The section numbers listed herein referto the section numbers in the Implementer’s Guide. Sections 6.1 and 6.5 convey security-relatedchanges. See the Q.2 report, below. Additional comments:

6.5.11: the change should be “H.245 control channel”6.5.12: the section does not show the change mark (“S”->“N”)

AVD-2222, Draft H.235 Version 3 - Security and Encryption For H-Series (H.323 and OtherH.245-Based) Multimedia Terminals (Editor H.235), is the updated draft. It was presented with thechanges made against the previous version; more editorial work is needed.

AVD-2243, Considerations for discussion on fast start-based security capability negotiation)(jointly with Q.G, Q.2, Q.3) (Siemens AG), addresses the issue of security capability negotiationduring fast start. Fast start by its nature has to map the H.245 OLC signaling with its phases ontothe call signaling handshake (i.e. SETUP and corresponding response). As such, some simplifyingassumptions are made (callee behaves as being assigned the master role), but also by sometweaking of the terminal capability signaling, especially for early media. Different from normalH.245 terminal capability negotiations where the caller offers a set of capabilities and the calleeselects an appropriate choice, fast start additionally opens one temporary logical channel for eachpotential capability. The callee may immediately use the desired one channel for early media andadditionally signals back the chosen capability. The problem is: each potential capability canbecome a very large number in future backward compatible systems. This document sketches someideas of how to potentially leverage the situation. It was presented to stimulate further thinking.

Security Topics, Including H.235

AVD-2223, Considerations for SRTP integration into H.235v3 (jointly with Q.G, Q.2, Q.3)(Siemens AG), provides some considerations on how to deploy SRTP from H.235. It considers



the IETF secure real time transport protocol (SRTP) for usage from within H.235v3, and identifiesthe SRTP capabilities in terms of an “abstract API.” Proposals are made for simplification andmapping the features to an H.323 environment with H.235, H.225.0 and H.245 signalingprocedures.

AVD-2224, New draft H.235 Annex G, Secure Real Time Transport Protocol Security Profile(SRTP) (jointly with Q.G, Q.2, Q.3) (Siemens AG), features an initial new draft Annex G forSRTP deployment by H.235.

It was asked if this profile overlaps with other profiles, or if it is mutually exclusive. Annex G isseen as a complement to the existing profile, but has some functional overlap with the voiceencryption (Annex D.7). The profile notion was felt to be confusing, as Annex G is not actually aprofile of the H.235 security features.

Some discussion addressed whether to make this work part of H.235, make it a separaterecommendation or to leave it as an annex. Leaving it as an annex was found acceptable, but theremight be a possibility to make that part into H.235v4 at some point, when it is considered stable.

It was further noted that the annex should make clear how it is used as a tool in the H.235 system.The number of keys was questioned and has to be adjusted (e.g., Annex G does not yet reflect thatRTCP is actually bi-directional even for a unidirectional media channel; and that for a full duplexmedia channel the RTCP is shared in both directions). Further comment was to consider other keymanagement systems (e.g., RSA-based).

Siemens volunteered to progress Annex G as editor.

Other issues related to security were discussed with Q.2/16, please see the Q.2/16 report, below.

Liaisons

Four liaisons were received from SG17:

AVD-2176, Liaison Statement on Multimodality and Multimediality - Ref: A morphological modelfor multi-sensory technologies and coherence in security (SG17/Q.10), requests collaboration inthe present standardization process of new “telebiometric” technologies. Help is needed indefining human factors in relation to terminals. Q.10/17 is in the process of generating systematictaxonomy of Telecommunication Biometric Devices to be used in Telecommunications, e.g.,Authentication, Telemedecine, e-Commerce, m-Commerce and TeleBanking. The response iscontained in TD-27. It was also suggested to involve G. Hellström’s Question H/16, on UserAccessibility.

AVD-2177, Response to Liaison Statement to ITU-T Study Groups on TelecommunicationReliability and Security (jointly with Q.ETS) (SG17), notes that Q.10/17 intends to start the studyof security for emergency telecommunications services. Through the study, they will find thesecurity issues related to multimedia communication systems on emergency telecommunicationsservices, and would like to address them in the cooperation with Q.G/16. This liaison was noted.

AVD-2178, Response to Liaison Statement to draft new Question Q.ETS/16 on EmergencyTelecommunications Service (ETS) (jointly with all) (SG17), notes that Q.10/17, as the leadingquestion for security issues in SG17, would like to consider and provide contributions to SG16’sactivities for ETS from the following aspects of security:



1. To prevent the attacks on emergency telecommunications system2. Authentication for the entities related to ETS3. Other security issues related to ETS

Q.10/17 believes that a full collaborative effort between Q.ETS/16 and Q.10/17 must lead to thebetter activities that address issues for the emergency telecommunications. This liaison was noted.

AVD-2179, Liaison on the Compendia of Communication Systems Security (jointly with Q.G, Qs.1-3/16) (SG17), thanks all the SGs for all of the replies given on the request for consideration ofthe Catalogue on ITU-T Recommendations related to Communication Systems Security (CSS) andon the Compendium of ITU-T approved security definitions, and particularly SG16, for theirdetailed advice. The Compendium is available at <http://www.itu.int/ITU-T/studygroups/com17/cssecurity.html> This liaison was noted.

Q.G/16 Work Program

Recommendation ApprovalExpected

Editor

H.235v3 10/2002 M. Euchner (Siemens AG)H.235 Annex G, SRTP Security 6/2003 M. Euchner (Siemens AG)H.324 security enhancements & H.235 Annex C ?? ??H.SETS (Security for ETS) ?? I. Brown (NCS)

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

P. Jones (Cisco Systems) is the Q.2/16 Rapporteur. TD-13a is the report of the Q.2/16 meeting;TD-06 is the agenda. The objectives of this meeting included review of items proposed for theH.323-series Implementer’s Guide, and progress in the following areas:

• H.323 Annex N (QoS) - no contributions received• H.323 Annex O (I-net protocols)• H.323 Annex P (Modem Relay)• H.225.0 Annex Gv2 (Communication between multimedia elements)• H.460. (Presence)• H.460.4 (Service Class Designations)• H.460.5 (Multiple Q.931 IEs) - no contributions received• H.460.6 (Extended Fast Connect)• H.460 (ReQuery)• H.460 (QoSMon) - no contributions received• H.323 Annex I (Packet based MM telephony over error prone channels) - no contributions

received• H.225.0v5 (Call signaling protocols and media stream packetization)• H.323v5 (Packet-based multimedia communications systems)

AVD-2175, Proposed New Question on “Syntax language for the support of PSTN/ISDNservices within IP session control protocols” (SG11), notes that this new Question aims to create anew MIME part to SIP messages that will carry a textual encoding of ISUP, or more precisely, anabstraction of ISUP, of sorts. This Question will attempt to address national ISUP variants andencompass fields from those variants. It was noted that the text of the proposed question reads“The major focus of this question is to develop specifications, which define the syntax language tobe used to support the PSTN/ISDN services not supported in SIP.” Q.2/16 should inquire aboutits applicability to H.323.



TD-23 is the reply liaison. It requests that they keep SG16 informed of their work on this as itmoves forward, and asks that they also keep in mind the requirements of H.323 in their definitionof the work to be done.

AVD-2181 (ITU-R Working Party 6M) provides the sixth revision of the working document fordiagrammatic interrelations (between ITU-R and ITU-T, particularly ITU-T SG9 J series) ofRecommendations for interactive broadcasting services and their summaries. This information wasreviewed, but no response was felt necessary.

AVD-2189, Progress of the discussion on generic end-to-end QoS service requirements (SG11),notes that a fundamental topic of discussion was raised as to whether the protocol mechanism forend-to-end QoS service control should be based on QoS classes and/or QoS parameters. SG11acknowledges the view of favoring the use of a limited number of QoS classes rather than QoSparameter values, based on the considerations provided in the different liaison responses. Alsofrom a BICC protocol perspective, SG11 is considering solutions for end-to-end QoS support forthe interworking between BICC networks and other networks like SIP and H.323. They see majoradvantages in using the QoS class approach for end-to-end QoS service control rather than the useof QoS parameters. Consequently, the studies in SG11 on protocol support for end-to-end QoSservice control in BICC will proceed based on the transfer of a limited set of QoS classes.

TD-30 is a liaison in response to SG11 and also to SG12 and SG13. It notes that Q.F/16 intendsto refer to values of the classes of service defined in Y.1541 and M.2301 ITU-T Recommendationsin the H series Recommendations dealing with End to End QoS for Multimedia services. Class 0 isof major interest when defining conversational services.

AVD-2192, Channel multiplexing protocol for IP-CME application - G.769/Y.1242 (SG15), notesthat first version of new ITU-T Recommendation G.769/Y.1242 (ex G.ipcme), coveringfunctionality, interfaces and performance requirements for circuit multiplication equipmentoptimized for IP-based networks was put forward for consent at the SG15 April-May 2002meeting; the channel multiplication protocol can be found in clause 8.7.1. A new Simple AudioMultiplexing Protocol in order to solve the problem of multiplexing different telephony servicesover same multiplex structure is newly proposed, and Q.5/15 agreed to start the evaluation of thisproposal as one of the potential candidate for future enhancement of G.769. Comments wererequested. No response was felt necessary at this time.

AVD-2193 (SG15) provides a proposal for the transport of IPv6 Jumbo Frames, and requestscomments as to the suitability and requirement for the transport of such frames and considerationof what service level parameters are required for such transport. It was agreed among the expertsthat, at this time, SG16 does not have an application for Jumbo frames within its systems. It wasagreed to send a reply indicating this, in TD-26a.

AVD-2194 (SG15) provides the current versions of the Access Network Transport (ANT)Standardization Plan and Work Plan, and requests comments. It was noted.

AVD-2197, Liaison Statement on Terrestrial Wireless Interactive Multimedia (TWIM)Applications (ITU-R JTG 1-6-8-9), provides the draft Conference Preparatory Meeting textdeveloped at the May 2002 meeting, for information.

AVD-2225, Revision of ITU-T Recommendation G.114 (SG12), notes that SG12 will reviseRecommendation G.114, One-way transmission time, in order to provide clear guidance on theeffects of transmission time with respect to end-to-end speech quality. The revisedRecommendation G.114 will be applicable to a mouth-to-ear scenario. The previously given hardlimits will be removed, but will be substituted by a curve based on E-Model (Recommendation



G.107) results. This curve will provide information on the effects of transmission time on theresulting speech quality in the absence of echo.

H.323-Series Implementer’s Guide

AVD-2200, Additions to Q.931 timers usage in H.225.0 (RADVision), notes the omission ofdescription of several Q.931 timers in H.225.0, and proposes to add the description of those timersto section 7.5 of H.225.0. It was agreed to add this material to the H.323-Series IG, except that theword “shall” will be replaced with “should” in reference to requiring the implementation of thetimers. However, a note shall also be inserted into the IG to indicate that these timers shall bemandatory in H.225.0v5.

AVD-2202, Technical corrections relating to progress indicator in Recommendation H.225.0(NTT), proposes that the technical corrections relating to carrying multiple progress indicatorinformation elements in same message be defined in Recommendation of H.225. There was aconcern that accepting these changes would potentially break backward compatibility. It waspointed out that H.460.5 can carry multiple IEs of the same type and could be used to resolve thisissue.

The contributor pointed out that the text in H.246 Annex C ( ISDN User Part Function - H.225.0Interworking) conflicts with H.225.0, as it says that multiple IEs may exist. It was proposed tochange Annex C so that it uses H.460.5. However, such a change would require Annex C to beimplemented only with H.323v4 entities. The Editor of H.246 Annex C seconded the proposal thatwe should update Annex C to reference H.460.5 as the means of carrying the additional IEs.

The contributor agreed that the group should follow the recommendation of the Editor.

AVD-2205, Clarifications and minor enhancements to H.323 Annex R, Robustness Methods forH.323 Entities (S. Gogineni, Cisco), notes that in the current form, H.323 Annex R could lead tosome ambiguity; without some needed enhancements/clarifications, it could be difficult orimpossible to implement. For example, the robustness methods were described for a Gatekeeperentity that participates in GKRCS and are somewhat lacking in areas of endpoint robustness. Somespecific issues are addressed either ambiguously or incompletely in the current form of thespecification. Ten proposals to be included in H.323 implementer’s guide are given. Most of theseproposals were accepted.

AVD-2206, Clarification to the H.323 Annex E protocol (V. Kakkar, Cisco), notes that thespecifics on the usage of Annex E well-known port or the advertised port need clarification. Threeproposals were made which were accepted with some changes.

AVD-2208, H.323 Series Implementer’s Guide Update (Editor), provides technical and editorialchanges to the H.323 Implementer’s Guide. The section numbers listed refer to the sectionnumbers in the Implementer’s Guide. The following were included:Section 6.1 (H.323 corrections): Change the word “exclude” to “preclude”.Section 6.5 (H.235 corrections): Say “H.245 Control Channel”, rather than H.245 channel.Section 6.1.8 (Clarification of Endpoint Unregistration and Gatekeeper Action): There was some

opposition to this addition, as experts considered this as an implementation matter. It was notaccepted.

Section 6.1.9 (Clarification of call termination when the H.245 channel is not separate): Firstchange - may to shall:This was not accepted. It was felt as though the change added no value. However, it waspointed out that what needs clarification is the general misunderstanding that an endpoint isrequired to initiate H.245.



Section 6.1.9: Second change: This section clarifies that an endpoint is not required to start H.245in order to terminate the call. Better: define two call cleanup procedures, one for the case whereFast Connect is used and no H.245 procedures have been initiated by either endpoint, and theother procedure as it is today for terminating a call wherein H.245 procedures have beeninitiated.

H.323 Annex O, Internet Protocols

AVD-2207, H.323 Annex O: Use of Internet Protocols with H.323 Systems (Editor, O. Levin,RADVision), defines procedures for using Internet protocols and technologies in the context ofH.323, to efficiently build and deploy H.323 services running over the Internet. It was suggestedthat the title, introduction, and abstract are a bit broader than the true scope of the document. Thoseshould be brought into alignment. The editor proposed to move the ENUM section under section4, as ENUM requires the URL.

It was mentioned that the TXT record usage is defined in H.225.0 for GK discovery, registration,and querying. All of that functionality should be incorporated into Annex O’s use of SRV records.To that end, Q.2/16 should add an “h323gk” service (name is not important) that the service nameendpoints may use to find a GK with which they may register.

It was suggested that “url-paramters” should be defined as it was in H.323v4, and individualparameters should be defined in a separate section.

When establishing a connection to an endpoint associated with a URL (the URL has no specifictransport or service), the text on page 9 suggests that TCP is used for the connection. It was agreedto leave this open to the endpoint to select whatever reliable call signaling transport it wishes to use.

It was noted that the service names would need to be registered with IANA. O. Levin will take thatas an action item.

H.323 Annex P, Modem Relay

AVD-2213, H.245 Additions for MoIP (Annex P Editor, P. Jones, Cisco), describes therequirements and proposed additions needed to support Modem over IP within H.245, along with adescription of the new data structures and their intended usage. This document does not describethe use of State Signaling Events (SSEs) or the specifics of the MoIP signaling, as Annex P/H.323will address those topics explicitly. The purpose of Annex P is to describe the procedures fortransferring modem signaling over an H.323-based network. The signaling procedures describe theuse of H.245, State Signaling Events (SSEs), and Extended Fast Connect to signal endpointcapabilities, to open and close logical channels, and to signal state changes. H.323 entities thatsupport the carriage of modem signals of IP networks shall provide that functionality in accordancewith this Annex.

It was suggested that if there are multiple RTP streams within a Media Stream Bundle (MSB),those streams must use unique SSRC (Synchronization Source [IETF RFC1889, RTP]) values.Others argued that the SSRC values should be the same. It was agreed that as long as an MSB hasonly one active RTP stream at a time, then it could use the same SSRC value. Perhaps this shouldbe renamed from “media stream bundle” to “multiple payload stream” or something else. It wasalso suggested to not refer to separate streams, but instead refer to payloads.

There were some concerns raised over whether signaling should be so much via H.245, rather thanhaving the signaling within the media stream itself. Others argued that it is necessary that the datatypes be advertised in advance via H.245. There was discussion on this point. A representative of



Q.11/16 reiterated the requirement to utilize the same UDP port to send various streams (voice,VBD, SPRT [Simple Packet Relay Transport], SSE).

There was a concern raised over the fact that the media types in an MSB are mixed: some are RTP(voice and VBD) and some are not (SPRT). The document needs to be careful to state that the fieldin the position of the PT field in RTP header is used for differentiation of stream elements.

If Q.2/16 moves forward with the use of MSBs, they must insert the restriction that MSBs are usedonly in a point-to-point connection.

It should be clarified that an MSB is a single stream with multiple types that may change. This isonly one set of timestamps and one SSRC value.

There were some concerns over the general usage of MSBs, as people may attempt to mix videoand audio. While this is not expected to be the case, the document should allow the mixing ofinformation that comes from the same source. For example, audio and DTMF generally originatesat the same source. 3Com suggested that MoIP is just another type of audio.

There was also a concern that if this is allowed for the general case, one also needs to be able to dothis with SDP and H.248.

It was noted that an MSB is similar to a single “m=“ line in SDP, which allows multiple mediatypes to be listed (so long as they are the same media type). This is one argument for trying to havea more general usage for MSBs.

If multiple types of data are allowed to be sent to the remote entity (RTP and SPRT), the documentneeds to list the requirements of the type of data that is sent to the remote entity. In the case ofthese two, the payload type has to be physically located in the same place.

It was mentioned that SSEs are required for MoIP’s usage of MSBs. It was suggested that the PTvalue be used to signal a mode change, but the Q.11/16 experts present said that SSEs need to beutilized to control a mode switch.

It was suggested to define the general requirements for MSBs if it should be allowed to be used forthe general case, outside of MSBs.

It was said that since SSEs are similar, but not the same as RFC2833, the SSE type should not be“AudioTelephonyEventCapability”, but a similar data type specific to it (perhaps an SSEType)should be defined.

The “foIP” field within the VMoIPCapability is not required, as T.38 may be signaled elsewhere.

There are some syntax errors within the ASN.1 that needs correcting. Q.2/16 also needs todetermine whether “redundancyEncoding” in H.245 truly means RFC2198.

The vMoIP v44 and v42bis compression parameters are all OPTIONAL. There may be some otherissues to consider with respect to the VMoIPCapability—the editor will work with Q.11/16 expertsto resolve those issues.

It was suggested that VMoIP and SSEs be generic capabilities within H.245.

TD-18 (R. Even, Polycom) provides comments on AVD-2213. It notes the discussion and lack ofconclusions at the previous IETF AVT meeting and offers suggestions.



An ad hoc group was formed to discuss the general use case of MSBs. That group will report backon the decisions reached (see below).

AVD-2214 (Editor, P. Jones, Cisco) is a copy of draft Annex P/H.323. This draft leverages theadditions proposed in AVD-2213 and the protocol and procedures documented in the currentV.MoIP draft (AVD-2230). The following changes were recommended:

In P.6, change “to the called endpoint” to “to the called endpoint at the beginning of a call”.

The Q.11 experts pointed out that out-of-band signaling is not an option any longer: SSEs shallalways be used to signal mode changes.

In P.7:• “MR” should be replaced with “SPRT”• “There are four types of streams”… Q.11/16 really thinks of only three streams: audio, SSEs,

and SPRT. However, audio may have more than one mode, VBD and “normal”.• There were concerns over the use of the word “stream” for each of the types of “streams,” as

an MSB has only one stream.• The following needs to be reworked: “By definition, an MSB channel is a single RTP session

that may carry RTP packets that have different payload type values and different SSRCvalues.”

In P.7.2, it didn’t seem to be clear that H.245 may be used in the absence of Fast Connect support,but it should be an option.

AVD-2230, V.MoIP Draft text, Procedures for the END-TO-END connection of V-series DCEsover an IP Network (Editor), was provided for information. This is the approved output text (D-006) from the June TR-30.1 meeting. This draft of the Recommendation specifies the operationbetween two IP Network gateways to facilitate the end-to-end connection of V-series DCEs over anIP network. The gateways are specified herein in terms of their functionality, signals and messagesand operating procedures. The principal characteristics of these gateways are as follows:

a) Support of a mechanism to allow the transparent transport of modem signals end-to-end.b) Support of mechanisms to allow the termination of modem signals at the gateways and the

transport of the data between gateways.c) The definition of a transport protocol, which can be used to relay the data between gateways.d) The definition of procedures to allow gateways to transition between Voice-over- Internet

Protocol and Modem-over-Internet Protocol operation.e) The definition of procedures to allow gateways to transition from Modem-over-Internet

Protocol operation to Facsimile-over-Internet Protocol.

Ad Hoc Meeting on Requirements for MSBs and Other H.245 Syntax

It was initially reiterated that there are four types of streams:

• Voice• VBD• SSEs• SPRT

Further, it was stated by the Q.11/16 experts that Voice and VBD are both “audio” and neithershall be present at the same time. Also, SPRT shall not be present at the same time as voice orVBD. However, SSEs may be present, as those packets are used for control.



It was said that SPRT packets are not RTP, unlike the other types of payloads, but they are orderedwith a sequence number.

It was also proposed to change the ASN.1 syntax that defines the MediaStreamBundle capabilitysuch that the “capabilities” is defined as a SET OF AlternateCapabilitySet. This change wouldallow an endpoint to indicate which DataTypes it supports as part of the bundle in a more concisemanner.

It was proposed that the FECData structure should be defined as simply:

FECData ::= CHOICE{

rfc2733 SEQUENCE{

protectedPayloadType INTEGER (0..127) OPTIONAL,dependentSessionID SessionID OPTIONAL,…

}}

This definition, unlike the previous, requires that either an MSB is used or that two OLCs are usedin order to build an FEC-protected stream. It also allows the removal of the FEC stream without theremoval of the FEC-protected stream. One of the strongest arguments for this change is thatsecurity attributes could not be defined for the separate stream as previously defined in AVD-2213.

It was also proposed to not use any of the existing redundancy encoding data structures, as they areill defined and not well suited for inclusion within DataType and MSBs. Q.2/16 should create anew set of redundancy encoding capabilities and use RedundancyEncodingData as defined inAVD-2213.

T. Anderson (Lucent) agreed to draft a set of requirements and a description of the Media StreamBundle (or whatever it shall be renamed as) that meets the requirements of Question 11/16 and isalso of general utility for H.323 systems. TD-34, Multiple Payload Streams: Requirements andDefinition (T. Anderson, Lucent), is a summary of the work from the ad hoc group studyingchanges to H.245 to support MoIP. TD-34 lists the requirements for a mechanism for supportingmultiple payload types in a single stream and provides a definition of a stream (multiple payloadstream [MPS]) consistent with the above requirements.

H.225.0 Annex Gv2, Communication Between and Within AdministrativeDomains

AVD-2245 (Editor, M. Gleason, Cisco) is H.225.0 Annex G, Communication Between and WithinAdministrative Domains, Version 2. This is a major revision to Version 1, principally in that theunderlying message definitions used by Annex G have been moved to a new Recommendation,H.501. Separating the message definitions from H.225.0 Annex G allows them to be used forother applications. In particular, the H.5xx Series recommendations for H.323 mobility will makeuse of the message definitions, and other applications are now free to do so as well. It was agreedto continue with the plan to put this forward for Consent in October 2002.

It was remarked that a central repository is still needed to store all of the Generic ExtensibilityFramework (GEF) identifiers, so as to prevent collision. E. Horvath (Siemens) agreed to draft anAnnex for H.460.1 that will contain the values from Annex R/H.323, H.501, and make mention of



the fact that H.460.x documents have a value reserved for them, by default, as “x.” The onlyexception is H.460.1, which has no GEF identifiers defined.

H.460.Presence

AVD-2246, Comments on the use of Instant Messaging and Presence in H.323 systems (S.Okubo, Waseda University), provides some thoughts for furthering this study in the light ofenhancing videoconferencing, videophone and other realtime conversational multimediacommunication systems. It explains that the realtime conversational communication process can bedecomposed into three phases: planning, meeting (H.323), and reporting. It was noted that T.120is available for reservation of audio conference or multipoint videoconference.

Presence is difficult to define and the definition may vary, depending on the user’s perspective, thenetwork operator’s perspective, etc. The IETF has been undertaking work to address presence andhas had a number of competing proposals on the topic.

To move this work forward, the usage scenarios must be defined. Those scenarios could then beturned into requirements. Companies are encourages to submit application scenarios that maypotentially turn into a set of requirements and ultimately protocols.

There were questions raised over whether Q.2/16 should create a protocol that is specific to H.323or to use a generic presence protocol. This decision should not be made until the applicationscenarios and requirements are examined.

H.460.4, Service Class Designations

AVD-2201 (Editor, G. Thom, Delta Information Systems) is the current draft of H.460.4, CallPriority Designation for H.323 Calls. Draft Recommendation H.460.4 defines messages andprocedures necessary to request a specific call priority for an H.323 call. This call priority indicatesthe importance of call completion for a given call or endpoint. It may be used to provide highavailability service level agreements as well as to provide support for International EmergencyCommunications. No comments were made against AVD-2201.

AVD-2211, Comments on draft for H.460.4 (M. Pierce, Artel), provides suggestions forcorrections to the current draft to support priority level definitions for other than the EmergencyTelecommunications case. It generalizes the Call Priority Designation description and defines anASN.1 which can be extended to include priority level definitions for other domains. The intent isto achieve commonality with work going on in the IETF. It notes that there are a few syntax errors.

On the topic of using ENUMERATED versus a CHOICE with NULL options, it was said that bothare encoded in the same way and that H.323 typically uses the latter. While it may make moresense to use ENUMERATED, it would differ from most H.323 syntax. It was agreed in a meetinga couple of years ago to continue to use CHOICE with NULL types.

There was a question about whether GSTN includes a “packet” network. The intent was not tolimit this to “switched” networks, but just to classify the types of networks as public, government,etc.

TD-17 (H.460.4 Editor, G. Thom, Delta Information Systems) provides detailed responses to thecomments in AVD-2211.

There was a general question related to these documents on controlling the bit rate of traffic inrelation to the priority of a call. The Rapporteur for Q.ETS said that this was being considered in



several ways, some of which are in H.priority. There seemed to be general agreement to keep asimple set of priority values and perhaps define mappings into other networks at interworkingpoints.

The Editor was asked to work with M. Pierce on AVD-2211 and, considering the above comments,provide a revised draft for the next meeting. It is the group’s desire that the two can come toagreements on most points; comments are certainly welcome to be provided to both individuals.

H.460.6, Extended Fast Connect

AVD-2249, Draft H.460.6 Extended Fast Connect Feature (Editor R. Gilman, Avaya), provides amethod by which an endpoint or a gatekeeper (a “party”) may negotiate the capability to initiate,rearrange, reconfigure, or close one or more media channels as efficiently and quickly as a SETusing the repeated fast start procedures. AVD-2249 provides a number of changes requested fromthe Geneva meeting:

• Added a parameter to specify symmetric codec operation.• Added close-all-channels via Null Capability Set.• Added a description of a “counter-offer” sequence as a negotiation mechanism.• Various editorial changes.

Attendees felt that the text of this contribution was difficult to understand. It would good to thinkof some way to improve the readability of the document. Perhaps more diagrams would be helpful.Perhaps there is a way to separate the channel reconfiguration from the other procedures within thedocument. In any case, the editor was encouraged to find a way to make this easier to understand.

The Rapporteur encouraged experts to review this work very carefully, to consider backward-compatibility with existing Fast Connect procedures. Every attempt has been made to preservebackward compatibility, of course, but a thorough review may avoid interoperability problems.

H.460.ReQuery

AVD-2215 (Editor, P. Jones, Cisco) is a first draft of H.460.ReQuery. H.460.ReQuery is amechanism that allows endpoints to query a Gatekeeper or Border Element for routes and alternateroutes multiple times for a single call. While querying the Gatekeeper or Border Element multipletimes may increase the time required to establish the call, it is expected that most calls will beestablished with a single query. This recommendation is focused on the cases where the call cannotcomplete to the first provided route to a destination. In such cases, the endpoint may query foralternate routes to the given destination. The alternate routes may also include different source ordestination alias information, different security tokens, or other information that may have beenexpensive or too time consuming to produce and/or provide in the initial query.

Comments included that it should be stated very clearly that a DRQ shall not be sent before re-querying for alternate routes. It should be very clear that the Call-ID is used by the Gatekeeper toassociate the subsequent queries with the original ARQ for the call and no other information, suchas aliases.

No other comments were made. It is the intention to put this forward for Consent in October 2002.



H.225.0v5, Call Signaling Protocols and Media Stream Packetization for Packet-Based Multimedia Communication Systems

AVD-2209, Restructure of the H.225.0 Protocol and Documentation (Editor V. Bhargava, Cisco),notes that as it stands today, Recommendation H.225.0 is a collection of varied protocols, all ofwhich although related, are distinct enough to be separated. For example, the Recommendationdescribes the RAS protocol, the derivative of call signaling protocol from Q.931, RTP/RTCP, andpayload types. AVD-2209 suggests that H.225.0 be reorganized into a set of Recommendationsunder the H.225 umbrella.

There was some concern that, if the current ASN.1 module is split into three modules, there may besome technical problems. It was suggested to keep the ASN.1 module intact as it is, but perhapsconsider only splitting the field definitions that are related to RAS and call signaling and place thosein H.225.1 and H.225.2.

With further discussion, the general feeling was that splitting the documents would result in havingto search through more documents to find needed information. However, cleaning up the document(removing the RTP Annex and making references to RFC1889, etc.) is certainly invited.

AVD-2210, Proposal to Add the Circuit Status Map to H.225 Messages (L. Fourie, Cisco), notesthat H.323v4 provides the ability for a Gateway to report call capacity information in thecallCapacity structure to a Gatekeeper to support routing of calls to that Gateway. H.323v4destinationCircuitId provided the means for a Gatekeeper to select a trunk group and circuit on aGateway for the outgoing call through that Gateway. However, the service state of individual PSTNcircuits in trunk groups on a Gateway cannot be reported to the Gatekeeper. This means that theGatekeeper cannot do proper circuit selection because it is does not know the service state ofcircuits on the Gateway. Individual PSTN circuits on the gateway may be taken out-of-service by aprovisioning command from service personnel or when an ISUP out-of-service or blockingmessage is received from the adjacent PSTN switch. In this case, the Gatekeeper will route the callto the Gateway because it knows that circuits are available (from callCapacity) on that Gateway butnot which circuits are in-service. When this occurs, the call will be rejected by the Gateway. Thisconsumes network resources unnecessarily and will potentially increase post-dial delay. To solvethe problem, AVD-2210 introduces the ability for a Gateway to send circuit service state to aGatekeeper in a circuitStatusMap.

It was agreed that work will begin on H.460.CircuitMaps with the contents of this contribution. L.Fourie (Cisco) will serve as editor.

AVD-2236, Addition of Hop Count Field for Call Signaling Loop Prevention (L. Modahala,Cisco), notes that when the H.225.0 Setup message is received by an endpoint, there is noindication regarding how many hops through the intermediate H.323 capable devices the callsignaling had traversed. Without the explicit “hopCount” field, the call signaling loop problemexists where the call could be routed back to the originating endpoint and again sent to the endpointthat, in the first place routed the call back to the originating endpoint. When this occurs repeatedly,it causes a routing loop. This proposal adds the “hopCount” field to the H.225.0 Setup messageand the procedure to detect and prevent the loop using the “hopCount” field. It was agreed toinclude this in H.225.0v5.

AVD-2237a, Signaling of Translated Source Number for Primary and Alternate Endpoints from theGatekeeper (L. Modahala, Cisco), notes that the call routing logic on the Gatekeeper or on theapplication working in conjunction with the Gatekeeper may desire to translate the calling number(e.g., from a private abbreviated dial plan calling number to a full E.164 calling number or modifiedcalling number) prior to or after destination address resolution. But the current RAS mechanism



does not allow the Gatekeeper to signal the translated number back to the endpoint. This proposaladds the mechanism to signal the translated source alias address between two gatekeepers andbetween a Gatekeeper and a registered endpoint.

It was suggested that the field names should be “srcInfo”, not “translatedSrcInfo”. Thesemantics of using this field need to be defined. For example, what does it mean to get an ACFwith this field present, but not populated, or not present at all?

This was accepted for H.225.0v5 with the above modifications.

AVD-2239, Registration of Carrier Identifier Code, Trunk groups and associated Address Patternsto the Gatekeeper (L. Modahala, Cisco), notes that in H.323 version 4, the terminalAliasPattern fieldin the Registration message indicates the alias patterns or prefix of E.164 addresses that the H.323endpoint supports. If the H.323 entity is also a gateway type of device, there may be one or moretrunk groups supported by the gateway. The trunk groups supported are advertised to theGatekeeper in the Registration Request (RRQ) message through the use of the callCapacity field,providing the ASCII string format of trunk group name and the maximum and/or current callcapacity. In reality, a trunk group connects to an end office or a tandem exchange and allows callsfor a certain range of numbers to be routed through them. In other words, there is a map orassociation between the trunk group and the address pattern supported by a gateway.

As an example, an egress gateway may have registered two trunk groups A and B each with a callcapacity limit of 192. Also, trunk group A might be configured on the gateway to route calls for+1919* prefixes +1714* and trunk group B might be configured to route calls for +1919* and+1910* prefixes. Hence the gateway might have registered +1919*, +1714* and +1910* addresspatterns. However, it is not possible currently to report which trunk group supports which addresspattern to the Gatekeeper. When the Gatekeeper routes the call, it can either route based on thetrunk group only or using the address pattern only. If the trunk group A is at full capacity ortemporarily out of service, the Gatekeeper does not know whether to reject calls for +1919 becausethe association is known only to the gateway. This problem could be resolved if the Gatekeeperknows the complete mapping. Hence, this proposal allows for the registration of the trunk groupand address pattern mapping to the Gatekeeper.

It was generally agreed that this functionality should be done as part of GEF, as it was notconsidered of general applicability to all H.323 endpoints and there are a number of fields that needto be added to support this proposal.

It was suggested that the authors create an H.460.x-style document for this work and bring it as acontribution to the next Rapporteur’s meeting. The H.460.x document will need to import relevantfields accepted from AVD-2240.

AVD-2240, Signaling of Carrier Identifier Code for call routing (L. Modahala, Cisco), notes that inH.323 version 4, the circuitInfo field in the H.225.0 Call Signaling and RAS messages facilitatedthe signaling of the information about the circuits used for the call. This allowed the Gatekeeper orthe originating H.323 gateway to indicate desired circuit to be used on the egress side for the call.It also allowed the originating gateway to report the circuit on which the call arrived. In voicewholesale applications, this enhanced the call routing functionality to route calls based on a logicalgroup of circuits. However, while inter working with SCN networks for routing voice calls over theIP network, it is required to signal the carrier selection to the egress side as well. Similarly, for thevirtual private network voice routing solution, it is necessary for signaling the origination andtermination customer or business identifiers. Typical applications include where the carrieridentification is used when the call is to be routed to a specific inter connect carrier network, whenthere are multiple carriers that can possibly route the call. This determination can be based onfactors such as cost, voice quality and time of day. Current H.225.0 and RAS protocols do not



allow for the signaling of the carrier or customer/business group identifier between H.323 entities.This proposal enhances the CircuitIdentifier type to signal the carrier identifier parameter betweenthe H.323 entities. It was accepted toward H.225.0v5.

AVD-2242, Use of Q.850 Cause Code values in Admission Reject (ARJ) of calls (L. Modahala,Cisco), notes that when the H.323 call admission request (ARQ) or the endpoint location request(LRQ) is rejected by the Gatekeeper, the reject reason is sent in the admission reject (ARJ) or thelocation reject (LRJ) messages. However, when the Gatekeeper rejects the call admission orendpoint location request, there are no guidelines to map the reject reason to the most appropriatecause code value as specified in Q.850 specification. While sending the H.225.0 RELEASECOMPLETE or PSTN side release (like Q.931 RELEASE COMPLETE message) back to theentity that requested the call routing, the appropriate cause code value is desired for proper calldisposition, such as providing applicable announcement. Also, in the case where the H.323 callarrives at the egress endpoint and the egress gatekeeper rejects the call for the reason of temporarynetwork overload, there is no appropriate reason. Moreover, the egress endpoint may not map toappropriate cause code value in the cause code IE sent back to the calling entity due to lack ofspecific guidelines. As a result, the calling endpoint may not be able to determine whether toperform a route re-query or drop the call. This proposal allows Q.850 cause code values sent inARJ and LRJ messages using the genericData field in the ARJ and LRJ messages.

This document should be named more appropriately, such as “Extended Rejection Reasons” orsimilar. There was a question as to “how did the Gatekeeper get the Q.850 code”?

It was noted that there are any number of reasons why errors may occur within the IP network and,quite likely, the work needs to add additional reasons beyond what is defined today. Perhaps thisshould be a topic for study. There was a bit of debate on this issue. It was not clear how the IPnetwork would generate a reasonable Q.850 code to provide to the Gateway. It was generally feltthat any necessary rejection reasons should simply be added to the ARJ reason list, rather thanaccept this contribution.

H.323v5, Packet-Based Multimedia Communications Systems

AVD-2251, A supplementary procedure for third party pause/rerouting (H. Horvath, Siemens),addresses a specific aspect of the third party pause and rerouting procedures in H.323 (clause8.4.6) and proposes a possible way to optimize these procedures. The procedure defined in 8.4.6does not specify how the controlling entity gets to know that previous channels have been closed.AVD-2251 proposes some additions to the RAS InformationRequest/Response procedure termedenhanced IRR signaling to address this issue.

The consensus was that having a simplified way of doing third party pause and re-routing would bedesirable. Perhaps the solution could utilize GEF and put the terminal in a paused state withoutrequiring explicit channel closures. Perhaps the endpoint may be brought out of the paused statewith either an explicit message and/or the reception of an Extended Fast Connect message. Theseissues need to be considered, along with the impact on H.450.x as those Recommendations all relyupon the third party pause and re-routing procedures from H.323v2.

A new GEF document, H.460.tppr, will provide this functionality.

H.235, Security and Encryption for H-Series (H.323 and Other H.245-Based)Multimedia Terminals

The following documents were discussed under H.235/security; please see the Q.G/16 meetingreport, above, for details.



AVD-2217, Out-of band DTMF Encryption (M. Euchner, Siemens)AVD-2218, Enhanced OFB mode in H.235v3 (H.235 Editor)AVD-2223, Considerations for SRTP integration into H.235v3 (Siemens)AVD-2224, New draft H.235 Annex G, Secure Real Time Transport Protocol Security Profile

(SRTP) (Siemens)AVD-2243, Considerations for discussion on fast start-based security capability negotiation

(Siemens)

Miscellaneous

AVD-2198, SCTP as a Transport for H.323 (RADVision), notes that H.225.0 defines twotransports for call signaling messages TPKT over TCP or H.323 Annex E (Framework and wire-protocol for multiplexed call signaling transport). This contribution posits to leverage the benefitsof SCTP as an additional means of transport. SCTP allows robust communication throughspecification of multiple addresses on each end of the association. SCTP is able to detect peerresets and reestablish associations in case of communication failure. SCTP also eliminates the needfor a message delimiting protocol (such as TPKT). SCTP as a transport for call signalingmessages is mentioned in H.323 Annex R, but there are no specific details provided there. Bothrobust (Annex R) and non-robust H.323 may benefit from using SCTP as a transport. Thepurpose of this contribution is to define usage of SCTP as a transport for H.225.0 messages.

It was agreed to accept this as an addition to H.225.0v5. The editors of H.323 and H.225.0 are alsorequested to consider making changes throughout H.323/H.225.0 where TCP is referenced andalso reference Annex E and SCTP. Actually, it would be better if those texts referred to the“reliable call signaling channel” and had a single place that defined the “reliable call signalingchannel” as one that could be TCP, Annex E, or SCTP.

AVD-2199, Directory Services Architecture for Multimedia Conferencing (RADVision, ViDe,Internet2), describes a directory services architecture using LDAP for multimedia conferencing. Inparticular, it describes a way to represent endpoints on the network, and to associate those endpointswith users. It discusses design and implementation considerations for the inter-relation of videoand voice-specific directories, enterprise directories, call servers and endpoints.

The architecture supports any generic video or voice over IP technology by deriving a protocol-specific class. This document describes the formal LDAP object class definitions andconfiguration files for commObject and its subclass h323Identity. These classes can be used torepresent H.323 endpoints in a directory. It is anticipated that future development of thisarchitecture may encompass SIP or other related conferencing protocols.

This contribution favors the IETF RFCs, rather than Microsoft’s Active Directory. It was generallyagreed to not be concerned with issues that are specific to Active Directory, as Microsoft is not anSDO and ITU documents cannot reference their documents.

TD-19 (R. Even, Polycom), which supports this architecture, offers additional technical comments,which the contributor is requested to consider.

It was agreed to take up this work under Question 4/16. A new draft Recommendation (H.ldap)will define the purpose and utility of the schema definition. Perhaps the first Annex would containthe definition of CommObject and other Annexes would be reserved for H.323, SIP, H.320, orother protocols.



AVD-2212, Proposal to Add Digit Maps to H.323 (P. Jones, Cisco), proposes a newRecommendation that adds Digit Maps to H.323 systems through the use of the GenericExtensibility Framework. The Digit Map syntax proposed within this document is similar to thatfound in H.248, but the procedures are not borrowed. The intention is that the H.323 endpoint willcollect digits and, once the digits are collected, it will send an ARQ to the Gatekeeper for calladmission. The intent is to reduce post dial delay and/or provisioning that would otherwise have tooccur in the absence of these digit maps.

Comments suggested that “Digit Maps” should be changed to “Digit Map”, and “Digit Map”should be changed to “Digit Map element” (or “strings” or something else distinct). Somestatement should be made as to how to treat a Digit Map with a TON specified when the device hasno concept of TON (Type of Number).

It was agreed to move forward with this work, perhaps trying for Consent at the October meeting.However, since this was the first time it has appeared, it needs more careful review.

AVD-2250, Change for Request Mode command for supporting custom format (Polycom), waspresented and discussed. Please see the Q.3/16 report, below, for details.

Q.2/16 Document Status

Recommendation Approval EditorH.323-Series Implementer’s Guide 10-2002 V. Bhargava (Cisco)H.225.0 Annex Gv2 (Inter-domain) 10-2002 M. Gleason (Cisco)H.460.4 (Service Class Designations) 10-2002 G. Thom (Delta)H.460.5 (Multiple IEs) 10-2002 S. Ruditsky (RADVision)H.460.6 (Extended Fast Connect) 10-2002 B. Gilman (Avaya)H.460.QoSMon 10-2002 E. Horvath (Siemens)H.323 Annex P (Modem Relay) 10-2002 P. Jones (Cisco)H.460.CircuitMaps 10-2002 L. Fourie (Cisco)H.460.ReQuery 10-2002 P. Jones (Cisco)H.323 Annex O (Internet protocols andTechnologies complementary to H.323)

2003 O. Levin (RADVision)

H.225.0v5 2003 V. Bhargava (Cisco)H.323v5 2003 R. Even (Accord)H.460.DigitMap 2003 P. Jones (Cisco)H.460.tppr 2003 E. Horvath (Siemens)Annex A/H.460.1 (ID Assignments) 2003 E. Horvath (Siemens)H.460.Presence 2003 TBDH.323 Annex I (Packet based MM Telephonyover Error Prone Channels)

2003 A. Li (Samsung)

H.323 Annex N (QoS) 2003 M. Buckley (Telchemy)

Q.2/16 MoIP ad hoc Meeting

A Rapporteurs ad hoc meeting is planned for August 19-20, 2002, with MoIP experts from Q.2/16,Q.3/16 and Q.11/16, in RTP, North Carolina. Work will be progressed on H.323 Annex P(Modem Relay), and H.460.6 (Extended Fast Connect).



Question 3/16, Infrastructure and Interoperability for Multimedia OverPacket Networks

The Q.3/16 Rapporteur is C. Groves (Ericsson). C. Groves welcomed T. Anderson (Lucent) as theNew Q.3 Rapporteur from this meeting forth. The Q.3/16 meeting report is TD-14r1, the agendais in TD-07. Question 3/16 met jointly with Q.2, as well as individually. The objectives of thismeeting were progress on:

• H.245v9• H.246 Annex C (ISDN User Part Function - H.225.0 Interworking) Implementer’s Guide• H.248.11 Media Gateway Overload Control Package• H.248.16 Enhanced Digit Collection Packages• H.248.17 Line Test Packages• H.248.18 Profile Package• H.248 Annex M.mcu MCU Composition – no contributions received• Supplement x to H.248 Packages Guide

Liaisons

AVD-2183, Clarifications to H.246 Annex C (SG11), notes that SG11 (Q.11/11) adopted theQ.3/16 Rapporteur’s suggestions (in a previous liaison) to overcome Q.11/12 problems with H.246Annex C. Since the changes that are the subject of the liaison were already incorporated into theH.246 Annex C section of the H.323 Implementer’s Guide, no reply was sent.

AVD-2191, Clarification on Automatic Level Control vs. Gain Control (SG15), notes that SG15 isnot aware of a standardized definition of gain control. One possible definition for gain control isthat it is a process or means by which gain is adjusted in a specific manner as a function of aspecified parameter, such as received signal level. The ratio of the output power to the input powercan be set to a fixed gain, expressed in [dB]. SG15 believes further that noise reduction is aseparate function from gain control. It was seen that the automatic value of gain control presentedin H.248 Annex E.13 was the same as Automatic Level Control with the assumption that the targetvalue of Automatic Level Control should be provisioned on the MG. A note will be added to theH.248 Implementer’s Guide to this effect. A response liaison to SG15 and SG11 is in TD-28,which states that the experts of Q.3/16 have determined that a change to H.248.1 Annex E.13 TDMCircuit Package is warranted to clarify the operation of Gain Control when it is set to automatic.

H.248 Material for the Implementer’s Guide

AVD-2244a (Editor, T. Anderson, Lucent), is the current version of the H.248 Implementer’sGuide Draft. The proposed technical additions in 6.1 (Specify types for rtp/jit and rtp/delay inAnnex E.12.4), 6.2 (Define the ‘#’ symbol in INEQUAL in text encoding), 6.4 (Define the symbolfor NULL context in text encoding) and 6.5 (Corrections to Appendix A example statistics) wereaccepted without comment. There was some discussion) whether the proposed addition in 6.3(Empty Descriptor Syntax was appropriate. The proposed change was accepted with a note toreview the change and contribute if it is not suitable. 6.6 (Corrections to Package Guidelines forStatistics in 12.1.5) was accepted with the addition that the types for statistics should be expandedto the set defined for properties. If the type should be restricted, contributions should be submitted.The unreviewed output text is in TD-36.

H.246 Annex C Material for the Implementer’s Guide

AVD-2202, Technical corrections relating to progress indicator in Recommendation of H.225(NTT), was presented. Please see the Q.2/16 report, above, for details.



AVD-2203 (T. Yoshikawa, NTT) proposes corrections relating to mapping of cause value in H.246Annex C. The proposal was accepted for inclusion into the H.246 Annex C section of the H.323Implementer’s Guide.

AVD-2204 (T. Yoshikawa, NTT) proposes corrections of Recommendation H.246 Annex Cregarding Bearer capability and Handling of fallback information in backward message, since thereis inconsistency between H.225.0 and H.246 Annex C. The proposal was accepted for inclusioninto the H.246 Annex C section of the H.323 Implementer’s Guide.

During the discussion of the H.246 Annex C contributions, the delegates agreed that it would beadvantageous to publish a new version to incorporate all the implementer’s guide changes. T.Yoshikawa (NTT) will be the editor for this new version of H.246 Annex C.

H.245v9, Control Protocol for Multimedia Communication

AVD-2213, H.245 Additions for Modem over IP (MoIP) (P. Jones, Cisco), was discussed underthe joint Q.2 and Q.3 meeting. Please see the Q.2/16 report, above.

AVD-2217, Out-of band DTMF Encryption (M. Euchner, Siemens), was presented and discussed,see also the Q.G/16 report, above. It was noted by the presenter that the first bullet point shouldread “encryptedalphanumeric.” It was asked what this encryption mechanism was targeted to: e-commerce, user to user? It was clarified that the primary use is for credit card numbers and pinnumber security. It was also questioned whether the encryptedalphanumeric type allows foraccents. The response was that currently it does not but neither does the non-encrypted typecontained in the base H.245. Contributions are invited if a new type for accents needs to be added.The proposals were accepted for inclusion in H.245 and H.235. There was still the open questionabout what UserInputSupportIndication is used for. M. Euchner will contact the H.245 editor toclarify.

AVD-2250, Addition to Request Mode command for supporting custom formats in H.263(Polycom), notes that in H.245 RequestMode, the H.263 video mode indicates the requested pictureresolution (SQCIF, QCIF, CIF, 4CIF and 16CIF or some custom picture format). The problem is,in the resolution choices that are part of the syntax, there is no option for specifying custom format.The custom format can be supplied in the h263Options. So currently in order to supply a customformat, you need to supply a standard format in the resolution choice and a custom format in theh263options, so it is not clear what the other side will do, use the standard or custom format.AVD-2250 suggests adding a choice of custom to the resolution options and specifying in the textthat for previous versions if a resolution choice and a custom format are specified then the customformat is the preferred requested mode.

The discussion questioned whether the flexibility of custom formats was needed, as such flexibilitymay cause interoperability problems. This was countered by the point that this was alreadycontained in the base H.245 and that one can’t stop people doing unusual things. The ASN.1 andtext changes in the proposal were accepted for inclusion into H.245v9. Modified text was acceptedto be included in the H.245 section of the H.323 Implementer’s Guide.

H.248, Gateway Control Protocol

The meeting suggested that for H.248 related issues, T. Taylor (Nortel Networks) should share theresults with the IETF Megaco working group and solicit their comments.



H.248.11, Media Gateway Overload Control Package

AVD-2195, Media Gateway Overload Control Package H.248.11 (M. Whitehead, BT), waspresented as a delta document from the previous editor’s input. There were concerns on why oneshould send an extra event in a Notify command and why not in a reply? It was seen that themechanism was to prevent the situation where you get a rejection. Instead the event indicates thatthe MG is reaching congestion state, so a separate message is appropriate. It was seen that thecurrent document/package is only relevant for simple calls (i.e., point to point) but may not berelevant for conference calls. An editor’s note will be added to highlight that the modification of thescope of the package to allow conference calls should be considered.

There were questions on how the interaction with priority works on an originating call i.e., youdon’t know if the call is a priority call until you get digits. It was resolved that it is up to the MGCto enforce priority in a congestion case, not the MG.

It was clarified that MIB is a database, SNMP is the protocol. This should be reflected in thedocument. The delegates indicated that a base MIB should be added to the document. Discussiontook place on where the requirements should be documented. It does not have to be part of thepackage section so the current layout of the document is fine.

The proposal was accepted as baseline for the package. The unreviewed output draft from themeeting is contained in TD-37r1.

H.248.16, Enhanced Digit Collection Packages

AVD-2247, Updated Draft H.248.16, “Enhanced Digit Collection Packages and Procedures” (K.Boyle, Nortel), updates the draft text for H.248.16, formerly H.248 Annex M.edcp. The originaldraft text was accepted at the February 2002 SG16 meeting in Geneva. This proposal updates tothe new recommendation numbering for the H.248 series, and adds an additional package to allowfor collecting digits during an active call. It was accepted without comment.

H.248.17, Line Test Packages

AVD-2231, Alternate Line Test Packages Draft (C. Groves, Ericsson), proposes an alternatebaseline for Line Test Packages to AVD-2130 (Lucent) presented at the Dublin 2001 SG16Rapporteurs’ meeting (see CSR 12.40).

It was commented that there is an inconsistency between signal type ON/OFF and duration. Thisshould be fixed. The current editor indicated that he had a preference for the proposed baseline.The proposal with the above comment was accepted as baseline text. The unreviewed output text iscontained in TD-40.

H.248.18, Profile Package

AVD-2232, Updated Profile Package Draft (C. Groves, Ericsson), presents an updated draft of theProfile Package. It contains editorial and a technical change to allow the setting of the ProfilesSupported property by the MGC.

It was commented that the package needs to address the generation of an error code if the MGCtries to set an unknown profile. T. Taylor (Nortel Networks) expressed some concern over theexample. There was also some concern that if a gateway had line and trunk profiles, the MGCwould still need to audit and thus profiles weren’t of help. This was countered that it reallydepends on what is described in the profile. It was seen that Profile clashes were a possible



problem; it was remarked that the mechanism proposed in the package helped that. It was indicatedthat Profiles were a “shorthand” way to list assumptions on the media gateway.

It was also highlighted that profiles are largely undefined. Contributions are solicited to further thework on profile definition.

The proposal was accepted with the addition of text with regards to handling error cases. Theunreviewed output text is contained in TD-39.

Supplement x to H.248 Packages Guide

AVD-2233, Packages Supplement Draft (C. Groves, Ericsson), provides updates to Supplement 2to the H.248 Sub-Series: Packages guide. It was accepted. T. Taylor remarked that the Q.SPNEpackage work has been dropped. This should be confirmed by the editor for possible amendmentto the supplement.

New Material

AVD-2234, Extended H.248.12 Packages (C. Holmberg, Ericsson), defines new properties forH.324M/H.323 interworking, which are needed when the interworking function is handled by theMGC. The properties are introduced in the new extended packages of H.324 package, H.245command package, and H.245 indication package. The proposal was agreed. Ericsson volunteeredto be editor and it was agreed that October is a reasonable approval date. An issue was raised thatthe base package uses a multiplex on a TDM termination when in fact it should be on a separatetermination. The editor along with T. Taylor will contact Mr. Sayer to propose a resolution to thisissue. A contribution is expected addressing the outcome. The document shall be known asH.248.12 Annex A.

AVD-2235, Conventions for the use of the Local and Remote Descriptors for H.223 multiplexers(C. Holmberg, Ericsson), describes how the Local and Remote Descriptors can be used withinH.223 MUX terminations. In particular it describes the use of the Session Description Protocol(SDP). In the MUX termination, the protocol is used to map logical channels to H.248 Streams,but also to specify other parameters for the logical channels, e.g., codec parameters. The proposalwas agreed with the comment that the draft should also include codepoints for H.221 (extendedscope). C. Holmberg (Ericsson) volunteered as editor; it was agreed that October is a reasonableapproval date. The document shall be known as H.248.LRM. The unreviewed output is containedin TD-38.

AVD-2248, Considerations for discussion of, and initial proposal for update of ServiceChangeprocedures for H.248 (K. Boyle, Nortel), presents some points to consider when discussingchanges to the ServiceChange procedures in Recommendation H.248.1. An initial proposal forServiceChange behaviors on the Root termination is also presented, to provide a starting point forthis work.

K. Boyle acknowledged that the work is very rudimentary. One delegate indicated that the ControlAssociation Text was good. It was also highlighted that the bullet points and the text in generalneed to cover non-root terminations. It was questioned whether it is possible for the MGC to tellthe MG to go back into service? The meeting didn’t think so. It was clarified that the ControlAssociated is in Megaco Terms not transport specific i.e., TCP. This needs to be clarified in thedocument text. It was agreed that in bullet 3 delay of 0 is incorrect.



T. Taylor discussed the problem of how the MG signals unambiguously to the MGC the state of itsdata, i.e., gone, up to date, stale. Reason could be used for this but needs to be better specified inthe document.

As a side issue it was highlighted that MGs need to initiate control associations, and it should beconsidered if this is appropriate for applications such as MIDCOM (IETF draft, middleboxcommunications).

It was agreed that the goal is be compliant with the existing H.248.1 7.2.8; where exceptions arefound these should be noted. It is not a goal to redefine 7.2.8. There was general support for thiswork. A new Annex F (Service Change Procedures) to H.248.1 is proposed with the approval timeframe of mid-2003. K. Boyle (Nortel) volunteered to be editor. TD-41r1 contains the unreviewedoutput of the meeting.

TD-35, Conversion of SDP Between H.248.1, SIP, and MGCP (Q.D Rapporteur, T. Taylor,Nortel), notes that the original motivation for the use of SDP within H.248.1 Local and Remotedescriptors was to make it easy to interwork with the Session Initiation Protocol (SIP - RFC2543).The original model was MGCP. However, because SG16 could not understand the negotiationmodel intended by MGCP and SIP, it invented its own. SIP (and MGCP) have more recentlyfirmed up the description of their negotiation model, but have based it on established practice ratherthan the innovations introduced by Megaco/H.248.1. As a result of this divergence, a number ofdifferences, which are identified, may be observed between SDP as used in SIP and MGCP andSDP as used in Megaco/H.248.1 This contribution was not discussed, but delegates wereencouraged to consider its contents.

Future Q.3/16 Meetings

A face to face ad hoc meeting on MoIP is scheduled August 19-20, in Research Triangle Park,North Carolina, USA. This will be followed by a phone conference to discuss the output. It isadvised that the H.245 experts take an interest in this work.

Q.3/16 Work Program / Document Status

Recommendation Timing Ref. Subject EditorH.245v9 (Revision) 2002 Control Protocol for

Multimedia CommunicationsC. Groves /M. Nilsson

H.246 Annex C v2(Revision)

2003? ISDN User Part Function -H.225.0 Interworking

C. Groves/T. Yoshikawa

H.248 IG (Revision) 02/2002 Gateway Control ProtocolImplementer’s Guide

C. Groves /T. Anderson

H.248.1 v1Amendment 1

02/2002 Gateway Control ProtocolVersion 1 Amendment 1

C. Groves /M. Pantaleo /T. Anderson

H.248.1v2(Revision)

02/2002 Gateway Control Protocol C. Groves / M. Pantaleo

H.248.1 Annex F 2003 TD-41 ServiceChange Behavior C. Groves/K. Boyle

H.248.8Amendment 1

02/2002 Error Code and ServiceChange Reason Description

C. Groves

H.248.9 02/2002 Advanced Media Serverpackage

C. Groves /T. Taylor



Recommendation Timing Ref. Subject EditorH.248.11 10/2002 TD-37 Media Gateway Overload

Control PackageC. Groves /M. Whitehead

H.248.LRM 10/2002 TD-38 The use of Local and RemoteDescriptors with H.221 &H.223 multiplexing

C. Groves/C. Holmberg

H.248.12 Annex A 10/2002 Extended H.324-, H.245Command- and H.245Indication Packages

C. Groves/C. Holmberg

H.248.13 02/2002 Quality Alert Ceasing Package C. GrovesH.248.14 02/2002 Inactivity Timer Package C. Groves /

T. AndersonH.248.15 02/2002 SDP H.248 Package

AttributesC. Groves

H.248.16 2002 Extended DTMF DetectionPackage

C. Groves /K. Boyle

H.248.17 10/2002 TD-40 Line Test Package C. Groves /T. Anderson

H.248.18 10/2002 TD-39 Package for Support ofMultiple Profiles

C. Groves

H.248.mcu 2002 Package to SupportDecomposed MCU

C. Groves / R. Even

H.248 Supplement 1(Revision)

02/2002 Supplement - H.248 PackagesGuide Release 2

C. Groves

H.341v2 (Revision) 2002 Management Information Base(MIB) for H.323 Systems

C. Groves /C. Blasberg

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

S. Okubo (Waseda University, Japan) is the Q.4/16 Rapporteur. TD-15 is the report of thismeeting; TD-08 is the agenda. The objective of this meeting was to continue developing the futuredirection(s) of this Question.

AVD-2246, Comments on the use of Instant Messaging and Presence in H.323 systems (S.Okubo, Waseda University), addresses the following:

• Potential of “presence” to enhance H.300-series system by addressing the phase before theactual communication session

• Need for more application scenarios before defining protocol(s)• Possible use of video as presence information• Need for a single solution

See the Q.2/16 report, above, report for the discussions at the joint session.

Q.4/16 Future Directions

This Question is open for contributions toward:

• Describing service scenarios,• Describing technical requirements• Elaborating the work plan.



As an outcome of the joint session, the work on directory services architecture using LDAP formultimedia conferencing (proposed in AVD-2199) will be handled in this Question. See theQ.2/16 report, above.

Question 5/16, Mobility for Multimedia Systems and Services

P. Jones (Cisco) is the Acting Rapporteur for Q.5/16. The meeting report is in TD-16.

Recommendations H.501 (Protocol for mobility management and inter-domain communication inmultimedia systems), H.510 (Mobility for H.323 multimedia systems), and H.530 (SymmetricSecurity Procedures for H.510) were approved under AAP procedures. Liaisons and matters ofgeneral interest have been discussed in the reports of other Questions, above.

AVD-2246, Comments on the use of Instant Messaging and Presence in H.323 systems (S.Okubo, Waseda University), was noted. The work on presence and instant messaging is relevantfor Q.5. The discussion following the presentation of this contribution is covered in the report ofQ.2/16, above.

There was no progress on any other Q.5/16 matters during this meeting due to the absence ofcontributions. Target dates of existing work items remain in place for the time being. M. Paul(Intel) will no longer be available as editor for H.520 (Presence and Instant Messaging) and theeditorship was passed to S. Ruditsky (RADVision).

Q.5/16 Work Items

Recommendations Approval EditorH.500 (General Mobility Management forMultimedia Systems and Terminals)

Oct, 2002 F. Bougant (France Telecom)

H.550 (Global Mobility Management Inter-workingand Interoperability for Multimedia Systems)

Feb, 2003 F. Bougant (France Telecom)

H.520 (Mobile Presence and IM for MultimediaSystems and Services)

Oct, 2002 S. Ruditsky (RADVision)

H.560 (Inter-working and Interoperability betweenMobile Presence and IM systems and currentPresence and IM systems (e.g., AOL, MSN, Yahoomessengers, SIMPLE)

Feb, 2003 ?



SG16 Rapporteurs Meeting Roster, June 24 – 28, 2002, Bruges,Belgium

Tom Taylor, Nortel Networks Q.D/16 RapporteurMike Buckley, Lucent UK Q.F/16 RapporteurMartin Euchner, Siemens Q.G/16 RapporteurPaul Jones, Cisco Q.2/16 RapporteurTerry Anderson, Lucent Q.3/16 RapporteurSakae Okubo, Waseda University Q.4/16 RapporteurPaul Jones, Cisco Q.5/16 Acting RapporteurHost: Belgacom

3Com James RenkelArtel Mike PierceBT Martin WhiteheadBT Chris WilmotCisco Vivek BhargavaCisco Louis FourieCisco Paul JonesECI Telecom Ltd. Ilana LeibovitchEricsson Christer HolmbergFrance Telecom Jean-Pierre BlinLM Ericsson Christian GrovesLucent Terry AndersonLucent Mike BuckleyMindspeed Keith ChuMOC-Israel Silvain SchafferNCS Hal FoltsNortel Kevin Boyle IINortel Tom TaylorNTT Hisataka OgishiNTT Tomoyuki YoshikawaPolycom Roni EvenRADVision Orit LevinRADVision Eli OrrRADVision Sasha RuditskySharp Keiichi HibiSiemens Martin EuchnerSiemens Ernst HorvathSiemens Peter LeisWaseda University Sakae Okubo

John Magill



Acronym Definitions

3GPP Third Generation Partnership Project (ETSI)AAP Alternative Approval Procedures (ITU)ACF Admission ConfirmAPI Application Programming InterfaceARJ Admission RejectARQ Admission Request (H.225)ASN Abstract Symbol NotationATM Asynchronous Transfer ModeAVT Audio/Visual TransportBICC Bearer Independent Call Control (ITU-T SG11)CIF Common Intermediate FormatCORBA Common Object Request Broker ArchitectureCS2 BICC Capability Set 2CSS Communication Systems SecurityDRQ Disengage RequestDTMF Dual Tone Multi FrequencyENUM tElephone NUmbering Mapping (IETF)ETS Emergency Telecommunications ServiceETSI European Telecommunications Standards InstituteFEC Forward Error CorrectionGEF Generic Extensibility FrameworkGK GateKeeperGKRCS Gate Keeper – Routed Call SignalingGSTN General Switched Telephone Network (i.e., PSTN)IANA Internet Assigned Number AuthorityID IdentificationIE Information ElementIETF Internet Engineering Task ForceIG Implementer’s GuideIM Instant MessagingIP Internet Protocol (IETF)IP-CME Circuit Multiplication Equipment optimized for IP based NetworksIRR Information Request ResponseISDN Integrated Services Digital NetworkISO International Organization for StandardizationISUP ISDN User PartITU International Telecommunication UnionITU-R International Telecommunication Union - Radiocommunications SectorITU-T International Telecommunication Union - Telecommunications SectorIV Initialization VectorJTG Joint Technical GroupLDAP Lightweight Directory Access ProtocolMCU Multi-point Control UnitMegaco MEdia GAteway Control Protocol (IETF)MG Media GatewayMGC Media Gateway ControllerMIB Management Information BaseMIME Multipurpose Internet Mail Extension (IETF)MM MultiMediaMoIP Modem over Internet ProtocolMSB Media Stream Bundle



MUX MultiplexerOFB Output FeedbackOLC Open Logical ChannelPSTN Public Switched Telephone NetworkPT Payload TypeQCIF Quarter CIFQoS Quality of ServiceQSC QoS ClassesRAS Registration, Administration, and StatusRFC Designation for an IETF Standard/DocumentRSVP Resource Reservation Setup Protocol (IETF)RSVP-TE Resource Reservation Protocol – Traffic Engineered (draft RFC3209)RTCP Real-time Transport Control Protocol (IETF)RTP Real Time Transport Protocol (IETF)SA3 3GPP - System Aspects - SecuritySCN Switched Circuit NetworkSCTP Stream Control Transmission ProtocolSDO Standards Development OrganizationSDP Session Description ProtocolSET Simple Endpoint TypesSG Study Group (ITU)SIP Session Initiation Protocol (IETF)SNMP Simple Network Management Protocol (IETF)SPNE Signal Processing Network EquipmentSPRT Simple Packet Relay TransportSQCIF Sub-Quarter Common Intermediate FormatSRTP Secure Real-time Transport ProtocolSRV DNS Service (RFC2782)SSE State Signaling EventSSRC Synchronization Source (IETF RFC1889, RTP)TBD To be DeterminedTCP Transmission Control ProtocolTDM Time Division MultiplexTIES Telecom Information Exchange ServicesTIPHON Telecommunications and Internet Protocol Harmonization Over Networks (ETSI

Project)TPKT Transport Packet (T.123)TSA Transmitting Subscriber internet AddressTSAG Telecommunication Standardization Advisory Group (ITU)UDP User Datagram Protocol (IETF)URL Uniform Resource LocatorVBD Voice Band DataVoIP Voice Over Internet ProtocolW3C World Wide Web ConsortiumWP Working Party (ITU)XML eXtended Markup Language



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 2002 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:

ITU-T SG9 Cable Networks & TransmissionSG15 WP1 Network AccessSG15 WP2 Network Signal ProcessingSG16 Multimedia

ETSI AT Access and TerminalsTIPHON Voice over InternetTM6 Transmission & Multiplexing

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 © 2002, 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. 13712

COMMUNICATIONS STANDARDS REVIEW - Linda Hall Library · AVC-2196 , Transmitting Draft...

Documents

Transcript of COMMUNICATIONS STANDARDS REVIEW - Linda Hall Library · AVC-2196 , Transmitting Draft...