QRE: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded

[Callaghan, Robert]

Hi Radhika, Paul & others

Shortly, my understanding is that IMT-2000 is not defining protocols
suitable (or intended for) packet-based networks, i.e. H.323 Systems on top
of e.g. IP, but they concentrate on more general level definitions.
While I do think that we need to consider IMT-2000 as well as other 3G
standardization bodies (I would argue that 3GPP is the dominant one at the
moment) and use as much of the specifications available as possible, I still
think that we need to make our own specifications for H.323. Even if we just
re-use some existing protocols, the usage of these needs to be clearly
specified in the context of H.323.

-Jaakko

> -----Original Message-----
> From: EXT Roy, Radhika R, ALCOO [mailto:rrroy at att.com]
> Sent: 17. September 2000 3:48
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H
> draft uploaded
>
>
> Hi, Paul:
>
> I am glad that you have asked this question.
>
> HLF and VLF are value-added functions, and these server functions are
> necessary for any mobile users. IMT-2000 is working to develop these
> protocols. SG16 and SG11 had one joint meeting in the last
> Feb'00 in Geneva.
> These protocols are VLF <-> HLF and others.
>
> All we (Q.13/16) need to do: An interface with the VLF by the
> H.323 GK.
>
> (An analogy can also given: H.245 is a common set of control
> protocol that
> is being used by H.323, H.324, and other applications.)
>
> If there are one or more functions are needed for any reasons that are
> specific to H.323, people can always augment that particular
> protocol. This
> is a fact of life.
>
> The same is also true for QoS, authentication, accounting,
> billing, and
> others.
>
> More importantly, IMT-2000 is dedicated for mobility.
>
> Our (Q.13/16) primary task is to extend the H.323 protocol
> for supporting
> mobility (as explained many times) is as follows:
>
> Part 1: Within the scope of Q.13/16: Extension of H.323
> (e.g., H.225.0 [RAS,
> Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs.
> (Contributions
> are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.)
>
> If we do NOT this part 1, we are NOT doing our primary job because the
> solution will NOT fly. We are rather "building a castle in the air."
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> Sent: Saturday, September 16, 2000 2:45 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H
> draft uploaded
>
>
> Radhika, et al,
>
> I have to confess that I have had no time to really follow
> the Annex H work,
> but I do have a question to toss out here:
>
> Why do you consider the VLF or HLF functions outside the
> scope of Q13/16?  I
> assume that these functions are IP-based (or at least used
> with the same
> call signaling transport as the H.323 system) and integrate
> with the H.323
> functions.
>
> You stated below that these functions are common for all
> mobile systems.  I
> will not argue that point, but will a common solution be the most
> appropriate for H.323 systems?  I would guess that trying to
> introduce a
> generic mechanism may or may not be the best solution for H.323.
>
> I'd like to hear counter arguments to yours.  Apparently
> others felt that
> these functions were necessary for H.323 systems and should be defined
> within the H.323 framework.
>
> Paul
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy at ATT.COM>
> To: <ITU-SG16 at mailbag.cps.intel.com>
> Sent: Friday, September 15, 2000 10:25 AM
> Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H
> draft uploaded
>
>
> > Hi, Everyone:
> >
> > The document MD-106 (H.323 Annex H) submitted by the editor remains
> > basically same from the fundamentally point of view. So,
> the comments
> > provided on the September 8 email (copy enclosed) remains
> the same as
> stated
> > earlier. The comments can be summarized as follows:
> >
> > The Annex should be divided into two parts:
> >
> > Part 1: Within the scope of Q.13/16: Extension of H.323
> (e.g., H.225.0
> [RAS,
> > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs.
> (Contributions
> > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.)
> >
> > Part 2: Outside the scope of Q.13/16: Back-end services related to
> Mobility
> > (or value-added services related mobility) containing VLF and HLF.
> >
> > So, it can be seen clearly that MD-106 (H.323 Annex H)
> submitted by the
> > editor does not contain the basic part 1 which is within
> the scope of
> > Q.13/16 (it rather contains part 2 which is outside the
> scope of Q.13/16).
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> > +1 732 420 1580
> >
> >
> > -----Original Message-----
> > From: Roy, Radhika R, ALCOO
> > Sent: Friday, September 08, 2000 10:23 AM
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: Re: [H.323 Mobility:] H.323 Annex H status check
> >
> > Hi, Everyone:
> >
> > The draft does not contain the basic part: Extensions of
> H.323 (e.g.,
> > H.225.0 messages). Contributions are there (e.g., D.354 of
> SG16 Feb'00,
> > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ
> messages
> > need to be removed to the base spec of H.323 because there
> is nothing
> > specific to be done with mobility. If it is used in the context of
> mobility,
> > the issues related to mobile need to be pointed out so that
> contributions
> > can be brought to address those issues. Contributions are
> there to note
> the
> > issues.
> >
> > The another suggestion is to make two parts of the Annex: 1. Basic
> extension
> > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end
> services
> > related to Mobility (or value-added services related
> mobility)containing
> VLF
> > and HLF.
> >
> > Part 2 clearly does not have to be specific to H.323. It is
> a general
> > service related to mobility. Every application that needs
> mobility may
> like
> > to use these services. This will be addressed in the light
> of the all
> mobile
> > applications of all questions of all SGs of the ITU-T. So, it is
> > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes
> this decision.
> >
> > Please note that Security (AuF) is also needed for the
> fixed users. So,
> this
> > is a generic service that needs to be developed for both
> fixed and mobile
> > users. So, it also belongs to the base H.323 spec. That is, any
> > specification related to AuF should be moved to the base
> H.323 spec as
> well
> > because it belong to both and the standard should be developed
> accordingly.
> >
> > For rapid determination, I would suggest to address part 1
> only in the
> first
> > phase.
> >
> > More specific technical comments will be given for each
> point once the
> > primary objectives are clarified.
> >
> > Best regards,
> >
> > Radhika R. Roy
> > AT&T
> >
> >
> > -----Original Message-----
> > From: Jaakko Sundquist [mailto:jaakko.sundquist at NOKIA.COM]
> > Sent: Thursday, September 14, 2000 7:28 AM
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
> >
> >
> > Hi all,
> >
> > I have uploaded MD-106 to URL:
> >
> ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10
6_H323AnnexHDr
> aft.zip .
> The document is a cleaned up version of TD-42 of the Portland meeting  and
> contains only editorial changes(as the template used in the draft document
> so far was, for some reason, a total mess).
> The only "exeption" to this is the following correction. Section 8.1 of
> TD-42 included the text: "Reference points A and B are out of the scope of
> this Annex.", which has been removed and instead section 8.3 now includes
> the text: "Reference points B, C and D are out of the scope of this Annex
> (Hinter is included but only as an option in case that utilization of
> reference point A is not practical).".
> The reason for this change is that the text in TD-42 is, as I understand
> from Mr. Rissanen's comments, a typo and should have mentioned reference
> points B and C instead of A and B.
>
> ------------------------------------------------
> Jaakko Sundquist           *
> +358 50 3598281            * Audere est Facere!
> jaakko.sundquist at nokia.com *
> ------------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com