- sg16-avd - lists.packetizer.com

standard.pictel.com is unavailable
by Patrick Luthi 07 Sep '00

07 Sep '00

This is just a quick note to let you that we have experienced a power supply failure with the standard.pictel.com server. Therefore, it won't be possible to access any files on the LBC, AVC. or video site until approximatively 12.00pm EST. Sorry for the inconvenience ! Patrick Luthi PictureTel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Reddy, Paul K 07 Sep '00

07 Sep '00

Hi Radhika, We as ITU-T SG16 Q13/Q14 group agreed on the H.323 Annex H Terms of Reference, which includes scope of H.323 Annex H. Now, you are proposing a different scope for H.323 Annex H on this reflector. I propose that we plan to have H.323 Mobility Adhoc group conference call discussion on your proposal instead of exchanging emails on this open reflector and come to some consensus on your proposal and then take a contribution to SG16 Q13/Q14 Rapporteurs meeting in Geneva. We as H.323 Mobility Adhoc group choose Mr. Markku Korpi as Chairman of the Adhoc group, I request Mr. Korpi to setup a conference call to discuss your proposal. I am willing to sponsor the Conference Call Bridge, I propose that we can have conference call on Monday September 11, 2000 from 7:00 AM to 9:00 AM (Pacific Standard Time). Please let me know your availability all other members who wants to participate, so that I can make the Conference call bridge arrangements. regards, Paul Paul K. Reddy Intel Corporation Office Phone# +1 (503)-264-9896 Mobile Phone# +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Thursday, September 07, 2000 7:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Hi, Everyone (including all Rapporteurs and WP2 Chairman): Again, it speaks for itself as it has been mentioned earlier. As if, few folks want to create their own charter, push the boundaries of each question so that they are the ONLY people who can decide what need to be addressed in each question no matter what happens to other questions in a given WP or SG or across the whole ITU-T. They are the people who are afraid of seeing the BIG picture of the ITU-T how one question relates to others to achieve a very narrow goal. Some of these people even participated in the joint meeting of SG16 and SG11 to see how SG11 is addressing the HLF, VLF, AuF, etc. for mobility so that no duplicate work is done elsewhere. Now they are turning their back. Why? Is the norm of the ITU process? It appears that some people do not need address any technical points, as if, they create their own mandate. It may create a good discussion in the upcoming SG16 meeting in the plenary and general session. Again, the proposal for H.323 Annex H has been repeated as follows: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. Let us focus on the charter and mandate of Q.13/16: This is item 1 only. Hope that the WP2 Chairman will have time to review the whole thing with true satisfaction in the light of all questions of all SGs within the ITU. Best regards, Radhika R. Roy AT&T rrroy(a)att.com +1 732 420 1580 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, September 07, 2000 5:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 I guess you mean that you agree with all 4 points, not just the fourth point, right (i.e. I guess there's a typo)? -Jaakko p.s. I didn't want to send this to the list... > -----Original Message----- > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > Sent: 07. September 2000 1:41 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi Everyone, > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > who made 4 point in this email. > > regards, > Paul Reddy > Editor of H.246 Annex E.1, Annex E.2 > > Paul K. Reddy > Roaming Services Capability Manager > Mobile Data Services Area of Opportunity > Applications and Services Lab > Intel's Architecture Labs > Intel Corporation > Office Phone# +1 (503)-264-9896 > Mobile Phone# +1 (503)-807-9564 > Email: paul.k.reddy(a)intel.com > > > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Wednesday, September 06, 2000 9:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > Again, it is interesting to see how a very narrow view can > create serious > problems not only for a simple Annex, but also for the whole > question, for > the whole study group, and for all other study groups of the ITU-T. > > Time and again, it has been said that let us work within the > mandate of > Q.13/16 first and contributions had been made to clarify those points. > Everything has been ignored just because few folks want to do > something > almost working like a close group without seeing the BIG > picture of all > questions of all SGs of the ITU-T. In fact, some joint > meetings were also > initiated between SG16 and SG11 to see how the HLFs, VLFs, > and AuFs related > protocols are being addressed elsewhere. > > Still, they are pushing the same thing just because few folks > brought some > contributions. Objections were put via contributions, emails, > and verbal > discussions. Even there is not a single editorial note in the document > related to those things. > > A simple example will reveal the fact. We have discussed that > there are > serious problems to use GRQ messages to discover the GKs in mobile > environment. Many contributions, emails, and verbal > explanations have been > provided. If you look into the present H.323 Annex H > write-up, you will see > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > environment. Not a single word has been used even as an editorial note > whether some members have raised the questions that there are > problems need > to be addressed for GRQs. The way the GRQ section has been > written, it is a > generic one and is nothing do with mobility. Rather, it suits > to be added in > the base H.323 spec. Many more examples can be given for each > technical > issue. > > This Annex has NOT done its first important task how to > extend the H.323 > signaling messages (RAS, Q.931, Annex G) to solve the > mobility problems for > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > the mandate of > Q.13/16. Contributions are there, but everything has been ignored. > > Rather, Annex H has focused in some areas for which it has NOT got the > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > HLF <-> AuFs, > etc. These work items are not the charter of Q.13./16 alone. > These are the > areas for the joint work with all other questions of all SGs > that deal with > mobility. (In another example, even if H.320, H.321, or H.324 > wants to be > used by mobile users, they can also use HLFs, VLFs, AuFs, > etc. Similarly, > all other mobile applications of all other SGs can also use > these HLFs, > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > the fixed > user. There is nothing fency about this.) > > (More importantly, these additional entities have raised > serious concerns: > How does a GK/BE play a role in the overall process while > "wild" suggestions > have been made to use the Annex G protocol as well? It has created a > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > In fact, some > members have boasted that they even do not see any need to go > via GKs or BEs > anymore so far mobility is concerned. As if, a "bomb " is > about to be placed > to break the very foundation of H.323 in the name of > extending of H.323 for > mobility.) > > More can be written for each technical issue, if needed. If > one likes to see > some of those points, please see the contributions that were > submitted in > the last Q.13/16 Portland meeting. > > Again, I am repeating the proposal for H.323 Annex H: > > 1. First, finish the extension of the existing H.323 base > specs, and H.225.0 > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > Terminals, GKs, BEs, and GWs. (see the contributions that are > being made so > far). > > 2. Second, develop a clear mandate whether the backend > protocols like VLF > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > Q.13/16 only, or > these protocols need to be worked with other SGs. (see the > contributions > that are being made so far). > > 3. Third, any protocols that re being used between VLF <-> > HLF, VLF <-> AuF, > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > its extension > because these are separate protocols and serve completely > different purposes > although may useful properties (e.g., hopcount, etc.) of the Annex G > protocol can be used for these protocols. > > It is very important to note that only item 1 is within the charter of > Q.13/16 (H.323). All other items need to be addressed in the > light of all > mobility works of all questions of all SGs of the ITU by the > working party > chair and others. > > (My personal view is this: Let H.323 Annex H be scoped for > item 1 only for > now as a first step. It will also take a good amount of time > to finish it. > People are waiting to see that this happens first. > > To include other items, it may take a long time to have > stable texts working > with all SGs. This will then constitue the second step.) > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, September 06, 2000 8:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Mr. Roy & other parties interested in H.323 Annex H, > > I found your posting addressing such general level issues > that I think it is > better to write a whole new mail as a response instead of > responding to your > claims and comments point by point... > > First of all you question the mandate of Annex H and its > relation to the > H.323 protocols. I find it very odd that you, without any > real arguments to > support for it, restrict the H.323 recommendations and thus > also Annex H to > handle ONLY the H.323 entities that have been defined prior > to Annex H. The > first real work that we got done for Annex H was to identify the > functionalities that were (are) needed for Mobility > Management and that were > missing from H.323. This is how we (in an ad hoc meeting in > Red Bank, in > which you yourself was also present) came up with the four new H.323 > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > defined NEW H.323 > entities that were NOT present prior to Annex H. If it is > illegal for us to > define new H.323 entities (as you seem to claim), I can't see > how the Border > Element ever got defined, since it was not defined prior to > the H.225 Annex > G. > > Second, you seem to have defined the HLF, VLF and AuF as > back-end services. > This is NOT how I see them. I see back-end services as > services that are NOT > defined in the H.323 series recommendations, but that may be used by > gatekeepers. In other words, back-end services or the > functionalities they > provide do NOT have any real definition in H.323, nor is it illegal to > define new entities to H.323 that provide same kind of > functionalities that > could be achieved by using some back-end service. The > back-end services that > are used in some implementations of the H.323 system can > undoubtedly be used > for similar purposes as the new functional entities of Annex > H are, but this > does not make the new entities back-end services. > Furthermore, the whole > point (or mandate) of Annex H is to make recommendations that > allow for > different manufacturer's equipment to be used in different > parts of the > (mobility enhanced) H.323 system and still allow the > users/terminals to move > around in the network. Thus, in my opinion, it is one of the > most important > issues of Annex H to define, how the HLF, VLF and AuF > communicate with each > other. By just stating that they are back-end services we > would in essence > NOT define this, since back-end services are NOT defined in H.323. > > Third, the protocol(s) that are used between the HLF, VLF and > AuF are still > and open issue. The reason, why the H.225 Annex G protocol is > used in the > present draft is that it is the only protocol that has been seriously > mentioned for this purpose. (Not only by the editor, but in various > contributions as well, although the editor takes full > responsibility of the > current text in the draft.) It has been identified that the > H.225 Annex H > protocol already has the functionality for locating a User > with a certain > aliasAddress. Really roughly said, this functionality is "half" of the > functionality that is needed for Mobility Management, the > other half being > the location updating procedures (which are not really > addressed by the > protocol yet). This is why the protocol is being considered > for the Annex H > usage. However, I would really like to see contributions > suggesting other > (preferably existing) protocols as well. Intel's contribution > APC-1902, was > the first one of this kind. These contributions should, however, state > clearly how the suggested protocols should be used, if there is any > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > (I'm not trying > to refer to the APC-1902 with this comment), but information > flows for the > needed Mobility Management procedures should be presented > (these include at > least the location updating procedures, call establishment > procedures, call > termination procedures and unregistration procedures). > > Fourth, the needed enhancements of the RAS, Q.931, etc. > protocols will be > provided by finishing the information flows on chapter 10. I > admit that not > much of this has yet been done, but on the other hand, at > least so far I > have found that there is not too much that has to be done > with respect to > these protocols. (There will probably be certain message > fields that will be > mandatory for Mobile Terminals that are optional in H.323 > normally, etc., > but I don't see a need for too many new message fields or messages.) > > Last, but not least, we a really in a hurry, if we want to > get the Annex H > determined in November. This is why I suggest that the > interested parties > provide the contributions describing the usage of other > protocols as the > Mobility Management protocols of Annex H as soon as possible. > Also it would > be very nice, if these contributions were made modeling the > chapter 10 of > the current draft, so that incorporating them to the annex > would be as fast > as possible. > > I'm still a bit in the middle of the process of digesting the > information I > have gotten about the Annex H work in Portland, but I'll try > to send a mail > summarizing (what I think is) our current situation later this week > (probably on Friday). I will also make a "cleaner" version of > the TD-42a as > the "starting point" for our interim work before Geneva (this > new draft will > not contain any other than editorial changes compared to TD-42a). > > ------------------------------------------------ > 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

2 1

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Roy, Radhika R, ALCOO 07 Sep '00

07 Sep '00

