- sg16-avd - lists.packetizer.com

PCS2001 Final Call for Papers
by ȣ�伺 03 Oct '00

03 Oct '00

Please find attached Final Call for Papers of Picture Coding Symposium 2001 to be held in Seoul, Korea during 25 April - 27 April, 2001. The deadline for paper submission, 15 October 2000, is coming soon. Updated paper submissioin information is at http://pcs.kaist.ac.kr. For further information, please send an email to pcs(a)pcs.kaist.ac.kr. We look forward to seeing you at the exciting PCS2001. Best Regards, Yo-Sung Ho ********************************************************** Yo-Sung Ho, Associate Professor Department of Information and Communications Kwang-Ju Institute of Science and Technology (K-JIST) 1 Oryong-Dong Puk-Gu Kwangju, 500-712, Korea TEL: +82-62-970-2211 FAX: +82-62-970-2204 EMAIL: hoyo(a)kjist.ac.kr **********************************************************

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 03 Oct '00

03 Oct '00

Hi, Everyone: The bottom line is that H.323 Annex H has done its own job. Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times): Part 1: Within the scope of Q.13/16: Extension of H.323(e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs.(Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.). It has done something that it MUST not do in the first place (exceeding the mandate Q.13/16). I am in full agreement with Dr. Jean-Claude Samou of France Telecom. AT&T is also planning to bring contributions in WP2/16 in the upcoming SG meeting (Nov'00). Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Tuesday, October 03, 2000 9:27 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi all, Maybe I should first clear up a potential misunderstanding. I don't think anyone in the Mobility ad hoc group is trying to avoid taking the work done in IMT-2000 or 3GPP into account. In fact we have used the IMT-2000 specification in our work already quite a lot (it is not a coincidence that the requirements, etc. are so similar between H.323 Annex H and IMT-2000) and definitely we would like to follow the IMT-2000 framework as much as we see possible (further co-operation and meetings would certainly be a positive thing). Also I am currently working on making the terminology of Annex H to correspond better to the 3GPP terminology as was requested in the Portland meeting. Furthermore, one of my intentions when encouraging people to come up with contributions for the Mobility Management procedures (information flows) of the annex has been to get propositions that might be better in line with especially the 3GPP work. Unfortunately I feel that I myself am not yet enough of an expert in 3GPP issues to be able to do that. However, I think the general feeling in the ad hoc group has been that the 3GPP and IMT-2000 specifications on the Mobility Management procedures will still take quite long before being ready. Another issue that has been raised is the question of possible (or probable) unnecessary complexity of the coming 3G Mobility Management protocols for enterprise usage. Thus a need to specify simple procedures for the Mobility Management quite quickly for H.323 has been recognized and this would also necessitate the definition of protocols or specifying how existing protocols would be used between the VLFs and HLFs for instance. In the absense of propositions to use other existing or future protocols, the annex draft at the moment suggests the usage of somewhat altered H.225 Annex G protocol as the Mobility Management protocol to be used between the GKs, VLFs, HLFs and AuFs (I think we should also limit the interfaces we are defining for the first version of the annex to perhaps just handle the VLF-HLF communications...). The good thing about this approach would, at least, be the easy addition to already existing H.323 systems because of the usage of existing (albeit slightly altered) H.323 family protocol. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ > Hi, Everyone: > > Sorry for not getting into the discussion earlier since I was > out of station > for some time. I just logged into my PC and saw your > interesting e-mail > discussion on mobility management protocols (in particular > between the VLF > and HLF). > > I would like to share here some concerns of Radhika Roy on > this matter. As > he clearly points out, the HLF and VLF are only value-added > functions which > are necessary for handling mobility of users. There is > nothing specific in > VLF <-> HLF in terms of mobility with respect packet vs. circuit or > connection oriented vs connectionless, etc. > > As you are probably aware of, the IMT-2000 group in ITU-T > SG11 is currently > working on developing a common mobility management protocol > which should > accomodate various users of different types of mobile systems > (e.g. IS-41, > UMTS, etc). This is the well known FAMILY concept in ITU-T > SG11. SG16 and > SG11 had one joint meeting in the last Feb'00 in Geneva. During this > meeting, this mobility protocol work was briefly introduced > by SG 11 and it > was recognized that the requirements & major concepts identified for > mobility in H.323 networks are very similar to those of > IMT-2000 (since > IMT-2000 should also provide packet-based multi-media > services), and a close > cooperation between these two groups is required on mobility > and roaming > aspects for the benefits of H.323 and IMT-2000 systems. In > addition, this > will allow the roaming of any users between different types > of network (for > instance an H.323 user roaming into an IS-41 or UMTS network and > vice-versa). Therefore, I tend to disagree with Jaakko who says that > IMT-2000 is not defining (or intended for) packet-based networks. For > instance the concept of VLF and HLF are pretty much close to > those of the > LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the > strict reason that > they are both server functions which handle mobility > independently of the > transport networks. Then why not a common protocol for common mobility > requirements and functions? On the other hand, I agree that > Extensions of > H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be > provided by Q.13/16 > since they are very specific to the H.323 type of access. > > Again, I would like to support Radhika in his analysis of > trying to develop > a common solution that fits the need of any type of mobile > users rather than > developing one VLF <-> HLF protocol for H.323, one VLF <-> > HLF for H.321, > etc. Otherwise, it will be a BIG mess for network operators > (as well for > manufacturers) and lead to have different protocols which may be > incompatible between themselves. This will also make the > inter-networking > aspects very tough thereby preventing any global roaming of users. > > FYI, I would also like to inform you that 3GPP has selected > SIP for its > MULTIMEDIA stuff. In this case, how would it be possible to > roam between a > 3GPP network and H.323 network, and with other networks (not using > SIP)unless an inter-connecting pipe such as a common MM > protocol (which > includes SIP mobility, H.323 mobility, IS-41 mobility, etc) > is developed. > > Therefore, I would suggest that we should rather work with a > more global > picture of ITU (as supported by Radhika) than a narrow one > limited to H.323 > mobility only. > > Let me be more positive now. I would really encourage SG16 and SG11 to > closely > cooperate together in order to develop this common protocol > jointly for the > success of ITU. I believe that this step has already started > at the joint > SG16-SG11 meeting in February 00. Why shoudn't this be continued? > > Best regards, > > Jean-Claude Samou, PhD > France Telecom R&D > 38-40, rue du General Leclerc > 92131 Issy les moulineaux > France > > Tel: + 33 1 45 29 58 40 > Fax: + 33 1 46 29 31 62 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Jaakko Sundquist 03 Oct '00

03 Oct '00

Hi all, Maybe I should first clear up a potential misunderstanding. I don't think anyone in the Mobility ad hoc group is trying to avoid taking the work done in IMT-2000 or 3GPP into account. In fact we have used the IMT-2000 specification in our work already quite a lot (it is not a coincidence that the requirements, etc. are so similar between H.323 Annex H and IMT-2000) and definitely we would like to follow the IMT-2000 framework as much as we see possible (further co-operation and meetings would certainly be a positive thing). Also I am currently working on making the terminology of Annex H to correspond better to the 3GPP terminology as was requested in the Portland meeting. Furthermore, one of my intentions when encouraging people to come up with contributions for the Mobility Management procedures (information flows) of the annex has been to get propositions that might be better in line with especially the 3GPP work. Unfortunately I feel that I myself am not yet enough of an expert in 3GPP issues to be able to do that. However, I think the general feeling in the ad hoc group has been that the 3GPP and IMT-2000 specifications on the Mobility Management procedures will still take quite long before being ready. Another issue that has been raised is the question of possible (or probable) unnecessary complexity of the coming 3G Mobility Management protocols for enterprise usage. Thus a need to specify simple procedures for the Mobility Management quite quickly for H.323 has been recognized and this would also necessitate the definition of protocols or specifying how existing protocols would be used between the VLFs and HLFs for instance. In the absense of propositions to use other existing or future protocols, the annex draft at the moment suggests the usage of somewhat altered H.225 Annex G protocol as the Mobility Management protocol to be used between the GKs, VLFs, HLFs and AuFs (I think we should also limit the interfaces we are defining for the first version of the annex to perhaps just handle the VLF-HLF communications...). The good thing about this approach would, at least, be the easy addition to already existing H.323 systems because of the usage of existing (albeit slightly altered) H.323 family protocol. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ > Hi, Everyone: > > Sorry for not getting into the discussion earlier since I was > out of station > for some time. I just logged into my PC and saw your > interesting e-mail > discussion on mobility management protocols (in particular > between the VLF > and HLF). > > I would like to share here some concerns of Radhika Roy on > this matter. As > he clearly points out, the HLF and VLF are only value-added > functions which > are necessary for handling mobility of users. There is > nothing specific in > VLF <-> HLF in terms of mobility with respect packet vs. circuit or > connection oriented vs connectionless, etc. > > As you are probably aware of, the IMT-2000 group in ITU-T > SG11 is currently > working on developing a common mobility management protocol > which should > accomodate various users of different types of mobile systems > (e.g. IS-41, > UMTS, etc). This is the well known FAMILY concept in ITU-T > SG11. SG16 and > SG11 had one joint meeting in the last Feb'00 in Geneva. During this > meeting, this mobility protocol work was briefly introduced > by SG 11 and it > was recognized that the requirements & major concepts identified for > mobility in H.323 networks are very similar to those of > IMT-2000 (since > IMT-2000 should also provide packet-based multi-media > services), and a close > cooperation between these two groups is required on mobility > and roaming > aspects for the benefits of H.323 and IMT-2000 systems. In > addition, this > will allow the roaming of any users between different types > of network (for > instance an H.323 user roaming into an IS-41 or UMTS network and > vice-versa). Therefore, I tend to disagree with Jaakko who says that > IMT-2000 is not defining (or intended for) packet-based networks. For > instance the concept of VLF and HLF are pretty much close to > those of the > LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the > strict reason that > they are both server functions which handle mobility > independently of the > transport networks. Then why not a common protocol for common mobility > requirements and functions? On the other hand, I agree that > Extensions of > H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be > provided by Q.13/16 > since they are very specific to the H.323 type of access. > > Again, I would like to support Radhika in his analysis of > trying to develop > a common solution that fits the need of any type of mobile > users rather than > developing one VLF <-> HLF protocol for H.323, one VLF <-> > HLF for H.321, > etc. Otherwise, it will be a BIG mess for network operators > (as well for > manufacturers) and lead to have different protocols which may be > incompatible between themselves. This will also make the > inter-networking > aspects very tough thereby preventing any global roaming of users. > > FYI, I would also like to inform you that 3GPP has selected > SIP for its > MULTIMEDIA stuff. In this case, how would it be possible to > roam between a > 3GPP network and H.323 network, and with other networks (not using > SIP)unless an inter-connecting pipe such as a common MM > protocol (which > includes SIP mobility, H.323 mobility, IS-41 mobility, etc) > is developed. > > Therefore, I would suggest that we should rather work with a > more global > picture of ITU (as supported by Radhika) than a narrow one > limited to H.323 > mobility only. > > Let me be more positive now. I would really encourage SG16 and SG11 to > closely > cooperate together in order to develop this common protocol > jointly for the > success of ITU. I believe that this step has already started > at the joint > SG16-SG11 meeting in February 00. Why shoudn't this be continued? > > Best regards, > > Jean-Claude Samou, PhD > France Telecom R&D > 38-40, rue du General Leclerc > 92131 Issy les moulineaux > France > > Tel: + 33 1 45 29 58 40 > Fax: + 33 1 46 29 31 62 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

iptel2001 Call for Papers
by Jiri Kuthan 02 Oct '00

02 Oct '00

Call for Papers 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The objectives of the IP Telephony Workshop are to bring together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony are solicited. Only papers with significant technical content, not "white papers" or tutorials, will be considered for publication: - Research papers (unique ideas, novel algorithms, architectures, measurements, theoretical and/or analytical contributions) - Surveys, state-of-the-art studies, technology comparisons - Implementation and deployment reports - Standardization reports Particular areas of interest include, but are not limited to, the following: - Integration with Internet services (e.g., web, instant messaging, games) - Added-value services (e.g., call centers, conferencing) - Mobility and 3rd generation wireless - Authentication, authorization, accounting, charging, settlement - QoS support - Security (e.g., privacy, authentication, certification authorities, firewall traversal) - Call signaling & processing - Feature creation - Supporting services (e.g., call routing, lookup services) - Audio & video encoding and transmission - Management and provisioning - Interworking with the PSTN - Design and deployment considerations (e.g., performance, scalability, reliability) Important Dates --------------- Full paper due November 27th, 2000 Notification of acceptance January 12th, 2001 Final version due January 31st, 2001 Program published and February 5th, 2001 registration opens Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee ------------------------------ Program Chair H. Schulzrinne Columbia University Program Committee M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research K. Mehdi University of Kansas D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. Stüttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin M. Zitterbart Technical University of Braunschweig Submission Instructions ----------------------- Authors are invited to submit full papers written in English before November 27th, 2000. The submissions will be reviewed, and accepted papers will be included in the program. Notifications of acceptance will be sent out on January 12th, 2000. Deadline for submission of camera-ready copies is January 31st, 2001. Authors of accepted papers will need to sign a Copyright Transfer Form and submit a Netbib entry. Papers must be submitted electronically using the Web site at http://www.cs.columbia.edu/iptel Submissions must be in PDF or Postscript; any other documents cannot be accepted. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. Papers must be formatted according to the IEEE Transactions format except for the font size, which MUST be 11pt. Templates are available at the Web site http://www.fokus.gmd.de/events/iptel2001/cfp/ Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, papers with more than 11 pages cannot be reviewed. Submissions must include: title, authors, affiliation, abstract, list of keywords, and contact information. One of the authors of each accepted paper must present the paper at iptel'2001. Contact Address --------------- Please, send all your inquiries regarding iptel2001 to iptel2001(a)egroups.com. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

PV2001 Final Call for Papers
by PV2001 25 Sep '00

25 Sep '00

Please find attached Final Call for Papers of Packet Video Workshop 2001 to be held in Kyungju, Korea During 30 April - 1 May, 2001. The deadline for paper submission, 15 November 2000, is coming soon. Updated paper submissioin information is at http://pv2001.kaist.ac.kr. For further information, please send an email to pv(a)pv2001.kaist.ac.kr. We look forward to an exciting PV2001. Best Regards, Chieteuk Ahn PV2001 Organizing Committee Chair

1 0

Portland meeting report and WP2 workplan in November
by Sakae OKUBO 23 Sep '00

23 Sep '00

Dear Q12-14/16 experts, The report of the Portland meeting APC-1949 has been placed at <http://standard.pictel.com/ftp/avc-site/0008_Por/APC1949.zp> with confirmed status. I have not received any comments. Mr. Tosco's workplan of WP2 in November is available at the following place: <http://standard.pictel.com/ftp/avc-site/0011_Gen/WP2_WorkPlan_Nov_00.zip> Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

TR: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by SAMOU Jean-claude FTRD/DAC/ISS 22 Sep '00

22 Sep '00

Hi, Everyone: Sorry for the disturbance. This is a re-transmission due to some mailing errors. -----Message d'origine----- De: SAMOU Jean-claude FTRD/DAC/ISS [mailto:jeanclaude.samou@RD.FRANCETELECOM.FR] Date: mercredi 20 septembre 2000 18:01 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Sorry for not getting into the discussion earlier since I was out of station for some time. I just logged into my PC and saw your interesting e-mail discussion on mobility management protocols (in particular between the VLF and HLF). I would like to share here some concerns of Radhika Roy on this matter. As he clearly points out, the HLF and VLF are only value-added functions which are necessary for handling mobility of users. There is nothing specific in VLF <-> HLF in terms of mobility with respect packet vs. circuit or connection oriented vs connectionless, etc. As you are probably aware of, the IMT-2000 group in ITU-T SG11 is currently working on developing a common mobility management protocol which should accomodate various users of different types of mobile systems (e.g. IS-41, UMTS, etc). This is the well known FAMILY concept in ITU-T SG11. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. During this meeting, this mobility protocol work was briefly introduced by SG 11 and it was recognized that the requirements & major concepts identified for mobility in H.323 networks are very similar to those of IMT-2000 (since IMT-2000 should also provide packet-based multi-media services), and a close cooperation between these two groups is required on mobility and roaming aspects for the benefits of H.323 and IMT-2000 systems. In addition, this will allow the roaming of any users between different types of network (for instance an H.323 user roaming into an IS-41 or UMTS network and vice-versa). Therefore, I tend to disagree with Jaakko who says that IMT-2000 is not defining (or intended for) packet-based networks. For instance the concept of VLF and HLF are pretty much close to those of the LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the strict reason that they are both server functions which handle mobility independently of the transport networks. Then why not a common protocol for common mobility requirements and functions? On the other hand, I agree that Extensions of H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be provided by Q.13/16 since they are very specific to the H.323 type of access. Again, I would like to support Radhika in his analysis of trying to develop a common solution that fits the need of any type of mobile users rather than developing one VLF <-> HLF protocol for H.323, one VLF <-> HLF for H.321, etc. Otherwise, it will be a BIG mess for network operators (as well for manufacturers) and lead to have different protocols which may be incompatible between themselves. This will also make the inter-networking aspects very tough thereby preventing any global roaming of users. FYI, I would also like to inform you that 3GPP has selected SIP for its MULTIMEDIA stuff. In this case, how would it be possible to roam between a 3GPP network and H.323 network, and with other networks (not using SIP)unless an inter-connecting pipe such as a common MM protocol (which includes SIP mobility, H.323 mobility, IS-41 mobility, etc) is developed. Therefore, I would suggest that we should rather work with a more global picture of ITU (as supported by Radhika) than a narrow one limited to H.323 mobility only. Let me be more positive now. I would really encourage SG16 and SG11 to closely cooperate together in order to develop this common protocol jointly for the success of ITU. I believe that this step has already started at the joint SG16-SG11 meeting in February 00. Why shoudn't this be continued? Best regards, Jean-Claude Samou, PhD France Telecom R&D 38-40, rue du General Leclerc 92131 Issy les moulineaux France Tel: + 33 1 45 29 58 40 Fax: + 33 1 46 29 31 62 -----Message d'origine----- De: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Date: mardi 19 septembre 2000 14:15 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Let me repeat it again: We have applications H.323, H.321, etc. These are packet-based networks. There are other protocols like H.324 etc, that are optimized for PSTN/ISDN networks. Now the application/middleware layer control protocol like H.245 is applicable for all applications whether an application is sent over the packet networks or circuit-switched networks. Similarly, application/middleware layer VLF <-> HLF and other protocols are nothing do with packet vs. circuit-switched networks. It MUST be a common protocol. There is nothing specific in VLF <-> HLF with respect packet vs. circuit or connection oriented vs connectionless. People are trying to create confusions for fulfilling a VERY narrow objectives ignoring the BIG picture of the ITU. Even for the sake of argument, if we consider the applications only for the packet-switched networks, then we MUST develop the generic protocols like VLF <-> HLF and others that can be used by all protocols like H.323, H.321, etc. that are used by the packet-switched networks. The same argument is true for QOS, billing, authentication, directory, etc, and others. Let us not confuse things. Let us take another case: RSVP, DiffServ, etc. are the network layer QOS protocol. These network layer QOS services can be used by any applications (e.g., H.323, SIP, etc.) over the IP network. That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF <-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc. It is a mess and defeats the fundamental purpose for creating of COMMON standards by the ITU. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, September 18, 2000 7:34 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi Radhika, Paul & others Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323. -Jaakko > -----Original Message----- > From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: 17. September 2000 3:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Hi, Paul: > > I am glad that you have asked this question. > > HLF and VLF are value-added functions, and these server functions are > necessary for any mobile users. IMT-2000 is working to develop these > protocols. SG16 and SG11 had one joint meeting in the last > Feb'00 in Geneva. > These protocols are VLF <-> HLF and others. > > All we (Q.13/16) need to do: An interface with the VLF by the > H.323 GK. > > (An analogy can also given: H.245 is a common set of control > protocol that > is being used by H.323, H.324, and other applications.) > > If there are one or more functions are needed for any reasons that are > specific to H.323, people can always augment that particular > protocol. This > is a fact of life. > > The same is also true for QoS, authentication, accounting, > billing, and > others. > > More importantly, IMT-2000 is dedicated for mobility. > > Our (Q.13/16) primary task is to extend the H.323 protocol > for supporting > mobility (as explained many times) is as follows: > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > If we do NOT this part 1, we are NOT doing our primary job because the > solution will NOT fly. We are rather "building a castle in the air." > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Saturday, September 16, 2000 2:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Radhika, et al, > > I have to confess that I have had no time to really follow > the Annex H work, > but I do have a question to toss out here: > > Why do you consider the VLF or HLF functions outside the > scope of Q13/16? I > assume that these functions are IP-based (or at least used > with the same > call signaling transport as the H.323 system) and integrate > with the H.323 > functions. > > You stated below that these functions are common for all > mobile systems. I > will not argue that point, but will a common solution be the most > appropriate for H.323 systems? I would guess that trying to > introduce a > generic mechanism may or may not be the best solution for H.323. > > I'd like to hear counter arguments to yours. Apparently > others felt that > these functions were necessary for H.323 systems and should be defined > within the H.323 framework. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, September 15, 2000 10:25 AM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > > Hi, Everyone: > > > > The document MD-106 (H.323 Annex H) submitted by the editor remains > > basically same from the fundamentally point of view. So, > the comments > > provided on the September 8 email (copy enclosed) remains > the same as > stated > > earlier. The comments can be summarized as follows: > > > > The Annex should be divided into two parts: > > > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 > [RAS, > > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > > > Part 2: Outside the scope of Q.13/16: Back-end services related to > Mobility > > (or value-added services related mobility) containing VLF and HLF. > > > > So, it can be seen clearly that MD-106 (H.323 Annex H) > submitted by the > > editor does not contain the basic part 1 which is within > the scope of > > Q.13/16 (it rather contains part 2 which is outside the > scope of Q.13/16). > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO > > Sent: Friday, September 08, 2000 10:23 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > > > Hi, Everyone: > > > > The draft does not contain the basic part: Extensions of > H.323 (e.g., > > H.225.0 messages). Contributions are there (e.g., D.354 of > SG16 Feb'00, > > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ > messages > > need to be removed to the base spec of H.323 because there > is nothing > > specific to be done with mobility. If it is used in the context of > mobility, > > the issues related to mobile need to be pointed out so that > contributions > > can be brought to address those issues. Contributions are > there to note > the > > issues. > > > > The another suggestion is to make two parts of the Annex: 1. Basic > extension > > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end > services > > related to Mobility (or value-added services related > mobility)containing > VLF > > and HLF. > > > > Part 2 clearly does not have to be specific to H.323. It is > a general > > service related to mobility. Every application that needs > mobility may > like > > to use these services. This will be addressed in the light > of the all > mobile > > applications of all questions of all SGs of the ITU-T. So, it is > > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes > this decision. > > > > Please note that Security (AuF) is also needed for the > fixed users. So, > this > > is a generic service that needs to be developed for both > fixed and mobile > > users. So, it also belongs to the base H.323 spec. That is, any > > specification related to AuF should be moved to the base > H.323 spec as > well > > because it belong to both and the standard should be developed > accordingly. > > > > For rapid determination, I would suggest to address part 1 > only in the > first > > phase. > > > > More specific technical comments will be given for each > point once the > > primary objectives are clarified. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Thursday, September 14, 2000 7:28 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > > > > Hi all, > > > > I have uploaded MD-106 to URL: > > > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10 6_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

TR: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by SAMOU Jean-claude FTRD/DAC/ISS 21 Sep '00

21 Sep '00

Hi, Everyone: This is a re-transmission due to mailing problems. -----Message d'origine----- De: SAMOU Jean-claude FTRD/DAC/ISS [mailto:jeanclaude.samou@RD.FRANCETELECOM.FR] Date: mercredi 20 septembre 2000 18:01 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Sorry for not getting into the discussion earlier since I was out of station for some time. I just logged into my PC and saw your interesting e-mail discussion on mobility management protocols (in particular between the VLF and HLF). I would like to share here some concerns of Radhika Roy on this matter. As he clearly points out, the HLF and VLF are only value-added functions which are necessary for handling mobility of users. There is nothing specific in VLF <-> HLF in terms of mobility with respect packet vs. circuit or connection oriented vs connectionless, etc. As you are probably aware of, the IMT-2000 group in ITU-T SG11 is currently working on developing a common mobility management protocol which should accomodate various users of different types of mobile systems (e.g. IS-41, UMTS, etc). This is the well known FAMILY concept in ITU-T SG11. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. During this meeting, this mobility protocol work was briefly introduced by SG 11 and it was recognized that the requirements & major concepts identified for mobility in H.323 networks are very similar to those of IMT-2000 (since IMT-2000 should also provide packet-based multi-media services), and a close cooperation between these two groups is required on mobility and roaming aspects for the benefits of H.323 and IMT-2000 systems. In addition, this will allow the roaming of any users between different types of network (for instance an H.323 user roaming into an IS-41 or UMTS network and vice-versa). Therefore, I tend to disagree with Jaakko who says that IMT-2000 is not defining (or intended for) packet-based networks. For instance the concept of VLF and HLF are pretty much close to those of the LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the strict reason that they are both server functions which handle mobility independently of the transport networks. Then why not a common protocol for common mobility requirements and functions? On the other hand, I agree that Extensions of H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be provided by Q.13/16 since they are very specific to the H.323 type of access. Again, I would like to support Radhika in his analysis of trying to develop a common solution that fits the need of any type of mobile users rather than developing one VLF <-> HLF protocol for H.323, one VLF <-> HLF for H.321, etc. Otherwise, it will be a BIG mess for network operators (as well for manufacturers) and lead to have different protocols which may be incompatible between themselves. This will also make the inter-networking aspects very tough thereby preventing any global roaming of users. FYI, I would also like to inform you that 3GPP has selected SIP for its MULTIMEDIA stuff. In this case, how would it be possible to roam between a 3GPP network and H.323 network, and with other networks (not using SIP)unless an inter-connecting pipe such as a common MM protocol (which includes SIP mobility, H.323 mobility, IS-41 mobility, etc) is developed. Therefore, I would suggest that we should rather work with a more global picture of ITU (as supported by Radhika) than a narrow one limited to H.323 mobility only. Let me be more positive now. I would really encourage SG16 and SG11 to closely cooperate together in order to develop this common protocol jointly for the success of ITU. I believe that this step has already started at the joint SG16-SG11 meeting in February 00. Why shoudn't this be continued? Best regards, Jean-Claude Samou, PhD France Telecom R&D 38-40, rue du General Leclerc 92131 Issy les moulineaux France Tel: + 33 1 45 29 58 40 Fax: + 33 1 46 29 31 62 -----Message d'origine----- De: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Date: mardi 19 septembre 2000 14:15 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Let me repeat it again: We have applications H.323, H.321, etc. These are packet-based networks. There are other protocols like H.324 etc, that are optimized for PSTN/ISDN networks. Now the application/middleware layer control protocol like H.245 is applicable for all applications whether an application is sent over the packet networks or circuit-switched networks. Similarly, application/middleware layer VLF <-> HLF and other protocols are nothing do with packet vs. circuit-switched networks. It MUST be a common protocol. There is nothing specific in VLF <-> HLF with respect packet vs. circuit or connection oriented vs connectionless. People are trying to create confusions for fulfilling a VERY narrow objectives ignoring the BIG picture of the ITU. Even for the sake of argument, if we consider the applications only for the packet-switched networks, then we MUST develop the generic protocols like VLF <-> HLF and others that can be used by all protocols like H.323, H.321, etc. that are used by the packet-switched networks. The same argument is true for QOS, billing, authentication, directory, etc, and others. Let us not confuse things. Let us take another case: RSVP, DiffServ, etc. are the network layer QOS protocol. These network layer QOS services can be used by any applications (e.g., H.323, SIP, etc.) over the IP network. That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF <-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc. It is a mess and defeats the fundamental purpose for creating of COMMON standards by the ITU. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, September 18, 2000 7:34 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi Radhika, Paul & others Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323. -Jaakko > -----Original Message----- > From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: 17. September 2000 3:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Hi, Paul: > > I am glad that you have asked this question. > > HLF and VLF are value-added functions, and these server functions are > necessary for any mobile users. IMT-2000 is working to develop these > protocols. SG16 and SG11 had one joint meeting in the last > Feb'00 in Geneva. > These protocols are VLF <-> HLF and others. > > All we (Q.13/16) need to do: An interface with the VLF by the > H.323 GK. > > (An analogy can also given: H.245 is a common set of control > protocol that > is being used by H.323, H.324, and other applications.) > > If there are one or more functions are needed for any reasons that are > specific to H.323, people can always augment that particular > protocol. This > is a fact of life. > > The same is also true for QoS, authentication, accounting, > billing, and > others. > > More importantly, IMT-2000 is dedicated for mobility. > > Our (Q.13/16) primary task is to extend the H.323 protocol > for supporting > mobility (as explained many times) is as follows: > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > If we do NOT this part 1, we are NOT doing our primary job because the > solution will NOT fly. We are rather "building a castle in the air." > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Saturday, September 16, 2000 2:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Radhika, et al, > > I have to confess that I have had no time to really follow > the Annex H work, > but I do have a question to toss out here: > > Why do you consider the VLF or HLF functions outside the > scope of Q13/16? I > assume that these functions are IP-based (or at least used > with the same > call signaling transport as the H.323 system) and integrate > with the H.323 > functions. > > You stated below that these functions are common for all > mobile systems. I > will not argue that point, but will a common solution be the most > appropriate for H.323 systems? I would guess that trying to > introduce a > generic mechanism may or may not be the best solution for H.323. > > I'd like to hear counter arguments to yours. Apparently > others felt that > these functions were necessary for H.323 systems and should be defined > within the H.323 framework. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, September 15, 2000 10:25 AM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > > Hi, Everyone: > > > > The document MD-106 (H.323 Annex H) submitted by the editor remains > > basically same from the fundamentally point of view. So, > the comments > > provided on the September 8 email (copy enclosed) remains > the same as > stated > > earlier. The comments can be summarized as follows: > > > > The Annex should be divided into two parts: > > > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 > [RAS, > > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > > > Part 2: Outside the scope of Q.13/16: Back-end services related to > Mobility > > (or value-added services related mobility) containing VLF and HLF. > > > > So, it can be seen clearly that MD-106 (H.323 Annex H) > submitted by the > > editor does not contain the basic part 1 which is within > the scope of > > Q.13/16 (it rather contains part 2 which is outside the > scope of Q.13/16). > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO > > Sent: Friday, September 08, 2000 10:23 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > > > Hi, Everyone: > > > > The draft does not contain the basic part: Extensions of > H.323 (e.g., > > H.225.0 messages). Contributions are there (e.g., D.354 of > SG16 Feb'00, > > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ > messages > > need to be removed to the base spec of H.323 because there > is nothing > > specific to be done with mobility. If it is used in the context of > mobility, > > the issues related to mobile need to be pointed out so that > contributions > > can be brought to address those issues. Contributions are > there to note > the > > issues. > > > > The another suggestion is to make two parts of the Annex: 1. Basic > extension > > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end > services > > related to Mobility (or value-added services related > mobility)containing > VLF > > and HLF. > > > > Part 2 clearly does not have to be specific to H.323. It is > a general > > service related to mobility. Every application that needs > mobility may > like > > to use these services. This will be addressed in the light > of the all > mobile > > applications of all questions of all SGs of the ITU-T. So, it is > > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes > this decision. > > > > Please note that Security (AuF) is also needed for the > fixed users. So, > this > > is a generic service that needs to be developed for both > fixed and mobile > > users. So, it also belongs to the base H.323 spec. That is, any > > specification related to AuF should be moved to the base > H.323 spec as > well > > because it belong to both and the standard should be developed > accordingly. > > > > For rapid determination, I would suggest to address part 1 > only in the > first > > phase. > > > > More specific technical comments will be given for each > point once the > > primary objectives are clarified. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Thursday, September 14, 2000 7:28 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > > > > Hi all, > > > > I have uploaded MD-106 to URL: > > > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10 6_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

my address has changed
by Euchner Martin 20 Sep '00

20 Sep '00

To whom it may concern: My address has changed. You may find the new email/phone/fax and postal address in the signature below. Kind regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 18 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://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16… <http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16…> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by SAMOU Jean-claude FTRD/DAC/ISS 20 Sep '00

20 Sep '00

Hi, Everyone: Sorry for not getting into the discussion earlier since I was out of station for some time. I just logged into my PC and saw your interesting e-mail discussion on mobility management protocols (in particular between the VLF and HLF). I would like to share here some concerns of Radhika Roy on this matter. As he clearly points out, the HLF and VLF are only value-added functions which are necessary for handling mobility of users. There is nothing specific in VLF <-> HLF in terms of mobility with respect packet vs. circuit or connection oriented vs connectionless, etc. As you are probably aware of, the IMT-2000 group in ITU-T SG11 is currently working on developing a common mobility management protocol which should accomodate various users of different types of mobile systems (e.g. IS-41, UMTS, etc). This is the well known FAMILY concept in ITU-T SG11. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. During this meeting, this mobility protocol work was briefly introduced by SG 11 and it was recognized that the requirements & major concepts identified for mobility in H.323 networks are very similar to those of IMT-2000 (since IMT-2000 should also provide packet-based multi-media services), and a close cooperation between these two groups is required on mobility and roaming aspects for the benefits of H.323 and IMT-2000 systems. In addition, this will allow the roaming of any users between different types of network (for instance an H.323 user roaming into an IS-41 or UMTS network and vice-versa). Therefore, I tend to disagree with Jaakko who says that IMT-2000 is not defining (or intended for) packet-based networks. For instance the concept of VLF and HLF are pretty much close to those of the LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the strict reason that they are both server functions which handle mobility independently of the transport networks. Then why not a common protocol for common mobility requirements and functions? On the other hand, I agree that Extensions of H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be provided by Q.13/16 since they are very specific to the H.323 type of access. Again, I would like to support Radhika in his analysis of trying to develop a common solution that fits the need of any type of mobile users rather than developing one VLF <-> HLF protocol for H.323, one VLF <-> HLF for H.321, etc. Otherwise, it will be a BIG mess for network operators (as well for manufacturers) and lead to have different protocols which may be incompatible between themselves. This will also make the inter-networking aspects very tough thereby preventing any global roaming of users. FYI, I would also like to inform you that 3GPP has selected SIP for its MULTIMEDIA stuff. In this case, how would it be possible to roam between a 3GPP network and H.323 network, and with other networks (not using SIP)unless an inter-connecting pipe such as a common MM protocol (which includes SIP mobility, H.323 mobility, IS-41 mobility, etc) is developed. Therefore, I would suggest that we should rather work with a more global picture of ITU (as supported by Radhika) than a narrow one limited to H.323 mobility only. Let me more positive now. I would really encourage SG16 and SG11 to closely cooperate together in order to develop this common protocol jointly for the success of ITU. I believe that this step has already started at the joint SG16-SG11 meeting in February 00. Why shoudn't be continued? Best regards, Jean-Claude Samou, PhD France Telecom R&D 38-40, rue du General Leclerc 92131 Issy les moulineaux France Tel: + 33 1 45 29 58 40 Fax: + 33 1 46 29 31 62 -----Message d'origine----- De: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Date: mardi 19 septembre 2000 14:15 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Let me repeat it again: We have applications H.323, H.321, etc. These are packet-based networks. There are other protocols like H.324 etc, that are optimized for PSTN/ISDN networks. Now the application/middleware layer control protocol like H.245 is applicable for all applications whether an application is sent over the packet networks or circuit-switched networks. Similarly, application/middleware layer VLF <-> HLF and other protocols are nothing do with packet vs. circuit-switched networks. It MUST be a common protocol. There is nothing specific in VLF <-> HLF with respect packet vs. circuit or connection oriented vs connectionless. People are trying to create confusions for fulfilling a VERY narrow objectives ignoring the BIG picture of the ITU. Even for the sake of argument, if we consider the applications only for the packet-switched networks, then we MUST develop the generic protocols like VLF <-> HLF and others that can be used by all protocols like H.323, H.321, etc. that are used by the packet-switched networks. The same argument is true for QOS, billing, authentication, directory, etc, and others. Let us not confuse things. Let us take another case: RSVP, DiffServ, etc. are the network layer QOS protocol. These network layer QOS services can be used by any applications (e.g., H.323, SIP, etc.) over the IP network. That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF <-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc. It is a mess and defeats the fundamental purpose for creating of COMMON standards by the ITU. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, September 18, 2000 7:34 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi Radhika, Paul & others Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323. -Jaakko > -----Original Message----- > From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: 17. September 2000 3:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Hi, Paul: > > I am glad that you have asked this question. > > HLF and VLF are value-added functions, and these server functions are > necessary for any mobile users. IMT-2000 is working to develop these > protocols. SG16 and SG11 had one joint meeting in the last > Feb'00 in Geneva. > These protocols are VLF <-> HLF and others. > > All we (Q.13/16) need to do: An interface with the VLF by the > H.323 GK. > > (An analogy can also given: H.245 is a common set of control > protocol that > is being used by H.323, H.324, and other applications.) > > If there are one or more functions are needed for any reasons that are > specific to H.323, people can always augment that particular > protocol. This > is a fact of life. > > The same is also true for QoS, authentication, accounting, > billing, and > others. > > More importantly, IMT-2000 is dedicated for mobility. > > Our (Q.13/16) primary task is to extend the H.323 protocol > for supporting > mobility (as explained many times) is as follows: > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > If we do NOT this part 1, we are NOT doing our primary job because the > solution will NOT fly. We are rather "building a castle in the air." > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Saturday, September 16, 2000 2:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Radhika, et al, > > I have to confess that I have had no time to really follow > the Annex H work, > but I do have a question to toss out here: > > Why do you consider the VLF or HLF functions outside the > scope of Q13/16? I > assume that these functions are IP-based (or at least used > with the same > call signaling transport as the H.323 system) and integrate > with the H.323 > functions. > > You stated below that these functions are common for all > mobile systems. I > will not argue that point, but will a common solution be the most > appropriate for H.323 systems? I would guess that trying to > introduce a > generic mechanism may or may not be the best solution for H.323. > > I'd like to hear counter arguments to yours. Apparently > others felt that > these functions were necessary for H.323 systems and should be defined > within the H.323 framework. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, September 15, 2000 10:25 AM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > > Hi, Everyone: > > > > The document MD-106 (H.323 Annex H) submitted by the editor remains > > basically same from the fundamentally point of view. So, > the comments > > provided on the September 8 email (copy enclosed) remains > the same as > stated > > earlier. The comments can be summarized as follows: > > > > The Annex should be divided into two parts: > > > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 > [RAS, > > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > > > Part 2: Outside the scope of Q.13/16: Back-end services related to > Mobility > > (or value-added services related mobility) containing VLF and HLF. > > > > So, it can be seen clearly that MD-106 (H.323 Annex H) > submitted by the > > editor does not contain the basic part 1 which is within > the scope of > > Q.13/16 (it rather contains part 2 which is outside the > scope of Q.13/16). > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO > > Sent: Friday, September 08, 2000 10:23 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > > > Hi, Everyone: > > > > The draft does not contain the basic part: Extensions of > H.323 (e.g., > > H.225.0 messages). Contributions are there (e.g., D.354 of > SG16 Feb'00, > > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ > messages > > need to be removed to the base spec of H.323 because there > is nothing > > specific to be done with mobility. If it is used in the context of > mobility, > > the issues related to mobile need to be pointed out so that > contributions > > can be brought to address those issues. Contributions are > there to note > the > > issues. > > > > The another suggestion is to make two parts of the Annex: 1. Basic > extension > > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end > services > > related to Mobility (or value-added services related > mobility)containing > VLF > > and HLF. > > > > Part 2 clearly does not have to be specific to H.323. It is > a general > > service related to mobility. Every application that needs > mobility may > like > > to use these services. This will be addressed in the light > of the all > mobile > > applications of all questions of all SGs of the ITU-T. So, it is > > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes > this decision. > > > > Please note that Security (AuF) is also needed for the > fixed users. So, > this > > is a generic service that needs to be developed for both > fixed and mobile > > users. So, it also belongs to the base H.323 spec. That is, any > > specification related to AuF should be moved to the base > H.323 spec as > well > > because it belong to both and the standard should be developed > accordingly. > > > > For rapid determination, I would suggest to address part 1 > only in the > first > > phase. > > > > More specific technical comments will be given for each > point once the > > primary objectives are clarified. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Thursday, September 14, 2000 7:28 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > > > > Hi all, > > > > I have uploaded MD-106 to URL: > > > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10 6_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: ARJ reject reasons?
by Euchner Martin 20 Sep '00

20 Sep '00

Paul and others, let me shortly explain the purpose of security denial: H.235 and security profiles say, that this value is returned in the reject messages whenever the received cryptoTokens are not acceptable for some security reason. This may occur due to failed authentication, lack of authorization (= permission) or failed integrity but also as part of security negotiation when the received crypto parameters are not acceptable or understood. Of course there several more reasons why security might fail and the responder sends security denial: the password/shared secret is invalid or not available, the endpoint is not allowed to use a service, replay detected, integrity violation detected, digital signature wrong, certificate expired.... Kind regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 18 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://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16… <http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16…> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Paul Long [SMTP:Plong@SMITHMICRO.COM] Gesendet am: Mittwoch, 20. September 2000 15:17 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: ARJ reject reasons? I put together a table that summarizes the meanings of the ARJ reject reasons if anyone is interested. It's at the top of this page: http://www.packetizer.com/h225impl.html. Let me know if you disagree with any of it. Paul Long Smith Micro Software, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: ARJ reject reasons?
by Ilya Freytsis 20 Sep '00

20 Sep '00

Paul, I can offer my interpretation for some of them: 1. InvalidPermission - GK may have policy rules for the different categories of endpoints (e.g. who is allowed to use gateway services etc.) 2. CallernotRegistered - EP that is not registered with the GK asks for the permission to place a call 3. SecurityDenial 4. requestDenied(no bandwidth available) - no comments 5. resourceUnavailable - e.g. no gateway resources available (my favorite) 6. callCapacityExceeded - GK has reached its call handling capacity (esp. in GK routed mode) Ilya Freytsis -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Tuesday, September 19, 2000 4:09 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: ARJ reject reasons? What is the difference between the three ARJ reject reasons, invalidPermission, callernotRegistered, and securityDenial? Likewise, what is the difference between the ARJ reject reasons, requestDenied (no bandwidth available), resourceUnavailable, and callCapacityExceeded? Paul Long Smith Micro Software, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 3

Re: ARJ reject reasons?
by Ilya Freytsis 20 Sep '00

20 Sep '00

Our H323/H320 gateway registers with the GK the list of aliases-prefixes that indicates available gateway resource. Every time a resource is used the list is re-registered. GK may have enough built-in knowledge of the prefix scheme to be able to specify resourceUnavailable in ARJ if it cannot satisfy request. Ilya Freytsis -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Tuesday, September 19, 2000 6:36 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: ARJ reject reasons? Ilya, So you think that invalidPermission is the code to return if the call violates some proprietary policy within the GK that is typically set by the administrator of the network/GK? Regarding resourceUnavailable, how does a GK know whether gateway "resources" are available? Doesn't it just know whether an alias or set of aliases are registered? How can it make this distinction? Or are you referring to the capacity of the GW, in which case wouldn't callCapacityExceeded be the correct reason to return? Another respondent said that callCapacityExceeded refered to the capacity of the other EP and not to the GK itself. I suppose it could be used for both. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Ilya Freytsis [mailto:ifreytsis@EZENIA.COM] Sent: Tuesday, September 19, 2000 5:02 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: ARJ reject reasons? Paul, I can offer my interpretation for some of them: 1. InvalidPermission - GK may have policy rules for the different categories of endpoints (e.g. who is allowed to use gateway services etc.) 2. CallernotRegistered - EP that is not registered with the GK asks for the permission to place a call 3. SecurityDenial 4. requestDenied(no bandwidth available) - no comments 5. resourceUnavailable - e.g. no gateway resources available (my favorite) 6. callCapacityExceeded - GK has reached its call handling capacity (esp. in GK routed mode) Ilya Freytsis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

subscribe
by Danny Wolfstein 20 Sep '00

20 Sep '00

Danny Wolfstein Senior Project Manager Surf Communication Solutions Ltd. E-mail: dannyw(a)surf.co.il Tel. +972-4-9095777, ext. 735 Fax. +972-4-9594055 Mobile +972-54-333748 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

ARJ reject reasons?
by Paul Long 19 Sep '00

19 Sep '00

What is the difference between the three ARJ reject reasons, invalidPermission, callernotRegistered, and securityDenial? Likewise, what is the difference between the ARJ reject reasons, requestDenied (no bandwidth available), resourceUnavailable, and callCapacityExceeded? Paul Long Smith Micro Software, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 19 Sep '00

19 Sep '00

Hi, Bob: Let me explain: Please see the Portland meeting minutes based on the AT&T contributions. The contribution (Comments on H.323 Annex H) clearly describes that VLF <-> HLF communications protocols are NOT within the scope of Q.13/16. The meeting minutes note that the contribution has been accepted, although some items have not been accepted. Based on this, it is interpreted that Rapporteur (Q.13/16) is yet to provide his consent that it is within the scope of Q.13/16 before we go to the next step. That is why, the question has been raised not to include VLF <-> HLF communications protocols and others at this point of time by the editor while we have not done our primary job (why should we be in a hurry to duplicate something skipping the main thing?). Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, September 19, 2000 2:38 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Roy, It is clear that you did not understand. 1) I said that the scope of Q.13/16 is defined by the rapporteur of Q.13/16. If he determines that VLF <----> is in the scope of Q.13/16, then it is in the scope. Disagreements can be appealed to the Working Party or the Study Group. As I understand it, it has been determined to be in scope. 2) A common protocol is a great idea, but not mandatory. There are many examples where the ITU has duplicate and competing standards. Let accept the fact the it is in scope and proceed with useful work As a thought, based on your arguments, Q13/16 should not work on QOS because there is work in SG11 on this subject. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Tuesday, September 19, 2000 1:06 PM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: RE: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Bob: It appears that you are agreeing with the fact there should be a common standard where it is necessary. For example, H.245 and others are the example of WP2. In this respect, we can also do the same for VLF <-> HLF, AuF <-> HLF, and others because all applications like H.323, H.321, H.324, etc. and others. First of all, it has to be clarified that it is the scope of a given question, and then the all companies need to be given the fair chances to bring contributions to solve the same problem. Please note that it has been said time and again (contributions had been brought) that these items are not within the scope of Q.13/16 and contributions were not brought assuming that we MUST not develop one VLF <-> HLF protocol for H.323, another VLF <-> HLF for H.321, and another one for H.324, and so on. There is nothing fency about this because it deals with mobile users. Please note that VLF <-> HLF communications are not specific to "MULTIMEDIA" or for the "IP Transport network" per se. We had a meeting with SG11 and SG16 to address how HLF and VLF protocols are being developed in SG11 (IMT-2000). Again coming to the fact, we have not done the job for the first 1: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00. Once we do this part, then we will enough time what needs to be done with others. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Monday, September 18, 2000 9:24 AM To: Roy, Radhika R, ALCOO Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: QRE: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Roy, It is the charter of Q13/16 to develop of Multimedia over IP applications. It is not limited to H.323, although this is the primary standard of interest. H.248 is a standard that is independent from H.323, but in the scope of multimedia over IP. This is in the scope of Q13/16. Now SG9 is standardizing MGCP in competition with H.248. In that SG9 is chartered with standards related to cable systems and MGCP is used in the cable industry, it is in their scope (Not good; but true). Annex G, is clearly a backend service that is used in support of H.323. It is also in the scope of Q13/16. VLF <-- --> HLF communication is clearly analogous with Annex G. Based on this analogy, it can be in the scope of Q13/16. Yes, IMT-2000 covers the next generation of mobile products. The last time I looked, SG16 is a participant in IMT-2000 regarding the multimedia applications. Based on this, any work done in SG16 regarding the support of multimedia application is, by definition, part of IMT-2000. A common solution for backend services is good. However, the operative word is common, as in fully supports all needs. Your example of H.245 is good. However, a focused solution that does not support all needs is worse than no solution. In your knowledge, do the solutions proposed by SG11 cover the needs of H.323? As an example, does the transport method scale to the smaller sized systems supported by H.323? If SG11 is truly considering the needs of H.323 this is very good; but this is not consistent with the past. As an example, they insist that all call control signaling must be ISUP, which does not scale to the smaller sizes. I think that Q13/16 should move forward with the standards necessary to support multimedia over IP. I accept the ruling of the rapporteur as to the scope of this work. I do not think that energy should be expended with further debates on this subject. If someone does not agree with the decision of the rapporteur, then the decision should be appealed to the working party or study group chairman. This is far more effective that the current argumentation. Just my opinion, Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Saturday, September 16, 2000 8:48 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Paul: I am glad that you have asked this question. HLF and VLF are value-added functions, and these server functions are necessary for any mobile users. IMT-2000 is working to develop these protocols. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. These protocols are VLF <-> HLF and others. All we (Q.13/16) need to do: An interface with the VLF by the H.323 GK. (An analogy can also given: H.245 is a common set of control protocol that is being used by H.323, H.324, and other applications.) If there are one or more functions are needed for any reasons that are specific to H.323, people can always augment that particular protocol. This is a fact of life. The same is also true for QoS, authentication, accounting, billing, and others. More importantly, IMT-2000 is dedicated for mobility. Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times) is as follows: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) If we do NOT this part 1, we are NOT doing our primary job because the solution will NOT fly. We are rather "building a castle in the air." Best regards, Radhika R. Roy AT&T -----Original Message----- > phase. > > More specific technical comments will be given for each point once the > primary objectives are clarified. > > Best regards, > > Radhika R. Roy > AT&T > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Callaghan, Robert 19 Sep '00

