<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>We should really try to stop going in circles and come to a conclusion. </FONT>
</P>
<P><FONT SIZE=2>These are the facts:</FONT>
</P>
<P><FONT SIZE=2>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. </FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>3) The effect on H.MMS.1 is probably minimal, just a change of reference.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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. </FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>Kind Regards,</FONT>
</P>
<P><FONT SIZE=2>Ernst Horvath</FONT>
<BR><FONT SIZE=2>Siemens AG</FONT>
</P>
<BR>
<P><FONT SIZE=2>> -----Ursprüngliche Nachricht-----</FONT>
<BR><FONT SIZE=2>> Von: Meyer, Greg W [<A HREF="mailto:greg.w.meyer@INTEL.COM">mailto:greg.w.meyer@INTEL.COM</A>]</FONT>
<BR><FONT SIZE=2>> Gesendet am: Freitag, 11. Jänner 2002 21:35</FONT>
<BR><FONT SIZE=2>> An: ITU-SG16@echo.jf.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Betreff: Report of Q.5 (mobility) phone conference, December </FONT>
<BR><FONT SIZE=2>> 18th, 200 1</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Roy, Radhika R, ALASO [<A HREF="mailto:rrroy@att.com">mailto:rrroy@att.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Friday, January 11, 2002 9:02 AM</FONT>
<BR><FONT SIZE=2>> To: BOUGANT François FTRD/DAC/ISS; ITU-SG16@echo.jf.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Cc: Meyer, Greg W</FONT>
<BR><FONT SIZE=2>> Subject: RE: Report of Q.5 (mobility) phone conference, December 18th,</FONT>
<BR><FONT SIZE=2>> 200 1</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Further to my earlier email, I like to add a summary. The </FONT>
<BR><FONT SIZE=2>> main reason is</FONT>
<BR><FONT SIZE=2>> that H.22x is almost a duplicate set of H.225.0 Annex G </FONT>
<BR><FONT SIZE=2>> protocol except few</FONT>
<BR><FONT SIZE=2>> parameters related to mobility (what can be done through </FONT>
<BR><FONT SIZE=2>> extending H.225.0</FONT>
<BR><FONT SIZE=2>> Annex G).</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Please note that we have developed as modular sets that are </FONT>
<BR><FONT SIZE=2>> decoupled as</FONT>
<BR><FONT SIZE=2>> follows:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs)</FONT>
<BR><FONT SIZE=2>> H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs)</FONT>
<BR><FONT SIZE=2>> H.225.0 Annex G - among the BEs</FONT>
<BR><FONT SIZE=2>> H.245 Call/media control (terminals, media-aware GKs, GWs)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The proposed H.22x overlaps completely with H.225.0 Annex G except few</FONT>
<BR><FONT SIZE=2>> mobility related parameters. Here lies the fundamental confusions.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Best regards,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Radhika R. Roy</FONT>
<BR><FONT SIZE=2>> rrroy@att.com</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Roy, Radhika R, ALASO</FONT>
<BR><FONT SIZE=2>> Sent: Friday, January 11, 2002 11:42 AM</FONT>
<BR><FONT SIZE=2>> To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16@echo.jf.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Cc: 'Meyer, Greg W'</FONT>
<BR><FONT SIZE=2>> Subject: RE: Report of Q.5 (mobility) phone conference, December 18th,</FONT>
<BR><FONT SIZE=2>> 200 1</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Hi, Mr. Francois and All:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The fundamental arguments have been that a protocol is </FONT>
<BR><FONT SIZE=2>> defined with its own</FONT>
<BR><FONT SIZE=2>> characteristics. For example, H.323 protocol has its own entities like</FONT>
<BR><FONT SIZE=2>> terminals, GKs, BEs, and GWs. Whatever protocol is used by </FONT>
<BR><FONT SIZE=2>> these entities</FONT>
<BR><FONT SIZE=2>> among themselves is known as H.323 protocol suit: For </FONT>
<BR><FONT SIZE=2>> example, H.225.0 Annex</FONT>
<BR><FONT SIZE=2>> G among BEs. So, the argument is that whatever protocol is </FONT>
<BR><FONT SIZE=2>> used among the</FONT>
<BR><FONT SIZE=2>> BEs is known as H..25.0 Annex G. The question is: How can we </FONT>
<BR><FONT SIZE=2>> define another</FONT>
<BR><FONT SIZE=2>> protocol like H.22x among the same BEs of H.323? Is it not </FONT>
<BR><FONT SIZE=2>> contradictory to</FONT>
<BR><FONT SIZE=2>> the fundamentals for development of the protocol? Will it not confuse</FONT>
<BR><FONT SIZE=2>> everything? (An analogy: How can we say that let us develop another</FONT>
<BR><FONT SIZE=2>> protocol, say, H.ZZZ to be used among terminals, GKs, and GWs </FONT>
<BR><FONT SIZE=2>> in addition to</FONT>
<BR><FONT SIZE=2>> H.323?)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The solution that we have been discussed among ourselves is </FONT>
<BR><FONT SIZE=2>> as follows (I am</FONT>
<BR><FONT SIZE=2>> providing a copy):</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> --------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> --------------</FONT>
<BR><FONT SIZE=2>> -------------------------------------------</FONT>
<BR><FONT SIZE=2>> 1. We are developing a new protocol where no protocol exists </FONT>
<BR><FONT SIZE=2>> and the same</FONT>
<BR><FONT SIZE=2>> can used by all applications to solve the mobility related </FONT>
<BR><FONT SIZE=2>> problems. For</FONT>
<BR><FONT SIZE=2>> example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. </FONT>
<BR><FONT SIZE=2>> Here where we</FONT>
<BR><FONT SIZE=2>> are defining a new "generic" protocol. This is not specific </FONT>
<BR><FONT SIZE=2>> to the H.323</FONT>
<BR><FONT SIZE=2>> protocol. (Whether VLF, HLF, and AuF will be colocated with </FONT>
<BR><FONT SIZE=2>> the BE/AMFE is a</FONT>
<BR><FONT SIZE=2>> matter of implementation.)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> 2. We have the H.225.0 Annex G protocol that allows us to </FONT>
<BR><FONT SIZE=2>> communicate among</FONT>
<BR><FONT SIZE=2>> the H.323 BEs. This is specific to H.323. All we need to do </FONT>
<BR><FONT SIZE=2>> is to extend</FONT>
<BR><FONT SIZE=2>> this protocol to serve our purposes. (An analogy can be </FONT>
<BR><FONT SIZE=2>> provided. It should</FONT>
<BR><FONT SIZE=2>> be done in a way what Paul Reddy has done for H.xxx Annex E.)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> 3. We have the H.225.0 (RAS + Q.931) protocol that is used </FONT>
<BR><FONT SIZE=2>> among the H.323</FONT>
<BR><FONT SIZE=2>> Terminals, GKs, and GWs. This is specific to H.323. All we </FONT>
<BR><FONT SIZE=2>> need to do is to</FONT>
<BR><FONT SIZE=2>> extend this protocol to serve our purposes. (An analogy can </FONT>
<BR><FONT SIZE=2>> be provided. It</FONT>
<BR><FONT SIZE=2>> should be done in a way what Paul Reddy has done for H.xxx Annex E.)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The questions that I have to you all: Why do you want to </FONT>
<BR><FONT SIZE=2>> develop a generic</FONT>
<BR><FONT SIZE=2>> protocol (if it is not H.323 specific) for items 2 and 3? If </FONT>
<BR><FONT SIZE=2>> you want to do</FONT>
<BR><FONT SIZE=2>> so, how do you definite the generic functional entities like </FONT>
<BR><FONT SIZE=2>> terminals, GKs,</FONT>
<BR><FONT SIZE=2>> BEs, GWs, etc? (Please also note that H.324 and H.310 do not have the</FONT>
<BR><FONT SIZE=2>> concept of functional entities like GKs.)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> My assumption has been that the same (items 2 and 3) can also </FONT>
<BR><FONT SIZE=2>> be done for</FONT>
<BR><FONT SIZE=2>> H.324, H.310, or other protocol while all protocols can use the same</FONT>
<BR><FONT SIZE=2>> "generic" protocol as developed in item 1.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Please also note that if we develop a "generic" protocol for </FONT>
<BR><FONT SIZE=2>> items 2 and 3</FONT>
<BR><FONT SIZE=2>> instead of being making protocol-specific extension, we will </FONT>
<BR><FONT SIZE=2>> force each</FONT>
<BR><FONT SIZE=2>> protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE </FONT>
<BR><FONT SIZE=2>> sets of protocols</FONT>
<BR><FONT SIZE=2>> (protocol specific + generic) among all its functional </FONT>
<BR><FONT SIZE=2>> entities. Is it nor</FONT>
<BR><FONT SIZE=2>> wastage of resources?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> --------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> --------------</FONT>
<BR><FONT SIZE=2>> -----------------------------------------</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> It is not that we cannot develop many fency things like H.22x, but it</FONT>
<BR><FONT SIZE=2>> contradicts the fundamental goals of the protocol development.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Best regards,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Radhika R. Roy</FONT>
<BR><FONT SIZE=2>> rrroy@att.com</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: BOUGANT François FTRD/DAC/ISS</FONT>
<BR><FONT SIZE=2>> [<A HREF="mailto:francois.bougant@RD.FRANCETELECOM.COM">mailto:francois.bougant@RD.FRANCETELECOM.COM</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Friday, January 11, 2002 10:32 AM</FONT>
<BR><FONT SIZE=2>> To: ITU-SG16@echo.jf.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Subject: Re: Report of Q.5 (mobility) phone conference, December 18th,</FONT>
<BR><FONT SIZE=2>> 200 1</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Dear all,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> During the last rapporteur's meeting (Dublin - Ireland), it </FONT>
<BR><FONT SIZE=2>> was expressed</FONT>
<BR><FONT SIZE=2>> that defining H.22x (designed on the basis of H.225 annex G v2 at the</FONT>
<BR><FONT SIZE=2>> current state - the backward compatibility with H.225 annex G </FONT>
<BR><FONT SIZE=2>> v1 would be</FONT>
<BR><FONT SIZE=2>> necessary) as a protocol used on BE--BE and BE--{Backend </FONT>
<BR><FONT SIZE=2>> service entities}</FONT>
<BR><FONT SIZE=2>> interfaces (other interfaces implying GKs could be </FONT>
<BR><FONT SIZE=2>> considered) and stopping</FONT>
<BR><FONT SIZE=2>> H.225 annex G would be a better way than defining a new </FONT>
<BR><FONT SIZE=2>> protocol used on</FONT>
<BR><FONT SIZE=2>> BE--{Backend service entities} interfaces and going on H.225 v2.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> A significant argument is : in the latter case, the BE would </FONT>
<BR><FONT SIZE=2>> support two</FONT>
<BR><FONT SIZE=2>> application-layer protocols that may evolve separatly in the </FONT>
<BR><FONT SIZE=2>> future. This</FONT>
<BR><FONT SIZE=2>> would tend to make BE functionalities harder to implement.</FONT>
<BR><FONT SIZE=2>> A second one is : if the H.22x "body" includes the H.225 </FONT>
<BR><FONT SIZE=2>> annex G protocol ,</FONT>
<BR><FONT SIZE=2>> it can be used for information exchange on BE--BE interface </FONT>
<BR><FONT SIZE=2>> even in the</FONT>
<BR><FONT SIZE=2>> H.323 mobility management context.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> To my understanding, H.22X would not contain any functional </FONT>
<BR><FONT SIZE=2>> architecture</FONT>
<BR><FONT SIZE=2>> description. This would be specifically described in every </FONT>
<BR><FONT SIZE=2>> H.MMS.x draft,</FONT>
<BR><FONT SIZE=2>> depending on the application context (H.323 specific, etc.). </FONT>
<BR><FONT SIZE=2>> To give an</FONT>
<BR><FONT SIZE=2>> example, the definition of generic entities would be </FONT>
<BR><FONT SIZE=2>> contained in H.MMS.0.</FONT>
<BR><FONT SIZE=2>> Specific entities such as GKs would be described in H.MMS.1.</FONT>
<BR><FONT SIZE=2>> Then, mobility management implies a limited set of </FONT>
<BR><FONT SIZE=2>> information exchanges</FONT>
<BR><FONT SIZE=2>> that are independants from the application (although the type </FONT>
<BR><FONT SIZE=2>> of exchange</FONT>
<BR><FONT SIZE=2>> data depends on the application). These are related to the </FONT>
<BR><FONT SIZE=2>> same actions at</FONT>
<BR><FONT SIZE=2>> least : user registration/deregistration, location update, </FONT>
<BR><FONT SIZE=2>> authentication,</FONT>
<BR><FONT SIZE=2>> information update (e.g. user service profile transfer, </FONT>
<BR><FONT SIZE=2>> update), location</FONT>
<BR><FONT SIZE=2>> information request. So I think it is possible to define a </FONT>
<BR><FONT SIZE=2>> "simple" generic</FONT>
<BR><FONT SIZE=2>> protocol.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Best regards,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> François Bougant</FONT>
<BR><FONT SIZE=2>> France Telecom</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -----Message d'origine-----</FONT>
<BR><FONT SIZE=2>> De : Roy, Radhika R, ALASO [<A HREF="mailto:rrroy@att.com">mailto:rrroy@att.com</A>]</FONT>
<BR><FONT SIZE=2>> Envoyé : mercredi 9 janvier 2002 16:16</FONT>
<BR><FONT SIZE=2>> À : BOUGANT François FTRD/DAC/ISS; ITU-SG16@echo.jf.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Cc : Meyer, Greg W</FONT>
<BR><FONT SIZE=2>> Objet : RE: Report of Q.5 (mobility) phone conference, December 18th,</FONT>
<BR><FONT SIZE=2>> 2001</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Hi, Mr. Francois and All:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> In addition, we also had some email correspondences among the </FONT>
<BR><FONT SIZE=2>> conference</FONT>
<BR><FONT SIZE=2>> participants and few interested folks including Mr. Jones and </FONT>
<BR><FONT SIZE=2>> Mr. Reddy. It</FONT>
<BR><FONT SIZE=2>> has been opined that H.22x is NOT needed because the extensions of the</FONT>
<BR><FONT SIZE=2>> existing application-specific protocol (e.g., H.225.0 Annex </FONT>
<BR><FONT SIZE=2>> G) for mobility</FONT>
<BR><FONT SIZE=2>> will serve the purpose.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Copies of the emails are enclosed below.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Best regards,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Radhika R. Roy</FONT>
<BR><FONT SIZE=2>> rrroy@att.com</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> PS: I would highly appreciate if Mr. Greg Meyer would send </FONT>
<BR><FONT SIZE=2>> the email to the</FONT>
<BR><FONT SIZE=2>> SG16 reflector as you know that I can receive the mail from </FONT>
<BR><FONT SIZE=2>> the reflector,</FONT>
<BR><FONT SIZE=2>> but cannot send it because of problems in filtering.</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
</BODY>
</HTML>