Hi Everyone:

We all agree that the lower netwokring layer will deal with specific QOS/BW issues.

However, it the GK which is responsible for the ARQ and Bandwidth messages. At the call level, a GK has to decide whether a H.323 call has to be accepted or not. So, options are there that there will be an "abstraction" of QOS/BW at the GK level before acceptance of the call.

This is an important parameter to provide or differentiate services (if anyone does not want to differentiate a service by using that parameter may be one's choice, but others do want to keep that option open).

Thanks and regards, Radhika R. Roy AT&T

---------- From: Chris Purvis WVdevmt-WS [SMTP:cpurvis@MADGE.COM] Sent: Wednesday, August 26, 1998 1:09 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: H225.0 Annex G: Response to Radhika's "clarifications"

All,

Last week's conference call seemed to me to come to some fairly clear conclusions, on the basis of which I understood that the following would be the basis for our ongoing work in this area.

Assume initially that there is global transport-layer connectivity between border-elements. We will consider the case where this is not so below.

There are up to four essentially different sorts of message that may be propogated for a call to take place in the envisaged environment: 1. Location messages. These allow a caller to discover, essentially, where to send its setup message. 2. Call setup messages 3. "H.245" messages 4. Data (in which I include audio & video data). There is no reason for any two of these types of message to propogate by the same route between border elements (indeed, there's no reason why audio and video, for example, should go the same route either). In particular, what I have designated the "location" stage may go take a complex route or consist of the "source" border element asking other border elements in turn for more information (where the "more information" may consist of more border elements to ask the question, in some structured form - probably traversing a hierarchy). There is also the point that a gatekeeper does not necessarily have (and neither should it be encumbered with) knowledge of other sorts of traffic traversing a network it is on. These points appeared to lead to a consensus that the bandwidth management scheme implemented in ARQ and BRQ messages, while of some use in a controlled LAN environment, is not up to the demands that this larger scheme would place on it. Moving on from that we seemed to be in agreement that, at least in these less controlled environments, bandwidth and QoS issues should be handled at a lower layer, on the grounds that there is (and should be) no difference from a router's point of view between H.323 data and any other UDP packets.

In the case without global transport-layer connectivity between border elements, things will change slightly, but only inasmuch as there may be one or more "pinch points" (such as proxies between transport networks) along the routes that all the different sorts of messages have to go through. The presence of such "pinch points" in some circumstances is not an argument in favour of artificially imposing them on all networks, however: even if a given route has "pinch points" there is no reason to force different types of message to go the same route between "pinch points".

Regards, Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis@madge.com