January 2002 - sg16-avd - lists.packetizer.com

FW: Question about the use of alternateEndpoints in ACF
by Lyons, Terry 05 May '02

05 May '02

> H.225 v4 contains this text: > "7.11.2 AdmissionConfirm (ACF) > ... alternateEndpoints - A sequence of prioritized endpoint alternatives > for destCallSignalAddress or destinationInfo." > > The feature seems intended to support robustness through redundancy in > large networks, > where there may be more than one media gateway capable of serving the same > AdmissionRequest (ARQ). > This would accord with the support for alternate gatekeepers in H.323 v4: > "7.2.6 Alternate gatekeeper procedures > For the purposes of ensuring system availability, redundancy, and > scalability, the Gatekeeper may provide the RAS signalling function by > utilizing multiple physical or logical devices, referred to as Alternate > Gatekeepers. If the endpoint supports the Alternate Gatekeeper procedures > defined in this section, it should include the supportsAltGK field in the > GRQ and RRQ messages. > When an endpoint initiates communication with the Gatekeeper, it may be > provided with a list of Alternate Gatekeepers via the GCF message. If the > Gatekeeper does not respond to the subsequent RRQ, the endpoint shall > attempt to register with the Gatekeeper using the list of Alternate > Gatekeepers provided in the GCF. If no Alternate Gatekeeper responds, the > endpoint shall reinitiate the Gatekeeper discovery process." > > The problem is that there are no procedures specified for the use of > alternateEndpoints. > What is it that causes a caller to terminate its Setup attempt to one > destination and to initiate a Setup attempt to the next destination in > priority order? > > Can we presume that the critical event is receiving a ReleaseComplete? > Then how do we determine whether the release reason or cause code is final > (no further Setup should be sent) or not (try another destination)? > Some calls should end after an announcement is played, eg. "The number you > are calling has been disconnected", > and will never succeed no matter how many alternative endpoints are > attempted. > > If the intention of alternateEndpoints has already been clarified > somewhere, please point me to it and excuse my ignorance. > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 >

3 2

Files Uploaded
by Tom-PT Taylor 31 Jan '02

31 Jan '02

I have uploaded the following files to the PictureTel site: d229_T38_SIP.zip IETF Work on T.38 SIP Call Flows Source: Canada (Contact Glen Parsons) d230_T38Dcorr.doc Proposed Changes to Recommendation T.38 Annex D Source: Canada (Contact Glen Parsons) d231_T38D_IANA.doc IANA Registrations for Recommendaiton T.38 Annex D Source: Canada (Contact Glen Parsons) td2-xxxDraftH248M1.zip Draft H.248 Annex M.1 Advanced Audio Server packages For Consent Source: Editor (Contact Tom Taylor) td2-xxx-EdResponseD186.doc Editor's Response To D.186 Source: Editor H.248 Annex M.1 (Contact Tom Taylor) Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)

2 1

Open issue in H.22x
by Horvath Ernst 31 Jan '02

31 Jan '02

Dear experts, attached is a summary regarding an open issue in H.22x (with possible impact on a pargraph in H.225.0 clause 6.1). I'd appreciate any help with improving this unclear piece of text. Regards, Ernst Horvath Siemens AG

1 0

Documents uploaded
by Miner Gleason 28 Jan '02

28 Jan '02

Hello, I have just uploaded to Incoming on the pictel server the following: H225_AnnexG_v2.zip This contains 2 versions of H.225.0 Annex G version 2 document: H225_Annex_G_v2_new.doc : With change marks H225_Annex_G_v2_new-ncm.doc : Without change marks This new version is a major revision, which now relies for its underlying protocol on the new H.22x Recommendation (which itself has been created from the Annex G version 1 protocol definition). It incorporates all submissions to date against version 1, as does the draft H.22x recommendation. Mr. Ernst Horvath of Siemans is the editor of the H.22x recommendation, which is found in: delayed_draft_Recommendation_H22x.zip also on the pictel server. -- best regards, miner --------------------------------------------------------------- Miner Gleason, Software Engineer | | | mgleason(a)cisco.com | :|: :|: 7025 Kit Creek Road, P.O. Box 14987 | :|||||: :|||||: Research Triangle Park, NC 27709-4987 | .:|||||||:.:|||||||:. 919-392-8752 fax: 919-392-7605 | c i s c o S y s t e m s

2 1

