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

Roy, Radhika R, ALCOO rrroy at ATT.COM
Tue Sep 19 13:05:40 EDT 2000


Hi, Bob:

It appears that you are agreeing with the fact there should be a common
standard where it is necessary. For example, H.245 and others are the
example of WP2. In this respect, we can also do the same for VLF <-> HLF,
AuF <-> HLF, and others because all applications like H.323, H.321, H.324,
etc. and others.

First of all, it has to be clarified that it is the scope of a given
question, and then the all companies need to be given the fair chances to
bring contributions to solve the same problem.

Please note that it has been said time and again (contributions had been
brought) that these items are not within the scope of Q.13/16 and
contributions were not brought assuming that we MUST not develop one VLF <->
HLF protocol for H.323, another VLF <-> HLF for H.321, and another one for
H.324, and so on. There is nothing fency about this because it deals with
mobile users.

Please note that VLF <-> HLF communications are not specific to "MULTIMEDIA"
or for the "IP Transport network" per se.

We had a meeting with SG11 and SG16 to address how HLF and VLF protocols are
being developed in SG11 (IMT-2000).

Again coming to the fact, we have not done the job for the first 1:

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.

Once we do this part, then we will enough time what needs to be done with
others.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Callaghan, Robert [mailto:Robert.Callaghan at icn.siemens.com]
Sent: Monday, September 18, 2000 9:24 AM
To: Roy, Radhika R, ALCOO
Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
Subject: QRE: [H.323 Mobility:] A cleaned up H.323 Annex H draft
uploaded


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-----
> phase.
>
> More specific technical comments will be given for each point once the
> primary objectives are clarified.
>
> Best regards,
>
> Radhika R. Roy
> AT&T
>
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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