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

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

H.248 Implementors Guide
by Terry L Anderson 24 Jan '02

24 Jan '02

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 please ignore the TD_H248IG.doc which failed during upload and so is incomplete. Note that there are likely to be additions to the IG during the meeting in Geneva. -- ------------------------------------------------------------ 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

1 0

New ITU-SG16 Mail Server
by Meyer, Greg W 24 Jan '02

24 Jan '02

All: As you may have already noticed, the ITU-SG16 mail list has a new server, echo.jf.intel.com. You may continue to send mail to the old server, mailbag.intel.com, and it will be redirected to the new server. You may also, of course, send mail directly to the new server (itu-sg16(a)echo.jf.intel.com) All mail you receive from the ITU-SG16 will be from the new server so this may affect your email filter properties. The procedures will also continue unchanged. All the properties for LISTSERV have been carried over to the new server. This means that you will continue to confirm any messages that you send to the list. By the way, I appreciate the comments (very positive) from this list for this new procedure. As a side benefit, if you receive a confirmation for a message you didn't send to the list, it indicates that you are infected with an email virus or someone is spoofing your address (so please don't confirm it!). But primarily, the new procedure has provided greater security against viruses and spam for the members of this mail list. If you have any quesitons or comments, please don't hesitate to contact me. Best Regards, Greg Meyer Intel Labs

1 0

H.460.1 text
by Pete Cordell 24 Jan '02

24 Jan '02

Dear All, I have uploaded the following to the Picturetel Incoming 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. All the best, Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 =============================================

1 0

delayed contributions
by Horvath Ernst 24 Jan '02

24 Jan '02

Dear experts, I uploaded the following two contributions to /Incoming: <delayed draft Recommendation H22x.zip> <QoS monitoring proposal.zip> The first one may also be relevant for tomorrow's Q.5 conference call. Regards, Ernst Horvath

2 1

Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1
by Meyer, Greg W 24 Jan '02

24 Jan '02

Forwarded per Mr. Roy's request (his IT dept is working on the problem). -----Original Message----- From: Roy, Radhika R, ALASO Sent: Thursday, January 24, 2002 9:17 AM To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16(a)echo.jf.INTEL.COM Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Hi, Mr. Bougant and All: If I understand your argument, it is this: "an annex of H.225, It would not be possible to make it evolve in order to meet the requirements of multimedia services THAT WOULD NOT BE call related." Now let us examine: What is H.225.0 Annex G protocol that is used among the BEs? Is not a kind of H.225.0 RAS messages that is de-coupled from the H.225.0 Q.931/932 call setup? So, from technical point of view, it is this: H.225.0 Annex G and the proposed H.22x are working in the same space. If we want to deprecate H.225.0 Annex G without enhancing it, only then, we can work for H.22x. The only advantage for H.22x that I see it is non-technical: The mobility group (Q.5) will be able to work independently without going through a process for enhancing of H.225.0 Annex G that is controlled by another group (Q.2). Now, my question to all SG16 members: Do you all want to support H.22x (instead of extending H.225.0 Annex G)? I have made points clearly and adequately. Now I will leave the matter to all other SG16 members to decide. I will keep myself off leaving the decision entirely to other SG16 members. Finally, I like to thank all members for participating in the debate. The bottom line is this: Let us decide H.22x or Enhancement of H.225.0 Annex G for mobility in the upcoming SG16 meeting. Best regards, Radhika R. Roy -----Original Message----- From: BOUGANT François FTRD/DAC/ISS [mailto:francois.bougant@RD.FRANCETELECOM.COM] Sent: Thursday, January 24, 2002 8:15 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Hi all, I fully agree with the arguments previously expressed by Ernst Orvath for H.22x in the specific context (H.22X being an enhanced version of H.225 annex G v2 draft). So I vote for H.22x. If such this MM protocol becomes a standard as an annex of H.225, It would not be possible to make it evolve in order to meet the requirements of multimedia services THAT WOULD NOT BE call related. This doesn't fit our decision to design a generic MM protocol. This justifies the "documentation" advantage as mentionned by Ernst. Anyway, considering the short time remaining until the plenary meeting, I would suggest to discuss also about the protocol design itself. Cordially François Bougant France Telecom -----Message d'origine----- De : Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] Envoyé : mercredi 23 janvier 2002 19:21 À : ITU-SG16(a)echo.jf.INTEL.COM Objet : Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Forwarded per Mr. Roy's request... -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Monday, January 21, 2002 6:12 AM To: Horvath Ernst; ITU-SG16(a)echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 ( Mr. Meyer: I would appreciate if you would kindly forward my message to the SG16 reflector.) Hi, Mr. Ernst: I understand your points. Now the question is: Do we want to kill or deprecate H.225.0 Annex G in the longer term through standardization of H.22x? Let us debate the pros and cons of H.22x from technical point of view (I will withdraw my objections to H.22x if sufficient technical arguments are provided). This is the fundamental debate for all of us in the SG16. So far, I have voted for enhancement of H.225.0 Annex G for mobility (because H.22x differs from H.225.0 Annex G by only 2/3 messages and does not say why it has to be fundamentally different from H.225.0 Annex G.) Best regards, Radhika R. Roy rrroy(a)att.com

