-----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Friday, January 11, 2002 8:44 AM To: BOUGANT François FTRD/DAC/ISS; ITU-SG16@echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1

(Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.)

Hi, Mr. Francois and All:

The fundamental arguments have been that a protocol is defined with its own characteristics. For example, H.323 protocol has its own entities like terminals, GKs, BEs, and GWs. Whatever protocol is used by these entities among themselves is known as H.323 protocol suit: For example, H.225.0 Annex G among BEs. So, the argument is that whatever protocol is used among the BEs is known as H..25.0 Annex G. The question is: How can we define another protocol like H.22x among the same BEs of H.323? Is it not contradictory to the fundamentals for development of the protocol? Will it not confuse everything? (An analogy: How can we say that let us develop another protocol, say, H.ZZZ to be used among terminals, GKs, and GWs in addition to H.323?)

The solution that we have been discussed among ourselves is as follows (I am providing a copy):

---------------------------------------------------------------------------- ------------------------------------------- 1. We are developing a new protocol where no protocol exists and the same can used by all applications to solve the mobility related problems. For example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. Here where we are defining a new "generic" protocol. This is not specific to the H.323 protocol. (Whether VLF, HLF, and AuF will be colocated with the BE/AMFE is a matter of implementation.)

2. We have the H.225.0 Annex G protocol that allows us to communicate among the H.323 BEs. This is specific to H.323. All we need to do is to extend this protocol to serve our purposes. (An analogy can be provided. It should be done in a way what Paul Reddy has done for H.xxx Annex E.)

3. We have the H.225.0 (RAS + Q.931) protocol that is used among the H.323 Terminals, GKs, and GWs. This is specific to H.323. All we need to do is to extend this protocol to serve our purposes. (An analogy can be provided. It should be done in a way what Paul Reddy has done for H.xxx Annex E.)

The questions that I have to you all: Why do you want to develop a generic protocol (if it is not H.323 specific) for items 2 and 3? If you want to do so, how do you definite the generic functional entities like terminals, GKs, BEs, GWs, etc? (Please also note that H.324 and H.310 do not have the concept of functional entities like GKs.)

My assumption has been that the same (items 2 and 3) can also be done for H.324, H.310, or other protocol while all protocols can use the same "generic" protocol as developed in item 1.

Please also note that if we develop a "generic" protocol for items 2 and 3 instead of being making protocol-specific extension, we will force each protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE sets of protocols (protocol specific + generic) among all its functional entities. Is it nor wastage of resources?

---------------------------------------------------------------------------- -----------------------------------------

It is not that we cannot develop many fency things like H.22x, but it contradicts the fundamental goals of the protocol development.

Best regards,

Radhika R. Roy rrroy@att.com

-----Original Message----- From: BOUGANT François FTRD/DAC/ISS [mailto:francois.bougant@RD.FRANCETELECOM.COM] Sent: Friday, January 11, 2002 10:32 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: Re: Report of Q.5 (mobility) phone conference, December 18th, 200 1

Dear all,

During the last rapporteur's meeting (Dublin - Ireland), it was expressed that defining H.22x (designed on the basis of H.225 annex G v2 at the current state - the backward compatibility with H.225 annex G v1 would be necessary) as a protocol used on BE--BE and BE--{Backend service entities} interfaces (other interfaces implying GKs could be considered) and stopping H.225 annex G would be a better way than defining a new protocol used on BE--{Backend service entities} interfaces and going on H.225 v2.

A significant argument is : in the latter case, the BE would support two application-layer protocols that may evolve separatly in the future. This would tend to make BE functionalities harder to implement. A second one is : if the H.22x "body" includes the H.225 annex G protocol , it can be used for information exchange on BE--BE interface even in the H.323 mobility management context.

To my understanding, H.22X would not contain any functional architecture description. This would be specifically described in every H.MMS.x draft, depending on the application context (H.323 specific, etc.). To give an example, the definition of generic entities would be contained in H.MMS.0. Specific entities such as GKs would be described in H.MMS.1. Then, mobility management implies a limited set of information exchanges that are independants from the application (although the type of exchange data depends on the application). These are related to the same actions at least : user registration/deregistration, location update, authentication, information update (e.g. user service profile transfer, update), location information request. So I think it is possible to define a "simple" generic protocol.

Best regards,

François Bougant France Telecom

-----Message d'origine----- De : Roy, Radhika R, ALASO [mailto:rrroy@att.com] Envoyé : mercredi 9 janvier 2002 16:16 À : BOUGANT François FTRD/DAC/ISS; ITU-SG16@echo.jf.INTEL.COM Cc : Meyer, Greg W Objet : RE: Report of Q.5 (mobility) phone conference, December 18th, 2001

Hi, Mr. Francois and All:

In addition, we also had some email correspondences among the conference participants and few interested folks including Mr. Jones and Mr. Reddy. It has been opined that H.22x is NOT needed because the extensions of the existing application-specific protocol (e.g., H.225.0 Annex G) for mobility will serve the purpose.

Copies of the emails are enclosed below.

Best regards,

Radhika R. Roy rrroy@att.com

PS: I would highly appreciate if Mr. Greg Meyer would send the email to the SG16 reflector as you know that I can receive the mail from the reflector, but cannot send it because of problems in filtering.