H225.0 Annex G: Response to Radhika's "clarifications"

Roy, Radhika R, ALTEC rrroy at ATT.COM
Thu Aug 27 06:49:29 EDT 1998


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 at MADGE.COM]
        Sent:  Wednesday, August 26, 1998 1:09 PM
        To:  ITU-SG16 at 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 at madge.com



More information about the sg16-avd mailing list