1 0

Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1
by BOUGANT François FTRD/DAC/ISS 24 Jan '02

24 Jan '02

Hi all, I fully agree with the arguments previously expressed by Ernst Orvath for H.22x in the specific context (H.22X being an enhanced version of H.225 annex G v2 draft). So I vote for H.22x. If such this MM protocol becomes a standard as an annex of H.225, It would not be possible to make it evolve in order to meet the requirements of multimedia services THAT WOULD NOT BE call related. This doesn't fit our decision to design a generic MM protocol. This justifies the "documentation" advantage as mentionned by Ernst. Anyway, considering the short time remaining until the plenary meeting, I would suggest to discuss also about the protocol design itself. Cordially François Bougant France Telecom -----Message d'origine----- De : Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] Envoyé : mercredi 23 janvier 2002 19:21 À : ITU-SG16(a)echo.jf.INTEL.COM Objet : Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Forwarded per Mr. Roy's request... -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Monday, January 21, 2002 6:12 AM To: Horvath Ernst; ITU-SG16(a)echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 ( Mr. Meyer: I would appreciate if you would kindly forward my message to the SG16 reflector.) Hi, Mr. Ernst: I understand your points. Now the question is: Do we want to kill or deprecate H.225.0 Annex G in the longer term through standardization of H.22x? Let us debate the pros and cons of H.22x from technical point of view (I will withdraw my objections to H.22x if sufficient technical arguments are provided). This is the fundamental debate for all of us in the SG16. So far, I have voted for enhancement of H.225.0 Annex G for mobility (because H.22x differs from H.225.0 Annex G by only 2/3 messages and does not say why it has to be fundamentally different from H.225.0 Annex G.) Best regards, Radhika R. Roy rrroy(a)att.com

1 0

delayed contribution "Accepting a ServiceChange (HandOff) from se condary MGC"
by Euchner Martin ICN M SR 3 24 Jan '02

24 Jan '02

On behalf of Mr. Leis, let me announce uploaded delayed contribution from Siemens "Accepting a ServiceChange (HandOff) from secondary MGC"" as service_change_contri.zip in the Incoming directory of the Pictel FTP server. 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 ----------------------------------------------------------------------- -----Original Message----- From: Leis Peter ICM N PG SP ST SN 1 Sent: Thursday, January 24, 2002 9:37 AM To: Euchner Martin ICN M SR 3 Subject: delayed contribution Hi, could you please upload the attached delayed contribution 'Accepting a ServiceChange (HandOff) from secondary MGC' to the PICTEL server and send an email to the reflector Peter Leis -------------------------------------------------- Peter Leis Siemens AG ICM N PG SP ST SN 1 phone +49 89 722 26200 fax +49 89 722 32806 email peter.leis(a)icn.siemens.de -------------------------------------------------- <mailto:peter.leis@icn.siemens.de------------------------------------------- ------->

1 0

3rd Q.5 Teleconference on 25th January 2002
by Euchner Martin ICN M SR 3 24 Jan '02

24 Jan '02

Folks, Tomorrow, we will have our third Q.5 teleconference on mobility jointly with Q.2 and Q.G experts. The conference will take at most 2 hours as shown below. Please submit any temporary documents for consideration as soon as possible and place them in the ftp://140.242.1.131/avc-site/Incoming/Q5conf/ <ftp://140.242.1.131/avc-site/Incoming/Q5conf/> Directory. Please also suggest any topics which you like to have covered: Here is my proposal for the agenda: * H.22x Status and progress * H.MMS.1 Status and progress * H.MMS.0 Status and progress * Resolution of potential overlap between H.22x and H.225.0 annex Gv2 * H.235 Annex G.1 (please see the file "delayed new H.235 AnnexG.1.zip" in the Q5conf directory) * Open issues * Preparation for the Geneva SG meeting * AOB Conference Call Meeting 3: Start: Jan 25, 2002 07:00 Pacific Time End: Jan 25, 2002 09:00 Pacific Time Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 3708752 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 Siemens contributions
by Euchner Martin ICN M SR 3 24 Jan '02

24 Jan '02

