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

Callaghan, Robert Robert.Callaghan at ICN.SIEMENS.COM
Mon Sep 18 09:24:08 EDT 2000


Roy,

It is the charter of Q13/16 to develop of Multimedia over IP applications.
It is not limited to H.323, although this is the primary standard of
interest.

H.248 is a standard that is independent from H.323, but in the scope of
multimedia over IP.  This is in the scope of Q13/16.  Now SG9 is
standardizing MGCP in competition with H.248.  In that SG9 is chartered with
standards related to cable systems and MGCP is used in the cable industry,
it is in their scope (Not good; but true).

Annex G, is clearly a backend service that is used in support of H.323.  It
is also in the scope of Q13/16.  VLF <-- --> HLF communication is clearly
analogous with Annex G.  Based on this analogy, it can be in the scope of
Q13/16.

Yes, IMT-2000 covers the next generation of mobile products.  The last time
I looked, SG16 is a participant in IMT-2000 regarding the multimedia
applications.   Based on this, any work done in SG16 regarding the support
of multimedia application is, by definition, part of IMT-2000.

A common solution for backend services is good.  However, the operative word
is common, as in fully supports all needs.  Your example of H.245 is good.
However, a focused solution that does not support all needs is worse than no
solution.  In your knowledge, do the solutions proposed by SG11 cover the
needs of H.323?  As an example, does the transport method scale to the
smaller sized systems supported by H.323?  If SG11 is truly considering the
needs of H.323 this is very good; but this is not consistent with the past.
As an example, they insist that all call control signaling must be ISUP,
which does not scale to the smaller sizes.

I think that Q13/16 should move forward with the standards necessary to
support multimedia over IP.  I accept the ruling of the rapporteur as to the
scope of this work.  I do not think that energy should be expended with
further debates on this subject.  If someone does not agree with the
decision of the rapporteur, then the decision should be appealed to the
working party or study group chairman.  This is far more effective that the
current argumentation.

Just my opinion,

Bob

------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756    Fax: +1.561.923.1403
Email:  Robert.Callaghan at ICN.Siemens.com
------------------------------------------------------------------

 -----Original Message-----
From:   Roy, Radhika R, ALCOO [mailto:rrroy at ATT.COM]
Sent:   Saturday, September 16, 2000 8:48 PM
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-106_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



More information about the sg16-avd mailing list