Corrections (It is LRQ [not ARQ])
dclowes at OZEMAIL.COM.AU
Sun Aug 30 21:38:01 EDT 1998
At 13:34 29/08/98 -0400, Radhika wrote:
>It is only LRQ (not ARQ) messages that are exchanged between the zones as
>per present Rec. H.323v2.
>I am sorry for this mistake (overlooking "LRQ" by "ARQ").
Sorry, I missed the thread change before sending my earlier reply.
>Mr. Purvis is correct with respect to the ARQ message statement of the
>present Rec. H.323v2. (It is also applicable to my two replies that I
>provided earlier to Mr. Vivian Liao.)
>Radhika R. Roy
>1. It is AT&T's proposed distributed model in which it is shown that it is
>necessary to send the ARQ/ACF/ARJ messages for inter-zone (inter-GK)
>communications (since the ARQ message has the "BW/QOS abstraction" that
>needs to be resolved between the source-destination path before sending the
>ACF or ARJ message in multiple zone environment considering the fact each GK
>is responsible for the "BW/QOS management" in its own zone only).
I feel that there are certain implicit assumptions being made here, which
may not be valid.
I suspect that you assume that a gatekeeper has control of resources within
its own zone. At least to an adequate degree that is can allocate resources
for H.323 bandwidth within its zone.
There also seems to be an assumption that H.323 zones meet at the edges,
without uncontrolled backbones in between. Possibly that paths extend over
multiple intervening zones, each with its own gatekeeper, and calls will be
"admitted" to each of those zones.
There may be an assumption that gatekeepers are located within the local
network of the endpoints of the zone.
Presumably, for all this to work, call (media) routes are to be determined
by the gatekeeper, rather than IP layer routing. Therefore packets would
have to be source-routed, something many routers and firewalls reject, else
the media may go by a path other than that which has been reserved.
>2. Similarly, the concept of logical zone has also been introduced in AT&T's
>proposed distributed model.
>In this respect, above two items can be considered as proposed extensions of
>[Even for the inter-(administrative)-domain GK communications, the
>destination address resolution based on BW/QOS and security policies are
>under discussion in our bi-weekly H.323 inter-GK conference calls. We are
>also very close to recognize the fact that an "abstraction of routing"
>between the GKs (as envisioned in AT&T's contribution) are needed. (Please
>also see Mr. Andrew Draper's recent proposal).]
I have concerns that some people's views of call routing is confused with
SCN circuit routing and IP packet routing. These concerns are triggered by
references to path-specifics, like references to "next"
hop/border-element/gateway etc., as though routing is being usurped by the
application layer, rather than left to the routing layer of the protocol
My feeling is that address resolution, call authorisation, and call payment
may have to go through several intermediates. The call itself, should be
placed directly between the endpoints themselves, with the possible
intervention of their respective gatekeepers for gatekeeper routed calls.
More information about the sg16-avd