Report of Q.5 (mobility) phone conference, December 18th, 200 1

[Meyer, Greg W]

Forwarded per Mr. Roy's request...

-----Original Message-----
From: Roy, Radhika R, ALASO [mailto:rrroy at att.com]
Sent: Friday, January 18, 2002 8:08 AM
To: Horvath Ernst; ITU-SG16 at echo.jf.INTEL.COM
Cc: Meyer, Greg W
Subject: 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 at att.com

-----Original Message-----
From: Horvath Ernst [mailto:ernst.horvath at SIEMENS.AT]
Sent: Friday, January 18, 2002 4:02 AM
To: ITU-SG16 at 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 at INTEL.COM]
> Gesendet am: Freitag, 11. Jänner 2002 21:35
> An: ITU-SG16 at 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 at att.com]
> Sent: Friday, January 11, 2002 9:02 AM
> To: BOUGANT François FTRD/DAC/ISS; ITU-SG16 at 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 at 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 at 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 at att.com
>
> -----Original Message-----
> From: BOUGANT François FTRD/DAC/ISS
> [ mailto:francois.bougant at RD.FRANCETELECOM.COM]
> Sent: Friday, January 11, 2002 10:32 AM
> To: ITU-SG16 at 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 at att.com]
> Envoyé : mercredi 9 janvier 2002 16:16
> À : BOUGANT François FTRD/DAC/ISS; ITU-SG16 at 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 at 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.
>