Hi, Paul: I am glad to hear from you. I do not think that we can decide among ourselves only (e.g., Ad Hoc H.323 Mobility Group). It is a bigger issue than H.323 Annex H, and few very few people understand what is going on. It affects the life of the entire ITU-T for all questions of all SGs. I am writing contributions probably for the SG16 plenary session to discus all issues related to each question especially that WP 2 handles. Let me provide some insights here: WP2 has questions for H.320, H.324, H.321, H.323, and others. Each question has its own architectural functional entities. For example, H.323 has its terminals, GKs/BEs, GWs, MCUs. etc. Similarly, each question has its own entities. Each application also needs to support mobility, QOS, billing, directory, security/authentication, accounting, etc. Now the challenge is that if the support of mobility, QOS, billing, directory, etc. are protocol specific (e.g., H.323, H.320, H.321), then these extensions belong to the respective protocols. For example, the mobility support of the H.323 terminals, GKs, BEs, and GWs that needs the extension of H.323 protocol (i.e., H.323 base spec,H.225.0 [RAS, Q.931, Annex G], H.245) rightly belongs to Q.13/16. Similar is the case with other applications (e.g., H.3230, H.324, H.321, IMT-2000 applications). Please note carefully: we are now adding some value-added functional entities for mobility like VLF, HLF, AuF, etc. But protocols for these need not to be the application (protocol) specific. That is, the communications between the VLF <-> HLF, HLF <-> AuF, etc. can be independent of any application protocols (e.g., H.323, H.320, H.324, H.321, IMT-2000, etc.). These are common protocols that can be developed independent of H.323, H.320, H.324, or H.321 protocol. In other words, all applications can use the same set of common protocols for VLF, HLF, and AuF communications. In this respect, we made an attempt to use IMT-2000's VLF, HLF, and AuF related protocols for the same purpose (I guess that you had been one of the lead persons for that liaison activity). In otherworlds, we wanted to avoid to develop separate VLF, HLF, and AuF protocols for each application, that is, one VLF/HLF/Auf protocol for H.323, another VLF/HLF/AuF protocol for IMT-2000, and so on. This has been the duplication of the same thing and creating a nightmare for interoperability. More importantly, it defeats the very purpose for developing of "common standards" for which the ITU is so much dedicated. The same example is not only true for mobility, this is also true for QOS, billing, directory, security/authentication, accounting. I have the same problem with the QOS for which Q.13/16 is working in H.323 Annex N. My company (AT&T) is working for almost for all SGs, and is participating in almost in all standard bodies. We are using all of those standards for providing services worldwide. So, the biggest problem that I have is to analyze what all those activities mean when services are provided combining all those standards together. I cannot just sit idle and let things go "wild" creating a mess when it comes to provides services including all applications and services. AT&T's networks not only support fixed H.323, H.320, and other services, we also support mobile applications (wireless, wire-line). It is a very serious matter from my company point of view. Had it been a trivial matter, I would not raise the alarm like this. It has very serious consequences for the entire ITU as well. I cannot just let this go like a loose canon. We need to shape the event for the common benefit of all. It is not that only the Ad Hoc mobility group of H.323 Annex H. It is the future of the 21st century standard works and process that are in stake. My earnest desire is to write contributions to explain all those things so that all delegates throughout the world can analyze what is at stake. New ideas are needed to face the challenge of the future standard works. I am glad that I have the opportunity to work in H.323 Annex H to visualize the greater problems. Now it is time to shape it to meet the future challenge although I know that it is not easy, but let me give a try: To show what belongs to where and how the extensions need to be done, not only for Annex H (mobility), but also for Annex N (QOS), accounting, security, and others. In the end, I like to count on the support of the people like yourself! In the meantime, if you have any suggestions, please send via emails so that all of us of SG16 folks throughout the world can participate in exchanging views. Best regards, Radhika R. Roy AT&T rrroy(a)att.com +1 732 420 1580 -----Original Message----- From: Reddy, Paul K [mailto:paul.k.reddy@intel.com] Sent: Thursday, September 07, 2000 1:21 PM To: Roy, Radhika R, ALCOO; ITU-SG16(a)mailbag.cps.intel.com Subject: RE: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Hi Radhika, We as ITU-T SG16 Q13/Q14 group agreed on the H.323 Annex H Terms of Reference, which includes scope of H.323 Annex H. Now, you are proposing a different scope for H.323 Annex H on this reflector. I propose that we plan to have H.323 Mobility Adhoc group conference call discussion on your proposal instead of exchanging emails on this open reflector and come to some consensus on your proposal and then take a contribution to SG16 Q13/Q14 Rapporteurs meeting in Geneva. We as H.323 Mobility Adhoc group choose Mr. Markku Korpi as Chairman of the Adhoc group, I request Mr. Korpi to setup a conference call to discuss your proposal. I am willing to sponsor the Conference Call Bridge, I propose that we can have conference call on Monday September 11, 2000 from 7:00 AM to 9:00 AM (Pacific Standard Time). Please let me know your availability all other members who wants to participate, so that I can make the Conference call bridge arrangements. regards, Paul Paul K. Reddy Intel Corporation Office Phone# +1 (503)-264-9896 Mobile Phone# +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Thursday, September 07, 2000 7:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Hi, Everyone (including all Rapporteurs and WP2 Chairman): Again, it speaks for itself as it has been mentioned earlier. As if, few folks want to create their own charter, push the boundaries of each question so that they are the ONLY people who can decide what need to be addressed in each question no matter what happens to other questions in a given WP or SG or across the whole ITU-T. They are the people who are afraid of seeing the BIG picture of the ITU-T how one question relates to others to achieve a very narrow goal. Some of these people even participated in the joint meeting of SG16 and SG11 to see how SG11 is addressing the HLF, VLF, AuF, etc. for mobility so that no duplicate work is done elsewhere. Now they are turning their back. Why? Is the norm of the ITU process? It appears that some people do not need address any technical points, as if, they create their own mandate. It may create a good discussion in the upcoming SG16 meeting in the plenary and general session. Again, the proposal for H.323 Annex H has been repeated as follows: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. Let us focus on the charter and mandate of Q.13/16: This is item 1 only. Hope that the WP2 Chairman will have time to review the whole thing with true satisfaction in the light of all questions of all SGs within the ITU. Best regards, Radhika R. Roy AT&T rrroy(a)att.com +1 732 420 1580 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, September 07, 2000 5:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 I guess you mean that you agree with all 4 points, not just the fourth point, right (i.e. I guess there's a typo)? -Jaakko p.s. I didn't want to send this to the list... > -----Original Message----- > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > Sent: 07. September 2000 1:41 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi Everyone, > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > who made 4 point in this email. > > regards, > Paul Reddy > Editor of H.246 Annex E.1, Annex E.2 > > Paul K. Reddy > Roaming Services Capability Manager > Mobile Data Services Area of Opportunity > Applications and Services Lab > Intel's Architecture Labs > Intel Corporation > Office Phone# +1 (503)-264-9896 > Mobile Phone# +1 (503)-807-9564 > Email: paul.k.reddy(a)intel.com > > > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Wednesday, September 06, 2000 9:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > Again, it is interesting to see how a very narrow view can > create serious > problems not only for a simple Annex, but also for the whole > question, for > the whole study group, and for all other study groups of the ITU-T. > > Time and again, it has been said that let us work within the > mandate of > Q.13/16 first and contributions had been made to clarify those points. > Everything has been ignored just because few folks want to do > something > almost working like a close group without seeing the BIG > picture of all > questions of all SGs of the ITU-T. In fact, some joint > meetings were also > initiated between SG16 and SG11 to see how the HLFs, VLFs, > and AuFs related > protocols are being addressed elsewhere. > > Still, they are pushing the same thing just because few folks > brought some > contributions. Objections were put via contributions, emails, > and verbal > discussions. Even there is not a single editorial note in the document > related to those things. > > A simple example will reveal the fact. We have discussed that > there are > serious problems to use GRQ messages to discover the GKs in mobile > environment. Many contributions, emails, and verbal > explanations have been > provided. If you look into the present H.323 Annex H > write-up, you will see > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > environment. Not a single word has been used even as an editorial note > whether some members have raised the questions that there are > problems need > to be addressed for GRQs. The way the GRQ section has been > written, it is a > generic one and is nothing do with mobility. Rather, it suits > to be added in > the base H.323 spec. Many more examples can be given for each > technical > issue. > > This Annex has NOT done its first important task how to > extend the H.323 > signaling messages (RAS, Q.931, Annex G) to solve the > mobility problems for > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > the mandate of > Q.13/16. Contributions are there, but everything has been ignored. > > Rather, Annex H has focused in some areas for which it has NOT got the > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > HLF <-> AuFs, > etc. These work items are not the charter of Q.13./16 alone. > These are the > areas for the joint work with all other questions of all SGs > that deal with > mobility. (In another example, even if H.320, H.321, or H.324 > wants to be > used by mobile users, they can also use HLFs, VLFs, AuFs, > etc. Similarly, > all other mobile applications of all other SGs can also use > these HLFs, > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > the fixed > user. There is nothing fency about this.) > > (More importantly, these additional entities have raised > serious concerns: > How does a GK/BE play a role in the overall process while > "wild" suggestions > have been made to use the Annex G protocol as well? It has created a > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > In fact, some > members have boasted that they even do not see any need to go > via GKs or BEs > anymore so far mobility is concerned. As if, a "bomb " is > about to be placed > to break the very foundation of H.323 in the name of > extending of H.323 for > mobility.) > > More can be written for each technical issue, if needed. If > one likes to see > some of those points, please see the contributions that were > submitted in > the last Q.13/16 Portland meeting. > > Again, I am repeating the proposal for H.323 Annex H: > > 1. First, finish the extension of the existing H.323 base > specs, and H.225.0 > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > Terminals, GKs, BEs, and GWs. (see the contributions that are > being made so > far). > > 2. Second, develop a clear mandate whether the backend > protocols like VLF > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > Q.13/16 only, or > these protocols need to be worked with other SGs. (see the > contributions > that are being made so far). > > 3. Third, any protocols that re being used between VLF <-> > HLF, VLF <-> AuF, > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > its extension > because these are separate protocols and serve completely > different purposes > although may useful properties (e.g., hopcount, etc.) of the Annex G > protocol can be used for these protocols. > > It is very important to note that only item 1 is within the charter of > Q.13/16 (H.323). All other items need to be addressed in the > light of all > mobility works of all questions of all SGs of the ITU by the > working party > chair and others. > > (My personal view is this: Let H.323 Annex H be scoped for > item 1 only for > now as a first step. It will also take a good amount of time > to finish it. > People are waiting to see that this happens first. > > To include other items, it may take a long time to have > stable texts working > with all SGs. This will then constitue the second step.) > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, September 06, 2000 8:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Mr. Roy & other parties interested in H.323 Annex H, > > I found your posting addressing such general level issues > that I think it is > better to write a whole new mail as a response instead of > responding to your > claims and comments point by point... > > First of all you question the mandate of Annex H and its > relation to the > H.323 protocols. I find it very odd that you, without any > real arguments to > support for it, restrict the H.323 recommendations and thus > also Annex H to > handle ONLY the H.323 entities that have been defined prior > to Annex H. The > first real work that we got done for Annex H was to identify the > functionalities that were (are) needed for Mobility > Management and that were > missing from H.323. This is how we (in an ad hoc meeting in > Red Bank, in > which you yourself was also present) came up with the four new H.323 > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > defined NEW H.323 > entities that were NOT present prior to Annex H. If it is > illegal for us to > define new H.323 entities (as you seem to claim), I can't see > how the Border > Element ever got defined, since it was not defined prior to > the H.225 Annex > G. > > Second, you seem to have defined the HLF, VLF and AuF as > back-end services. > This is NOT how I see them. I see back-end services as > services that are NOT > defined in the H.323 series recommendations, but that may be used by > gatekeepers. In other words, back-end services or the > functionalities they > provide do NOT have any real definition in H.323, nor is it illegal to > define new entities to H.323 that provide same kind of > functionalities that > could be achieved by using some back-end service. The > back-end services that > are used in some implementations of the H.323 system can > undoubtedly be used > for similar purposes as the new functional entities of Annex > H are, but this > does not make the new entities back-end services. > Furthermore, the whole > point (or mandate) of Annex H is to make recommendations that > allow for > different manufacturer's equipment to be used in different > parts of the > (mobility enhanced) H.323 system and still allow the > users/terminals to move > around in the network. Thus, in my opinion, it is one of the > most important > issues of Annex H to define, how the HLF, VLF and AuF > communicate with each > other. By just stating that they are back-end services we > would in essence > NOT define this, since back-end services are NOT defined in H.323. > > Third, the protocol(s) that are used between the HLF, VLF and > AuF are still > and open issue. The reason, why the H.225 Annex G protocol is > used in the > present draft is that it is the only protocol that has been seriously > mentioned for this purpose. (Not only by the editor, but in various > contributions as well, although the editor takes full > responsibility of the > current text in the draft.) It has been identified that the > H.225 Annex H > protocol already has the functionality for locating a User > with a certain > aliasAddress. Really roughly said, this functionality is "half" of the > functionality that is needed for Mobility Management, the > other half being > the location updating procedures (which are not really > addressed by the > protocol yet). This is why the protocol is being considered > for the Annex H > usage. However, I would really like to see contributions > suggesting other > (preferably existing) protocols as well. Intel's contribution > APC-1902, was > the first one of this kind. These contributions should, however, state > clearly how the suggested protocols should be used, if there is any > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > (I'm not trying > to refer to the APC-1902 with this comment), but information > flows for the > needed Mobility Management procedures should be presented > (these include at > least the location updating procedures, call establishment > procedures, call > termination procedures and unregistration procedures). > > Fourth, the needed enhancements of the RAS, Q.931, etc. > protocols will be > provided by finishing the information flows on chapter 10. I > admit that not > much of this has yet been done, but on the other hand, at > least so far I > have found that there is not too much that has to be done > with respect to > these protocols. (There will probably be certain message > fields that will be > mandatory for Mobile Terminals that are optional in H.323 > normally, etc., > but I don't see a need for too many new message fields or messages.) > > Last, but not least, we a really in a hurry, if we want to > get the Annex H > determined in November. This is why I suggest that the > interested parties > provide the contributions describing the usage of other > protocols as the > Mobility Management protocols of Annex H as soon as possible. > Also it would > be very nice, if these contributions were made modeling the > chapter 10 of > the current draft, so that incorporating them to the annex > would be as fast > as possible. > > I'm still a bit in the middle of the process of digesting the > information I > have gotten about the Annex H work in Portland, but I'll try > to send a mail > summarizing (what I think is) our current situation later this week > (probably on Friday). I will also make a "cleaner" version of > the TD-42a as > the "starting point" for our interim work before Geneva (this > new draft will > not contain any other than editorial changes compared to TD-42a). > > ------------------------------------------------ > 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

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Reddy, Paul K 07 Sep '00

07 Sep '00

