- sg16-avd - lists.packetizer.com

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