Hi Everyone:
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").
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.)
Sincerely,
Radhika R. Roy
PS:
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).
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 Rec. H.323v2.
[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).]
From: Roy, Radhika R, ALTEC Reply To: Mailing list for parties associated with ITU-T Study Group 16 Sent: Friday, August 28, 1998 6:03 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: ARQ/ACF
Hi Santo:
Section 8.1.6.(3/27/98 - Contact Person G. Thom - Editor) - Thanks, Radhika
8.1.6 Optional Called Endpoint Signalling The procedures defined in 8.1.4 and 8.1.5 show that when a called endpoint is registered to a Gatekeeper, a Setup message is initially sent to the called endpoint from the calling endpoint or the calling endpoint's Gatekeeper. If the called endpoint's Gatekeeper wishes to use the Gatekeeper routed call model, it returns its own Call Signalling Channel Transport Address in the ACF. The called endpoint then uses the Facility message to redirect the call to the called endpoint's Gatekeeper's Call Signalling Transport Address. These procedures assume that the calling endpoint or calling endpoint's Gatekeeper only knows the called endpoints Call Signalling Channel Transport Address. This address may have been received in an LCF sent in response to an LRQ requesting the address of the called endpoint or it may be known through out of band methods. If the called endpoint's Gatekeeper desires a Gatekeeper routed call model, it may return its own Call Signalling Transport Address in the LCF. This will allow the calling endpoint or calling endpoints Gatekeeper to send the Setup message directly to the called endpoints Gatekeeper, thus eliminating the redirection process. An example of this scenario is shown in Figure 24/H.323. In this example, both endpoints are registered to different Gatekeepers, and both Gatekeepers choose to route the call signalling (similar to the case in Figure 23/H.323). Endpoint 1 (calling endpoint) sends an ARQ (1) to Gatekeeper
Gatekeeper 1 multicasts an LRQ(2) to locate called Endpoint 2. Gatekeeper 2 returns an LCF(3) with the Call Signalling Channel Transport Address of itself. Thus, Gatekeeper 1 will subsequently send a Setup (6) message to Gatekeeper 2's Call Signalling Channel Transport Address and Gatekeeper 2 will send a Setup (8) message to Endpoint 2. Endpoint 2 initiates the ARQ (9)/ACF (10) exchange with Gatekeeper 2. Endpoint 2 then responds to Gatekeeper 2 with the Connect (12) message which contains its H.245 Control Channel Transport Address for use in H.245 signalling. Gatekeeper 2 sends the Connect (13) message to Gatekeeper 1 which may contain the Endpoint 2 H.245 Control Channel Transport Address, or a Gatekeeper 2 (MC) H.245 Control Channel Transport Address, based on whether the Gatekeeper 2 chooses to route the H.245 Control Channel or not. Gatekeeper 1 sends the Connect (14) message to Endpoint 1 which may contain the H.245 Control Channel Transport Address sent by Gatekeeper 2, or a Gatekeeper 1 (MC) H.245 Control Channel Transport Address, based on whether the Gatekeeper 1 chooses to route the H.245 Control Channel or not.
<<...>>
From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] Reply To: Mailing list for parties associated with ITU-T Study Group 16 Sent: Friday, August 28, 1998 5:46 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: ARQ/ACF
Hi Radhika:
You wrote:
- Current H.323v2 (e.g., Section 8 with explicit Figures) DOES
envisions
the RAS signaling messages including ARQ can be sent between the GKs in addition between the H.323 entities and the GK. (Please note the difference with Mr. Purvis reply).
I quickly scanned Section 8 of H.323v2 and could not find the case where ARQ's are sent between GK's. Could you be more specific on which sub-section it is in or what figure? That would help me a lot. Thanks.
-santo
At 13:34 29/08/98 -0400, Radhika wrote:
Hi Everyone:
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.)
Sincerely,
Radhika R. Roy
PS:
- 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.
- 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 Rec. H.323v2.
[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 involved.
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.
Douglas
participants (2)
-
Douglas Clowes -
Roy, Radhika R, ALTEC