- sg16-avd - lists.packetizer.com

H.323 Crypto Support
by Brian C. Wiles 25 Mar '02

25 Mar '02

In reading H.235, it seems to be vary vague with regards to how to setup encryption profiles. Also, I see no mention of other crypto algorithms such as Blowfish. To me, the H.235 support for encryption seems too complicated for something that should just needs to exchange keys and algorithms. In developing our H.323 stack, we decided to use SSL and a couple of simple non-standard parameters to provide the key exchange and algorithm negotiation. The reasons we did this was because: 1.) Crypto can be negotiated within the Setup and Connect messages, 2.) We wanted something that would work without an H.245 channel (H.323 Annex F implementation for example), and 3.) We could not find any H.323 products that supported crypto that we needed to be compatible with in the short term. So, unless there are any objections, I propose we add 2 parameters to the H.225 Setup and Connect messages: cryptoKey OCTET STRING OPTIONAL cryptoAlgorithm CryptoAlgorithm CryptoAlgorithm would then be defined as: CryptoAlgorithm ::= CHOICE { DES NULL, Triple-DES NULL, Blowfish NULL, ... } The cryptoKey would be the raw binary data for the key as the algorithm accepts. Since the program would know the length of the octet string, it could calculate the number of bits, if needed. Other algoritmhs could be added. We should probably set a requirement that all crypto-capable endpoints be able to use one of the above algorithms, to increase the chances of making a secure call. I would vote for Blowfish, but I'm not going to go against the majority if something else wins. Hopefully, I have explained this clearly. I think it's about time we came up with a simple solution that is easy to add new algorithms rather than having to use profiles. Our stack has employed essentially this same technique with non-standard parameters, and it has proved very efficient and stable. Plus, it's about time more H.323 endpoints support crypto since the regulations have been relaxed in the U.S. Any comments/flames? -Brian

3 2

Help requested !
by Gregory 22 Mar '02

22 Mar '02

Hello, I'm a student doing some research about VC for the University libre de Bruxelles. My thesis is about a statement of the different uses of VC. The questionnaire is very easy to fill in (it takes 5 '). I'll let you know about the report once I've done it. Thanks for your help, Grégory DUEZ stagiaire - ULB tél: 071/60 02 59 e-mail : gregoryduez(a)belgacom.net Questionnaire : 1) Why do you use videoconference for ? 2) Since how long have you been using videoconference ? 3) The type of material ? (hardware+software+accessories) 4) What are the advantages and disadvantages of VC ? 5) Don't you have any remarks ? 6) Don't you have any useful contacts (e-mail) of people using VC ? (or you can also forward them this e-mail) 7) Name and activites of your company Thanks for your help !

1 0

Question about "packet-based network originated call"
by Lyons, Terry 21 Mar '02

21 Mar '02

> -----Original Message----- > From: Lyons, Terry > Sent: Monday, March 18, 2002 4:47 PM > To: imtch323implementors(a)mail.imtc.org > Cc: ITU-SG16(a)echo.jf.INTEL.COM; Lyons, Terry > Subject: Question about "packet-based network originated call" > > Is this restriction of H.225.0 enforceable? > ------------------------------------------------------------- > Numbering plan identification (octet No. 3, bits 1-4) > - Encoded following the values and rules of Table 4-11/Q.931. A > number in the form of a dialed digit string should be coded as '0000' > Unknown. If set to '1001' (Private Numbering Plan) in a packet-based > network originated call, this indicates that: > 1) the dialed digit string is not present in Setup; and > 2) the call will be routed via an alias address in the > User-user information. > ------------------------------------------------------------- > > 1. How can one tell if it's a "packet-based network originated call"? > All H.323 Setups of practical interest are carried over a packet-based > network, ie. IP, > but did they originate there or were they gatewayed from a circuit-based > network? > Or is the quoted phrase trying to make some other distinction? > > 2. Talk of the dialed digit string and routing seems to fit best 7.2.2.4 > Called Party Number. > However, the passage reproduced above comes from 7.2.2.6 Calling Party > Number. > > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 >

1 0

SG16 Feb 2002 outputs - H.248v2
by Christian Groves 12 Mar '02

12 Mar '02

G'Day all, I have uploaded to the following Geneve outputs: pl-031r1_H248_v2.zip to: ftp://standard.pictel.com/avc-site/Incoming/ Regards, Christian

2 1

Re: H.323 Series IG as approved in 2002 Geneva SG16 meeting
by OKUBO Sakae 09 Mar '02

09 Mar '02