Re: Minutes of the 3rd Q.5 Teleconference jointly with Q.2 and Q. G experts; January 25, 16:00 - 17:35 CET
by Euchner Martin ICN M SR 3 28 Jan '02

28 Jan '02

Ok, this make much more sense now. Thanks Miner, for pointing this out. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 47713 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Miner Gleason [mailto:mgleason@cisco.com] Sent: Monday, January 28, 2002 5:02 PM To: ITU-SG16(a)echo.jf.INTEL.COM Cc: Euchner Martin ICN M SR 3 Subject: Re: Minutes of the 3rd Q.5 Teleconference jointly with Q.2 and Q.G experts; January 25, 16:00 - 17:35 CET Hello, I would like to make one small correction to the minutes published today by Mr. Euchner. Euchner Martin ICN M SR 3 wrote: > - The AccessRequest messages have been removed in H.22x. > However, some more input is needed regarding the optional features. This > appears not really crucial as this issue is considered as for further study. The AccessRequest messages have not been removed (at least i hope not, they are an essential part of the protocol!). Rather it is the "capabilities" field in the AccessRequest message that was removed. This field was added by a submission to the Dublin Rapporteur's meeting; the submission was later withdrawn. -- best regards, miner --------------------------------------------------------------- Miner Gleason, Software Engineer | | | mgleason(a)cisco.com | :|: :|: 7025 Kit Creek Road, P.O. Box 14987 | :|||||: :|||||: Research Triangle Park, NC 27709-4987 | .:|||||||:.:|||||||:. 919-392-8752 fax: 919-392-7065 | c i s c o S y s t e m s

1 0

Minutes of the 3rd Q.5 Teleconference jointly with Q.2 and Q.G ex perts; January 25, 16:00 - 17:35 CET
by Euchner Martin ICN M SR 3 28 Jan '02

28 Jan '02

