Hi, Paul:
It is not about "master" protocol per se. It is also NOT the name change
(even the name change provides the meets the first step of the fundamental
objective because the same protocol can be used by all applications for
mobility in the context of HLF/VLF/AUF: H.323, H.310, H.324, IMT-2000, and
others - it is also a very big gain).
It is the big picture of Q.5/16 how the whole mobility question needs to be
addressed.
People want to build "inefficient" protocol by duplicating the same thing
for the same purpose is against the very fundamental principle of ITU
standardization.
The protocol used by HLF/VLF/AuF/Billing/QOS/Accounting will NOT be called
H.225.0 Annex G. The proposal has been made with the name of simple
extensions of some messages of Annex G (as if nothing else is needed here
now or in the future) to fulfill the very short-term "narrow" objectives.
But it is forgotten that many more things are ahead to address all issues
related to mobility.
Hope this clarifies the things.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT]
Sent: Tuesday, May 22, 2001 5:38 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: AW: Annex Gv2
Paul,
I welcome the proposal not to approve H.225.0 annex G v2 now.
In my contribution to Q.5/16 I suggest to make the mobility management
protocol a "profile" of the annex G protocol, after adding the few extras
that mobility management would require. However, some members strongly
oppose to calling mobility management "H.225.0 annex G". Since the arguing
is about names rather than content, it would be undesirable to duplicate the
work and define nearly identical protocols in two different recommendations.
Maybe we can define a "master protocol" in a separate recommendation and
then derive various profiles from this master protocol: for the current
annex G (reference point A), for reference point B (GK-BE), for mobility
management, etc.
Regards,
Ernst Horvath
Siemens AG
> -----Ursprüngliche Nachricht-----
> Von: Paul E. Jones [mailto:paulej@PACKETIZER.COM]
> Gesendet am: Dienstag, 22. Mai 2001 06:14
> An: ITU-SG16(a)mailbag.cps.intel.com
> Betreff: Re: Annex Gv2
>
> Paul,
>
> I think the decisions made for H.225.0 Annex Gv2 as it
> relates to Q.5 work
> should be considered, but I stress even more the other two issues: the
> editor feels that the content has not changed significantly enough and
> comments I've received from others relating to reference
> point D. I believe
> the latter two issues are most significant.
>
> Two questions I hear from people often are "How does the GK
> talk to the BE?"
> and "What good does it do to have the usage information in
> Annex G when it
> can't be passed to/from the GK?" Consideration should be
> given to whether
> those questions are adequately answered (which they're not)
> and whether we
> want to answer those question within the protocol at this time.
>
> Paul
>
> ----- Original Message -----
> From: "Reddy, Paul K" <paul.k.reddy(a)INTEL.COM>
> To: <ITU-SG16(a)mailbag.cps.INTEL.COM>
> Sent: Monday, May 21, 2001 7:48 PM
> Subject: Re: Annex Gv2
>
>
> > Hi Radhika,
> >
> > With respect to your point on 2a, Q.5/16 has been defined
> the Objectives,
> > scope, work plan for study period 2001-2004 during last Rapporteur's
> meeting
> > in Lanceston, Australia. As far as the protocol for H.MMS.1
> (Mobility for
> > Multimedia systems based on H.323) recommendation has not
> been decided as
> of
> > last meeting. Your contributions and other contributions
> have come in for
> > Porte Seguro's meeting in Brazil will consider for
> discussion on Mobility
> > protocols like H.MMS.General (based on H.225.0 AnnexG or
> other protocol
> > etc.)
> >
> > PS: Paul, I would recommend not to delay the approval of
> H.225.0 Annex
> Gv2,
> > if Annex Gv2 does not include the Mobility work. - Paul
> >
> > regards,
> > Paul
> >
> > Paul K. Reddy
> > Rapporteur for Q.5/16
> > Intel Corporation, Mailstop:JF3-377
> > 2111 N.E. 25th Avenue,
> > Hillsboro, OR - 97229, USA
> > Office Phone # +1 (503)-264-9896
> > Mobile Phone # +1 (503)-807-9564
> > Email: paul.k.reddy(a)intel.com
> >
> >
> > -----Original Message-----
> > From: Roy, Radhika R [mailto:rrroy@ATT.COM]
> > Sent: Monday, May 21, 2001 9:18 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: Annex Gv2
> >
> >
> > Hi, Paul:
> >
> > Let me explain where H.225.0 Annex G may fit with respect
> to mobility as
> > well as non-mobility as follows:
> >
> > 1. Anything extension that does NOT deal with MOBILITY in
> H.225.0 Annex G
> > version 2 can be considered for approval.
> >
> > 2. Anything that deals with MOBILITY (or with an intention
> to support
> > mobility indirectly) in H.225.0 Annex G version 2 MUST NOT
> be considered
> for
> > approval because of the following:
> >
> > a. The scope and reference points of mobility Q.5/16 needs
> to be defined
> > that is consistent with its charter.
> >
> > b. H.MMS.x work will be defined and completed in accordance
> to item a.
> >
> > c. All applications can use the common protocol for
> HLF/VLF/AuF (and other
> > value-added services). It will be a new protocol and will
> NOT have any
> > application-specific name (e.g., H.225.0 Annex G).
> >
> > d. As soon as we complete item c, we will see what needs to
> be done for
> > H.323. In H.323, we may have to extend H.225.0 RAS +
> H.225.0 Annex G.
> These
> > are application-specific extensions to support MOBILITY
> (applicable for
> each
> > application as well: H.310, H.324, IMT-2000, etc.).
> >
> > This is what has been proposed by AT&T in all contributions.
> >
> > Hope this will help.
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM]
> > Sent: Sunday, May 20, 2001 10:06 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Annex Gv2
> >
> >
> > Folks,
> >
> > The editor of Annex G has recommended that we not approve
> Annex G at this
> > meeting, citing that there is insufficient material to
> warrant approval.
> I
> > have also heard comments from some that additional work
> should be done in
> > the area of defining reference point D. Of course, we also
> have the open
> > question of where (if anywhere) Annex G fits into the H.MMS.x work.
> >
> > For the benefit of those not planning to attend the
> meeting, please tell
> me
> > if you would have objections to *not* approving Annex Gv2
> at this meeting.
> >
> > Thanks,
> > Paul
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
