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@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@mailbag.intel.com