19 Sep '00

Roy, It is clear that you did not understand. 1) I said that the scope of Q.13/16 is defined by the rapporteur of Q.13/16. If he determines that VLF <----> is in the scope of Q.13/16, then it is in the scope. Disagreements can be appealed to the Working Party or the Study Group. As I understand it, it has been determined to be in scope. 2) A common protocol is a great idea, but not mandatory. There are many examples where the ITU has duplicate and competing standards. Let accept the fact the it is in scope and proceed with useful work As a thought, based on your arguments, Q13/16 should not work on QOS because there is work in SG11 on this subject. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Tuesday, September 19, 2000 1:06 PM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: RE: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Bob: It appears that you are agreeing with the fact there should be a common standard where it is necessary. For example, H.245 and others are the example of WP2. In this respect, we can also do the same for VLF <-> HLF, AuF <-> HLF, and others because all applications like H.323, H.321, H.324, etc. and others. First of all, it has to be clarified that it is the scope of a given question, and then the all companies need to be given the fair chances to bring contributions to solve the same problem. Please note that it has been said time and again (contributions had been brought) that these items are not within the scope of Q.13/16 and contributions were not brought assuming that we MUST not develop one VLF <-> HLF protocol for H.323, another VLF <-> HLF for H.321, and another one for H.324, and so on. There is nothing fency about this because it deals with mobile users. Please note that VLF <-> HLF communications are not specific to "MULTIMEDIA" or for the "IP Transport network" per se. We had a meeting with SG11 and SG16 to address how HLF and VLF protocols are being developed in SG11 (IMT-2000). Again coming to the fact, we have not done the job for the first 1: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00. Once we do this part, then we will enough time what needs to be done with others. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Monday, September 18, 2000 9:24 AM To: Roy, Radhika R, ALCOO Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: QRE: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Roy, It is the charter of Q13/16 to develop of Multimedia over IP applications. It is not limited to H.323, although this is the primary standard of interest. H.248 is a standard that is independent from H.323, but in the scope of multimedia over IP. This is in the scope of Q13/16. Now SG9 is standardizing MGCP in competition with H.248. In that SG9 is chartered with standards related to cable systems and MGCP is used in the cable industry, it is in their scope (Not good; but true). Annex G, is clearly a backend service that is used in support of H.323. It is also in the scope of Q13/16. VLF <-- --> HLF communication is clearly analogous with Annex G. Based on this analogy, it can be in the scope of Q13/16. Yes, IMT-2000 covers the next generation of mobile products. The last time I looked, SG16 is a participant in IMT-2000 regarding the multimedia applications. Based on this, any work done in SG16 regarding the support of multimedia application is, by definition, part of IMT-2000. A common solution for backend services is good. However, the operative word is common, as in fully supports all needs. Your example of H.245 is good. However, a focused solution that does not support all needs is worse than no solution. In your knowledge, do the solutions proposed by SG11 cover the needs of H.323? As an example, does the transport method scale to the smaller sized systems supported by H.323? If SG11 is truly considering the needs of H.323 this is very good; but this is not consistent with the past. As an example, they insist that all call control signaling must be ISUP, which does not scale to the smaller sizes. I think that Q13/16 should move forward with the standards necessary to support multimedia over IP. I accept the ruling of the rapporteur as to the scope of this work. I do not think that energy should be expended with further debates on this subject. If someone does not agree with the decision of the rapporteur, then the decision should be appealed to the working party or study group chairman. This is far more effective that the current argumentation. Just my opinion, Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Saturday, September 16, 2000 8:48 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Paul: I am glad that you have asked this question. HLF and VLF are value-added functions, and these server functions are necessary for any mobile users. IMT-2000 is working to develop these protocols. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. These protocols are VLF <-> HLF and others. All we (Q.13/16) need to do: An interface with the VLF by the H.323 GK. (An analogy can also given: H.245 is a common set of control protocol that is being used by H.323, H.324, and other applications.) If there are one or more functions are needed for any reasons that are specific to H.323, people can always augment that particular protocol. This is a fact of life. The same is also true for QoS, authentication, accounting, billing, and others. More importantly, IMT-2000 is dedicated for mobility. Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times) is as follows: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) If we do NOT this part 1, we are NOT doing our primary job because the solution will NOT fly. We are rather "building a castle in the air." Best regards, Radhika R. Roy AT&T -----Original Message----- > phase. > > More specific technical comments will be given for each point once the > primary objectives are clarified. > > Best regards, > > Radhika R. Roy > AT&T > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 19 Sep '00