Hi Jaakko, Yes, I mean that I agree with all four points you made in this email. regards, Paul -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Thursday, September 07, 2000 4:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 So I managed to send this to the list anyways, although I only meant it for Mr. Reddy. Sorry for the quite pointless mails... -Jaakko > -----Original Message----- > From: EXT Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: 07. September 2000 12:11 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > I guess you mean that you agree with all 4 points, not just the fourth > point, right (i.e. I guess there's a typo)? > > -Jaakko > > p.s. I didn't want to send this to the list... > > > -----Original Message----- > > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > > Sent: 07. September 2000 1:41 > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Hi Everyone, > > > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > > who made 4 point in this email. > > > > regards, > > Paul Reddy > > Editor of H.246 Annex E.1, Annex E.2 > > > > Paul K. Reddy > > Roaming Services Capability Manager > > Mobile Data Services Area of Opportunity > > Applications and Services Lab > > Intel's Architecture Labs > > Intel Corporation > > Office Phone# +1 (503)-264-9896 > > Mobile Phone# +1 (503)-807-9564 > > Email: paul.k.reddy(a)intel.com > > > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > > Sent: Wednesday, September 06, 2000 9:33 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > > > Again, it is interesting to see how a very narrow view can > > create serious > > problems not only for a simple Annex, but also for the whole > > question, for > > the whole study group, and for all other study groups of the ITU-T. > > > > Time and again, it has been said that let us work within the > > mandate of > > Q.13/16 first and contributions had been made to clarify > those points. > > Everything has been ignored just because few folks want to do > > something > > almost working like a close group without seeing the BIG > > picture of all > > questions of all SGs of the ITU-T. In fact, some joint > > meetings were also > > initiated between SG16 and SG11 to see how the HLFs, VLFs, > > and AuFs related > > protocols are being addressed elsewhere. > > > > Still, they are pushing the same thing just because few folks > > brought some > > contributions. Objections were put via contributions, emails, > > and verbal > > discussions. Even there is not a single editorial note in > the document > > related to those things. > > > > A simple example will reveal the fact. We have discussed that > > there are > > serious problems to use GRQ messages to discover the GKs in mobile > > environment. Many contributions, emails, and verbal > > explanations have been > > provided. If you look into the present H.323 Annex H > > write-up, you will see > > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > > environment. Not a single word has been used even as an > editorial note > > whether some members have raised the questions that there are > > problems need > > to be addressed for GRQs. The way the GRQ section has been > > written, it is a > > generic one and is nothing do with mobility. Rather, it suits > > to be added in > > the base H.323 spec. Many more examples can be given for each > > technical > > issue. > > > > This Annex has NOT done its first important task how to > > extend the H.323 > > signaling messages (RAS, Q.931, Annex G) to solve the > > mobility problems for > > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > > the mandate of > > Q.13/16. Contributions are there, but everything has been ignored. > > > > Rather, Annex H has focused in some areas for which it has > NOT got the > > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > > HLF <-> AuFs, > > etc. These work items are not the charter of Q.13./16 alone. > > These are the > > areas for the joint work with all other questions of all SGs > > that deal with > > mobility. (In another example, even if H.320, H.321, or H.324 > > wants to be > > used by mobile users, they can also use HLFs, VLFs, AuFs, > > etc. Similarly, > > all other mobile applications of all other SGs can also use > > these HLFs, > > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > > the fixed > > user. There is nothing fency about this.) > > > > (More importantly, these additional entities have raised > > serious concerns: > > How does a GK/BE play a role in the overall process while > > "wild" suggestions > > have been made to use the Annex G protocol as well? It has created a > > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > > In fact, some > > members have boasted that they even do not see any need to go > > via GKs or BEs > > anymore so far mobility is concerned. As if, a "bomb " is > > about to be placed > > to break the very foundation of H.323 in the name of > > extending of H.323 for > > mobility.) > > > > More can be written for each technical issue, if needed. If > > one likes to see > > some of those points, please see the contributions that were > > submitted in > > the last Q.13/16 Portland meeting. > > > > Again, I am repeating the proposal for H.323 Annex H: > > > > 1. First, finish the extension of the existing H.323 base > > specs, and H.225.0 > > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > > Terminals, GKs, BEs, and GWs. (see the contributions that are > > being made so > > far). > > > > 2. Second, develop a clear mandate whether the backend > > protocols like VLF > > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > > Q.13/16 only, or > > these protocols need to be worked with other SGs. (see the > > contributions > > that are being made so far). > > > > 3. Third, any protocols that re being used between VLF <-> > > HLF, VLF <-> AuF, > > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > > its extension > > because these are separate protocols and serve completely > > different purposes > > although may useful properties (e.g., hopcount, etc.) of the Annex G > > protocol can be used for these protocols. > > > > It is very important to note that only item 1 is within the > charter of > > Q.13/16 (H.323). All other items need to be addressed in the > > light of all > > mobility works of all questions of all SGs of the ITU by the > > working party > > chair and others. > > > > (My personal view is this: Let H.323 Annex H be scoped for > > item 1 only for > > now as a first step. It will also take a good amount of time > > to finish it. > > People are waiting to see that this happens first. > > > > To include other items, it may take a long time to have > > stable texts working > > with all SGs. This will then constitue the second step.) > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Wednesday, September 06, 2000 8:08 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Mr. Roy & other parties interested in H.323 Annex H, > > > > I found your posting addressing such general level issues > > that I think it is > > better to write a whole new mail as a response instead of > > responding to your > > claims and comments point by point... > > > > First of all you question the mandate of Annex H and its > > relation to the > > H.323 protocols. I find it very odd that you, without any > > real arguments to > > support for it, restrict the H.323 recommendations and thus > > also Annex H to > > handle ONLY the H.323 entities that have been defined prior > > to Annex H. The > > first real work that we got done for Annex H was to identify the > > functionalities that were (are) needed for Mobility > > Management and that were > > missing from H.323. This is how we (in an ad hoc meeting in > > Red Bank, in > > which you yourself was also present) came up with the four new H.323 > > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > > defined NEW H.323 > > entities that were NOT present prior to Annex H. If it is > > illegal for us to > > define new H.323 entities (as you seem to claim), I can't see > > how the Border > > Element ever got defined, since it was not defined prior to > > the H.225 Annex > > G. > > > > Second, you seem to have defined the HLF, VLF and AuF as > > back-end services. > > This is NOT how I see them. I see back-end services as > > services that are NOT > > defined in the H.323 series recommendations, but that may be used by > > gatekeepers. In other words, back-end services or the > > functionalities they > > provide do NOT have any real definition in H.323, nor is it > illegal to > > define new entities to H.323 that provide same kind of > > functionalities that > > could be achieved by using some back-end service. The > > back-end services that > > are used in some implementations of the H.323 system can > > undoubtedly be used > > for similar purposes as the new functional entities of Annex > > H are, but this > > does not make the new entities back-end services. > > Furthermore, the whole > > point (or mandate) of Annex H is to make recommendations that > > allow for > > different manufacturer's equipment to be used in different > > parts of the > > (mobility enhanced) H.323 system and still allow the > > users/terminals to move > > around in the network. Thus, in my opinion, it is one of the > > most important > > issues of Annex H to define, how the HLF, VLF and AuF > > communicate with each > > other. By just stating that they are back-end services we > > would in essence > > NOT define this, since back-end services are NOT defined in H.323. > > > > Third, the protocol(s) that are used between the HLF, VLF and > > AuF are still > > and open issue. The reason, why the H.225 Annex G protocol is > > used in the > > present draft is that it is the only protocol that has been > seriously > > mentioned for this purpose. (Not only by the editor, but in various > > contributions as well, although the editor takes full > > responsibility of the > > current text in the draft.) It has been identified that the > > H.225 Annex H > > protocol already has the functionality for locating a User > > with a certain > > aliasAddress. Really roughly said, this functionality is > "half" of the > > functionality that is needed for Mobility Management, the > > other half being > > the location updating procedures (which are not really > > addressed by the > > protocol yet). This is why the protocol is being considered > > for the Annex H > > usage. However, I would really like to see contributions > > suggesting other > > (preferably existing) protocols as well. Intel's contribution > > APC-1902, was > > the first one of this kind. These contributions should, > however, state > > clearly how the suggested protocols should be used, if there is any > > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > > (I'm not trying > > to refer to the APC-1902 with this comment), but information > > flows for the > > needed Mobility Management procedures should be presented > > (these include at > > least the location updating procedures, call establishment > > procedures, call > > termination procedures and unregistration procedures). > > > > Fourth, the needed enhancements of the RAS, Q.931, etc. > > protocols will be > > provided by finishing the information flows on chapter 10. I > > admit that not > > much of this has yet been done, but on the other hand, at > > least so far I > > have found that there is not too much that has to be done > > with respect to > > these protocols. (There will probably be certain message > > fields that will be > > mandatory for Mobile Terminals that are optional in H.323 > > normally, etc., > > but I don't see a need for too many new message fields or messages.) > > > > Last, but not least, we a really in a hurry, if we want to > > get the Annex H > > determined in November. This is why I suggest that the > > interested parties > > provide the contributions describing the usage of other > > protocols as the > > Mobility Management protocols of Annex H as soon as possible. > > Also it would > > be very nice, if these contributions were made modeling the > > chapter 10 of > > the current draft, so that incorporating them to the annex > > would be as fast > > as possible. > > > > I'm still a bit in the middle of the process of digesting the > > information I > > have gotten about the Annex H work in Portland, but I'll try > > to send a mail > > summarizing (what I think is) our current situation later this week > > (probably on Friday). I will also make a "cleaner" version of > > the TD-42a as > > the "starting point" for our interim work before Geneva (this > > new draft will > > not contain any other than editorial changes compared to TD-42a). > > > > ------------------------------------------------ > > 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

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Roy, Radhika R, ALCOO 07 Sep '00

07 Sep '00

Hi, Everyone (including all Rapporteurs and WP2 Chairman): Again, it speaks for itself as it has been mentioned earlier. As if, few folks want to create their own charter, push the boundaries of each question so that they are the ONLY people who can decide what need to be addressed in each question no matter what happens to other questions in a given WP or SG or across the whole ITU-T. They are the people who are afraid of seeing the BIG picture of the ITU-T how one question relates to others to achieve a very narrow goal. Some of these people even participated in the joint meeting of SG16 and SG11 to see how SG11 is addressing the HLF, VLF, AuF, etc. for mobility so that no duplicate work is done elsewhere. Now they are turning their back. Why? Is the norm of the ITU process? It appears that some people do not need address any technical points, as if, they create their own mandate. It may create a good discussion in the upcoming SG16 meeting in the plenary and general session. Again, the proposal for H.323 Annex H has been repeated as follows: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. Let us focus on the charter and mandate of Q.13/16: This is item 1 only. Hope that the WP2 Chairman will have time to review the whole thing with true satisfaction in the light of all questions of all SGs within the ITU. Best regards, Radhika R. Roy AT&T rrroy(a)att.com +1 732 420 1580 -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, September 07, 2000 5:11 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 I guess you mean that you agree with all 4 points, not just the fourth point, right (i.e. I guess there's a typo)? -Jaakko p.s. I didn't want to send this to the list... > -----Original Message----- > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > Sent: 07. September 2000 1:41 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi Everyone, > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > who made 4 point in this email. > > regards, > Paul Reddy > Editor of H.246 Annex E.1, Annex E.2 > > Paul K. Reddy > Roaming Services Capability Manager > Mobile Data Services Area of Opportunity > Applications and Services Lab > Intel's Architecture Labs > Intel Corporation > Office Phone# +1 (503)-264-9896 > Mobile Phone# +1 (503)-807-9564 > Email: paul.k.reddy(a)intel.com > > > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Wednesday, September 06, 2000 9:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > Again, it is interesting to see how a very narrow view can > create serious > problems not only for a simple Annex, but also for the whole > question, for > the whole study group, and for all other study groups of the ITU-T. > > Time and again, it has been said that let us work within the > mandate of > Q.13/16 first and contributions had been made to clarify those points. > Everything has been ignored just because few folks want to do > something > almost working like a close group without seeing the BIG > picture of all > questions of all SGs of the ITU-T. In fact, some joint > meetings were also > initiated between SG16 and SG11 to see how the HLFs, VLFs, > and AuFs related > protocols are being addressed elsewhere. > > Still, they are pushing the same thing just because few folks > brought some > contributions. Objections were put via contributions, emails, > and verbal > discussions. Even there is not a single editorial note in the document > related to those things. > > A simple example will reveal the fact. We have discussed that > there are > serious problems to use GRQ messages to discover the GKs in mobile > environment. Many contributions, emails, and verbal > explanations have been > provided. If you look into the present H.323 Annex H > write-up, you will see > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > environment. Not a single word has been used even as an editorial note > whether some members have raised the questions that there are > problems need > to be addressed for GRQs. The way the GRQ section has been > written, it is a > generic one and is nothing do with mobility. Rather, it suits > to be added in > the base H.323 spec. Many more examples can be given for each > technical > issue. > > This Annex has NOT done its first important task how to > extend the H.323 > signaling messages (RAS, Q.931, Annex G) to solve the > mobility problems for > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > the mandate of > Q.13/16. Contributions are there, but everything has been ignored. > > Rather, Annex H has focused in some areas for which it has NOT got the > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > HLF <-> AuFs, > etc. These work items are not the charter of Q.13./16 alone. > These are the > areas for the joint work with all other questions of all SGs > that deal with > mobility. (In another example, even if H.320, H.321, or H.324 > wants to be > used by mobile users, they can also use HLFs, VLFs, AuFs, > etc. Similarly, > all other mobile applications of all other SGs can also use > these HLFs, > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > the fixed > user. There is nothing fency about this.) > > (More importantly, these additional entities have raised > serious concerns: > How does a GK/BE play a role in the overall process while > "wild" suggestions > have been made to use the Annex G protocol as well? It has created a > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > In fact, some > members have boasted that they even do not see any need to go > via GKs or BEs > anymore so far mobility is concerned. As if, a "bomb " is > about to be placed > to break the very foundation of H.323 in the name of > extending of H.323 for > mobility.) > > More can be written for each technical issue, if needed. If > one likes to see > some of those points, please see the contributions that were > submitted in > the last Q.13/16 Portland meeting. > > Again, I am repeating the proposal for H.323 Annex H: > > 1. First, finish the extension of the existing H.323 base > specs, and H.225.0 > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > Terminals, GKs, BEs, and GWs. (see the contributions that are > being made so > far). > > 2. Second, develop a clear mandate whether the backend > protocols like VLF > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > Q.13/16 only, or > these protocols need to be worked with other SGs. (see the > contributions > that are being made so far). > > 3. Third, any protocols that re being used between VLF <-> > HLF, VLF <-> AuF, > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > its extension > because these are separate protocols and serve completely > different purposes > although may useful properties (e.g., hopcount, etc.) of the Annex G > protocol can be used for these protocols. > > It is very important to note that only item 1 is within the charter of > Q.13/16 (H.323). All other items need to be addressed in the > light of all > mobility works of all questions of all SGs of the ITU by the > working party > chair and others. > > (My personal view is this: Let H.323 Annex H be scoped for > item 1 only for > now as a first step. It will also take a good amount of time > to finish it. > People are waiting to see that this happens first. > > To include other items, it may take a long time to have > stable texts working > with all SGs. This will then constitue the second step.) > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, September 06, 2000 8:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Mr. Roy & other parties interested in H.323 Annex H, > > I found your posting addressing such general level issues > that I think it is > better to write a whole new mail as a response instead of > responding to your > claims and comments point by point... > > First of all you question the mandate of Annex H and its > relation to the > H.323 protocols. I find it very odd that you, without any > real arguments to > support for it, restrict the H.323 recommendations and thus > also Annex H to > handle ONLY the H.323 entities that have been defined prior > to Annex H. The > first real work that we got done for Annex H was to identify the > functionalities that were (are) needed for Mobility > Management and that were > missing from H.323. This is how we (in an ad hoc meeting in > Red Bank, in > which you yourself was also present) came up with the four new H.323 > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > defined NEW H.323 > entities that were NOT present prior to Annex H. If it is > illegal for us to > define new H.323 entities (as you seem to claim), I can't see > how the Border > Element ever got defined, since it was not defined prior to > the H.225 Annex > G. > > Second, you seem to have defined the HLF, VLF and AuF as > back-end services. > This is NOT how I see them. I see back-end services as > services that are NOT > defined in the H.323 series recommendations, but that may be used by > gatekeepers. In other words, back-end services or the > functionalities they > provide do NOT have any real definition in H.323, nor is it illegal to > define new entities to H.323 that provide same kind of > functionalities that > could be achieved by using some back-end service. The > back-end services that > are used in some implementations of the H.323 system can > undoubtedly be used > for similar purposes as the new functional entities of Annex > H are, but this > does not make the new entities back-end services. > Furthermore, the whole > point (or mandate) of Annex H is to make recommendations that > allow for > different manufacturer's equipment to be used in different > parts of the > (mobility enhanced) H.323 system and still allow the > users/terminals to move > around in the network. Thus, in my opinion, it is one of the > most important > issues of Annex H to define, how the HLF, VLF and AuF > communicate with each > other. By just stating that they are back-end services we > would in essence > NOT define this, since back-end services are NOT defined in H.323. > > Third, the protocol(s) that are used between the HLF, VLF and > AuF are still > and open issue. The reason, why the H.225 Annex G protocol is > used in the > present draft is that it is the only protocol that has been seriously > mentioned for this purpose. (Not only by the editor, but in various > contributions as well, although the editor takes full > responsibility of the > current text in the draft.) It has been identified that the > H.225 Annex H > protocol already has the functionality for locating a User > with a certain > aliasAddress. Really roughly said, this functionality is "half" of the > functionality that is needed for Mobility Management, the > other half being > the location updating procedures (which are not really > addressed by the > protocol yet). This is why the protocol is being considered > for the Annex H > usage. However, I would really like to see contributions > suggesting other > (preferably existing) protocols as well. Intel's contribution > APC-1902, was > the first one of this kind. These contributions should, however, state > clearly how the suggested protocols should be used, if there is any > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > (I'm not trying > to refer to the APC-1902 with this comment), but information > flows for the > needed Mobility Management procedures should be presented > (these include at > least the location updating procedures, call establishment > procedures, call > termination procedures and unregistration procedures). > > Fourth, the needed enhancements of the RAS, Q.931, etc. > protocols will be > provided by finishing the information flows on chapter 10. I > admit that not > much of this has yet been done, but on the other hand, at > least so far I > have found that there is not too much that has to be done > with respect to > these protocols. (There will probably be certain message > fields that will be > mandatory for Mobile Terminals that are optional in H.323 > normally, etc., > but I don't see a need for too many new message fields or messages.) > > Last, but not least, we a really in a hurry, if we want to > get the Annex H > determined in November. This is why I suggest that the > interested parties > provide the contributions describing the usage of other > protocols as the > Mobility Management protocols of Annex H as soon as possible. > Also it would > be very nice, if these contributions were made modeling the > chapter 10 of > the current draft, so that incorporating them to the annex > would be as fast > as possible. > > I'm still a bit in the middle of the process of digesting the > information I > have gotten about the Annex H work in Portland, but I'll try > to send a mail > summarizing (what I think is) our current situation later this week > (probably on Friday). I will also make a "cleaner" version of > the TD-42a as > the "starting point" for our interim work before Geneva (this > new draft will > not contain any other than editorial changes compared to TD-42a). > > ------------------------------------------------ > 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: Revised H.323 URL document
by Callaghan, Robert 07 Sep '00

07 Sep '00

Paul, I definitely like "mode" as a replacement for "protocol." It clearly represents the required procedure without over doing details. I think that we got it. 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: Paul E. Jones [mailto:paulej@acm.org] Sent: Wednesday, September 06, 2000 11:20 PM To: Robert Callaghan; Orit Levin; ITU-SG16(a)mailbag.cps.intel.com Subject: Revised H.323 URL document Orit, Bob, et al, Attached is the revised section covering the syntax of the H.323 URL. This (I hope) includes all of the changes we have discussed so far. I am not sure that we settled on the "mode" parameter, but I made the change here in this document-- feedback is welcome. Best Regards, Paul

1 0

Re: H.323 URL Specification (second try)
by Callaghan, Robert 07 Sep '00

07 Sep '00

Paul, I think that we are in agreement (who would believe this). I will drop the requirement for case insensitive for the user part. I would rather have UTF-8. The DNS part still must be ASCII and case insensitive. I hope that Orit, and others, are also in agreement. 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: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, September 06, 2000 10:41 PM To: Callaghan, Robert; Orit Levin Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) Subject: Re: Re: H.323 URL Specification (second try) Bob, To prevent the HTML mail headaches, I will comment by item number. 0) Yes, I believe that DNS may be used to locate the "host" and an LRQ then sent to port "port" of "host". "host" will resolve the address and return an LCF. The user is not necessarily registered with the GK. Actually, the LRQ might even be forwarded (available in v4) and the GK to which the user is actually registered may reply. Now, that does not mean that the endpoint has to perform the DNS query and resolve the address-- it may pass it to the GK for resolution. The Gatekeeper might also pass it to a border element for resolution, since Annex G can send templates around with domain names in them indicating the domains it can resolve. So, I think there are two possible resolution mechanisms available to a Gatekeeper. I believe what I meant to say I was going to remove is the statement in parentheses about the LRQ message being used. Essentially, we're left with just saying that the default protocol is "ras", which means that a GK should resolve the address. However, mentioned separately.. somewhere.. that I think it might be reasonable to specify the resolution "mode" rather than the protocol: "direct" (i.e., one sends a setup to the address) or "indirect" (i.e., RAS must be used by the endpoint and the GK may use RAS or Annex G, a database, a carrier pigeon, etc.) 1) I did not make my point very clear at all-- I apologize. What I was trying to say is that users enter aliases, not IP addresses. Today, most H.323 users enter telephone numbers or some type of alias and not the IP address of the called endpoint. I unsuccessfully tried to draw a parallel between alias vs IP and user vs host. In my opinion, the most common forms of the URL will be either "h323:user@host" or "h323:user". The former will be the most popular, by far. The latter will be more widely used inside corporate networks. We see this today with popular e-mail programs, etc. Some companies are so large that multiple domains are necessary, so it doesn't work well. However, most companies keep all e-mail address for the company under one domain. So, "h323:user" would be very likely in many corporate environments. I prefer to allow these two syntaxes as I believe they are most common. I do not want "h323:paulej@"-- that I just don't like. Paul ----- Original Message ----- From: Callaghan, Robert <mailto:Robert.Callaghan@icn.siemens.com> To: 'Paul E. <mailto:paulej@packetizer.com> Jones' ; Orit <mailto:orit@radvision.com> Levin Cc: Mailing list for parties associated with <mailto:ITU-SG16@mailbag.cps.intel.com> ITU-T Study Group 16 (E-mail) Sent: Tuesday, September 05, 2000 10:54 AM Subject: RE: Re: H.323 URL Specification (second try) Paul, See below. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com <mailto:Robert.Callaghan@ICN.Siemens.com> ------------------------------------------------------------------ (0) The use of url means the "address resolution" is done (by the local GK) using the DNS, not RAS! This is why the "user only" url of H.323, is really an exceptional case. It is a question, if we want to keep it within the url. It lets the local (source) GK know, that the "address resolution" procedure should performed by other, then DNS, means. The "protocol" means: the signaling H.323 protocol to contact the (next hop towards the) destination, after the IP address had been resolved. (0) I will remove the reference to RAS and expect to see an explicit description of the procedure in Annex O. What I would expect is that the hostport part will resolve to a GK to which LRQ messages are directed. [RWC] Now I am confused. I thought that DNS was used to locate the resolution server. Then LRQ(RAS) was used to communicate with that server to resolve the address of the user. The server doing the address resolution may not be involved in the final connections. (1) I disagree that it is the exception. I would contend that calling a specific machine would be the exception. Sure, one can call and endpoint directly, but that's not typical. It is in testing and development environments, but in production environments, users enter telephone numbers. Also, I can imagine intranets where the h323 URL might be used. At work, I might post a page with "h323:paulej", but I would never post "h323:@cisco.com". However, the latter is allowed, of course. What I do not want is "h323:paulej@" on a web page. That's ugly, in my opinion. I realize that the SIP folks chose that, but it seems illogical to me. [RWC] I do not see any relationship between an URL and a telephone number. If a user enters a telephone number the connection should be established using either the dialedDigits alias or the partyNumber alias not the URL-id alias. For me, the URL user should be a name type structure like in email users. This allows for a number as a name but not as a telephone number. I do not accept the SIP and ENUM concept where telephone numbers are funny names with a default domain for DNS. In fact, I think that this will not work due to difficulties with administration ownership of telephone numbers. [RWC] I do agree that user only will be an exception because it forces the use of a default domain for DNS. It is not likely that there will be universal default domain. (2) If I provided "h323:@192.168.1.1;proto=q931", a device should assume that it can reach it on the default 1720 port or the default Annex E port (as described in Annex E). If, however, I use a different port like "h323:@192.168.1.1:2500;proto=q931", I would say that Annex E is out of the picture. That is another reason why I believe the first step to resolution should be through a Gatekeeper. The gatekeeper can not only resolve the address, but also indicate any non-standard ports, including both the TCP and Annex E transport information. [RWC] In this case the endpoint that wished to use Annex E must support the requirement of Annex E that requires the ability to fall back to TCP.

