Hi Radhika & the rest of you mob people,
Since I'm not coming to Portland, I'll send you my comments on APC-1932 here. You can discuss these issues further with Mr. Rissanen in Portland.
** Comments on chapter 2 of APC-1932 **
The LRQ mechanism will, of course still work, but I think that for a true global mobile system, the mechanism is VERY inefficient and thus a better way of locating the called user must be standardized. I.e. generally a GK has no way of knowing under which GK (or set of GKs) the called user is located and thus in order for the LRQ mechanism to work, the LRQ must be sent to all GKs in a domain. The domains may include many GKs, thus the LRQs would create very much traffic also adding one GK to the domain would necessitate all the other GKs to be informed in order for the LRQ mechanism to work. Furthermore the originating GK does not even know whether the user is located in the same domain, thus the GK would have to wait an arbitrarily long time for an LCF and if the LCF does not arrive, inter-domain communications would be needed -> how long should this time be?
I really do not see, how the VLF <-> HLF communications across domain boundaries BREAKS the H.323 model. The H.225 Annex G states that "all inter-domain communications are executed via border elements" (not an exact quotation), but we can either change that statement into "all inter-domain communications must be executed by using the H.225 Annex G protocol" and use the protocol between VLFs and HLFs or we can say that the VLF and the HLF must always be co-located with a BE (to create elements HLF/BE and VLF/BE).
As for the question about the "distributed" vs. "hierarchical" model. Again, the VLF, HLF and AuF are just FUNCTIONALITIES, i.e. you can co-locate them with each other or with a GK or a BE. Thus, if you want your GK to be able to directly communicate with a HLF, you can add the VLF functionality to that network element thus creating a GK/VLF (or perhaps a GK/VLF/BE), which can communicate with the HLF. Thus the current H.323 Annex H architectural model does not stop you from utilizing either the "distributed" or the "hierarchical" model.
These comments apply on some parts of the chapter 3 also.
** Section 2.1 **
I do not understand this at all. We are producing an enhanchement to the H.323 protocols and in doing this, we have identified new functional elements that are not present in the H.323 standards beforehand. So, the interfaces may not have been a part of the H.323 standards before, but after Annex H is done they will be. As for the specific interfaces, I don't think we need to specify the HLF-HLF interface (in fact, the interface is not even present in the architecture diagram) and my opinion is that we can leave the AuF-HLF and especially the AuF-VLF interface unspecified in the first version of the annex (thus assuming that the AuF is co-located with the HLF). I have proposed to use the H.225 Annex G protocol in these interfaces, but there can, of course, be other options as well and I would really love to see contributions utilizing other mechanisms, such as the IETF's AAA, etc. My opinion is, however, that we must select and standardize the use of some specific protocol to really enable interworking between different manufacturer's products.
These comments apply on some parts of the chapter 3 also.
** Section 2.2 **
I think we have a linguistic misunderstanding here. I would like, if some native English speaker would comment this, but I understand the terms in the following way:
- Visited Domain, etc. should be read: "the domain currently being visited by the user". I think that this kind of interpretation is commonly used in technical language (or am I totally wrong?). - Visiting Domain would sound to me like: "the domain is visiting somewhere". - Serving Domain is OK, and is already used in Annex H. - Target Domain is OK. In the present draft I have used "new Domain" instead of "target Domain". Target and source are words that are commonly used for the new and old domain, etc. (E.g. in GSM handovers, the terms "source BTS" and "target BTS" are used. If using the words "new" and "old" is confusing or misleading, I ahve nothing against using target and source.
These comments apply on some parts of the chapter 3 also.
** Chapter 3 **
Most of my comments on this chapter are already captured in the above comments for chapter 2.
A few short notes on the other issues: - You're right, the security check for unregistration is definitely needed. - Also Connection Termination needs to be handled, although I imagine that there is nothing really special about it compared to the "normal" H.323 system (that is why it isn't included in the present draft), unless supplementary services (and perhaps some billing issues) are taken into account.
Those are my comments, I will discuss the issues with Mr. Rissanen so that you can have a meaningful discussion about them in Portland. Have a nice meeting everyone!
***
Finally, just to annoy the editor of H.323 Annex K: Ice-hockey isn't enough for us Finns anymore, now we are beating you in football (socker) also... Finland - Norway 3-1!!!!
------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist@nokia.com * ------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com