Yes it's true. I uploaded yesterday evening two of our delayed contributions to the Incoming directory without announcing them. delayed_AES.zip "Proposal to separate H.235 Annex G security into new Annex G.1 for User/Terminal Security and address Generic Mobility Management Security in another document" delayed_new_H.235_AnnexG.1.zip "Inclusion of the AES encryption algorithm to H.235V3" However, I can't find them anywhere. Thus, I uploaded them again to the Incoming directory. 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: Thursday, January 24, 2002 4:32 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Fwd: Editors TD for H.248 Annex M.ka Dear SG16 experts, At 16:31 -0500 02/01/23, Terry L Anderson wrote: >I have uploaded a copy of the Editors TD for H.248 Annex M.ka >(KeepAlive) to the avc-site/incoming directory as: > >TD_H248AnM.keepAlive.zip This and other three documents have been moved to the /0202_Gen directory. delayed_AES.zip delayed_new_H.235_AnnexG.1.zip TD_H248AnM.keepAlive.zip h.460.4.zip You can download them from: 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

Re: [jvt-experts] ftp server clogged
by Euchner Martin ICN M SR 3 24 Jan '02

24 Jan '02

For of you having difficulties accessing the clogged PictureTel FTP site with a web browser: Here is a special nice trick (originally figured out by Paul Jones) how to still access the clogged PictureTel FTP site with a web-browser: Use the following URL instead (it works!) ftp://140.242.1.131/avc-site/ 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: Wednesday, January 23, 2002 4:25 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Fwd: [jvt-experts] ftp server clogged Dear Q.D,F,G,2-5/16 experts, Please follow the mentioned guidance for accessing the PictureTel ftp site. 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 ********************************************************* >Subject: [jvt-experts] ftp server clogged >Date: Tue, 22 Jan 2002 17:51:42 -0800 >Thread-Topic: ftp server clogged >Thread-Index: AcGjsIFF/XbIRXXRQL+93YJ7Dh2V0w== >From: "Gary Sullivan" <garysull(a)microsoft.com> >To: <jvt-experts(a)mail.imtc.org> >X-OriginalArrivalTime: 23 Jan 2002 01:51:42.0409 (UTC) >FILETIME=[816D7390:01C1A3B0] >Reply-To: "Gary Sullivan" <garysull(a)microsoft.com> > > >We've had trouble today with the PictureTel ftp server. >Please follow these guidelines when accessing this site >to avoid causing these problems (especially in the next >few days): > >1) When you use the site, log on, do what you need to > do rapidly, and log off. Long pauses keep other > people from using the site and cause timeouts that > leave the server in a bad state. > >2) Don't use an http browser for ftp access. Use a > stand-alone ftp tool instead. The browsers > seem to exhibit behavior that causes difficulties > for the server (like not quitting their sessions). > >3) Turn off any automatic site mirroring programs for > the next few days. Lots of people seem to be > running these things and some of them seem to > be clogging the system. > >I continue to be trying to find a new JVT ftp site >to rectify these problems. > >Best Regards, > >Gary Sullivan >

1 0

Fwd: Uploaded files to Incoming
by OKUBO Sakae 24 Jan '02

24 Jan '02

Dear SG16 experts, They are now available at /0202_Gen of the avc-site. At 16:16 +1100 02/01/24, Christian Groves wrote: >I have placed the following files in the incoming directory. Could you >please move them to the Geneve directory? > >1. [DC-xxx_Annex_L_amm1] Proposed H.248 Annex L Amendment 1 >2. [DC-xxx_Annex_M_1] Comments to H.248 Annex M.1 Audio Server Package >3. [DC-xxx_Annex_M_qac] H.248 Annex M.qac Quality Alert Ceasing Package >4. [DC-xxx_Annex_N] H.248 Annex N SDP H.248 Package Attribute >5. [DC-xxx_Imp_Guide] H.248 Implementors' Guide Additions >6. [DC-xxx_MuxDescription] Clarification of H.248 Mux Descriptor Usage >7. [DC-xxx_Nx64K] Addition of Nx64K Service to the H.248 Mutliplex >descriptor >8. [DC-xxx_Packages_Guide] Packages Guide >9. [DC-xxx_Profile_Pkg] Draft H.248 Annex M.profile Profile Package >10. [DC-xxx_H248v2] Draft H.248v2 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

Fwd: Editors TD for H.248 Annex M.ka
by OKUBO Sakae 23 Jan '02

23 Jan '02

Dear SG16 experts, At 16:31 -0500 02/01/23, Terry L Anderson wrote: >I have uploaded a copy of the Editors TD for H.248 Annex M.ka >(KeepAlive) to the avc-site/incoming directory as: > >TD_H248AnM.keepAlive.zip This and other three documents have been moved to the /0202_Gen directory. delayed_AES.zip delayed_new_H.235_AnnexG.1.zip TD_H248AnM.keepAlive.zip h.460.4.zip You can download them from: 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