1 0

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Jaakko Sundquist 07 Sep '00

07 Sep '00

So I managed to send this to the list anyways, although I only meant it for Mr. Reddy. Sorry for the quite pointless mails... -Jaakko > -----Original Message----- > From: EXT Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: 07. September 2000 12:11 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > I guess you mean that you agree with all 4 points, not just the fourth > point, right (i.e. I guess there's a typo)? > > -Jaakko > > p.s. I didn't want to send this to the list... > > > -----Original Message----- > > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > > Sent: 07. September 2000 1:41 > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Hi Everyone, > > > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > > who made 4 point in this email. > > > > regards, > > Paul Reddy > > Editor of H.246 Annex E.1, Annex E.2 > > > > Paul K. Reddy > > Roaming Services Capability Manager > > Mobile Data Services Area of Opportunity > > Applications and Services Lab > > Intel's Architecture Labs > > Intel Corporation > > Office Phone# +1 (503)-264-9896 > > Mobile Phone# +1 (503)-807-9564 > > Email: paul.k.reddy(a)intel.com > > > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > > Sent: Wednesday, September 06, 2000 9:33 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > > > Again, it is interesting to see how a very narrow view can > > create serious > > problems not only for a simple Annex, but also for the whole > > question, for > > the whole study group, and for all other study groups of the ITU-T. > > > > Time and again, it has been said that let us work within the > > mandate of > > Q.13/16 first and contributions had been made to clarify > those points. > > Everything has been ignored just because few folks want to do > > something > > almost working like a close group without seeing the BIG > > picture of all > > questions of all SGs of the ITU-T. In fact, some joint > > meetings were also > > initiated between SG16 and SG11 to see how the HLFs, VLFs, > > and AuFs related > > protocols are being addressed elsewhere. > > > > Still, they are pushing the same thing just because few folks > > brought some > > contributions. Objections were put via contributions, emails, > > and verbal > > discussions. Even there is not a single editorial note in > the document > > related to those things. > > > > A simple example will reveal the fact. We have discussed that > > there are > > serious problems to use GRQ messages to discover the GKs in mobile > > environment. Many contributions, emails, and verbal > > explanations have been > > provided. If you look into the present H.323 Annex H > > write-up, you will see > > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > > environment. Not a single word has been used even as an > editorial note > > whether some members have raised the questions that there are > > problems need > > to be addressed for GRQs. The way the GRQ section has been > > written, it is a > > generic one and is nothing do with mobility. Rather, it suits > > to be added in > > the base H.323 spec. Many more examples can be given for each > > technical > > issue. > > > > This Annex has NOT done its first important task how to > > extend the H.323 > > signaling messages (RAS, Q.931, Annex G) to solve the > > mobility problems for > > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > > the mandate of > > Q.13/16. Contributions are there, but everything has been ignored. > > > > Rather, Annex H has focused in some areas for which it has > NOT got the > > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > > HLF <-> AuFs, > > etc. These work items are not the charter of Q.13./16 alone. > > These are the > > areas for the joint work with all other questions of all SGs > > that deal with > > mobility. (In another example, even if H.320, H.321, or H.324 > > wants to be > > used by mobile users, they can also use HLFs, VLFs, AuFs, > > etc. Similarly, > > all other mobile applications of all other SGs can also use > > these HLFs, > > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > > the fixed > > user. There is nothing fency about this.) > > > > (More importantly, these additional entities have raised > > serious concerns: > > How does a GK/BE play a role in the overall process while > > "wild" suggestions > > have been made to use the Annex G protocol as well? It has created a > > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > > In fact, some > > members have boasted that they even do not see any need to go > > via GKs or BEs > > anymore so far mobility is concerned. As if, a "bomb " is > > about to be placed > > to break the very foundation of H.323 in the name of > > extending of H.323 for > > mobility.) > > > > More can be written for each technical issue, if needed. If > > one likes to see > > some of those points, please see the contributions that were > > submitted in > > the last Q.13/16 Portland meeting. > > > > Again, I am repeating the proposal for H.323 Annex H: > > > > 1. First, finish the extension of the existing H.323 base > > specs, and H.225.0 > > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > > Terminals, GKs, BEs, and GWs. (see the contributions that are > > being made so > > far). > > > > 2. Second, develop a clear mandate whether the backend > > protocols like VLF > > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > > Q.13/16 only, or > > these protocols need to be worked with other SGs. (see the > > contributions > > that are being made so far). > > > > 3. Third, any protocols that re being used between VLF <-> > > HLF, VLF <-> AuF, > > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > > its extension > > because these are separate protocols and serve completely > > different purposes > > although may useful properties (e.g., hopcount, etc.) of the Annex G > > protocol can be used for these protocols. > > > > It is very important to note that only item 1 is within the > charter of > > Q.13/16 (H.323). All other items need to be addressed in the > > light of all > > mobility works of all questions of all SGs of the ITU by the > > working party > > chair and others. > > > > (My personal view is this: Let H.323 Annex H be scoped for > > item 1 only for > > now as a first step. It will also take a good amount of time > > to finish it. > > People are waiting to see that this happens first. > > > > To include other items, it may take a long time to have > > stable texts working > > with all SGs. This will then constitue the second step.) > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Wednesday, September 06, 2000 8:08 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > > Mandate of > > Q. 13/1 6 > > > > > > Mr. Roy & other parties interested in H.323 Annex H, > > > > I found your posting addressing such general level issues > > that I think it is > > better to write a whole new mail as a response instead of > > responding to your > > claims and comments point by point... > > > > First of all you question the mandate of Annex H and its > > relation to the > > H.323 protocols. I find it very odd that you, without any > > real arguments to > > support for it, restrict the H.323 recommendations and thus > > also Annex H to > > handle ONLY the H.323 entities that have been defined prior > > to Annex H. The > > first real work that we got done for Annex H was to identify the > > functionalities that were (are) needed for Mobility > > Management and that were > > missing from H.323. This is how we (in an ad hoc meeting in > > Red Bank, in > > which you yourself was also present) came up with the four new H.323 > > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > > defined NEW H.323 > > entities that were NOT present prior to Annex H. If it is > > illegal for us to > > define new H.323 entities (as you seem to claim), I can't see > > how the Border > > Element ever got defined, since it was not defined prior to > > the H.225 Annex > > G. > > > > Second, you seem to have defined the HLF, VLF and AuF as > > back-end services. > > This is NOT how I see them. I see back-end services as > > services that are NOT > > defined in the H.323 series recommendations, but that may be used by > > gatekeepers. In other words, back-end services or the > > functionalities they > > provide do NOT have any real definition in H.323, nor is it > illegal to > > define new entities to H.323 that provide same kind of > > functionalities that > > could be achieved by using some back-end service. The > > back-end services that > > are used in some implementations of the H.323 system can > > undoubtedly be used > > for similar purposes as the new functional entities of Annex > > H are, but this > > does not make the new entities back-end services. > > Furthermore, the whole > > point (or mandate) of Annex H is to make recommendations that > > allow for > > different manufacturer's equipment to be used in different > > parts of the > > (mobility enhanced) H.323 system and still allow the > > users/terminals to move > > around in the network. Thus, in my opinion, it is one of the > > most important > > issues of Annex H to define, how the HLF, VLF and AuF > > communicate with each > > other. By just stating that they are back-end services we > > would in essence > > NOT define this, since back-end services are NOT defined in H.323. > > > > Third, the protocol(s) that are used between the HLF, VLF and > > AuF are still > > and open issue. The reason, why the H.225 Annex G protocol is > > used in the > > present draft is that it is the only protocol that has been > seriously > > mentioned for this purpose. (Not only by the editor, but in various > > contributions as well, although the editor takes full > > responsibility of the > > current text in the draft.) It has been identified that the > > H.225 Annex H > > protocol already has the functionality for locating a User > > with a certain > > aliasAddress. Really roughly said, this functionality is > "half" of the > > functionality that is needed for Mobility Management, the > > other half being > > the location updating procedures (which are not really > > addressed by the > > protocol yet). This is why the protocol is being considered > > for the Annex H > > usage. However, I would really like to see contributions > > suggesting other > > (preferably existing) protocols as well. Intel's contribution > > APC-1902, was > > the first one of this kind. These contributions should, > however, state > > clearly how the suggested protocols should be used, if there is any > > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > > (I'm not trying > > to refer to the APC-1902 with this comment), but information > > flows for the > > needed Mobility Management procedures should be presented > > (these include at > > least the location updating procedures, call establishment > > procedures, call > > termination procedures and unregistration procedures). > > > > Fourth, the needed enhancements of the RAS, Q.931, etc. > > protocols will be > > provided by finishing the information flows on chapter 10. I > > admit that not > > much of this has yet been done, but on the other hand, at > > least so far I > > have found that there is not too much that has to be done > > with respect to > > these protocols. (There will probably be certain message > > fields that will be > > mandatory for Mobile Terminals that are optional in H.323 > > normally, etc., > > but I don't see a need for too many new message fields or messages.) > > > > Last, but not least, we a really in a hurry, if we want to > > get the Annex H > > determined in November. This is why I suggest that the > > interested parties > > provide the contributions describing the usage of other > > protocols as the > > Mobility Management protocols of Annex H as soon as possible. > > Also it would > > be very nice, if these contributions were made modeling the > > chapter 10 of > > the current draft, so that incorporating them to the annex > > would be as fast > > as possible. > > > > I'm still a bit in the middle of the process of digesting the > > information I > > have gotten about the Annex H work in Portland, but I'll try > > to send a mail > > summarizing (what I think is) our current situation later this week > > (probably on Friday). I will also make a "cleaner" version of > > the TD-42a as > > the "starting point" for our interim work before Geneva (this > > new draft will > > not contain any other than editorial changes compared to TD-42a). > > > > ------------------------------------------------ > > 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

Enforcing symmetric operation in the context of slow start for H. 323v4
by Mike Nilsson 07 Sep '00

07 Sep '00

At the Portland rapporteur's meeting of Q12-14, document APC-1881, 'Enforcing symmetric operation in the context of slow start for H.323v4', was discussed. The outcome of the discussion, as described in the meeting report, is: This was accepted for the H.323 IG and also H.323 V4. It was agreed that this was meritorius, but that some further discussion was needed. See TD-47. The agreement is that APC-1881 is adopted for changes to H.323 V4, and TD-47 for H.245 V7, with the redefinition of the receiveAndTransmitt capability being the preferred approach. It was noted that the rejectReason needs to be mentioned in TD-47. Text will also be added to note that the procedures of TD-47 only apply if the slave has detected a conflict. All are urged to look very closely at this, and to consider if there are any issues with this. If any are found, we will make changes in November. The editor will post this discussion on the mailing list to ensure broad discussion. The purpose of this mail is simply to do as the meeting report stated, and highlight the issue and to try to get broad agreement on the proposed solution. As far as H.245 is concerned the proposed solution is to include text from TD-47a that is labelled as 'Proposal for immediate action' and the first option (redefinition of the receiveAndTransmitt capability) from the section labelled 'Longer term options'. The documents are available at: ftp://standard.pictel.com/avc-site/0008_Por/APC-1881.zip ftp://standard.pictel.com/avc-site/0008_Por/TD-47a.zip Best regards Mike Nilsson -------------------- Mike Nilsson Multimedia Applications B81 Room 102 pp14 BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.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: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Jaakko Sundquist 07 Sep '00

07 Sep '00

I guess you mean that you agree with all 4 points, not just the fourth point, right (i.e. I guess there's a typo)? -Jaakko p.s. I didn't want to send this to the list... > -----Original Message----- > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM] > Sent: 07. September 2000 1:41 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi Everyone, > > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, > who made 4 point in this email. > > regards, > Paul Reddy > Editor of H.246 Annex E.1, Annex E.2 > > Paul K. Reddy > Roaming Services Capability Manager > Mobile Data Services Area of Opportunity > Applications and Services Lab > Intel's Architecture Labs > Intel Corporation > Office Phone# +1 (503)-264-9896 > Mobile Phone# +1 (503)-807-9564 > Email: paul.k.reddy(a)intel.com > > > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Wednesday, September 06, 2000 9:33 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Hi, Everyone (including all Rapporteurs and WP 2 Chairman): > > Again, it is interesting to see how a very narrow view can > create serious > problems not only for a simple Annex, but also for the whole > question, for > the whole study group, and for all other study groups of the ITU-T. > > Time and again, it has been said that let us work within the > mandate of > Q.13/16 first and contributions had been made to clarify those points. > Everything has been ignored just because few folks want to do > something > almost working like a close group without seeing the BIG > picture of all > questions of all SGs of the ITU-T. In fact, some joint > meetings were also > initiated between SG16 and SG11 to see how the HLFs, VLFs, > and AuFs related > protocols are being addressed elsewhere. > > Still, they are pushing the same thing just because few folks > brought some > contributions. Objections were put via contributions, emails, > and verbal > discussions. Even there is not a single editorial note in the document > related to those things. > > A simple example will reveal the fact. We have discussed that > there are > serious problems to use GRQ messages to discover the GKs in mobile > environment. Many contributions, emails, and verbal > explanations have been > provided. If you look into the present H.323 Annex H > write-up, you will see > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile > environment. Not a single word has been used even as an editorial note > whether some members have raised the questions that there are > problems need > to be addressed for GRQs. The way the GRQ section has been > written, it is a > generic one and is nothing do with mobility. Rather, it suits > to be added in > the base H.323 spec. Many more examples can be given for each > technical > issue. > > This Annex has NOT done its first important task how to > extend the H.323 > signaling messages (RAS, Q.931, Annex G) to solve the > mobility problems for > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is > the mandate of > Q.13/16. Contributions are there, but everything has been ignored. > > Rather, Annex H has focused in some areas for which it has NOT got the > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, > HLF <-> AuFs, > etc. These work items are not the charter of Q.13./16 alone. > These are the > areas for the joint work with all other questions of all SGs > that deal with > mobility. (In another example, even if H.320, H.321, or H.324 > wants to be > used by mobile users, they can also use HLFs, VLFs, AuFs, > etc. Similarly, > all other mobile applications of all other SGs can also use > these HLFs, > VLFs, AuFs, etc. Take the case of AuF, it can also be used by > the fixed > user. There is nothing fency about this.) > > (More importantly, these additional entities have raised > serious concerns: > How does a GK/BE play a role in the overall process while > "wild" suggestions > have been made to use the Annex G protocol as well? It has created a > "dangerous" mechanism to "by-pass" the very need of GKs/BEs. > In fact, some > members have boasted that they even do not see any need to go > via GKs or BEs > anymore so far mobility is concerned. As if, a "bomb " is > about to be placed > to break the very foundation of H.323 in the name of > extending of H.323 for > mobility.) > > More can be written for each technical issue, if needed. If > one likes to see > some of those points, please see the contributions that were > submitted in > the last Q.13/16 Portland meeting. > > Again, I am repeating the proposal for H.323 Annex H: > > 1. First, finish the extension of the existing H.323 base > specs, and H.225.0 > (RAS, Q.931, Annex G)to support mobility among the H.323 entities: > Terminals, GKs, BEs, and GWs. (see the contributions that are > being made so > far). > > 2. Second, develop a clear mandate whether the backend > protocols like VLF > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of > Q.13/16 only, or > these protocols need to be worked with other SGs. (see the > contributions > that are being made so far). > > 3. Third, any protocols that re being used between VLF <-> > HLF, VLF <-> AuF, > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or > its extension > because these are separate protocols and serve completely > different purposes > although may useful properties (e.g., hopcount, etc.) of the Annex G > protocol can be used for these protocols. > > It is very important to note that only item 1 is within the charter of > Q.13/16 (H.323). All other items need to be addressed in the > light of all > mobility works of all questions of all SGs of the ITU by the > working party > chair and others. > > (My personal view is this: Let H.323 Annex H be scoped for > item 1 only for > now as a first step. It will also take a good amount of time > to finish it. > People are waiting to see that this happens first. > > To include other items, it may take a long time to have > stable texts working > with all SGs. This will then constitue the second step.) > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: Wednesday, September 06, 2000 8:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - > Mandate of > Q. 13/1 6 > > > Mr. Roy & other parties interested in H.323 Annex H, > > I found your posting addressing such general level issues > that I think it is > better to write a whole new mail as a response instead of > responding to your > claims and comments point by point... > > First of all you question the mandate of Annex H and its > relation to the > H.323 protocols. I find it very odd that you, without any > real arguments to > support for it, restrict the H.323 recommendations and thus > also Annex H to > handle ONLY the H.323 entities that have been defined prior > to Annex H. The > first real work that we got done for Annex H was to identify the > functionalities that were (are) needed for Mobility > Management and that were > missing from H.323. This is how we (in an ad hoc meeting in > Red Bank, in > which you yourself was also present) came up with the four new H.323 > (functional) entities: HLF, VLF, AuF and IWF. Thus we have > defined NEW H.323 > entities that were NOT present prior to Annex H. If it is > illegal for us to > define new H.323 entities (as you seem to claim), I can't see > how the Border > Element ever got defined, since it was not defined prior to > the H.225 Annex > G. > > Second, you seem to have defined the HLF, VLF and AuF as > back-end services. > This is NOT how I see them. I see back-end services as > services that are NOT > defined in the H.323 series recommendations, but that may be used by > gatekeepers. In other words, back-end services or the > functionalities they > provide do NOT have any real definition in H.323, nor is it illegal to > define new entities to H.323 that provide same kind of > functionalities that > could be achieved by using some back-end service. The > back-end services that > are used in some implementations of the H.323 system can > undoubtedly be used > for similar purposes as the new functional entities of Annex > H are, but this > does not make the new entities back-end services. > Furthermore, the whole > point (or mandate) of Annex H is to make recommendations that > allow for > different manufacturer's equipment to be used in different > parts of the > (mobility enhanced) H.323 system and still allow the > users/terminals to move > around in the network. Thus, in my opinion, it is one of the > most important > issues of Annex H to define, how the HLF, VLF and AuF > communicate with each > other. By just stating that they are back-end services we > would in essence > NOT define this, since back-end services are NOT defined in H.323. > > Third, the protocol(s) that are used between the HLF, VLF and > AuF are still > and open issue. The reason, why the H.225 Annex G protocol is > used in the > present draft is that it is the only protocol that has been seriously > mentioned for this purpose. (Not only by the editor, but in various > contributions as well, although the editor takes full > responsibility of the > current text in the draft.) It has been identified that the > H.225 Annex H > protocol already has the functionality for locating a User > with a certain > aliasAddress. Really roughly said, this functionality is "half" of the > functionality that is needed for Mobility Management, the > other half being > the location updating procedures (which are not really > addressed by the > protocol yet). This is why the protocol is being considered > for the Annex H > usage. However, I would really like to see contributions > suggesting other > (preferably existing) protocols as well. Intel's contribution > APC-1902, was > the first one of this kind. These contributions should, however, state > clearly how the suggested protocols should be used, if there is any > ambiguity. I.e. just stating: "Use Mobile IP" is not enough > (I'm not trying > to refer to the APC-1902 with this comment), but information > flows for the > needed Mobility Management procedures should be presented > (these include at > least the location updating procedures, call establishment > procedures, call > termination procedures and unregistration procedures). > > Fourth, the needed enhancements of the RAS, Q.931, etc. > protocols will be > provided by finishing the information flows on chapter 10. I > admit that not > much of this has yet been done, but on the other hand, at > least so far I > have found that there is not too much that has to be done > with respect to > these protocols. (There will probably be certain message > fields that will be > mandatory for Mobile Terminals that are optional in H.323 > normally, etc., > but I don't see a need for too many new message fields or messages.) > > Last, but not least, we a really in a hurry, if we want to > get the Annex H > determined in November. This is why I suggest that the > interested parties > provide the contributions describing the usage of other > protocols as the > Mobility Management protocols of Annex H as soon as possible. > Also it would > be very nice, if these contributions were made modeling the > chapter 10 of > the current draft, so that incorporating them to the annex > would be as fast > as possible. > > I'm still a bit in the middle of the process of digesting the > information I > have gotten about the Annex H work in Portland, but I'll try > to send a mail > summarizing (what I think is) our current situation later this week > (probably on Friday). I will also make a "cleaner" version of > the TD-42a as > the "starting point" for our interim work before Geneva (this > new draft will > not contain any other than editorial changes compared to TD-42a). > > ------------------------------------------------ > 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

Revised H.323 URL document
by Paul E. Jones 06 Sep '00

06 Sep '00

Orit, Bob, et al, Attached is the revised section covering the syntax of the H.323 URL. This (I hope) includes all of the changes we have discussed so far. I am not sure that we settled on the "mode" parameter, but I made the change here in this document-- feedback is welcome. Best Regards, Paul

1 0

RE: Re: H.323 URL Specification (second try)
by Callaghan, Robert 06 Sep '00

06 Sep '00

Paul, See below. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ (0) The use of url means the "address resolution" is done (by the local GK) using the DNS, not RAS! This is why the "user only" url of H.323, is really an exceptional case. It is a question, if we want to keep it within the url. It lets the local (source) GK know, that the "address resolution" procedure should performed by other, then DNS, means. The "protocol" means: the signaling H.323 protocol to contact the (next hop towards the) destination, after the IP address had been resolved. (0) I will remove the reference to RAS and expect to see an explicit description of the procedure in Annex O. What I would expect is that the hostport part will resolve to a GK to which LRQ messages are directed. [RWC] Now I am confused. I thought that DNS was used to locate the resolution server. Then LRQ(RAS) was used to communicate with that server to resolve the address of the user. The server doing the address resolution may not be involved in the final connections. (1) I disagree that it is the exception. I would contend that calling a specific machine would be the exception. Sure, one can call and endpoint directly, but that's not typical. It is in testing and development environments, but in production environments, users enter telephone numbers. Also, I can imagine intranets where the h323 URL might be used. At work, I might post a page with "h323:paulej", but I would never post "h323:@cisco.com". However, the latter is allowed, of course. What I do not want is "h323:paulej@" on a web page. That's ugly, in my opinion. I realize that the SIP folks chose that, but it seems illogical to me. [RWC] I do not see any relationship between an URL and a telephone number. If a user enters a telephone number the connection should be established using either the dialedDigits alias or the partyNumber alias not the URL-id alias. For me, the URL user should be a name type structure like in email users. This allows for a number as a name but not as a telephone number. I do not accept the SIP and ENUM concept where telephone numbers are funny names with a default domain for DNS. In fact, I think that this will not work due to difficulties with administration ownership of telephone numbers. [RWC] I do agree that user only will be an exception because it forces the use of a default domain for DNS. It is not likely that there will be universal default domain. (2) If I provided "h323:@192.168.1.1;proto=q931", a device should assume that it can reach it on the default 1720 port or the default Annex E port (as described in Annex E). If, however, I use a different port like "h323:@192.168.1.1:2500;proto=q931", I would say that Annex E is out of the picture. That is another reason why I believe the first step to resolution should be through a Gatekeeper. The gatekeeper can not only resolve the address, but also indicate any non-standard ports, including both the TCP and Annex E transport information. [RWC] In this case the endpoint that wished to use Annex E must support the requirement of Annex E that requires the ability to fall back to TCP.

2 1

RE: Re: H.323 URL Specification
by Callaghan, Robert 06 Sep '00

06 Sep '00

Paul, I agree that HTML can be a problem, that I know of. I only replied to the thread. See below. 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----- * For protocol, use “h225rs” or “h323rs” instead of “ras”. This controls the confusion with the dial-in protocol know as RAS. * For protocol, use “h225cs” or “h323cs” instead of “q931”. This controls the confusion with real Q.931 For protocol, use “h225ar” or “h323ar” instead of “annex-g”. I really like the use of "ras", even though there are conflicts in other contexts. However, I agree that q931 is not really ideal. How about these: lrq, setup, ar (for AccessRequest)? So rather than specifying a protocol, we specify the message to use? [RWC] I definitely don’t like q931 and annex-g. As a secondary question, how is an endpoint to handle ras and annex-g? Obtain the information directly or go through the GK? This should be stated. My view on this is that the endpoint should have one of two options: 1) It contacts the endpoint directly, or 2) It sends to URL to the GK for resolution [RWC] I agree with this as long as GK resolution is performed via normal RAS. * Is “escaped” limited to two hexdigits? How does one escape to Unicode characters? This should be possible. It has never been proposed to use unicode, so, yes, the "escaped" set is limited to two bytes (the data type is actually IA5String). However, we could add a statement that says that the entire H323-URL is UTF-8 encoded. In that way, characters from other languages could converted to UTF-8 and then escaped where necessary. [RWC] We cannot have UTF-8 in the domain part of the URL. I would like to see UTF-8 in the user part of the name through the use of escaped characters. So perhaps the user part of the name should be defined as a UTF-8 encoded string of characters, with the only restrictions being that "%" and "@" must be escaped if they exist in the user part. Sound good? However, this does bring to my attention the fact that the character set is now very limited. Any character can be represented, but it would be nice to allow François to enter his name like that, rather than Fran%83ois. What character set limitations does IA5 impose on us? Can we use any binary value between 0-255 for each character? If so, I would also like to propose that we change the "unreserved" production to allow any character between 0-255, excluding % and @ (since those have special meanings). What do you think? [RWC] 0-255 is not sufficient. I believe that the above mentioned change (re: UTF-8) will give us the means of allowing the full range of unicode characters for the user name part. However, this raises another question: how do we enforce the rule that names are not case sensitive. That would suggest that for any given character set within unicode, the manufacturer will have to know which characters are the upper and lower case ranges. Is this desirable to recommend? I like names that are not case sensitive, but this might be overly complex to try to do. It would make internationalization of a Gatekeeper, for example, much more difficult than it is today-- I suspect some vendors will not go through the effort. Should we re-think the "case insensitive" issue? [RWC] I don’t see case insensitive as being in conflict with UTF-8. Part of the characters as defined as case oriented and some are not.

