Douglas:
Thanks for the reply. Now we have the chance to go for the next step to understand the short comings of the present H.323v2 as well as proposed extension specified in AT&T's distributed model.
I would like to separate the answer in two parts: 1. General aspects of H.323 and 2. Specific to Vivian's topology and configuration.
General aspects of H.323: ----------------------------------
H.323 is a multimedia application, and is independent of the underlying transport networks (i.e., LAN, IP, ATM, FR, and/or others - in any combinations). H.323 considers only H.323 entities (e.g., terminals, MCs, MCUs, etc) and GKs. The communications occur between H.323 entiries and GKs, and between GKs. A single GK controls and manages a zone, and a zone may be independent of network topology and may composed of multiple segments which are connected using routers, switches, and/or other devices.
H.323 does envision communications between the GKs. For example, LRQ messages are sent between the GKs. Between the GKs, as mentioned earlier, there can be many routers, switches, or other devices. This implies an "abstraction of routing" for sending the RAS messages between the GKs at the H.323 level, however, the specific implementation of "routing" of the RAS messages at the "network level" is not addressed in H.323v2.
[In AT&T's distributed model, it is proposed that all GKs should be capable to exchanges all RAS signaling messages (not only LRQ as envisions by the present H.323v2) to solve problems, and the "pathValue" field has been introduced to formalize the "abstraction of routing" notion between the GKs at the H.323 level considering the multiple-GK environment. At H.323 level, AT&T's proposed contribution does not propose any "specific routing schemes" or "routing interfaces".]
H.323 envisions that all communications shall be done between H.323 entities such as H.323 terminals, MCUs, MCs, and GKs. At H.323 level, the communications can take place within a given zone or between multiple zones. At H.323 level, the communication topology has be covered by the single zone GK or multiple zone GKs. H.323 cannot offer any help if the communication topology is not covered by the H.323 GKs.
H.323v2 does not provide mechanisms how the MCUs should be chosen automatically in view of multiple MCUs. That is, a specific MCU has to be chosen by the calling party. (The automatic call deflection by the setup message by a new party to an established multipoint [N-party call] conference call to a MCU is not supported by H.323v2 unless somehow the required MCU's known address is put in the setup message.)
At H.323 level, Communications are done between the H.323 entities: H.323 terminals, H.323 MCUs, H.323 GKs, etc., and there is no "notion" of communications of "local" or "remote".
Specific to Vivian's topology and configuration: --------------------------------------------------------------
In Vivian's configuration, only one MCU has been shown, and that MCU is located in a separate zone. There are 4 zones (GK1, GK2, GK3, and GK4) where H.323 terminals are located, and one MCU in a separate zone that has its own GK.
According to AT&T's proposal, the GKs will be able to know where the MCU is located through exchanging of RAS messages (e.g., LRQs). The calling party may select the MCU where the conference will be controlled. The GKs will be able to send the signaling messages to the particular GK where the MCU is located.
AT&T's proposal allows the ARQ and other RAS messages between the source and destination GKs so that all GK s between the source-destination entities (the word "path" may be mis-understood) can work cooperatively from the resource management point of view whether a call be accepted or not before the actual call is setup.
A MCU that will be controlling the multipoint conference call will be the master.
If a new party (e.g., F in Vivian's example) wants to join the "already" established "multipoint" conference call, F has to join the conference via the MCU (most like to know the conference bridge number priori from the calling party E1 by F). The present H.323v2 does not provide any mechanisms to deflect the setup message of a new joining member automatically to go the MCU (until the new calling party [in this case it is F] knows priori the address of the MCU).
{RSVP reserves the bandwidth at the network level especially in the IP network, and RSVP even may not be applicable to reserve the bandwidth at the LAN. Similarly, there are many mechanisms may be available for the ATM network level. These BW/QOS schemes are limited to the network level only. However, H.323 is an application, any the "abstraction" of BW/QOS is end-to-end that include resources for "network level" as well as "upper middleware level" at the H.323 call level.}
I hope that my above answers will clarify all questions that you might have. If any more questions remain, please let me know.
Thanks and regards,
Radhika
---------- From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] Reply To: Mailing list for parties associated with ITU-T Study Group 16 Sent: Sunday, August 30, 1998 7:30 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: ARQ/ACF
Radhika,
In common with others, I cannot see in H.323v2 generally, nor section 8.1.6 specifically, as quoted in your other response, where ARQ is being sent between gatekeepers. I'll let their comments rest.
I am not too clear on conference calls, and how the MCU is determined. presumably, that is done by the first party, or between the first two parties. For the n'th party to join a conference, do they join by reference to the conference, the MCU (not knowing which MCU was selected) or by reference to one of the endpoints currently participating in the conference? I suspect the latter, and that the call will be deflected to the MC by a Facility response to the Setup.
Section 8.1.9 allows for an ad-hoc conference to be connected with "an MC associated with the Gatekeeper". It also allows for "The master-slave determination procedure is used to determine which MC will be the active MC for the conference." So, if the MC is dynamic, how is the new endpoint expected to "know" of it?
At 17:18 28/08/98 -0400, Radhika wrote:
Vivian:
I am extremely happy in seeing Mr. Clowes answers. I am also adding a
little
text in Clowes' answers to clarify further in relation to the proposed AT&T's distributed model.
I am using one of your assumptions is that MCU is located in zone that has its own GK. In H.323, each GK manages resources in its own zone.
Now MCU will be acting as the central point that will be controlling the call. That is, a calling H.323 endpoint will set up a call with the MCU,
and
in turn MCU will set up the call with the called H.323 endpoints. If a new H.323 endpoint located in new zone wants to join the conference, it will also contact the MCU.
Now the RAS signaling messages between the GKs will be following the
similar
logic. That is, from the calling H.323 endpoint's GK to the MCU's GK, and then from MCU's GK to the called H.323 endpoints' respective GKs, etc.
Thanks, Radhika
PS:
- 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). 2. In "logical" zone environment, the resource management is also extremely important especially in the context of large network where million of users share the same physical network (e.g., in carrier networks, in virtual private networking environment, the network reosources are partioned logically between the corporate customers, and resource managemnt is also done accordingly). [Please note the difference with Mr. Purvis reply].
Should GK4 forwards ARQ to GK that has the MC?? F should not use any resources in the zone of GK is responsible for.
Not normally.
[Radhika: As I have mentioned in the begining, the communication will be done between the MCU and the H.323 endpoint. So, the call will span at
least
two zones: Zone of MCU and Zone 4 of F. Each GK manages resources in each zone. As a result, GK of Zone 4 will not be able to confirm the ARQ message because it does not know about the resources of Zone of the MCU. Accordance to AT&T's proposed distributed model, GK4 of Zone 4 will send the ARQ message to the GK of (MCU) zone after cinfirming its own resources. As soon as the (MCU) GK confirms the resources of its zone, ACF message will be
sent
from the (MCU) GK to the GK4 of Zone 4. GK4 then sends the ACF message to F.]
Where this initial connection is to one of the endpoints involved in the conference, this gets to be a little confusing. How should the GK in the destination zone respond, if a deflection to an out-of-zone MC is the (unknown by GK at this time) future response, and yet local resources are depleted?
or F has to, because H.245 control message exchanges also consume the reources?
Endpoint F should receive an ACF from its own gatekeeper, relating to resource and policy in its own zone. It should then establish a call signalling channel and send a SETUP to the MC. The MC will send an ARQ to its own gatekeeper, to request resourse allocation in its own zone, for this part of the conference.
[Radhika: According to AT&T's proposed distributed model, it will be preferable to follow the ARQ/ACF signaling paths as mentioned above by me. Then, the call signaling SETUP message should be sent to the MCU (because one of the main puposes of the ARQ message is to confirm the resource between the source-destination path).]
I thought that the ARQ bandwidth management was only local, and not path related. Each endpoint (including the MCU) may send an ARQ to its own GK for local bandwidth management. Gatekeepers in unrelated zones are not able to do much about resources on shared backbone path segments. Mechanisms such as RSVP, executed by the endpoints, would seem to be appropriate for path resource reservation and confirmation.
Regards,
Douglas
Radhika,
I welcome any opportunity to test and improve my understanding of H.323, particularly in the area of call establishment, diversion and teardown.
At 15:42 31/08/98 -0400, Radhika wrote:
Douglas:
Thanks for the reply. Now we have the chance to go for the next step to understand the short comings of the present H.323v2 as well as proposed extension specified in AT&T's distributed model.
I would like to separate the answer in two parts: 1. General aspects of H.323 and 2. Specific to Vivian's topology and configuration.
General aspects of H.323:
H.323 is a multimedia application, and is independent of the underlying transport networks (i.e., LAN, IP, ATM, FR, and/or others - in any combinations). H.323 considers only H.323 entities (e.g., terminals, MCs, MCUs, etc) and GKs. The communications occur between H.323 entiries and GKs, and between GKs. A single GK controls and manages a zone, and a zone may be independent of network topology and may composed of multiple segments which are connected using routers, switches, and/or other devices.
Just terminology, but my usage is that H.323 refers to "H.323 entity", which includes gatekeeper and endpoint. Endpoints then is broken down into gateway, terminal, and MCU. The MCU consists of MC and optional MP(s).
Communication is between endpoints and _their_ gatekeeper(s), between endpoints, and between gatekeepers.
Communication, in H.323, is end-to-end. An "end" may include a gateway, usually to another system, but could be for codec conversion. An MCU is regarded as an "end". H.323 also provides for "gatekeeper routed" calls, where some parts of the call go through a gatekeeper (usually Q.931, occasionally H.245). Otherwise, communication is not "through" other entities.
H.323 does envision communications between the GKs. For example, LRQ messages are sent between the GKs. Between the GKs, as mentioned earlier, there can be many routers, switches, or other devices. This implies an "abstraction of routing" for sending the RAS messages between the GKs at the H.323 level, however, the specific implementation of "routing" of the RAS messages at the "network level" is not addressed in H.323v2.
H.323 is very vague about Inter-Gatekeeper communication. It specifically exemplifies the LRQ. It also provides for gatekeeper routed call signalling and control channel.
The gatekeeper may redirect the H.245 Control Channel to an MC when an ad hoc multipoint conference switches from a point-to-point conference to a multipoint conference.
The MC may be discovered by LRQ by the gatekeeper. Its identity may not be known beforehand by either endpoint, nor the gatekeeper.The point being that its identity is unknown to an endpoint wishing to join the conference after its establishment.
[In AT&T's distributed model, it is proposed that all GKs should be capable to exchanges all RAS signaling messages (not only LRQ as envisions by the present H.323v2) to solve problems, and the "pathValue" field has been introduced to formalize the "abstraction of routing" notion between the GKs at the H.323 level considering the multiple-GK environment. At H.323 level, AT&T's proposed contribution does not propose any "specific routing schemes" or "routing interfaces".]
H.323 envisions that all communications shall be done between H.323 entities such as H.323 terminals, MCUs, MCs, and GKs. At H.323 level, the communications can take place within a given zone or between multiple zones. At H.323 level, the communication topology has be covered by the single zone GK or multiple zone GKs. H.323 cannot offer any help if the communication topology is not covered by the H.323 GKs.
My understanding is that there is at most one zone per endpoint, and that communications occurs _between_ zones, rather than _through_ zones.
H.323v2 does not provide mechanisms how the MCUs should be chosen automatically in view of multiple MCUs. That is, a specific MCU has to be chosen by the calling party. (The automatic call deflection by the setup message by a new party to an established multipoint [N-party call] conference call to a MCU is not supported by H.323v2 unless somehow the required MCU's known address is put in the setup message.)
H.323v2 does not specify how the MCU is chosen, but it does provide mechanisms for choosing one, and for redirecting the initial call to the MCU. See section 8.4.3 of H.323v2. This section also shows how a setup message may be deflected, to the previously unknown MCU, by a Facility message indicating routeCallToMC.
At H.323 level, Communications are done between the H.323 entities: H.323 terminals, H.323 MCUs, H.323 GKs, etc., and there is no "notion" of communications of "local" or "remote".
Whether you refer to each entity as local/remote, near-end/far-end, A/B, source/destination, ingress/egress, or some other terminology, it is useful to be able to differentiate participants using English words that are not in the definitions section of the standard.
When talking about bandwidth reservation in the network segment which is "local" to the entity requesting use of the bandwith on the network segment near it, English provides the term "local" to describe it. Perhaps you would prefer "relevant", "appropriate", or some other term if "local" has objectionable connotations for you.
Specific to Vivian's topology and configuration:
In Vivian's configuration, only one MCU has been shown, and that MCU is located in a separate zone. There are 4 zones (GK1, GK2, GK3, and GK4) where H.323 terminals are located, and one MCU in a separate zone that has its own GK.
Correct.
According to AT&T's proposal, the GKs will be able to know where the MCU is located through exchanging of RAS messages (e.g., LRQs). The calling party may select the MCU where the conference will be controlled. The GKs will be able to send the signaling messages to the particular GK where the MCU is located.
H.323v2 allows for the call to be established between an initial terminal and the MCU, with (or without, if absent) the involvement of the gatekeepers in the respective zones, and subsequent terminals invited to join the conference.
H.323 also allows for the creation of an ad hoc conference from a point-to-point conference, where an MC is already involved in the call. Or from a from a gatekeeper routed call where an MC is not involved in the call.
AT&T's proposal allows the ARQ and other RAS messages between the source and destination GKs so that all GK s between the source-destination entities (the word "path" may be mis-understood) can work cooperatively from the resource management point of view whether a call be accepted or not before the actual call is setup.
H.323v2 allows for a new endpoint to call an endpoint currently participating in a conference, but not containing the MC. The procedure (8.4.3.3 part 2) involves sending a SETUP message and returning a FACILITY message indicating routeCallToMC, and specifying the signalling address of the MC (or its gatekeeper, for GK routed).
A MCU that will be controlling the multipoint conference call will be the master.
If a new party (e.g., F in Vivian's example) wants to join the "already" established "multipoint" conference call, F has to join the conference via the MCU (most like to know the conference bridge number priori from the calling party E1 by F). The present H.323v2 does not provide any mechanisms to deflect the setup message of a new joining member automatically to go the MCU (until the new calling party [in this case it is F] knows priori the address of the MCU).
If the MCU has been dynamically determined, F probably has no idea of the identity of the MCU. It would normally begin call establishment with one of the known endpoints, say E1. Call establishment from F to E1 proceeds normally until the SETUP. The SETUP message, according to the text, contains CID = N and conferenceGoal = join, but I see no reason why that should be required. Terminal E1 respondes to the SETUP with a Facility message that tells F to join the conference, the CID of the conference, and the address of the MCU. This is the first F needs to know of the conference, of the CID, or of the MCU.
{RSVP reserves the bandwidth at the network level especially in the IP network, and RSVP even may not be applicable to reserve the bandwidth at the LAN. Similarly, there are many mechanisms may be available for the ATM network level. These BW/QOS schemes are limited to the network level only. However, H.323 is an application, any the "abstraction" of BW/QOS is end-to-end that include resources for "network level" as well as "upper middleware level" at the H.323 call level.}
H.323 is provides for multimedia communication over packet based networks which may not provide a guaranteed Quality of Service, and are most likely, shared with other traffic. While the network may be dedicated, and quality may be guaranteed, that is a degenerative case.
There has been some discussion on the list of the adequacies of the BW/QoS mechanisms included in H.323. Much of it has been directed at the inadequacies of the mechanisms in various scenarios.
In a shared network environment, the best that BW management can aspire to, is to limit the network utilisation by H.323 traffic. Other traffic, not under control of the GK, will have a potentially significant impact on QoS.
It is possible, in some cases, that the GK controls all of the traffic in a particular network. But, in the general case, resource issues, and QoS issues, will have to be resolved at the network level. Mechanisms like RSVP, dedicated bandwidth, private lines are appropriate to this network level functionality. Any abstraction at the application level still has to be implemented at the network level.
Forgive me if I am wrong, but I still read you as proposing to set up some form of "path" through multiple gatekeepers, with reserved bandwidth in a sequence of zones. That sort of thing will only work if the network layer routing follows the same "path", which, in the general case, cannot be guaranteed, and is probably not desirable.
To force the network level router to pass RTP media packets through the same path, presumably source-routing could be used, if available at the network layers. Not desirable!
Or the RTP media packets would have to pass through the intermediate gatekeeper(s), as a media-level gatekeeper-routed call scenario. Not desirable!
If a "path" were reserved by ARQ, and it failed, rerouting would require "re-ARQ-ing" on an alternate "path". Not desirable!
I hope that my above answers will clarify all questions that you might have. If any more questions remain, please let me know.
Am I confused?
Thanks and regards,
Radhika
Regards,
Douglas
participants (2)
-
Douglas Clowes -
Roy, Radhika R, ALTEC