19 Sep '00

Hi, Bob: It appears that you are agreeing with the fact there should be a common standard where it is necessary. For example, H.245 and others are the example of WP2. In this respect, we can also do the same for VLF <-> HLF, AuF <-> HLF, and others because all applications like H.323, H.321, H.324, etc. and others. First of all, it has to be clarified that it is the scope of a given question, and then the all companies need to be given the fair chances to bring contributions to solve the same problem. Please note that it has been said time and again (contributions had been brought) that these items are not within the scope of Q.13/16 and contributions were not brought assuming that we MUST not develop one VLF <-> HLF protocol for H.323, another VLF <-> HLF for H.321, and another one for H.324, and so on. There is nothing fency about this because it deals with mobile users. Please note that VLF <-> HLF communications are not specific to "MULTIMEDIA" or for the "IP Transport network" per se. We had a meeting with SG11 and SG16 to address how HLF and VLF protocols are being developed in SG11 (IMT-2000). Again coming to the fact, we have not done the job for the first 1: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00. Once we do this part, then we will enough time what needs to be done with others. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Monday, September 18, 2000 9:24 AM To: Roy, Radhika R, ALCOO Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: QRE: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Roy, It is the charter of Q13/16 to develop of Multimedia over IP applications. It is not limited to H.323, although this is the primary standard of interest. H.248 is a standard that is independent from H.323, but in the scope of multimedia over IP. This is in the scope of Q13/16. Now SG9 is standardizing MGCP in competition with H.248. In that SG9 is chartered with standards related to cable systems and MGCP is used in the cable industry, it is in their scope (Not good; but true). Annex G, is clearly a backend service that is used in support of H.323. It is also in the scope of Q13/16. VLF <-- --> HLF communication is clearly analogous with Annex G. Based on this analogy, it can be in the scope of Q13/16. Yes, IMT-2000 covers the next generation of mobile products. The last time I looked, SG16 is a participant in IMT-2000 regarding the multimedia applications. Based on this, any work done in SG16 regarding the support of multimedia application is, by definition, part of IMT-2000. A common solution for backend services is good. However, the operative word is common, as in fully supports all needs. Your example of H.245 is good. However, a focused solution that does not support all needs is worse than no solution. In your knowledge, do the solutions proposed by SG11 cover the needs of H.323? As an example, does the transport method scale to the smaller sized systems supported by H.323? If SG11 is truly considering the needs of H.323 this is very good; but this is not consistent with the past. As an example, they insist that all call control signaling must be ISUP, which does not scale to the smaller sizes. I think that Q13/16 should move forward with the standards necessary to support multimedia over IP. I accept the ruling of the rapporteur as to the scope of this work. I do not think that energy should be expended with further debates on this subject. If someone does not agree with the decision of the rapporteur, then the decision should be appealed to the working party or study group chairman. This is far more effective that the current argumentation. Just my opinion, Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Saturday, September 16, 2000 8:48 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Paul: I am glad that you have asked this question. HLF and VLF are value-added functions, and these server functions are necessary for any mobile users. IMT-2000 is working to develop these protocols. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. These protocols are VLF <-> HLF and others. All we (Q.13/16) need to do: An interface with the VLF by the H.323 GK. (An analogy can also given: H.245 is a common set of control protocol that is being used by H.323, H.324, and other applications.) If there are one or more functions are needed for any reasons that are specific to H.323, people can always augment that particular protocol. This is a fact of life. The same is also true for QoS, authentication, accounting, billing, and others. More importantly, IMT-2000 is dedicated for mobility. Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times) is as follows: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) If we do NOT this part 1, we are NOT doing our primary job because the solution will NOT fly. We are rather "building a castle in the air." Best regards, Radhika R. Roy AT&T -----Original Message----- > phase. > > More specific technical comments will be given for each point once the > primary objectives are clarified. > > Best regards, > > Radhika R. Roy > AT&T > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 19 Sep '00