2 1

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Reddy, Paul K 06 Sep '00

06 Sep '00

Hi Everyone, I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H, who made 4 point in this email. regards, Paul Reddy Editor of H.246 Annex E.1, Annex E.2 Paul K. Reddy Roaming Services Capability Manager Mobile Data Services Area of Opportunity Applications and Services Lab Intel's Architecture Labs Intel Corporation Office Phone# +1 (503)-264-9896 Mobile Phone# +1 (503)-807-9564 Email: paul.k.reddy(a)intel.com -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Wednesday, September 06, 2000 9:33 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Hi, Everyone (including all Rapporteurs and WP 2 Chairman): Again, it is interesting to see how a very narrow view can create serious problems not only for a simple Annex, but also for the whole question, for the whole study group, and for all other study groups of the ITU-T. Time and again, it has been said that let us work within the mandate of Q.13/16 first and contributions had been made to clarify those points. Everything has been ignored just because few folks want to do something almost working like a close group without seeing the BIG picture of all questions of all SGs of the ITU-T. In fact, some joint meetings were also initiated between SG16 and SG11 to see how the HLFs, VLFs, and AuFs related protocols are being addressed elsewhere. Still, they are pushing the same thing just because few folks brought some contributions. Objections were put via contributions, emails, and verbal discussions. Even there is not a single editorial note in the document related to those things. A simple example will reveal the fact. We have discussed that there are serious problems to use GRQ messages to discover the GKs in mobile environment. Many contributions, emails, and verbal explanations have been provided. If you look into the present H.323 Annex H write-up, you will see that, as if, GRQ is the "Nirvana" for discovering the GK in mobile environment. Not a single word has been used even as an editorial note whether some members have raised the questions that there are problems need to be addressed for GRQs. The way the GRQ section has been written, it is a generic one and is nothing do with mobility. Rather, it suits to be added in the base H.323 spec. Many more examples can be given for each technical issue. This Annex has NOT done its first important task how to extend the H.323 signaling messages (RAS, Q.931, Annex G) to solve the mobility problems for the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is the mandate of Q.13/16. Contributions are there, but everything has been ignored. Rather, Annex H has focused in some areas for which it has NOT got the mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, HLF <-> AuFs, etc. These work items are not the charter of Q.13./16 alone. These are the areas for the joint work with all other questions of all SGs that deal with mobility. (In another example, even if H.320, H.321, or H.324 wants to be used by mobile users, they can also use HLFs, VLFs, AuFs, etc. Similarly, all other mobile applications of all other SGs can also use these HLFs, VLFs, AuFs, etc. Take the case of AuF, it can also be used by the fixed user. There is nothing fency about this.) (More importantly, these additional entities have raised serious concerns: How does a GK/BE play a role in the overall process while "wild" suggestions have been made to use the Annex G protocol as well? It has created a "dangerous" mechanism to "by-pass" the very need of GKs/BEs. In fact, some members have boasted that they even do not see any need to go via GKs or BEs anymore so far mobility is concerned. As if, a "bomb " is about to be placed to break the very foundation of H.323 in the name of extending of H.323 for mobility.) More can be written for each technical issue, if needed. If one likes to see some of those points, please see the contributions that were submitted in the last Q.13/16 Portland meeting. Again, I am repeating the proposal for H.323 Annex H: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. It is very important to note that only item 1 is within the charter of Q.13/16 (H.323). All other items need to be addressed in the light of all mobility works of all questions of all SGs of the ITU by the working party chair and others. (My personal view is this: Let H.323 Annex H be scoped for item 1 only for now as a first step. It will also take a good amount of time to finish it. People are waiting to see that this happens first. To include other items, it may take a long time to have stable texts working with all SGs. This will then constitue the second step.) Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Wednesday, September 06, 2000 8:08 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Mr. Roy & other parties interested in H.323 Annex H, I found your posting addressing such general level issues that I think it is better to write a whole new mail as a response instead of responding to your claims and comments point by point... First of all you question the mandate of Annex H and its relation to the H.323 protocols. I find it very odd that you, without any real arguments to support for it, restrict the H.323 recommendations and thus also Annex H to handle ONLY the H.323 entities that have been defined prior to Annex H. The first real work that we got done for Annex H was to identify the functionalities that were (are) needed for Mobility Management and that were missing from H.323. This is how we (in an ad hoc meeting in Red Bank, in which you yourself was also present) came up with the four new H.323 (functional) entities: HLF, VLF, AuF and IWF. Thus we have defined NEW H.323 entities that were NOT present prior to Annex H. If it is illegal for us to define new H.323 entities (as you seem to claim), I can't see how the Border Element ever got defined, since it was not defined prior to the H.225 Annex G. Second, you seem to have defined the HLF, VLF and AuF as back-end services. This is NOT how I see them. I see back-end services as services that are NOT defined in the H.323 series recommendations, but that may be used by gatekeepers. In other words, back-end services or the functionalities they provide do NOT have any real definition in H.323, nor is it illegal to define new entities to H.323 that provide same kind of functionalities that could be achieved by using some back-end service. The back-end services that are used in some implementations of the H.323 system can undoubtedly be used for similar purposes as the new functional entities of Annex H are, but this does not make the new entities back-end services. Furthermore, the whole point (or mandate) of Annex H is to make recommendations that allow for different manufacturer's equipment to be used in different parts of the (mobility enhanced) H.323 system and still allow the users/terminals to move around in the network. Thus, in my opinion, it is one of the most important issues of Annex H to define, how the HLF, VLF and AuF communicate with each other. By just stating that they are back-end services we would in essence NOT define this, since back-end services are NOT defined in H.323. Third, the protocol(s) that are used between the HLF, VLF and AuF are still and open issue. The reason, why the H.225 Annex G protocol is used in the present draft is that it is the only protocol that has been seriously mentioned for this purpose. (Not only by the editor, but in various contributions as well, although the editor takes full responsibility of the current text in the draft.) It has been identified that the H.225 Annex H protocol already has the functionality for locating a User with a certain aliasAddress. Really roughly said, this functionality is "half" of the functionality that is needed for Mobility Management, the other half being the location updating procedures (which are not really addressed by the protocol yet). This is why the protocol is being considered for the Annex H usage. However, I would really like to see contributions suggesting other (preferably existing) protocols as well. Intel's contribution APC-1902, was the first one of this kind. These contributions should, however, state clearly how the suggested protocols should be used, if there is any ambiguity. I.e. just stating: "Use Mobile IP" is not enough (I'm not trying to refer to the APC-1902 with this comment), but information flows for the needed Mobility Management procedures should be presented (these include at least the location updating procedures, call establishment procedures, call termination procedures and unregistration procedures). Fourth, the needed enhancements of the RAS, Q.931, etc. protocols will be provided by finishing the information flows on chapter 10. I admit that not much of this has yet been done, but on the other hand, at least so far I have found that there is not too much that has to be done with respect to these protocols. (There will probably be certain message fields that will be mandatory for Mobile Terminals that are optional in H.323 normally, etc., but I don't see a need for too many new message fields or messages.) Last, but not least, we a really in a hurry, if we want to get the Annex H determined in November. This is why I suggest that the interested parties provide the contributions describing the usage of other protocols as the Mobility Management protocols of Annex H as soon as possible. Also it would be very nice, if these contributions were made modeling the chapter 10 of the current draft, so that incorporating them to the annex would be as fast as possible. I'm still a bit in the middle of the process of digesting the information I have gotten about the Annex H work in Portland, but I'll try to send a mail summarizing (what I think is) our current situation later this week (probably on Friday). I will also make a "cleaner" version of the TD-42a as the "starting point" for our interim work before Geneva (this new draft will not contain any other than editorial changes compared to TD-42a). ------------------------------------------------ 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

