Forwarded per Mr. Roy's request... -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Monday, January 21, 2002 6:12 AM To: Horvath Ernst; ITU-SG16@echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1 ( Mr. Meyer: I would appreciate if you would kindly forward my message to the SG16 reflector.) Hi, Mr. Ernst: I understand your points. Now the question is: Do we want to kill or deprecate H.225.0 Annex G in the longer term through standardization of H.22x? Let us debate the pros and cons of H.22x from technical point of view (I will withdraw my objections to H.22x if sufficient technical arguments are provided). This is the fundamental debate for all of us in the SG16. So far, I have voted for enhancement of H.225.0 Annex G for mobility (because H.22x differs from H.225.0 Annex G by only 2/3 messages and does not say why it has to be fundamentally different from H.225.0 Annex G.) Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Monday, January 21, 2002 5:04 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1 Mr. Roy, since my company actively promoted the Annex G approach I have no problem with it. But H.22x would NOT be a NEW protocol, it would still be H.225.0 annex G (v2, to be precise) if used between border elements. The only "documentation" advantage of a separate recommendation is that for further applications it may be cleaner to use H.22x than H.225.0 annex G. What we ought to avoid is that a further application specifies nearly the same protocol again from scratch. Regards, Ernst Horvath

-----Ursprüngliche Nachricht----- Von: Roy, Radhika R, ALASO [ mailto:rrroy@att.com] Gesendet am: Freitag, 18. Jänner 2002 17:08 An: Horvath Ernst; ITU-SG16@echo.jf.INTEL.COM Cc: Meyer, Greg W Betreff: RE: Report of Q.5 (mobility) phone conference, December 18th, 200 1

(I would request Mr. Meyer to send the message to the SG16 reflector ... and thanks to Mr. Meyer. ) -------------------------------------------------------------- ----------

Hi, Mr. Ernst and All:

We have seen all pros and cons of all arguments.

There are some fundamental problems to develop another NEW protocol like "H.22x" among the BEs.

So, my vote will be for "H.225.0 Annex v2" that will include all mobility features extending H.225.0 Annex G v1.

Best regards,

Radhika R. Roy rrroy@att.com

-----Original Message----- From: Horvath Ernst [ mailto:ernst.horvath@SIEMENS.AT] Sent: Friday, January 18, 2002 4:02 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1

We should really try to stop going in circles and come to a conclusion.

These are the facts:

1) For a full year the procedures described in H.MMS.1 have been stable; they referred to H.225.0 Annex G, but that was opposed by some participants in the mobility discussion. This was one reason why mobility work progressed slower than expected.

2) In Dublin we found a compromise which did not change the technical solution, just the form of presentation and documentation: the "protocol kernel" should be lifted out of H.225.0 Annex G and turned into an own recommendation. This would allow different applications to make use of this protocol independently and still maintain the protocol in a single document. One application would be H.225.0 Annex G v2, another one mobility management.

3) The effect on H.MMS.1 is probably minimal, just a change of reference.

4) Contrary to Mr. Roy's statement there is absolutely no overlap with H.225.0 Annex G since the protocol specification is removed from Annex G and replaced by a reference to H.22x. The protocol itself is fully backwards compatible with Annex G version 1.

It is now up to the work group to decide how to proceed, either in the present way with an external protocol specification in H.22x or in the former way with the protocol specification integrated in H.225.0 Annex G. In the latter case Annex G version 2 would have to include some extensions needed by H.MMS.1 and H.235 Annex G.

Whatever the decision will be, H.MMS.1 will hardly be affected. The implications for H.225.0 annex G v2 and H.MMS.0 would be bigger: both of these documents will either simply refer to H.22x or contain their own (yet very similar) protocol specification.

In any case, we should try our best to finalize H.MMS.1 in February. This means the protcol must be finalized as well, whether it's H.22x or H.225.0 Annex G v2.

Kind Regards,

Ernst Horvath Siemens AG

...

-----Ursprüngliche Nachricht----- Von: Meyer, Greg W [ mailto:greg.w.meyer@INTEL.COM] Gesendet am: Freitag, 11. Jänner 2002 21:35 An: ITU-SG16@echo.jf.INTEL.COM Betreff: Report of Q.5 (mobility) phone conference, December 18th, 200 1

-----Original Message----- From: Roy, Radhika R, ALASO [ mailto:rrroy@att.com] Sent: Friday, January 11, 2002 9:02 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.)

Further to my earlier email, I like to add a summary. The main reason is that H.22x is almost a duplicate set of H.225.0 Annex G protocol except few parameters related to mobility (what can be done through extending H.225.0 Annex G).

Please note that we have developed as modular sets that are decoupled as follows:

H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs) H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs) H.225.0 Annex G - among the BEs H.245 Call/media control (terminals, media-aware GKs, GWs)

The proposed H.22x overlaps completely with H.225.0 Annex G except few mobility related parameters. Here lies the fundamental confusions.

Best regards,

Radhika R. Roy rrroy@att.com

-----Original Message----- From: Roy, Radhika R, ALASO Sent: Friday, January 11, 2002 11:42 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.