19 Sep '00

Hi, Everyone: Let me repeat it again: We have applications H.323, H.321, etc. These are packet-based networks. There are other protocols like H.324 etc, that are optimized for PSTN/ISDN networks. Now the application/middleware layer control protocol like H.245 is applicable for all applications whether an application is sent over the packet networks or circuit-switched networks. Similarly, application/middleware layer VLF <-> HLF and other protocols are nothing do with packet vs. circuit-switched networks. It MUST be a common protocol. There is nothing specific in VLF <-> HLF with respect packet vs. circuit or connection oriented vs connectionless. People are trying to create confusions for fulfilling a VERY narrow objectives ignoring the BIG picture of the ITU. Even for the sake of argument, if we consider the applications only for the packet-switched networks, then we MUST develop the generic protocols like VLF <-> HLF and others that can be used by all protocols like H.323, H.321, etc. that are used by the packet-switched networks. The same argument is true for QOS, billing, authentication, directory, etc, and others. Let us not confuse things. Let us take another case: RSVP, DiffServ, etc. are the network layer QOS protocol. These network layer QOS services can be used by any applications (e.g., H.323, SIP, etc.) over the IP network. That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF <-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc. It is a mess and defeats the fundamental purpose for creating of COMMON standards by the ITU. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, September 18, 2000 7:34 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi Radhika, Paul & others Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323. -Jaakko > -----Original Message----- > From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: 17. September 2000 3:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Hi, Paul: > > I am glad that you have asked this question. > > HLF and VLF are value-added functions, and these server functions are > necessary for any mobile users. IMT-2000 is working to develop these > protocols. SG16 and SG11 had one joint meeting in the last > Feb'00 in Geneva. > These protocols are VLF <-> HLF and others. > > All we (Q.13/16) need to do: An interface with the VLF by the > H.323 GK. > > (An analogy can also given: H.245 is a common set of control > protocol that > is being used by H.323, H.324, and other applications.) > > If there are one or more functions are needed for any reasons that are > specific to H.323, people can always augment that particular > protocol. This > is a fact of life. > > The same is also true for QoS, authentication, accounting, > billing, and > others. > > More importantly, IMT-2000 is dedicated for mobility. > > Our (Q.13/16) primary task is to extend the H.323 protocol > for supporting > mobility (as explained many times) is as follows: > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > If we do NOT this part 1, we are NOT doing our primary job because the > solution will NOT fly. We are rather "building a castle in the air." > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Saturday, September 16, 2000 2:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Radhika, et al, > > I have to confess that I have had no time to really follow > the Annex H work, > but I do have a question to toss out here: > > Why do you consider the VLF or HLF functions outside the > scope of Q13/16? I > assume that these functions are IP-based (or at least used > with the same > call signaling transport as the H.323 system) and integrate > with the H.323 > functions. > > You stated below that these functions are common for all > mobile systems. I > will not argue that point, but will a common solution be the most > appropriate for H.323 systems? I would guess that trying to > introduce a > generic mechanism may or may not be the best solution for H.323. > > I'd like to hear counter arguments to yours. Apparently > others felt that > these functions were necessary for H.323 systems and should be defined > within the H.323 framework. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, September 15, 2000 10:25 AM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > > Hi, Everyone: > > > > The document MD-106 (H.323 Annex H) submitted by the editor remains > > basically same from the fundamentally point of view. So, > the comments > > provided on the September 8 email (copy enclosed) remains > the same as > stated > > earlier. The comments can be summarized as follows: > > > > The Annex should be divided into two parts: > > > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 > [RAS, > > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > > > Part 2: Outside the scope of Q.13/16: Back-end services related to > Mobility > > (or value-added services related mobility) containing VLF and HLF. > > > > So, it can be seen clearly that MD-106 (H.323 Annex H) > submitted by the > > editor does not contain the basic part 1 which is within > the scope of > > Q.13/16 (it rather contains part 2 which is outside the > scope of Q.13/16). > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO > > Sent: Friday, September 08, 2000 10:23 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > > > Hi, Everyone: > > > > The draft does not contain the basic part: Extensions of > H.323 (e.g., > > H.225.0 messages). Contributions are there (e.g., D.354 of > SG16 Feb'00, > > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ > messages > > need to be removed to the base spec of H.323 because there > is nothing > > specific to be done with mobility. If it is used in the context of > mobility, > > the issues related to mobile need to be pointed out so that > contributions > > can be brought to address those issues. Contributions are > there to note > the > > issues. > > > > The another suggestion is to make two parts of the Annex: 1. Basic > extension > > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end > services > > related to Mobility (or value-added services related > mobility)containing > VLF > > and HLF. > > > > Part 2 clearly does not have to be specific to H.323. It is > a general > > service related to mobility. Every application that needs > mobility may > like > > to use these services. This will be addressed in the light > of the all > mobile > > applications of all questions of all SGs of the ITU-T. So, it is > > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes > this decision. > > > > Please note that Security (AuF) is also needed for the > fixed users. So, > this > > is a generic service that needs to be developed for both > fixed and mobile > > users. So, it also belongs to the base H.323 spec. That is, any > > specification related to AuF should be moved to the base > H.323 spec as > well > > because it belong to both and the standard should be developed > accordingly. > > > > For rapid determination, I would suggest to address part 1 > only in the > first > > phase. > > > > More specific technical comments will be given for each > point once the > > primary objectives are clarified. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Thursday, September 14, 2000 7:28 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > > > > Hi all, > > > > I have uploaded MD-106 to URL: > > > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10 6_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 Annex I
by Baese Gero 19 Sep '00

19 Sep '00

Dear Experts, at the Portland Meeting a controversial discussion arised about the new Annex I specification. Several misunderstandings between the participants as well as about the outcome of the Osaka Meeting were the reasons. At the moment we(Siemens) are trying to establish a co-operation with UCLA as well as the editor of the Annex I in order to find the best possible solution for the standard. We addressed both of them directly. If a merger of the both proposals will be possible we will work it out together and present it at the next rapporteurs meeting. Further we want to ask all experts for their technical assistance. Please provide us with more requirements as well as scenarios you can think of Annex I would be used for. Best Wishes Gero Baese ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

APC-1950
by Glen Freundlich 18 Sep '00

18 Sep '00

Dear Colleagues, I have placed APC-1950, a liaison from the BICC group in SG11, in the Incoming directory of avc-site. Note that the zip file contains 5 files. Regards, Glen

1 0

QRE: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Callaghan, Robert 18 Sep '00

18 Sep '00

Roy, It is the charter of Q13/16 to develop of Multimedia over IP applications. It is not limited to H.323, although this is the primary standard of interest. H.248 is a standard that is independent from H.323, but in the scope of multimedia over IP. This is in the scope of Q13/16. Now SG9 is standardizing MGCP in competition with H.248. In that SG9 is chartered with standards related to cable systems and MGCP is used in the cable industry, it is in their scope (Not good; but true). Annex G, is clearly a backend service that is used in support of H.323. It is also in the scope of Q13/16. VLF <-- --> HLF communication is clearly analogous with Annex G. Based on this analogy, it can be in the scope of Q13/16. Yes, IMT-2000 covers the next generation of mobile products. The last time I looked, SG16 is a participant in IMT-2000 regarding the multimedia applications. Based on this, any work done in SG16 regarding the support of multimedia application is, by definition, part of IMT-2000. A common solution for backend services is good. However, the operative word is common, as in fully supports all needs. Your example of H.245 is good. However, a focused solution that does not support all needs is worse than no solution. In your knowledge, do the solutions proposed by SG11 cover the needs of H.323? As an example, does the transport method scale to the smaller sized systems supported by H.323? If SG11 is truly considering the needs of H.323 this is very good; but this is not consistent with the past. As an example, they insist that all call control signaling must be ISUP, which does not scale to the smaller sizes. I think that Q13/16 should move forward with the standards necessary to support multimedia over IP. I accept the ruling of the rapporteur as to the scope of this work. I do not think that energy should be expended with further debates on this subject. If someone does not agree with the decision of the rapporteur, then the decision should be appealed to the working party or study group chairman. This is far more effective that the current argumentation. Just my opinion, Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Saturday, September 16, 2000 8:48 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Paul: I am glad that you have asked this question. HLF and VLF are value-added functions, and these server functions are necessary for any mobile users. IMT-2000 is working to develop these protocols. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. These protocols are VLF <-> HLF and others. All we (Q.13/16) need to do: An interface with the VLF by the H.323 GK. (An analogy can also given: H.245 is a common set of control protocol that is being used by H.323, H.324, and other applications.) If there are one or more functions are needed for any reasons that are specific to H.323, people can always augment that particular protocol. This is a fact of life. The same is also true for QoS, authentication, accounting, billing, and others. More importantly, IMT-2000 is dedicated for mobility. Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times) is as follows: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) If we do NOT this part 1, we are NOT doing our primary job because the solution will NOT fly. We are rather "building a castle in the air." Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, September 16, 2000 2:45 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Radhika, et al, I have to confess that I have had no time to really follow the Annex H work, but I do have a question to toss out here: Why do you consider the VLF or HLF functions outside the scope of Q13/16? I assume that these functions are IP-based (or at least used with the same call signaling transport as the H.323 system) and integrate with the H.323 functions. You stated below that these functions are common for all mobile systems. I will not argue that point, but will a common solution be the most appropriate for H.323 systems? I would guess that trying to introduce a generic mechanism may or may not be the best solution for H.323. I'd like to hear counter arguments to yours. Apparently others felt that these functions were necessary for H.323 systems and should be defined within the H.323 framework. Paul ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Friday, September 15, 2000 10:25 AM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > Hi, Everyone: > > The document MD-106 (H.323 Annex H) submitted by the editor remains > basically same from the fundamentally point of view. So, the comments > provided on the September 8 email (copy enclosed) remains the same as stated > earlier. The comments can be summarized as follows: > > The Annex should be divided into two parts: > > Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > Part 2: Outside the scope of Q.13/16: Back-end services related to Mobility > (or value-added services related mobility) containing VLF and HLF. > > So, it can be seen clearly that MD-106 (H.323 Annex H) submitted by the > editor does not contain the basic part 1 which is within the scope of > Q.13/16 (it rather contains part 2 which is outside the scope of Q.13/16). > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > > > -----Original Message----- > From: Roy, Radhika R, ALCOO > Sent: Friday, September 08, 2000 10:23 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > Hi, Everyone: > > The draft does not contain the basic part: Extensions of H.323 (e.g., > H.225.0 messages). Contributions are there (e.g., D.354 of SG16 Feb'00, > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ messages > need to be removed to the base spec of H.323 because there is nothing > specific to be done with mobility. If it is used in the context of mobility, > the issues related to mobile need to be pointed out so that contributions > can be brought to address those issues. Contributions are there to note the > issues. > > The another suggestion is to make two parts of the Annex: 1. Basic extension > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end services > related to Mobility (or value-added services related mobility)containing VLF > and HLF. > > Part 2 clearly does not have to be specific to H.323. It is a general > service related to mobility. Every application that needs mobility may like > to use these services. This will be addressed in the light of the all mobile > applications of all questions of all SGs of the ITU-T. So, it is > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes this decision. > > Please note that Security (AuF) is also needed for the fixed users. So, this > is a generic service that needs to be developed for both fixed and mobile > users. So, it also belongs to the base H.323 spec. That is, any > specification related to AuF should be moved to the base H.323 spec as well > because it belong to both and the standard should be developed accordingly. > > For rapid determination, I would suggest to address part 1 only in the first > phase. > > More specific technical comments will be given for each point once the > primary objectives are clarified. > > Best regards, > > Radhika R. Roy > AT&T > > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Thursday, September 14, 2000 7:28 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > Hi all, > > I have uploaded MD-106 to URL: > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-106_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Jaakko Sundquist 18 Sep '00