1 0

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Roy, Radhika R, ALCOO 06 Sep '00

06 Sep '00

Hi, Everyone (including all Rapporteurs and WP 2 Chairman): Again, it is interesting to see how a very narrow view can create serious problems not only for a simple Annex, but also for the whole question, for the whole study group, and for all other study groups of the ITU-T. Time and again, it has been said that let us work within the mandate of Q.13/16 first and contributions had been made to clarify those points. Everything has been ignored just because few folks want to do something almost working like a close group without seeing the BIG picture of all questions of all SGs of the ITU-T. In fact, some joint meetings were also initiated between SG16 and SG11 to see how the HLFs, VLFs, and AuFs related protocols are being addressed elsewhere. Still, they are pushing the same thing just because few folks brought some contributions. Objections were put via contributions, emails, and verbal discussions. Even there is not a single editorial note in the document related to those things. A simple example will reveal the fact. We have discussed that there are serious problems to use GRQ messages to discover the GKs in mobile environment. Many contributions, emails, and verbal explanations have been provided. If you look into the present H.323 Annex H write-up, you will see that, as if, GRQ is the "Nirvana" for discovering the GK in mobile environment. Not a single word has been used even as an editorial note whether some members have raised the questions that there are problems need to be addressed for GRQs. The way the GRQ section has been written, it is a generic one and is nothing do with mobility. Rather, it suits to be added in the base H.323 spec. Many more examples can be given for each technical issue. This Annex has NOT done its first important task how to extend the H.323 signaling messages (RAS, Q.931, Annex G) to solve the mobility problems for the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is the mandate of Q.13/16. Contributions are there, but everything has been ignored. Rather, Annex H has focused in some areas for which it has NOT got the mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs, HLF <-> AuFs, etc. These work items are not the charter of Q.13./16 alone. These are the areas for the joint work with all other questions of all SGs that deal with mobility. (In another example, even if H.320, H.321, or H.324 wants to be used by mobile users, they can also use HLFs, VLFs, AuFs, etc. Similarly, all other mobile applications of all other SGs can also use these HLFs, VLFs, AuFs, etc. Take the case of AuF, it can also be used by the fixed user. There is nothing fency about this.) (More importantly, these additional entities have raised serious concerns: How does a GK/BE play a role in the overall process while "wild" suggestions have been made to use the Annex G protocol as well? It has created a "dangerous" mechanism to "by-pass" the very need of GKs/BEs. In fact, some members have boasted that they even do not see any need to go via GKs or BEs anymore so far mobility is concerned. As if, a "bomb " is about to be placed to break the very foundation of H.323 in the name of extending of H.323 for mobility.) More can be written for each technical issue, if needed. If one likes to see some of those points, please see the contributions that were submitted in the last Q.13/16 Portland meeting. Again, I am repeating the proposal for H.323 Annex H: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. It is very important to note that only item 1 is within the charter of Q.13/16 (H.323). All other items need to be addressed in the light of all mobility works of all questions of all SGs of the ITU by the working party chair and others. (My personal view is this: Let H.323 Annex H be scoped for item 1 only for now as a first step. It will also take a good amount of time to finish it. People are waiting to see that this happens first. To include other items, it may take a long time to have stable texts working with all SGs. This will then constitue the second step.) Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Wednesday, September 06, 2000 8:08 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6 Mr. Roy & other parties interested in H.323 Annex H, I found your posting addressing such general level issues that I think it is better to write a whole new mail as a response instead of responding to your claims and comments point by point... First of all you question the mandate of Annex H and its relation to the H.323 protocols. I find it very odd that you, without any real arguments to support for it, restrict the H.323 recommendations and thus also Annex H to handle ONLY the H.323 entities that have been defined prior to Annex H. The first real work that we got done for Annex H was to identify the functionalities that were (are) needed for Mobility Management and that were missing from H.323. This is how we (in an ad hoc meeting in Red Bank, in which you yourself was also present) came up with the four new H.323 (functional) entities: HLF, VLF, AuF and IWF. Thus we have defined NEW H.323 entities that were NOT present prior to Annex H. If it is illegal for us to define new H.323 entities (as you seem to claim), I can't see how the Border Element ever got defined, since it was not defined prior to the H.225 Annex G. Second, you seem to have defined the HLF, VLF and AuF as back-end services. This is NOT how I see them. I see back-end services as services that are NOT defined in the H.323 series recommendations, but that may be used by gatekeepers. In other words, back-end services or the functionalities they provide do NOT have any real definition in H.323, nor is it illegal to define new entities to H.323 that provide same kind of functionalities that could be achieved by using some back-end service. The back-end services that are used in some implementations of the H.323 system can undoubtedly be used for similar purposes as the new functional entities of Annex H are, but this does not make the new entities back-end services. Furthermore, the whole point (or mandate) of Annex H is to make recommendations that allow for different manufacturer's equipment to be used in different parts of the (mobility enhanced) H.323 system and still allow the users/terminals to move around in the network. Thus, in my opinion, it is one of the most important issues of Annex H to define, how the HLF, VLF and AuF communicate with each other. By just stating that they are back-end services we would in essence NOT define this, since back-end services are NOT defined in H.323. Third, the protocol(s) that are used between the HLF, VLF and AuF are still and open issue. The reason, why the H.225 Annex G protocol is used in the present draft is that it is the only protocol that has been seriously mentioned for this purpose. (Not only by the editor, but in various contributions as well, although the editor takes full responsibility of the current text in the draft.) It has been identified that the H.225 Annex H protocol already has the functionality for locating a User with a certain aliasAddress. Really roughly said, this functionality is "half" of the functionality that is needed for Mobility Management, the other half being the location updating procedures (which are not really addressed by the protocol yet). This is why the protocol is being considered for the Annex H usage. However, I would really like to see contributions suggesting other (preferably existing) protocols as well. Intel's contribution APC-1902, was the first one of this kind. These contributions should, however, state clearly how the suggested protocols should be used, if there is any ambiguity. I.e. just stating: "Use Mobile IP" is not enough (I'm not trying to refer to the APC-1902 with this comment), but information flows for the needed Mobility Management procedures should be presented (these include at least the location updating procedures, call establishment procedures, call termination procedures and unregistration procedures). Fourth, the needed enhancements of the RAS, Q.931, etc. protocols will be provided by finishing the information flows on chapter 10. I admit that not much of this has yet been done, but on the other hand, at least so far I have found that there is not too much that has to be done with respect to these protocols. (There will probably be certain message fields that will be mandatory for Mobile Terminals that are optional in H.323 normally, etc., but I don't see a need for too many new message fields or messages.) Last, but not least, we a really in a hurry, if we want to get the Annex H determined in November. This is why I suggest that the interested parties provide the contributions describing the usage of other protocols as the Mobility Management protocols of Annex H as soon as possible. Also it would be very nice, if these contributions were made modeling the chapter 10 of the current draft, so that incorporating them to the annex would be as fast as possible. I'm still a bit in the middle of the process of digesting the information I have gotten about the Annex H work in Portland, but I'll try to send a mail summarizing (what I think is) our current situation later this week (probably on Friday). I will also make a "cleaner" version of the TD-42a as the "starting point" for our interim work before Geneva (this new draft will not contain any other than editorial changes compared to TD-42a). ------------------------------------------------ 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

1 0

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q. 13/1 6
by Jaakko Sundquist 06 Sep '00

06 Sep '00

Mr. Roy & other parties interested in H.323 Annex H, I found your posting addressing such general level issues that I think it is better to write a whole new mail as a response instead of responding to your claims and comments point by point... First of all you question the mandate of Annex H and its relation to the H.323 protocols. I find it very odd that you, without any real arguments to support for it, restrict the H.323 recommendations and thus also Annex H to handle ONLY the H.323 entities that have been defined prior to Annex H. The first real work that we got done for Annex H was to identify the functionalities that were (are) needed for Mobility Management and that were missing from H.323. This is how we (in an ad hoc meeting in Red Bank, in which you yourself was also present) came up with the four new H.323 (functional) entities: HLF, VLF, AuF and IWF. Thus we have defined NEW H.323 entities that were NOT present prior to Annex H. If it is illegal for us to define new H.323 entities (as you seem to claim), I can't see how the Border Element ever got defined, since it was not defined prior to the H.225 Annex G. Second, you seem to have defined the HLF, VLF and AuF as back-end services. This is NOT how I see them. I see back-end services as services that are NOT defined in the H.323 series recommendations, but that may be used by gatekeepers. In other words, back-end services or the functionalities they provide do NOT have any real definition in H.323, nor is it illegal to define new entities to H.323 that provide same kind of functionalities that could be achieved by using some back-end service. The back-end services that are used in some implementations of the H.323 system can undoubtedly be used for similar purposes as the new functional entities of Annex H are, but this does not make the new entities back-end services. Furthermore, the whole point (or mandate) of Annex H is to make recommendations that allow for different manufacturer's equipment to be used in different parts of the (mobility enhanced) H.323 system and still allow the users/terminals to move around in the network. Thus, in my opinion, it is one of the most important issues of Annex H to define, how the HLF, VLF and AuF communicate with each other. By just stating that they are back-end services we would in essence NOT define this, since back-end services are NOT defined in H.323. Third, the protocol(s) that are used between the HLF, VLF and AuF are still and open issue. The reason, why the H.225 Annex G protocol is used in the present draft is that it is the only protocol that has been seriously mentioned for this purpose. (Not only by the editor, but in various contributions as well, although the editor takes full responsibility of the current text in the draft.) It has been identified that the H.225 Annex H protocol already has the functionality for locating a User with a certain aliasAddress. Really roughly said, this functionality is "half" of the functionality that is needed for Mobility Management, the other half being the location updating procedures (which are not really addressed by the protocol yet). This is why the protocol is being considered for the Annex H usage. However, I would really like to see contributions suggesting other (preferably existing) protocols as well. Intel's contribution APC-1902, was the first one of this kind. These contributions should, however, state clearly how the suggested protocols should be used, if there is any ambiguity. I.e. just stating: "Use Mobile IP" is not enough (I'm not trying to refer to the APC-1902 with this comment), but information flows for the needed Mobility Management procedures should be presented (these include at least the location updating procedures, call establishment procedures, call termination procedures and unregistration procedures). Fourth, the needed enhancements of the RAS, Q.931, etc. protocols will be provided by finishing the information flows on chapter 10. I admit that not much of this has yet been done, but on the other hand, at least so far I have found that there is not too much that has to be done with respect to these protocols. (There will probably be certain message fields that will be mandatory for Mobile Terminals that are optional in H.323 normally, etc., but I don't see a need for too many new message fields or messages.) Last, but not least, we a really in a hurry, if we want to get the Annex H determined in November. This is why I suggest that the interested parties provide the contributions describing the usage of other protocols as the Mobility Management protocols of Annex H as soon as possible. Also it would be very nice, if these contributions were made modeling the chapter 10 of the current draft, so that incorporating them to the annex would be as fast as possible. I'm still a bit in the middle of the process of digesting the information I have gotten about the Annex H work in Portland, but I'll try to send a mail summarizing (what I think is) our current situation later this week (probably on Friday). I will also make a "cleaner" version of the TD-42a as the "starting point" for our interim work before Geneva (this new draft will not contain any other than editorial changes compared to TD-42a). ------------------------------------------------ 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

1 0

H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q.13/1 6
by Roy, Radhika R, ALCOO 05 Sep '00

05 Sep '00

Hi, Everyone (including Rapporteurs and WP 2 Chairman): I appreciate that Istvan Sebestyen has rightly pointed out, " ... By this development the "enterprise" and the "mobile carrier" solution are likely to develop separately, which is not too good for compatibility and interoperability." I am just curious to know more technical insights: Enterprise vs. Carrier solution for H.323 mobility. It is a very useful discussion to clarify further what we are up to. May be I have missed some of the discussions. H.323 is a transport independent multimedia application. So, H.323 mobility solution is applicable for both wire-line and wireless (wireless LAN, packet-switched [pico-, micro-, and macro-cell) network. So, as Istvan pointed out, the H.323 mobility solution will be only one that is applicable for all networking conditions. The next question comes: Does H.323 Annex H is going to meet our objectives as it stands now? The answer is "No." First of all: What is the mandate of Annex H? Its mandate is to extend H.323 to support mobility. What do we mean by H.323 protocol? These protocols are H.323 base specs, H.225.0 (RAS, Q.931, Annex G),and H.245 where the communications are performed among the H.323 entities: Terminals, GKs, BEs, and GWs. So, Q.13/16 has the charter to extend those protocols to support mobility among its functional entities: Terminals, GKs, BEs, and GWs. If you examine the write-up of the present Annex H, one can easily see that there is almost no mention how the H.323 base specs, H.225.0 (RAS, Q.931, Annex G) need to be extended to support mobility among H.323 entities like Terminals, GKs, BEs, and GWs. Many contributions are there, and many emails have been sent. But nothing is coming out of this. Rather, it is interesting to see that some folks are trying to push something that may not be the charter of Q.13/16, or even may not be the charter of SG16. For example, communications between VLF and HLF, between VLF and AuF, or between HLF and AuF. These are generic protocols and no special treatment is needed because of H.323. For example, IMT-2000 is also working in this area. We can use those protocols for this purpose, or if needed, a joint work item can be developed between the SG16 and other SGs. We are NOT sure why we are spending an enormous amount of time in doing this in Q.13/16 while ignoring the basic work of Q.13/16 to extend the existing H.323 protocol to support mobility for its existing functional entities. Another wild suggestion is being made: Use of the H.323 Annex G for the VLFs, HLFs, AuFs, etc. This suggestion shows how we are creating confusions in the development of mobility protocol. VLFs, HLFs, AuFs, etc. are known as the backend servers, and these protocols are known as the backend services (BES) protocols. H.323 has NOT developed any BES protocol so far. Please note that H.225.0 Annex G protocol is being used for communications between the GKs/BEs, and "NOT" for communications between the Backend servers like VLFs, HLFs, AuFs, etc. The protocols for communications between VLF and HLF, between VLF and AuF, or between HLF and AuF should be a separate sets of protocols, not the extension H.225.0 Annex G. However, these protocols may use some useful functional features that are suitable for the backend services protocols (e.g., hopcount, etc.), but these MUST be termed as the NEW backend services protocols. Many contributions have been made to explain those things. I have not seen any progress that we have made so far in this direction. So, the final proposal is this for H.323 Annex H: 1. First, finish the extension of the existing H.323 base specs, and H.225.0 (RAS, Q.931, Annex G)to support mobility among the H.323 entities: Terminals, GKs, BEs, and GWs. (see the contributions that are being made so far). 2. Second, develop a clear mandate whether the backend protocols like VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of Q.13/16 only, or these protocols need to be worked with other SGs. (see the contributions that are being made so far). 3. Third, any protocols that re being used between VLF <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or its extension because these are separate protocols and serve completely different purposes although may useful properties (e.g., hopcount, etc.) of the Annex G protocol can be used for these protocols. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Sebestyen Istvan ICN M CS 27 [mailto:Istvan.Sebestyen@ICN.SIEMENS.DE] Sent: Tuesday, September 05, 2000 6:21 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: response to open letter from Tom Taylor Importance: High Dear Colleagues, ... By this development the "enterprise" and the "mobile carrier" solution are likely to develop separately, which is not too good for compatibility and interoperability. Kind regards, Istvan Sebestyen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: response to open letter from Tom Taylor
by Sebestyen Istvan ICN M CS 27 05 Sep '00

05 Sep '00

Dear Colleagues, I fully agree with the comments made by Dale Skran, and this was also the essence what he said in the Welches, OR meeting - in his usual humorous, but occasionally a bit provocative way (that, by the way, I personally love so much...). The subject, as it came up also in the Oregon meeting, is very important, can not and should not be ignored (this was supported by several people). As I have pointed out already in the Osaka meeting, large companies seems to be divided on the subject (so nobody is blaming here anybody). The "enterprise" side of those very same companies favour very clearly the H.323 mobility, while the "mobile carrier" side supports (rightly or wrongly, that the discussion point) the SIP based solution. As it was pointed out, originally the requirement for the SIP based solution came from the carriers (e.g. MCI Worldcom come to my mind), so from our customers, who are the kings...but, as a matter of fact they were then supported by a few supporting contributions coming from manufacturers. By this development the "enterprise" and the "mobile carrier" solution are likely to develop separately, which is not too good for compatibility and interoperability. Kind regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51, D-81359 Munich, Germany Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://intranet.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/standards ---------------------------------------------------------------------------- ---------------- > ---------- > From: Skran, Dale[SMTP:DSkran@SONUSNET.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, August 30, 2000 3:29 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: response to open letter from Tom Taylor > > Dear Tom: > Allow me to repeat the comments I made during the meeting. I noted that a > large contribution comparing SIP and H.323 had been submitted to 3GPP, > having the conclusion of SIP's superiority. I complained that I was > disappointed in the non-technical nature of much of the material provided, > and urged the delegates to bring in real technical contributions > concerning > the possible demerits of H.323, with a view to the improvement thereof. > My > goal, then, as now, is the improvement of H.323, and also to call the > delegates attention to a document whose existance they may not have been > aware of, and which might stimulate them to bring in additional > contributions. > Any implication that, for example, 3GPP members are gullible, or there > were > no other contributions in 3GPP on this topic appears to be speculation. > In > addition, the idea that I or Sonus might profit in some fashion from these > comments is both speculative and humorous. As you can clearly see, they > have brought me nothing but trouble so far. I am still hoping for the > real > gain of additional valuable H.323 related contributions. > I would like to take this opportunity to thank Francois Audet for his many > contributions to H.323 over the years, both as an editor and as a > contributor, and also to his many contributions to the ATM Forum. > Francois > has been, without fail, a positive and helpful member of Q13 and the H.323 > community, and I would like to thank Nortel for supporting his standards > work. > One of the criticisms of H.323 in the 3GPP discussions appeared to be the > idea that SIP would be easier to modify for the wireless environment than > H.323, apparently because of a perception that the SIP community is more > open to change. I feel this is completely unfair and untrue. As > rapporteur, I have always welcomed new contributors and new ideas into the > H.323 system of recommendations, and would like to urge the further > consideration of H.323 for wireless/mobile applications by groups other > than > 3GPP (of course, further consideration by 3GPP is also welcome!). Such > groups will find Q13/WP2/SG16 ready and eager to work with them in > defining > any changes needed for the wireless/mobile environment. > I would also like to call attention to the continuing work of Q13 in H.323 > Annex H and I. > H.323 Annex H (User Service, and Terminal Mobility in H.323) > Determination 11/00 Editor J. Sundquist (Nokia) > H.323 Annex I (Packet based MM Telephony over Error Prone Channels) > Determination 11/00 Editor B. Aronson (Toshiba) > > Sincrely, > Dale Skran > Q13 Rapporteur > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: Support bi-directional channels in annex C fast start
by Roni Even 05 Sep '00

05 Sep '00

Paul, TD14 from 9902-MON clearly states that the change was done to support fast start. This is the implementer guide for version 2. I am including the text as well as attaching the TD. I would think that the problem was not putting the extra text in the fast start procedure. IF it is not clear I can add some text to annex C Thanks Roni H.323 Annex C - Indication of ATM capabilities in TransportCapability Description: Annex C requires that the indication of ATM be indicated in the Terminal Capability Set, but it implies that it is done in the capability exchange procedures. While this is valid when fast start is not used, it is not when fast start procedures are used since they do not use the capability exchange procedures before setting up the channels. The current wording unfortunately prohibits the use of fast start with Annex C. This contribution proposes that the wording be amended to allow for this indication to be provided in fast start as well. More specifically, the current Annex mandates that the Terminal Capability set be used to indicate the ATM capabilities. If fast start is used, the TransportCapability (where the ATM information is included) is not included. It is however included in the OpenLogicalChannel. Annex C shall be amended the text to reflect this. It shall also be clarified that OpenLogicalChannel is used instead of OpenLogicalChannelAck when fast start is used..This change will be reflected in H.323 v3. C.3.6 Transport Capabilities added to TerminalCapabilityTransportCapability Set For operation of H.323 on AAL5, an addition to the TerminalCapabilityTransportCapability set is made in H.245. This includes transport level capabilities such as support for ATM Transfer Capability (DBR, SBR1, SBR2, SBR3, ABT/DT, ABT/IT, ABR) as defined in Recommendation I.371. Terminals that do not send this new capability parameter shall not make use of the new methods described in this Annex. The TransportCapability information can be sent as part of the Terminal Capability set exchange in the capability exchange phase. It is also included in the OpenLogicalChannel. ... C.3.7.1 ATM address The ATM address for an RTP stream shall be given in the mediaChannel subfield of H2250LogicalChannelParameters of the H.245 OpenLogicalChannelAck message (or the OpenLogicalChannel in the case of fast start). The mediaChannel subfield UnicastAddress or MulticastAddress shall be filled with the 20-octet NSAP-style ATM End System Address. ... C.3.8.2 Bidirectional logical channels If the bidirectional usage is indicated, the receiving endpoint shall send an OpenLogicalChannelAck (or the OpenLogicalChannel in the case of fast start) and then it must watch for an ATM VC to be opened by the other endpoint. When ATM VC is completed, it may then use the reverse direction for the media type indicated in the OpenLogicalChannel command. The endpoint that initiates the OpenLogicalChannel command is the endpoint that shall open the ATM VC. ... -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, September 05, 2000 9:13 AM To: Mailing list for parties associated with ITU-T Study Group 16; Roni_e(a)ACCORD.CO.IL Subject: Re: Support bi-directional channels in annex C fast start Ron, Here are the facts that led to this: 1) In H.323v3 (which is what the Implementers Guide is correcting), it is illegal to use a bi-directional channel with Fast Connect. 2) Section C.3.8.2 and it's parent section C.3.8 were written with H.245 signaling in mind-- there was no thought of Fast Connect here. The procedure is not defined. With H.323v4, Fast Connect was extended to include bi-directional TCP channels, but nothing has been contributed for bi-directional ATM VCs. To simply say it is allowed opens a very large hole. I will quote the authors of the e-mail sent to me that prompted my proposed correction. Since it was sent privately, I will withhold their names. It states: [[ begin quote ]] We believe that there is a conflict between Annex C and H.323 version 3 WRT the Faststart and the method used to open logical channels. Annex C talks about using B-directional OLCs and H.323 V3 claims that only uni- directional OLCs are used during Faststart. ... Annex C in H.323v3 (C.3.8.2) still allows for bidirectional channels in FastStart. It doesn't go into any details, but I can think of two possibilities: - It either opens an exception and allows for the reverse channel to be specified, or - It takes advantage of the fact that the *two* unidirectional channels (forward and reverse) are sent in the same message and somehow associates them as being the same SVC (using the SessionID and/or the mediaChannel value). [[ end quote ]] The author of that e-mail definitely pointed out a whole in the specification. Annex C references bi-directional channels used with Fast Connect, but that is explicitly illegal in V3. I am not at all opposed to re-inserting this text into H.323v4, but we definitely need some clarifying text that explains how this shall be used in Annex C. We cannot assume that the readers understand how it works. Would you be willing to draft text for Annex C to be included in the decided document in November? Best Regards, Paul ----- Original Message ----- From: "Roni Even" <Roni_e(a)ACCORD.CO.IL> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Sunday, September 03, 2000 6:03 AM Subject: Support bi-directional channels in annex C fast start > Hi, > During the Portland meeting I had a concern about the change in H.323 V4 and > Implementers guide described in APC 1875a item 17 that was added by the > editor. This change was also added by the editor to the white draft of H.323 > V4. The editor pointed out that there is a contradiction between the text in > Annex C in paragraph C.3.8.2 and fast start in 8.1.71. concerning the use of > bi-directional channels. > I looked at the subject and my suggestion is to keep the text in annex C and > add to the end of the first paragraph of 8.1.7.1 "or one bi-directional > channel logical channel as described in annex C" > Thanks > Roni Even > > ******************************** > Roni Even > VP Product Planning > Accord Networks > Phone: +972-3-9251200 > Fax: +972-3-9211571 > email: roni_e(a)accord.co.il > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

