AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1
Horvath Ernst
ernst.horvath at SIEMENS.AT
Mon Jan 21 05:04:02 EST 2002
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 at att.com]
> Gesendet am: Freitag, 18. Jänner 2002 17:08
> An: Horvath Ernst; ITU-SG16 at 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 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20020121/2d1b1c50/attachment-0004.html>
More information about the sg16-avd
mailing list