18 Sep '00

Hi Radhika, Paul & others Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323. -Jaakko > -----Original Message----- > From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: 17. September 2000 3:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Hi, Paul: > > I am glad that you have asked this question. > > HLF and VLF are value-added functions, and these server functions are > necessary for any mobile users. IMT-2000 is working to develop these > protocols. SG16 and SG11 had one joint meeting in the last > Feb'00 in Geneva. > These protocols are VLF <-> HLF and others. > > All we (Q.13/16) need to do: An interface with the VLF by the > H.323 GK. > > (An analogy can also given: H.245 is a common set of control > protocol that > is being used by H.323, H.324, and other applications.) > > If there are one or more functions are needed for any reasons that are > specific to H.323, people can always augment that particular > protocol. This > is a fact of life. > > The same is also true for QoS, authentication, accounting, > billing, and > others. > > More importantly, IMT-2000 is dedicated for mobility. > > Our (Q.13/16) primary task is to extend the H.323 protocol > for supporting > mobility (as explained many times) is as follows: > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > If we do NOT this part 1, we are NOT doing our primary job because the > solution will NOT fly. We are rather "building a castle in the air." > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Saturday, September 16, 2000 2:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Radhika, et al, > > I have to confess that I have had no time to really follow > the Annex H work, > but I do have a question to toss out here: > > Why do you consider the VLF or HLF functions outside the > scope of Q13/16? I > assume that these functions are IP-based (or at least used > with the same > call signaling transport as the H.323 system) and integrate > with the H.323 > functions. > > You stated below that these functions are common for all > mobile systems. I > will not argue that point, but will a common solution be the most > appropriate for H.323 systems? I would guess that trying to > introduce a > generic mechanism may or may not be the best solution for H.323. > > I'd like to hear counter arguments to yours. Apparently > others felt that > these functions were necessary for H.323 systems and should be defined > within the H.323 framework. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, September 15, 2000 10:25 AM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > > Hi, Everyone: > > > > The document MD-106 (H.323 Annex H) submitted by the editor remains > > basically same from the fundamentally point of view. So, > the comments > > provided on the September 8 email (copy enclosed) remains > the same as > stated > > earlier. The comments can be summarized as follows: > > > > The Annex should be divided into two parts: > > > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 > [RAS, > > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > > > Part 2: Outside the scope of Q.13/16: Back-end services related to > Mobility > > (or value-added services related mobility) containing VLF and HLF. > > > > So, it can be seen clearly that MD-106 (H.323 Annex H) > submitted by the > > editor does not contain the basic part 1 which is within > the scope of > > Q.13/16 (it rather contains part 2 which is outside the > scope of Q.13/16). > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO > > Sent: Friday, September 08, 2000 10:23 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > > > Hi, Everyone: > > > > The draft does not contain the basic part: Extensions of > H.323 (e.g., > > H.225.0 messages). Contributions are there (e.g., D.354 of > SG16 Feb'00, > > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ > messages > > need to be removed to the base spec of H.323 because there > is nothing > > specific to be done with mobility. If it is used in the context of > mobility, > > the issues related to mobile need to be pointed out so that > contributions > > can be brought to address those issues. Contributions are > there to note > the > > issues. > > > > The another suggestion is to make two parts of the Annex: 1. Basic > extension > > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end > services > > related to Mobility (or value-added services related > mobility)containing > VLF > > and HLF. > > > > Part 2 clearly does not have to be specific to H.323. It is > a general > > service related to mobility. Every application that needs > mobility may > like > > to use these services. This will be addressed in the light > of the all > mobile > > applications of all questions of all SGs of the ITU-T. So, it is > > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes > this decision. > > > > Please note that Security (AuF) is also needed for the > fixed users. So, > this > > is a generic service that needs to be developed for both > fixed and mobile > > users. So, it also belongs to the base H.323 spec. That is, any > > specification related to AuF should be moved to the base > H.323 spec as > well > > because it belong to both and the standard should be developed > accordingly. > > > > For rapid determination, I would suggest to address part 1 > only in the > first > > phase. > > > > More specific technical comments will be given for each > point once the > > primary objectives are clarified. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Thursday, September 14, 2000 7:28 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > > > > Hi all, > > > > I have uploaded MD-106 to URL: > > > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10 6_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 16 Sep '00

16 Sep '00

Hi, Paul: I am glad that you have asked this question. HLF and VLF are value-added functions, and these server functions are necessary for any mobile users. IMT-2000 is working to develop these protocols. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. These protocols are VLF <-> HLF and others. All we (Q.13/16) need to do: An interface with the VLF by the H.323 GK. (An analogy can also given: H.245 is a common set of control protocol that is being used by H.323, H.324, and other applications.) If there are one or more functions are needed for any reasons that are specific to H.323, people can always augment that particular protocol. This is a fact of life. The same is also true for QoS, authentication, accounting, billing, and others. More importantly, IMT-2000 is dedicated for mobility. Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times) is as follows: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) If we do NOT this part 1, we are NOT doing our primary job because the solution will NOT fly. We are rather "building a castle in the air." Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, September 16, 2000 2:45 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Radhika, et al, I have to confess that I have had no time to really follow the Annex H work, but I do have a question to toss out here: Why do you consider the VLF or HLF functions outside the scope of Q13/16? I assume that these functions are IP-based (or at least used with the same call signaling transport as the H.323 system) and integrate with the H.323 functions. You stated below that these functions are common for all mobile systems. I will not argue that point, but will a common solution be the most appropriate for H.323 systems? I would guess that trying to introduce a generic mechanism may or may not be the best solution for H.323. I'd like to hear counter arguments to yours. Apparently others felt that these functions were necessary for H.323 systems and should be defined within the H.323 framework. Paul ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Friday, September 15, 2000 10:25 AM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > Hi, Everyone: > > The document MD-106 (H.323 Annex H) submitted by the editor remains > basically same from the fundamentally point of view. So, the comments > provided on the September 8 email (copy enclosed) remains the same as stated > earlier. The comments can be summarized as follows: > > The Annex should be divided into two parts: > > Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > Part 2: Outside the scope of Q.13/16: Back-end services related to Mobility > (or value-added services related mobility) containing VLF and HLF. > > So, it can be seen clearly that MD-106 (H.323 Annex H) submitted by the > editor does not contain the basic part 1 which is within the scope of > Q.13/16 (it rather contains part 2 which is outside the scope of Q.13/16). > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > > > -----Original Message----- > From: Roy, Radhika R, ALCOO > Sent: Friday, September 08, 2000 10:23 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > Hi, Everyone: > > The draft does not contain the basic part: Extensions of H.323 (e.g., > H.225.0 messages). Contributions are there (e.g., D.354 of SG16 Feb'00, > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ messages > need to be removed to the base spec of H.323 because there is nothing > specific to be done with mobility. If it is used in the context of mobility, > the issues related to mobile need to be pointed out so that contributions > can be brought to address those issues. Contributions are there to note the > issues. > > The another suggestion is to make two parts of the Annex: 1. Basic extension > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end services > related to Mobility (or value-added services related mobility)containing VLF > and HLF. > > Part 2 clearly does not have to be specific to H.323. It is a general > service related to mobility. Every application that needs mobility may like > to use these services. This will be addressed in the light of the all mobile > applications of all questions of all SGs of the ITU-T. So, it is > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes this decision. > > Please note that Security (AuF) is also needed for the fixed users. So, this > is a generic service that needs to be developed for both fixed and mobile > users. So, it also belongs to the base H.323 spec. That is, any > specification related to AuF should be moved to the base H.323 spec as well > because it belong to both and the standard should be developed accordingly. > > For rapid determination, I would suggest to address part 1 only in the first > phase. > > More specific technical comments will be given for each point once the > primary objectives are clarified. > > Best regards, > > Radhika R. Roy > AT&T > > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Thursday, September 14, 2000 7:28 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > Hi all, > > I have uploaded MD-106 to URL: > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-106_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 16 Sep '00

