Hi, Folks:
Further to my earlier message, I am sending a note related to the fundamental issues of the present H.MMS.1 (Mobility for H.323) draft. The note also includes the proposed solutions for all those issues.
Please note that we discussed all those issues in the last November'00 SG16 meeting. We do not want that the same should be repeated in the upcoming SG16 May-June'01 meeting. In this regard, I also draw the special attention of editors of H.MMS.1 and H.225.0 Annex G, Rapporteurs of Q5/16 and Q2/16, and Mr. Tosco as well.
Issues and Solutions of H.MMS.1 (Mobility for H.323):
1. Problem A: The document (Section 10, H.NMS.1 Mobility for H.323 Multimedia Systems [MD-112, AVD-2053a]) still shows that HLF, VLF, and AuF, as if, are another sets of H.323 functional entities (like GKs, BEs, MCUs and terminals) that are entitled to use H.323/H.225.0 (RAS, Q.931/932)/H.225.0 Annex G protocols. However, like many other services such as directory, billing, and others, HLF, VLF, and AuF are the backend services and the protocols used by those entities must NOT be called a part of the H.323/H.225.0 protocol because these backend services protocols can be used by other application protocols (e.g., H.234, H.310) as well.
Problem B: If the mobility management protocol is called H.225.0 Annex G, it cannot be used or extended for the global mobility management purpose (e.g., H.MMS.2).
Problem C: More functionalities like Authentication, Charging/Billing, Directory, Policy, and other entities are needed for mobile (and even for non-mobile) functions. We cannot use make them as a part of H.323 protocol.
Problem D: We cannot make one HLF/VLF/AuF protocol for H.323, another HLF/VLF/AuF protocol for H.324, and another for H.310, and another for IMT-2000. The same protocols MUST be allowed to be used by any applications whenever needed without providing any restrictions.
Solution for problems A, B, C, and D: No functional entity like HLF, VLF, AuF, Charging/Billing, Policy, Directory or others will be defined as the H.323 functional entity. Rather, each of this entity will be a backend functional entity and the protocol among these entities must be independent of the H.323/H.225.0 Annex G protocol. The protocol used among HLF, VLF, and AuF entities may have all capabilities, functionalities and features as described in the document, but MUST be called a different protocol (e.g., M.management) so that all application protocols including H.323 will be at liberty to use it. So, the said protocol MUST NOT be called H.225.0 Annex G or its extension. In other words, we are changing the name only (not the capabilities, functions, or features). Similar will be the case for Charging/Billing, Policy, Directory or others.
2. Problem: Mobility management procedures (Section 10, H.NMS.1 Mobility for H.323 Multimedia Systems [MD-112, AVD-2053a (Figure 11a)]) still indicate that there is only one HLF that communicates directly with the VLFs located in two separate administrative domains. This breaks the fundamental concept of the administrative domains as standardized in H.323 because an administrative domain is autonomous and can communicate only through the BEs (with one HLF, this principle is violated and breaks the basic foundation of H.225.0 Annex G).
Solution: Similar to inter-zone (e.g., Figure 13 of AVD-2053a), the communications between the two administrative domains MUS be made via the BEs no matter whether there is one or multiple HLFs. Communications scenarios with at least one HLF in each administrative domain needs to be shown.
Best regards, Radhika R. Roy AT&T
Technology Consultant Room 3D-2C09 200 S. Laurel Avenue Middletown, NJ 07748 +1 732 420 1580 rrroy@att.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com