H.323 Products
by Paul E. Jones 05 Sep '00

05 Sep '00

Folks, Frequently, I am asked for a list of H.323 products (IP phones, gateways, MCUs, etc.) What I would like to do is build a fairly complete list of products (both hardware and software). I will make the list available on Packetizer so that people can be directed to one place for the list. If your company has an H.323-compliant product on the market, please send me the following: Category: Phone (Terminal) MCU Gateway Gatekeeper Other (Lucent's "Phone on a Chip" is a good example) Company Name URL pointing to the product description on the web Once I get a few responses, I will post the information. Thanks! Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 1

Support bi-directional channels in annex C fast start
by Roni Even 05 Sep '00

05 Sep '00

Hi, During the Portland meeting I had a concern about the change in H.323 V4 and Implementers guide described in APC 1875a item 17 that was added by the editor. This change was also added by the editor to the white draft of H.323 V4. The editor pointed out that there is a contradiction between the text in Annex C in paragraph C.3.8.2 and fast start in 8.1.71. concerning the use of bi-directional channels. I looked at the subject and my suggestion is to keep the text in annex C and add to the end of the first paragraph of 8.1.7.1 "or one bi-directional channel logical channel as described in annex C" Thanks Roni Even ******************************** Roni Even VP Product Planning Accord Networks Phone: +972-3-9251200 Fax: +972-3-9211571 email: roni_e(a)accord.co.il ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H248 Implementers Guide Draft Now Available
by Christian Groves 04 Sep '00

04 Sep '00

G'Day all, The first draft of the H.248 Implementers Guide can be found at: ftp://standard.pictel.com/avc-site/Incoming/H248_implementors_guide_v1.zip It is in PDF and Word format. Enjoy. Cheers, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 URL Specification
by Callaghan, Robert 04 Sep '00

04 Sep '00

See inline comments Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ * The port should be specified as belonging the specified protocol. What do you mean? Are you in favor of this: h323:paulej@packetizer.com:1719 <mailto:h323:paulej@packetizer.com:1719> or do you want this: h323:paulej@packetizer.com;proto=ras,port=1719 <mailto:h323:paulej@packetizer.com;proto=ras,port=1719> [RWC] I prefer choice one in the base specification. * For protocol, use “h225rs” or “h323rs” instead of “ras”. This controls the confusion with the dial-in protocol know as RAS. * For protocol, use “h225cs” or “h323cs” instead of “q931”. This controls the confusion with real Q.931 For protocol, use “h225ar” or “h323ar” instead of “annex-g”. I really like the use of "ras", even though there are conflicts in other contexts. However, I agree that q931 is not really ideal. How about these: lrq, setup, ar (for AccessRequest)? So rather than specifying a protocol, we specify the message to use? [RWC] I definitely don’t like q931 and annex-g. As a secondary question, how is an endpoint to handle ras and annex-g? Obtain the information directly or go through the GK? This should be stated. Or how about this-- make it easier for those not familiar with the protocols. Specify the type of device: h323:paulej@packetizer.com;dev=gk <mailto:h323:paulej@packetizer.com;device=gk> Or dev=ep or dev=be [RWC] This was a mistake on my part. I meant annex-k for the API link. We don’t need a device field. The software/hardware can then determine the protocol. This might be the best solution, since "h323" is supposed to represent the protocol in the first place. * The specification of “ras” belonging to LRQ is limiting. For me, the first contact is over ARQ to my GK. Then the GK may use LRQ or any other means to resolve the address. From this view point, there is no difference between “ras” and “annex-g”. If we just specify the type of device the URL is associated with it will resolve this issue. [RWC] The type of device for what: the endpoint for the contact point. I don’t think the URL should change the normal procedure of an endpoint using the GK, if one is present. Annex-g should never be used by and endpoint (see annex g). The only applies to GKs or boarder elements. * Is “escaped” limited to two hexdigits? How does one escape to Unicode characters? This should be possible. It has never been proposed to use unicode, so, yes, the "escaped" set is limited to two bytes (the data type is actually IA5String). However, we could add a statement that says that the entire H323-URL is UTF-8 encoded. In that way, characters from other languages could converted to UTF-8 and then escaped where necessary. [RWC] We cannot have UTF-8 in the domain part of the URL. I would like to see UTF-8 in the user part of the name through the use of escaped characters. However, this does bring to my attention the fact that the character set is now very limited. Any character can be represented, but it would be nice to allow François to enter his name like that, rather than Fran%83ois. What character set limitations does IA5 impose on us? Can we use any binary value between 0-255 for each character? If so, I would also like to propose that we change the "unreserved" production to allow any character between 0-255, excluding % and @ (since those have special meanings). What do you think? [RWC] 0-255 is not sufficient. * I see no need for the URL ARQ be resolved to a URL. It could be resolved to any alias using the alias replacement rules. The means that an URL in and ARQ could be replaced with a partyNumber (last paragraph). You lost me here. If you are saying that there's no need to put a partyNumber inside a URL or that the GK should be allowed to map the URL alias to a partyNumber when returning an ACF, I agree. Otherwise, I need some clarification. [RWC] It is possible to pass a URL to a GK and have it respond with a partyNumber under the rules of alias substitution by the GK. Then the SETUP is sent using the partyNumber alias not the url alias. Paul

2 1

Annex K over multiple domains (Regarding APC-1934)
by Espen Skj�ran 01 Sep '00

01 Sep '00

Dear M.Ishii and S.Minono, Thank you for addressing the errors and ambiguities in H.323 Annex K in APC-1934. I am sorry I could not attend to the meeting, but will try to explain my comments here. I have also though about the use of Annex K (and other service control mechanisms using the ServiceControlSession scheme) outside the local zone, for example using Annex K from home domain to the visiting terminal would be of great value. However, I have intentionally delayed contributions on this field as I wanted the mobility work to have a clear architecture and messages before the service control issues are brought in. I have targeted the ServiceControl codepoints for Annex K in call signaling messages, along with RCF and SCI, for simplicity. The other RAS messages have included this for other applications, e.g. the call credit. I have assumed that annex K communication exist between the local gatekeeper and the endpoint, or between two entities in a call. Now as you suggest, we can also do useful services between different entities out of a call, and that shouldn't be restricted. 2.5.1 Adding ServiceControl fields to LRJ/LCF I have sort of assumed that most applications want the possibility to update a session later, in which case they need an open channel towards the endpoint. The LCF/LRJ message is a one-time thing. Also, to do services that interact with call control layer a service provider needs the call signaling channel anyway, in which case they wouldn't need the URL in the LCF message, but rather do the whole thing within the call signaling channel. But as you say, lightweight applications could take use of a ServiceControlSession in LRJ/LCF messages, for example by showing a list of other call addresses through the H.323 URL. I have nothing against adding the ServiceControlSession to LRJ/LCF. 2.5.2. Forwarding the SCI message by gatekeepers Forwarding the SCI message, I think, will require quite substantial changes to the SCI message, along with addressing schemes in the existing gatekeepers. I like the idea that the RAS messages (well, at least most of them), have clear states and are kept on the same interface, in this case terminal-gatekeeper. What about following the same schemes as H.450 and H.323 Annex L instead? Using call independent signaling? (ConferenceGoal = callIndependentSupplementaryService) This way we don't have to include addressing info in SCI, we reuse existing gatekeeper policing and addressing schemes. Services will be available even if the client's gatekeeper does not support v4 or Annex K. Also, the use of the sessionID will be clear (as these are defined over one specific interface). I hope this clarifies my points and that my suggestions satisfy you. I guess the addition of ServiceControl fields to LRQ and LCF would be the job of H.225 editor, while I can bring in a statement about the use of call independent signaling in K.2.1 and K.2.2? Regards, Espen Skjaeran ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Re: H.323 URL Specification (second try)
by Orit Levin 01 Sep '00

01 Sep '00

(0) The use of url means the "address resolution" is done (by the local GK) using the DNS, not RAS! This is why the "user only" url of H.323, is really an exceptional case. It is a question, if we want to keep it within the url. It lets the local (source) GK know, that the "address resolution" procedure should performed by other, then DNS, means. The "protocol" means: the signaling H.323 protocol to contact the (next hop towards the) destination, after the IP address had been resolved. (1) Since "user only" is an exception in H.323, I still believe, that it is dangerous to leave it just as an "user"... (2) If you would like to say that the destination can be reached by either "RAS on UDP on port #n" or by "H.225.0/Q.931 on "Annex E" port #m", you need to advertise two different URL for the same (?) service. It may be OK, but we all have to agree on the meaning. BTW, I think that specifying the "message name" instead of the protocol is a great idea. It really fits the URL concept. On the other hand, I disagree with the "dev" proposal, from the same reason. Now you have the job to put all the interleaving and agreed upon comments in the new url draft text and start the next round. It is fun to work on the mailing list... Cheers, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Paul E. Jones <paulej(a)packetizer.com> To: Orit Levin <orit(a)radvision.com> Cc: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Friday, September 01, 2000 10:13 AM Subject: Re: Re: H.323 URL Specification (second try) Orit, 1.. The reason for suggesting LRQ for RAS is simply that if you have a URL and I tell you that you use RAS to resolve this, how do you expect to resolve it? The endpoint may pass it to the GK, but the GK still has to resolve the address somehow. I don't mind removing the statement about LRQ. After all, we really need explicit procedure in Annex O to really use this URL properly. 2.. I do not like having URLs like this: h323:paulej@. I would much rather follow the conventions of UNIX programs like "finger", which allows one to do such things as "finger @hostname.com" and "finger user". It seems much more logical, in my opinion. I really only want to associate the "@" with the hostport. 3.. I don't understand your comments here. Can you clarify? Let me comment on the revisions you made to the document: "The only url-parameter defined.." -> "Currently, the only url-parameter defined" I would prefer to leave the that sentence there as it is, or modify is as follows: "The protocol parameter shall be interpreted as the..." thus removing all references to what is "currently" defined. Below, there is a statement that says that the definition of additional semicolon-delimited url-parameters, so that will address future changes. When no protocol is specified, I said that the interpreting entity shall assume the protocol is ras. I would prefer to leave it as shall to avoid any interoperability issues. Also, I agree that the last proposed sentence you provided about unknown parameters shall be ignored is good-- I will add that to the document. Paul ----- Original Message ----- From: Orit Levin To: ITU-SG16(a)mailbag.cps.intel.com Sent: Thursday, August 31, 2000 12:47 PM Subject: Re: H.323 URL Specification (second try) Hi Paul, Bob and others! I am attaching a slightly modified version with changes, that I think, are MUST. In addition, I have the following reservations: 0. I have a problem with explicitly binding "RAS" with "LRQ". May be, the default should be "SHALL", "RAS" and "LRQ". But "RAS" shall NOT mean "LRQ first". 1. In case only the "user" is specified, I would prefer to always have the "@" sign: "user@". Indeed, it is visually deferent from the simple "user", but - It is going to be placed in a different alias type - It will make the parsers' logic easier when distinguishing between the cases: "h323-user@; parameters" and "foreign-url-with-its-own-parameters@" - We may not predict today all possible complications. I am not sure, we will always be able to keep the user part in a clean "escaped" format. 2. Once we go forward with the currently proposed definition, we allow for each url link FOR THE REST OF THE H323-URL LIFE only a single combination of (signaling-protocol, transport-protocol, transport-protocol-port). In order to specify more then one possibility for the START procedures, separate URLs will need to be provided. Any opinions? Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Paul E. Jones <paulej(a)PACKETIZER.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Thursday, August 31, 2000 2:07 AM Subject: H.323 URL Specification (second try) Orit, Bob, and Others, Please disregard the previous e-mail. It contained a slightly out-of-date revision of the text. I believe the URL proper is the same in both documents, but the surrounding text has changed. Again, I welcome feedback. Best Regards, Paul

1 0