Dear Mr. Vivek Bhargava, >I have uploaded the H.323 Series Implementer's Guide as H323SeriesIG.doc to >the Incoming directory at the Pictel server. > >Please make it available as an approved document for the February 2002, >Geneva meeting. Now it is available at /0202_Gen directory. 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

Documents from SG16 meeting in Geneva
by Terry L Anderson 04 Mar '02

04 Mar '02

I have uploaded the following documents: pl-029_H.248M_6_InactivityTimer.doc (Consented) pl-033_H248ImplementorsGuide.zip (approved) to the SG16 draft server at: ftp://standard.pictel.com/avc-site/Incoming/ They should soon be moved to: ftp://standard.pictel.com/avc-site/0202_Gen/ Note that since all Implementors Guide items applying to H.248 and Annexes A-E were swept into H.248V1Coregengum and H.248V2, this ImplementorsGuide only contains items applying to other Annexes. New corrections to H.248v1 or v2 will be added to this document in future versions. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

2 1

SG16 Feb 2002 outputs
by Christian Groves 28 Feb '02

28 Feb '02

G'Day all, I have uploaded to the following Geneve outputs: pl-023_H248_Annex_M5.zip pl-024_H248_Annex_N.zip pl-027_H248_Packages_Guide.zip pl-034_H248_Annex_L_amm1.zip 2-073r2_Q3_meeting_report.zip to: ftp://standard.pictel.com/avc-site/Incoming/ Regards, Christian

2 1

0202_Gen documents
by OKUBO Sakae 17 Feb '02

17 Feb '02

Dear SG16 experts, I have moved all the files at /Incoming to /0202_Gen directory. using browser http://standard.pictel.com/ftp/avc-site/0202_Gen/ using ftp tool ftp://standard.pictel.com/avc-site/0202_Gen/ Using this opportunity, can I ask the following? 1) to Rapporteurs and Editors Please upload the output documents for the Geneva meeting last two weeks to /Incoming. Mr. Tosco's WP2 report is already available as /0202_Gen/WP2_report_020215.zip. Please note again that the PictureTel site is not to mirror the ITU TIES site, but used for the benefits of experts based on the voluntary efforts of the contributors. Post an announcement at the reflector when you have uploaded your document. 2) to everybody Please refrain from using space in your file name when you upload a file at /Incoming. Use of _ is suggested. It eases file manipulation such as zip and move. 3) to Q5 Rapporteur and Editors I found several mobility related files at /Incoming. Please advise me if some of them are working documents thus can be deleted. 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

Re: avd-2152
by Tom-PT Taylor 17 Feb '02

17 Feb '02

Here is the relevant passage from the Dublin meeting report: AVD-2152 - Metrology proposal for Multimedia [France Telecom] The contribution was discussed and it was agreed that the proposals, particularly those on modelling bursty packet loss should be incorporated into the draft of H.mmclass. An editing group met to produce a first draft of H.mmclass. This is contained in TD-31 and was presented and agreed by the meeting. -----Original Message----- From: Freytsis, Ilya [mailto:ifreytsis@CETACEAN.COM] Sent: Wednesday, February 13, 2002 6:47 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: avd-2152 Hello, Could anybody tell me if any further work was done to follow this AVD submitted for the meeting in Dublin? Was it discussed in Dublin? Thank you. Ilya Freytsis Principal Engineer Cetacean Networks Inc. ph. (603) 766-6065 fax (603) 766-7190 ifreytsis(a)cetacean.com

1 0

Reports of the Working Party 2
by OKUBO Sakae 15 Feb '02

15 Feb '02

Dear SG16 experts, We have just finished the SG16 meeting in Geneva. I have placed the following report of Working Party 2 that Mr. Tosco and Rapporteurs generated at the Incoming directory of the PictureTel ftp site. It will be moved to /0202_Gen without notice. So please find it either at /Incoming or /0202_Gen. using browser http://standard.pictel.com/ftp/avc-site/Incoming/WP2_report_020215.zip using ftp tool ftp://standard.pictel.com/avc-site/Incoming/WP2_report_020215.zip It consists of the following six files: Report Part I 2.02r.doc -- report of the discussions Rep. Part II 2.02r.doc -- list of documents for consented/approved Liaison statements 2.02r.doc -- liaison statements to be sent out Meetings Rep 2.02r.doc -- plan of interim meetings Status Report 2.02r.doc -- Status Report for Recommendations of WP2/16 sg16wkpr WP2r.doc -- WP2 work program 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

ASN.1 Information
by Paul E. Jones 14 Feb '02

14 Feb '02

Folks, An interesting presentation was given to attendees of the ITU-T SG16 meeting attendees this past week by Mr. Olivier Dubuisson on the topic of ASN.1. You can preview the slides at: http://asn1.elibel.tm.fr/biblio/improve-your-ASN1-specifications.htm or download the zipped PowerPoint file from: http://asn1.elibel.tm.fr/biblio/improve-your-ASN1-specifications.zip Best Regards, Paul

