Hi, Bob:

Let me explain:

Please see the Portland meeting minutes based on the AT&T contributions. The contribution (Comments on H.323 Annex H) clearly describes that VLF <-> HLF communications protocols are NOT within the scope of Q.13/16. The meeting minutes note that the contribution has been accepted, although some items have not been accepted.

Based on this, it is interpreted that Rapporteur (Q.13/16) is yet to provide his consent that it is within the scope of Q.13/16 before we go to the next step.

That is why, the question has been raised not to include VLF <-> HLF communications protocols and others at this point of time by the editor while we have not done our primary job (why should we be in a hurry to duplicate something skipping the main thing?).

Best regards, Radhika R. Roy AT&T

-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, September 19, 2000 2:38 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded

Roy,

It is clear that you did not understand.

1) I said that the scope of Q.13/16 is defined by the rapporteur of Q.13/16. If he determines that VLF <----> is in the scope of Q.13/16, then it is in the scope. Disagreements can be appealed to the Working Party or the Study Group. As I understand it, it has been determined to be in scope.

2) A common protocol is a great idea, but not mandatory. There are many examples where the ITU has duplicate and competing standards.

Let accept the fact the it is in scope and proceed with useful work

As a thought, based on your arguments, Q13/16 should not work on QOS because there is work in SG11 on this subject.

Bob

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

-----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Tuesday, September 19, 2000 1:06 PM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: RE: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded

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@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@ICN.Siemens.com ------------------------------------------------------------------

-----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Saturday, September 16, 2000 8:48 PM To: ITU-SG16@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@mailbag.intel.com

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