Corrections (It is LRQ [not ARQ])

Roy, Radhika R, ALTEC rrroy at ATT.COM
Sat Aug 29 13:34:52 EDT 1998


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 at 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
> 1.
> 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 at 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 at MAILBAG.INTEL.COM
> > Subject:      Re: ARQ/ACF
> >
> > Hi Radhika:
> >
> > You wrote:
> >
> > 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).
> >
> > 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
> >
>



More information about the sg16-avd mailing list