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(a)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(a)att.com
-----Original Message-----
From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT]
Sent: Monday, January 21, 2002 5:04 AM
To: ITU-SG16(a)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(a)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(a)att.com
>
> -----Original Message-----
> From: Horvath Ernst [ mailto:ernst.horvath@SIEMENS.AT]
> Sent: Friday, January 18, 2002 4:02 AM
> To: ITU-SG16(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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.
> >
>