Minutes of the 3rd Q.5 Teleconference jointly with Q.2 and Q.G experts January 25, 16:00 - 17:35 CET Participants: * Minor Gleason (CICSO), H.225.0 Annex GV2 Editor * Martin Euchner (Siemens AG), H.235 Annex G.1 Editor * Paul Reddy (Intel Corp), Q.5 Rapporteur * Ernst Horvath (Siemens AG); Editor of H.22x and of H.MMS.1 * Francois Bougant (France Telecom), Editor of H.MMS.0 * Radhika Roy (ATT) Mr. Euchner volunteered as teleconference chair and took down notes for the meeting minutes as shown below. Agenda: 1. H.22x Status and progress 2. H.MMS.1 Status and progress 3. H.MMS.0 Status and progress 4. H.235 Annex G.1 and new key management protocol: status and progress 5. H.225.0 Annex Gv2 Status and progress 6. Resolution of potential between H.22x and H.225.0 Annex Gv2 7. Open Issues 8. Discussion on protocol design 9. Preparation for the Geneva SG meeting 10. AOB After the initial get together and introduction, the agenda was settled. The goal of this teleconference was to obtain understanding in the current situation of the drafts, resolve critical and controversial issues and prepare for the SG16 meeting ahead. As part of this, the editors gave a brief status report on the draft recommendations. Ad 1) Mr. Horvath first gave some background information on the decision made in Dublin, to create a separate draft recommendation H.22x for mobility purposes. The current draft as submitted in a recent delayed contribution shows only minor changes against the previous version since the last teleconference. The editor believes that the document is ready to be finalized to go into consent. Ad 2) Then, Mr. Horvath reported on the status of H.MMS.1. That draft has not been updated since the last teleconference. The content is seen as stable and the editor believes that the document is ready to be finalized to go into consent. Ad 3.) Mr. Bougant gave status on H.MMS.0. That draft is scheduled for consent in October 2002. He feels that there is not yet full consensus upon the contents and some more work and considerations are necessary. It was agreed that the topic of H.MMS.0 is not as urgent for the upcoming SG meeting; thus, this agenda item was postponed. Ad 4.) Mr. Euchner pointed to two delayed contributions regarding H.235 Annex G. One contribution requests to separate security for user/terminal mobility from the generic mobility management security issues. This would narrow the scope of H.235 Annex G.1. It is proposed to address the user/terminal mobility security issues in a distinct H.235 annex G.1. Another delayed contribution proposes an entirely new and improved key management & security protocol for H.235 Annex G.1. That document has undergone substantial revision since the last teleconference: several open issues are now solved such as terminal authentication, missing procedures added and much more editorial cleanup. Ad 5). Mr. Gleason briefly reported on the situation regarding H.225.0 annex Gv2. He mentioned to have an alternative draft in preparation, but he has not made any submissions yet. This would depend on the outcome of the teleconference, he said. Ad 6.) Some emails have been exchanged via the reflector prior to the conference, addressing concerns and attempts on clarification on potential overlap between H.225.0 Annex G and H.22x. The editor pointed out that he removed the overlap on the border elements. He has chosen a neutral term "peer entity" that could be applied to any mobility functional entity. The group agreed to this procedure and the concerns were basically settled. The next question was how to document this important distinction? Further Mr. Bougant asked how H.22x relates against call-related services with open interfaces of service control nodes and external databases of a generic mobility management protocol? It was generally understood that H.22x goes far beyond H.323 without explicitly addressing call related services. However, mobility and management issues are within the scope of H.22x. It was agreed that keeping H.22x separate from H.225.0 Annex G is seen as the better and clearer way. A clear and unambiguous name of draft H.22x needs to be chosen. Some ideas such as "Communication protocol among entities", "Mobility of Multimedia Systems" or the editors title in the delayed contribution should be considered as input. However, it was also pointed out, that the title should somehow address the relationship with call control and in general, some taxonomy would really be helpful. The terminology and scope should be general enough and as such not be limited to Annex G and border elements. As an action item, the editor(s) will work this issue out and make some proposals for that matter (first on mailing list if possible and then as input to the SG16 Q.5 discussion). Ad 7.) Several open issues in the drafts deserve resolution until finalizing the documents. In general, all experts are requested to carefully review the available documents for consent and assist in resolving any existing or new open issues. The editors briefly touched the most urgent issues and showed where more work is needed. 7.1 Open issues in the H.22x Delayed Contribution: - Page 8 points out an open issue regarding the different usage of TPKT for UDP vs. TCP. That problem actually refers to Annex G.1, but it is not fully understood yet in the light of H.22x. As no Annex Gv1 experts were present who could give reasoning, it was suggested to raise this issue on the mailing list, perhaps additionally asking VocalTec on some hints. - The AccessRequest messages have been removed in H.22x. However, some more input is needed regarding the optional features. This appears not really crucial as this issue is considered as for further study. - Editors note 1 in section 5.4: It was proposed to use the neutral term "peer element" instead of "border element". - The second editors note could be removed. - The OID for H.22x is proposed to be the same as for H.225.0 Annex G unless someone comes with a counterproposal. A question was raised how to potentially incorporate and address further messages for H.22x at some point in the future. It was said, that doing this would be well possible, based upon the available extension mechanism. - An editorial inconsistency was pointed out regarding full names such as AccessRejection (Annex G, H.22x) vs. AuthenticationReject (H.235 Annex G.1). It was agreed to use the long names consistently in all documents; the editors of H.22x and H.235 Annex G.1 will change the text accordingly. 7.2 Open issues in H.MMS.1: - An open issue appears on page 2 regarding the identification to put into the address pattern (email ID or URL form?). While no apparent solution was immediately available, experts are requested to think about this issue and come up with proposals. - It was desired to have the Q.2 experts review the correct and inline usage of the RAS messages. - Q.5 experts should review the used terminology such as e.g. "H.323 mobile terminal" or consider potential alternative names like "hosting terminal". - The H.MMS.1 architecture is described to be fully self-contained without any forward reference to H.MMS.0 generic mobility management architecture. Mr. Bougant considers H.MMS.1 architecture as a subset of the H.MMS.1 architecture, where H.MMS.0 addresses a broader scope and being separate from the H.MMS.1 with H.323 specific aspects. It was also said that the names and reference points were chosen differently from those in H.MMS.0. Ad 10) Mr. Reddy asked on whether contributions were submitted regarding H.MMS.3 "Presence" and H.MMS.4"Instant Messaging". At that point in time, no such contribution were identified, but also not precluded to be somewhere in the queue as the TSB has not yet completed its job. The chair closed the Teleconference by thanking all the participants for joining and helping make progress in the matters. He wished everyone a safe journey to Geneva. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 47713 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm> | D-81359 Muenchen Internet: http://www.siemens.de/ <http://www.siemens.de/> | __________________ | Germany -----------------------------------------------------------------------

2 1

Re: [imtch323implementors] Conference Alias
by Paul E. Jones 26 Jan '02

26 Jan '02

