COM 16-67 (Amendment 5 to H.222.0|ISO/IEC 13818-1) is correct
okubo at giti.or.jp
Thu Aug 27 00:20:58 EDT 1998
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
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
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
Phone:+44 1753 661359 email: cpurvis at madge.com
More information about the sg16-avd