Hi Everyone:
We are discussing about H.323 addresing schemes in our bi-weekly H.323
inter-GK conf calls.
The H.323 addresses that are being considered are 1. E.164, 2. E-mail, 3.
URL, and 4. TCP/UDP/RTP port addresses (and 5. aliases as well I guess).
Although a hierarchical notion of addressing scehmes have been discussed, we
have also recognized that some other variations of addressing schemes are
there.
For example, people change their physical locations, but they might have to
keep the …
[View More]same E.164 addresses. So, a translation is needed. Therefore, the
very physical relationship of E.164 addressing scheme (e.g., knowing NPAs
and NXXs, one can find the distance) has been broken.
Another example can be 800 numbers where the translation is also needed.
In addition, from mobility point of view (device or person) wired (and
wireless?) environement may also be looked into.
As we go froward, we may consider many of those aspects as pointed above to
provide solutions for the H.323 addressing schemes.
Regards,
Radhika R. Roy
AT&T
732 949 8657
rrroy(a)att.com
[View Less]
Hi Evryone:
I thought that we would be using the document number as suggested by me as
we would enclose documents in the email so that we could refer each other
documents appropriately.
Regards,
Radhika R. Roy
AT&T
> ----------
> From: Andrew Draper WVdevmt-WS[SMTP:adraper@DEV.MADGE.COM]
> Reply To: Mailing list for parties associated with ITU-T Study Group
> 16
> Sent: Tuesday, September 01, 1998 9:06 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> …
[View More]Subject: Re: Communications between Administrative Domains
>
> <<File: ResolveGK_santo1.doc>>
> Santo,
>
> Enclosed are my responses to your comments. Hopefully this will help
> clarify my
> meaning in the areas where the proposal was unclear.
>
> Regards,
>
> Andy
>
> --
> Andrew Draper - Principal Development Engineer - WAVE Software
> Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks.
> mailto:adraper@dev.madge.com phone:+44 1753 661329
> pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F
>
>
[View Less]
Douglas:
I really appreciate your email to help me to clarify the things that will
definitely improve our in-depth understandings related to H.323.
I have answered each item below step by step. If you have any more
questions, please let me know.
Again, I heartfelt thanks to you for providing me an opportunity to explain
the things to the worldwide ITU-T SG 16 audiences.
Regards,
Radhika
> ----------
> From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU]
> Reply To: …
[View More]Mailing list for parties associated with ITU-T Study Group
> 16
> Sent: Monday, August 31, 1998 9:27 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: ARQ/ACF
>
> 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.
>
> [Radhika: Yes, in general, H.323 entities means as long as those entities
> communicate with H.323 messages at H.323 level.]
>
> >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.
>
> [Radhika: Yes, you are right. H.323v2 allows for both RAS signaling
> messages (mandatory) as well as gatekeeper routed call signaling messages
> (optional).]
>
> 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.
>
> [Radhika: Yes, it is a very good point that you have brought up. I like to
> see that others also comment on that. How does an endpoint know before
> hand the identity of an MCU in the case of multiple-MCU environment. My
> guess is that some how some knowledge for the address of the MCU has to be
> there.]
>
> >[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.
>
> [Radhika: I guess that there can be many H.323 endpoints per zone. Each
> zone will have one GK. There will be communications between the GKs at
> H.323 level. I do not know what you mean by "between the zones" or
> "through the zones". I guess that it is the communications between the
> GKs. However, each GK controls and manages resources within its zone.]
>
> >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.
>
> [Radhika: I assume that one can choose if one knows "which one" to choose.
> That is, one needs have the knowledge of the MCUs, and accordingly that
> information has to be embedded in the facility message. H.323v2, as I
> understand, does not provide any mechanisms what "criteria" to be used to
> choose one MCU over another. Probably, these criteria have been left for
> implementations to differentiate services.]
>
> >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.
>
> [Radhika: I apologize for any mis-understanding in interpretation of
> different terminologies. I was just refering to "ARQ bandwidth management
> is local only".]
>
> >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.
>
> [Radhika: Yes, in general, it is true for all cases in H.323v2. People may
> not need the help of GKs at all, if they think they have all the
> information what the GKs have to provide them. That is, RAS signaling
> messages may not be needed before the call setup. However, if they need to
> get the help of the GKs, RAS signaling messages may need to be transferred
> between the GKs.]
>
> 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.
>
> [Radhika: Yes, H.323v2 provides some mechanisms. However, we may also try
> to improve the specifications in the future to make it more dynamic from a
> point-to-point call (where neither MC nor GK is involved) to a
> point-to-multipoint call along with sub-conferences within a given
> conference.]
>
> >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).
>
> [Radhika: Yes, you are right, and one has to know the "address" of the MC
> (i.e., priori known address). This setup message is being used by-passing
> the GKs. That is, no RAS signaling is used (i.e., no help from the GKs as
> well). However, the description above that refers to AT&T's proposal
> clearifies the fact how inter-GK communications will help to confirm the
> resources at the H.323 call level using the ARQ/ACF/ARJ messages when the
> H.323 call traverses multiple zones.]
>
> >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.
>
> [Radhika: I guess that you are more or less in agreement with respect to
> different alternatives how F may join in the already established
> conference. In you example, F discovers he conference ID, MCU, etc. after
> calling the endpoint E1 asuming F knows endpoint E1 priori. In my example,
> it is assumed that F knows the MCU and conference ID priori, and does not
> know endpoint E1's identity.]
>
> >{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.
>
> [Radhika: Yes, that is right. Let me add a little more. I do not know
> whether a network has to be dedicated or not to guarantee quality. For
> example, an ATM network may be shared among millions of users. Even then,
> an ATM network has the capability to guarantee quality at the network
> level. H.323 is a multimedia application, and it is end-to-end. H.323
> requires "network level" as well as "upper layer (above network layer)"
> services between the source and destination H.323 entities. That is, H.323
> requires services both from "network level" and "upper layer (above
> network layer)" services to satisfy its requirements. For example, an
> H.323 MCU in a carrier network whose resources are shared among thousands
> of users, its "upper layer (above network layer)" resource management is
> very critical in addition to the "network level" resource management. In
> H.323 level, an end-to-end resource management that includes both "network
> layer" and "upper layer" for each H.323 call is very critical. Please also
> note that a H.323 call can be multimedia, multipoint call as well.]
>
> 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.
>
> [Radhika: You are right. I do not think that we should go for any specific
> implementation schemes for the BW/QOS mechanisms at the H.323 level. In
> H.323, we creating some "abstractions" at the H.323 level in a technology
> independent way so that we are leaving enough room for creativity for
> competition to differentiate services. This creation of "abstractions" is
> the most fundamental mechanisms of H.323. That is why, we see that H.323
> has become so popular that IETF, ATM-F, and other are implementing H.323
> over specific technologies. I would say that this is one of the most
> important standards of our time ever created by the ITU-T. However, if
> there are some standards that are developed for some specific technologies
> for implementations of H.323 including BW/QOS, we may use those
> specificaions as well.]
>
> 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.
>
> [Radhika: Form H.323 point of view, a GK does controls and manages
> resources of a zone, and communications occur at H.323 level. If there are
> multiple zones, each GK in each zone will have the responsibility to
> control and manage resources. That is, H.323 does not specifies the
> situation if the resources are not under GK control. As I mentioned
> before, it is also perfectly OK, (I guess that I am right), not to use any
> services that are offered by GKs if one thinks that one has all the
> answers what H.323 GKs provide. In AT&T proposal, an extension has been
> proposed for inter-zone communications via GKs considering multiple
> zones.]
>
> 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.
>
> [Radhika: It depends. Please see earlier write-up very carefully. I have
> also used an example of MCU. For example, the upper layer (above network
> level) reources of an MCU do not fall into the category of "network level"
> functionality. The resources of a zone means all the resources that
> include both "network" and "upper" layer. At H.323 level, we create
> "abstrations", and we do not address for any specific implementations. (I
> personally has worked in this area for a long time. I have devloped some
> schemes how to implement those things from higher layer to the lower
> layer, and these schemes are implementation specifics. In standard arena,
> it may create debates whether those schemes are optimal or the most
> efficient.) Definitely, many (if not all of them) of the application
> abstractions have to be translated into the network level. This is the
> real challenege. For example, there is no one-to-one mapping betwen the
> application level BW/QOS parameters to the network level BW/QOS
> parameters. I had talks with many people in the standards arena wheher
> they worked on those issues. They indicated that they were yet to work in
> those areas.
>
Radhika: Some hypothetical implementation examples might be helpful.
The extreme case would have ben "not to use any resource control" (similar
to one unspecified bit rate [UBR] as it is used in the public Internet). In
this case, for example, all GKs of all zones will just confirm as soon as
the ARQ message for each call since no conrol is needed. A little conrol may
specifiy accept N number of calls per zone if the total bandwidth does not
exceed certain upper limit. Or, there may be more shophisticated
implementations at the H.323 call level that uses the help of GKs via
inter-zone communications between the H.323 source-destination entities.
Radhika: Many network level BW/QOS schemes have been developed. ATM
network is the prime exapmle. We can also think RSVP in the context of
IP-based router network. As I mentioned before, RSVP does not provide any
support for controling BW/QOS over the LAN. That is, in LAN-IP (wide area
network)-LAN configuration, RSVP can only provide support in the IP (wide
area network) part only. In other words, even at the "end-to-end network
level", RSVP does not help.
Radhika: Considering the above situation, let us think about an
end-to-end H.323 call between the H.323 source-destination entities. This
includes both "network" and "upper" layer. We are considering that a GK will
have the "abstractions" BW/QOS that that will be translated in all layers as
appropriate. At H.323 level, we do not expect to have specific answers for
specific implementations for all lower layers. We are just creating
"abstraction" for now.]
> 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.
>
> [Radhika: It depends how sophisticated models are developed at the GK
> level. Let us not stop creativity for differentiate services through
> offering quality. If one does not want to implement that, as I mentioned
> bfore, it is up to one's choice. But let me provide some very high level
> examples. A GK of a given zone may consider that it will ONLY care about
> the total number of calls and the upper limit of bandwidth no matter
> whether what paths are being followed within its zone by the actual call.
> Therefore, the actual path level information at the routers of the said
> zone may not be needed at all. There can be numerous ways of
> implementations for "BW/QOS abstractions" especially from the service
> providers' point of view. At H.323 level, we are not solving those
> problems at all. We are keeping all possible options open, if one really
> wants to implement.]
>
> 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!
>
> [Radhika: Please see my answers given above. In H.323 level, nothing is
> forced. It is an option. How that option will be implemented it is up to
> one's choice. A GK has the knowlege at the zone level only ("network level
> path" knowlege is not mandated at the H.323 level). How the "BW/QOS
> abstraction" is implemented at the lower level is implementaion specific,
> and H.323 does not mandate any specific implementations at the lower
> level.]
>
> Or the RTP media packets would have to pass through the intermediate
> gatekeeper(s), as a media-level gatekeeper-routed call scenario. Not
> desirable!
>
> [Radhika: Inter-GK (inter-zone) communications are dealing with the RAS
> signaling messages only. It does not mandates how the gatekeeper routed
> call will take place. Once all the information is obtained vis the RAS
> signaling messages, it is up to one's choice how the gatekeeper routed
> will take place depending on the optimal configuration. It can be as
> simple as one GK only. Or, it can also be via multiple GKs if that is the
> best choice (e.g., some back-end services are distributed over multiple
> GKs.). I hope that this explanation will clarify the things.]
>
> If a "path" were reserved by ARQ, and it failed, rerouting would require
> "re-ARQ-ing" on an alternate "path". Not desirable!
>
> [Radhika: I guess that above answers will clarify the situations. It is
> the inter-zone communications, and it does not mandates any specific
> "network level paths" at the H.323 GK level. So, this concern stated above
> will not be there.]
>
> >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
>
[View Less]
Dear Q.11-14 Experts,
I have put the delayed contributions to September SG16 meeting as
ftp://standard.pictel.com/avc-site/Incoming/H323DTCP_rev.rtf
and
ftp://standard.pictel.com/avc-site/Incoming/H323anxD.rtf
and
ftp://standard.pictel.com/avc-site/Incoming/H450Comm.rtf
The title of H323DTCP_rev.rtf is "PROPOSAL OF TCP SUPPORT ON H.323 ANNEX D".
This contribution is prepared to discuss real-time facsimile, H.323
Annex D. It provides the conditions for selecting TCP or UDP.
In H323anxD …
[View More]and H450Comm, i had informed already.
But,please igonore following files ;
H323anxD.doc, H323DTCP.doc, H450Com.doc and H450Comm.doc
I will submit this contributions to ITU-T in a few days.
Best regards,
---
Yasubumi Chimura
OKI Electric Industry Co.,Ltd.
e-mail:chimura730@ainet.oki.co.jp
Phone +81-3-3454-2111
FAX +81-3-3798-7684
[View Less]
Dear Q.11-14 Experts,
I have put a delayed contribution to September SG16 meeting as
ftp://standard.pictel.com/avc-site/Incoming/H323anxD.doc
The title is "PROPOSAL FOR CORRECTION OF H.323 ANNEX D".
This contribution is prepared to discuss real-time facsimile, H.323
Annex D. It provides some corrections to the text of H.323 Annex D.
Best regards,
---
Yasubumi Chimura
OKI Electric Industry Co.,Ltd.
e-mail:chimura730@ainet.oki.co.jp
Phone +81-3-3454-2111
FAX +81-3-3798-7684
Dear Q.11-14 Experts,
I have put a delayed contribution to September SG16 meeting as
ftp://standard.pictel.com/avc-site/Incoming/H450Comm.doc
The title is "Comments on the Recommendation H.450.1, H.450.2
and H.450.3".
In the Telecommunication Technology Committee(TTC) in Japan,
they generate their standards based on the ITU-T recommendations
considering national matter items and so on. Through their activity
related ITU-T H.450.1, H.450.2 and H.450.3, a number of problems
are found.
The …
[View More]contribution is prepared to discuss Implementers' guide.
But, I'm mistake a filename. Please ignore "H450Com.doc".
I will submit this contribution to ITU-T in a few days.
Best regards,
---
Yasubumi Chimura
OKI Electric Industry Co.,Ltd.
e-mail:chimura730@ainet.oki.co.jp
Phone +81-3-3454-2111
FAX +81-3-3798-7684
[View Less]
_Somebody must_ know the answers to this!
I have been looking at the source and destination address information in
H.323 version 2, and am feeling a little confused.
Perhaps someone can point me to something that will clarify the position.
Version 1 had a number of addressing fields, for both the source and
destination. Version 2 extends that in a number of areas, both as
additional fields for what I'll call the primary address, but also as
sequences of source and destination alternatives. …
[View More]It also introduces the
Endpoint IE, which contains a number of OPTIONAL address structures.
Referring to the Endpoint first, I notice that it contains both an
aliasAddress, and a destinationInfo. The descriptions for these elements do
not seem convincingly right. If the Endpoint refers to a destination,
presumably both (this endpoint and destination) are the same.
I also notice that Endpoint does not contain the new element
remoteExtensionAddress which has been added, as destination address
information, to both ACF and SETUP messages. If this is the number to be
dialled from a remote gateway, may it not be different for different
destination gateways? I think it could be, and so should also appear in the
Endpoint IE. I think that it should be an optional element in the ARQ as
well, if the source endpoint knows this information.
I also see that remoteExtensionAddress is a SEQUENCE OF in the ACF, but
only a single AliasAddress in the SETUP message. Why?
I assume that alternateEndpoints, in the ACF message, are alternates to be
tried in the event that the endpoint specified in the dest* elements
(priority 0) is not successful.
It gets more difficult when I look at the ARQ message. Can someone please
tell me what is the intention of the srcAlternatives and destAlternatives
elements?
If the purpose of srcAlternatives, in ARQ, is to allow for an endpoint that
has multiple possible identities, shouldn't ACF specify which identity is
confirmed, and which alternative to use in the SETUP message? To include an
OPTIONAL sourceAddress Endpoint in the ACF, would also allow a gatekeeper
to override or add source address information for the call.
On the subject of where authorisation tokens between source and destination
could be included in call setup, has anything been discussed or decided? By
that I mean a token of some kind, generated by the source gatekeeper and to
be relayed through the setup process to the destination gatekeeper, as
input to the destination admission determination.
Regards,
Douglas
[View Less]
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.…
[View More]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(a)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:
>
>1. 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
[View Less]
Dear Q.12-14/16 experts,
I have moved the following documents to
ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/
J Ott> H323-AnnexF-01a.zip
D Walker> h450_7_980831.zip
Best regards,
Sakae OKUBO (Mr.)
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830
Fax: +81 3 5287 …
[View More]7287
e-mail: okubo(a)giti.or.jp
***********************************************************
[View Less]