Aparna, There are no special "conference aliases", as you suggest, the term is used to refer to terminal aliases that represent a conference. For example, an MCU might register with the dialedDigits alias "1234". If the user dials 1234, the call would be directed to the MCU that registered the alias. If the MCU wishes to use this method for directing calls, it would be reasonable for the MCU to register an alias for each conference. However, H.323 does not limit the actual implementation. You could certainly build an MCU that presents the user with a greeting asking for the conference ID to be entered when the user dials the number. This is typical with traditional conference bridges. Paul ----- Original Message ----- From: "Aparna Kuppachi" <aparna_mlist(a)yahoo.com> To: <imtch323implementors(a)mail.imtc.org>; <ITU-SG16(a)echo.jf.INTEL.COM> Sent: Monday, January 21, 2002 11:54 PM Subject: [imtch323implementors] Conference Alias > Hi, > > Sec 8.1.13 of H323v4 talks about establishing > conference calls using "conference aliases". If a GK > is present in the network, and EPs perform ARQ > procedures using the conference alias, how does the GK > resolve the conference alias to one of the MCUs > registered with it? Does an MCU register with the > conference alias as one of its terminal aliases in its > initial RRQ with the GK ? Also, does an MCU have to > register with multiple conference aliases in order to > support multiple simultaneous conferences ? > > Regards, > Aparna. > > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > > --- > You are currently subscribed to imtch323implementors as: paulej(a)packetizer.com > To unsubscribe send a blank email to leave-imtch323implementors-35197H(a)mail.imtc.org >

1 0

8 documents uploaded
by OKUBO Sakae 25 Jan '02

25 Jan '02

Dear SG16 experts, The following 8 documents are now available at: using browser http://standard.pictel.com/ftp/avc-site/0202_Gen/ using ftp tool ftp://standard.pictel.com/avc-site/0202_Gen/ At 09:43 +0100 02/01/25, Euchner Martin ICN M SR 3 wrote: >I've just uploaded a Siemens delayed contribution "delayed new H.235 Annex >G_KM.1.zip" with the Title "Improved key-management and security protocol >for H.235 Annex G.1" to the Incoming directory. The same file is also >stored in the Q5Conf directory for potential consideration during the >Mobility Teleconference today. > >You may also find two Rapporteurs TDs: >"Rapp-TD H235AnnexF.zip" with the title "Draft recommendationH.235 Annex F >"Hybrid Security Profile" for Consent" >and >"pl-xxx Identification of References from H.235v3 (per Recommendation >A.5).zip" with the title "Identification of References from H.235v3 (per >Recommendation A.5)" At 10:19 -0500 02/01/25, Sasha Ruditsky wrote: >I've just uploaded 2 delayed contributions > >delayed_SSRC.zip with title "Multiplexing of RTP/RTCP streams" >and delayed_Description.zip with title "Adding description to the H.245 >channels" > >to the Incoming directory. This contributions are resubmissions of the TDs >20 and 26 from the Dubling meeting. from Cisco >requery.zip >MoIP Signalling in H.323.doc >Call Identifier.doc Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 *********************************************************

1 0

H323 Implementers Guide inconsistency in 6.9.10
by Lyons, Terry 25 Jan '02

25 Jan '02

A small discrepancy has come to our attention: If the intent is to change the value of bit M from 0 to 1, then the description should change too from non-ISDN to ISDN. 6.9.10 Technical Correction Relating to Sending ACM Description: Section C.7.1.3 contains a technical error in the assignment of the values of M, K and I. The corrected text is shown below. [Begin Correction] C.7.1.3 Sending of the Address Complete Message (ACM) Backward call indicators If bit I is 1 0 then: bit K ISDN user part indicator 1 ISDN user part used all the way If bit I is 0 then: bit M ISDN access indicator 01 terminating access non-ISDN [End Correction] The meaning of bit M whether 0 or 1 is defined by 3.5/Q.763 bit M ISDN access indicator 0 terminating access non-ISDN 1 terminating access ISDN - TLyons(a)sonusnet.com +1 732 625-3003 ext 212

1 0

delayed contribution uploaded
by Sasha Ruditsky 25 Jan '02

25 Jan '02

I've just uploaded 2 delayed contributions delayed_SSRC.zip with title "Multiplexing of RTP/RTCP streams" and delayed_Description.zip with title "Adding description to the H.245 channels" to the Incoming directory. This contributions are resubmissions of the TDs 20 and 26 from the Dubling meeting. Thanks, Sasha Ruditsky

1 0