1 0

avd-2152
by Freytsis, Ilya 13 Feb '02

13 Feb '02

Hello, Could anybody tell me if any further work was done to follow this AVD submitted for the meeting in Dublin? Was it discussed in Dublin? Thank you. Ilya Freytsis Principal Engineer Cetacean Networks Inc. ph. (603) 766-6065 fax (603) 766-7190 ifreytsis(a)cetacean.com

1 0

Re: Annex O
by OKUBO Sakae 04 Feb '02

04 Feb '02

Dear Orit, >I am experiencing some problems with the PictureTel site. >Could you, please, upload the attached documentto the Geneva directory? It is now available at the following place: using browser http://standard.pictel.com/ftp/avc-site/0202_Gen/AnnexO.zip using ftp tool ftp://standard.pictel.com/avc-site/0202_Gen/AnnexO.zip 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

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

H.235 OIDs collision
by Euchner Martin ICN M SR 3 25 Jan '02

25 Jan '02

All, A clash of overlapping OIDs values has been detected in H.235Version 2. OIDs "K", "L" and "M" in the Appendix I currently have the same value assigned as OIDs "A", "B" and "R" of Annex E. However, of course each of the mentioned OIDs shall have a unique value in order to unambiguously identify its purpose. Implementations deploying OIDs from Annex E and Appendix I might thus currently run into interoperability problems. It is proposed to re-allocate the OIDs in Appendix I with new and distinct values (see below). Object Identifier Reference Object Identifier Value Description "K" {itu-t (0) recommendation (0) h (8) 235 version (0) 2 31} indicates a RADIUS challenge in the ClearToken "L" {itu-t (0) recommendation (0) h (8) 235 version (0) 2 32} indicates a RADIUS response (conveyed in the challenge field) in the ClearToken "M" {itu-t (0) recommendation (0) h (8) 235 version (0) 2 33} indicates BES default mode with a protected password in the ClearToken Table I.1/H.235: Object Identifiers used by Appendix I.4.6 Please, let me hear your opinion on whether the proposal appears acceptable, or suggest your alternative otherwise. 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 -----------------------------------------------------------------------

1 0

delayed contribution uploaded and some Rapporteurs TDs uploaded
by Euchner Martin ICN M SR 3 25 Jan '02

25 Jan '02

Dear all, 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 recommendation H.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)" 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: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Friday, January 25, 2002 3:33 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Documents uploaded Dear SG16 experts, At 16:10 +0000 02/01/24, Pete Cordell wrote: >I have uploaded the following to the PicturetelIncoming directory and >submitted it to the TSB: > >Draft Recommendation H.460.1 - Guidelines for the Use of the Generic >Extensible Framework > >It is much the same text as submitted to the Dublin meeting except for a >few editorial changes, mentioning XML as an option for the encoded in raw >form, and specifying that the standard identifier of an ITU-T defined >module is related to its identity in the H.460.n series of recommendations. At 12:44 -0500 02/01/24, Terry L Anderson wrote: >I have uploaded a copy of the the Editors TD for H.248 Implementors >Guide to the avc-site/Incoming directory as TD_H248IG.zip >[...] >Note that there are likely to be additions to the IG during the meeting >in Geneva. They have been moved to: using browser http://standard.pictel.com/ftp/avc-site/0202_Gen/ using ftp tool ftp://standard.pictel.com/avc-site/0202_Gen/ 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

Documents uploaded
by OKUBO Sakae 24 Jan '02

24 Jan '02

Dear SG16 experts, At 16:10 +0000 02/01/24, Pete Cordell wrote: >I have uploaded the following to the PicturetelIncoming directory and >submitted it to the TSB: > >Draft Recommendation H.460.1 - Guidelines for the Use of the Generic >Extensible Framework > >It is much the same text as submitted to the Dublin meeting except for a >few editorial changes, mentioning XML as an option for the encoded in raw >form, and specifying that the standard identifier of an ITU-T defined >module is related to its identity in the H.460.n series of recommendations. At 12:44 -0500 02/01/24, Terry L Anderson wrote: >I have uploaded a copy of the the Editors TD for H.248 Implementors >Guide to the avc-site/Incoming directory as TD_H248IG.zip >[...] >Note that there are likely to be additions to the IG during the meeting >in Geneva. They have been moved to: using browser http://standard.pictel.com/ftp/avc-site/0202_Gen/ using ftp tool ftp://standard.pictel.com/avc-site/0202_Gen/ 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