16 Sep '00

Hi, Everyone: The document MD-106 (H.323 Annex H) submitted by the editor remains basically same from the fundamentally point of view. So, the comments provided on the September 8 email (copy enclosed) remains the same as stated earlier. The comments can be summarized as follows: The Annex should be divided into two parts: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) Part 2: Outside the scope of Q.13/16: Back-end services related to Mobility (or value-added services related mobility) containing VLF and HLF. So, it can be seen clearly that MD-106 (H.323 Annex H) submitted by the editor does not contain the basic part 1 which is within the scope of Q.13/16 (it rather contains part 2 which is outside the scope of Q.13/16). Best regards, Radhika R. Roy AT&T +1 732 420 1580 -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Friday, September 08, 2000 10:23 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] H.323 Annex H status check Hi, Everyone: The draft does not contain the basic part: Extensions of H.323 (e.g., H.225.0 messages). Contributions are there (e.g., D.354 of SG16 Feb'00, Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ messages need to be removed to the base spec of H.323 because there is nothing specific to be done with mobility. If it is used in the context of mobility, the issues related to mobile need to be pointed out so that contributions can be brought to address those issues. Contributions are there to note the issues. The another suggestion is to make two parts of the Annex: 1. Basic extension of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end services related to Mobility (or value-added services related mobility)containing VLF and HLF. Part 2 clearly does not have to be specific to H.323. It is a general service related to mobility. Every application that needs mobility may like to use these services. This will be addressed in the light of the all mobile applications of all questions of all SGs of the ITU-T. So, it is out-of-scope of Q.13/16 because Q.13/16 alone cannot makes this decision. Please note that Security (AuF) is also needed for the fixed users. So, this is a generic service that needs to be developed for both fixed and mobile users. So, it also belongs to the base H.323 spec. That is, any specification related to AuF should be moved to the base H.323 spec as well because it belong to both and the standard should be developed accordingly. For rapid determination, I would suggest to address part 1 only in the first phase. More specific technical comments will be given for each point once the primary objectives are clarified. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Thursday, September 14, 2000 7:28 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi all, I have uploaded MD-106 to URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-106_H323AnnexHDr aft.zip . The document is a cleaned up version of TD-42 of the Portland meeting and contains only editorial changes(as the template used in the draft document so far was, for some reason, a total mess). The only "exeption" to this is the following correction. Section 8.1 of TD-42 included the text: "Reference points A and B are out of the scope of this Annex.", which has been removed and instead section 8.3 now includes the text: "Reference points B, C and D are out of the scope of this Annex (Hinter is included but only as an option in case that utilization of reference point A is not practical).". The reason for this change is that the text in TD-42 is, as I understand from Mr. Rissanen's comments, a typo and should have mentioned reference points B and C instead of A and B. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1