Subject: RE: call clearing by GK

From: [email-masked]
Date: Wed, 10 Mar 1999 10:26:09 +0530

Hi All,
      I agree with Santo.
In case of normal scenario, when GK had received ARQ, then GK can release
the call using DRQ, irrespective of the call model. In this case, GK has
all the info about CRV and other parameters.

In case of preGranted Arq, two cases are direct model and GK-routed model.
In case of direct model, because neither ARQ was received not any call
signalling message, so there is no point of GK trying to disengage the call
(As Chris pointed out.) because GK is not even aware of the call. In other
GK-routed model, because GK does not know CRV and other essential
parameters, it can not send DRQ. As "whether RAS CRV and call siganlling
CRV have to be same or not", is still not clear, GK can not bank on Call
Signalling CRV to send DRQ. So Release Complete is the only option left to
release the call. Moreover there are other scenarios also where GK can send
Release Complete to any of the endpoint, involved in the call (like
mandatory elements missing in a message etc.), so from feasibility and
possiblity point of view this should not be an issue. Moreover according to
the scenario given by Santo, B can receive release Complete sent by A and
relayed by GK. In my opinion, endpoint B is transparent to whether Release
Complete was initiated by endpoint A or GK.

Thanks,
Ritu.

Santo Wiryaman <[email-masked]> on 03/10/99 01:16:49 AM

Please respond to Santo Wiryaman <[email-masked]>

To:   [email-masked]
cc:
Subject:  RE: call clearing by GK

Hi Srini,
The key word in section 8.5.3 is "may".  Furthermore, the section refers to
Figure 34 which suggests a Direct-routed GK, in which case sending a DRQ is
the only thing the GK can do.  In a GK-routed case, the GK may also send
ReleaseComplete first, instead of a DRQ, in my opinion.
Consider A is in a call with B through GK (GK-routed).  When A initiates
the
disconnect, the following may take place:
1. A sends H.245 EndSession to GK
2. GK "relays" the EndSession to B
3. A sends ReleaseComplete to GK
4. GK "relays" the ReleaseComplete to B
5. A sends DRQ to GK
6. B sends DRQ to GK
The point is, endpoint B must handle a disconnect procedure that is
initiated by A. Therefore, the GK should be able to disconnect B using the
same sequence as if the the disconnect had been initiated by A.
Regards,
Santo Wiryaman
VideoServer Inc.
[email-masked]
> -----Original Message-----
> From:   [email-masked] [SMTP:[email-masked]]
> Sent:   Tuesday, March 09, 1999 2:15 PM
> To:     [email-masked]; [email-masked];
> [email-masked]
> Subject:     Re: call clearing by GK
>
> Please find my comments inline.
>
> thanks,
> Srini
> Trillium Digital Systems, Inc.
>
>
> >
> > Oops!
> > Sorry about the blank response!  Let's try again!
> >
> > This isn't QUITE as simple a question as it looks.
> > I'd recommend looking at it from the two separate points of view:
> > >From the endpoint's point of view, I would say the answer is "yes" (as
> Ritu
> > says).  A gatekeeper is allowed to send you a DRQ to clear the call.
> > Depending on how the endpoint is written, though, this may not be
> trivial to
> > achieve, since without pregranted ARQs it is reasonable for an endpoint
> to
> > want to match up DRQs with individual ARQs.
> >
> > As a gatekeeper, though, I wonder why one would want to implement that.
> For
> > the gatekeeper to be aware of a call when using pregranted ARQs, it
must
> be
> > routing call signalling, so it can quite happily terminate the call by
> means
> > of ReleaseComplete - which will NOT break poorly written endpoints.
> >
> > The related question is whether an endpoint sends a DRQ on "normal"
call
> > termination in these cases.  If the gatekeeper is routing
> call-signalling it
> > is arguably unnecessary (ReleaseComplete clears the call); if not, then
> > potentially the first the gatekeeper knows about the call is the DRQ at
> its
> > end (not useful!)!  Note that H.323v2 section 8.5.2 assumes that ARQ
has
> > happened at the beginning of the call, so behaviour where this is
absent
> > (due to pregranted ARQ) is arguable.
>
>
> In normal case, where ARQ happend at the beginning of the call, H.323V2
> section 8.5.3 clearly says GK may terminate the call by sending DRQ and
> endpoints shall follow the steps 1-6 of section 8.5, where the step
> 6 is sending the Release Complete. Hence, IMO, GK shall not send Release
> Complete to clear the call in normal case, it shall use DRQ. In the
> preGrantedArq case, I agree with Chris that sending Release Complete is
> one possible way to clear the call by GK.
>
>
>
> >
> > This leaves a question mark over the use of the other call-specific RAS
> > message, BRQ.  Bandwidth issues with pregranted ARQs are discussed in
> both a
> > contribution and a TD from the recent Monterey meeting (I forget the
> > numbers).
> >
> > Regards,
> > Chris
> > --
> > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
> > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
> ENGLAND
> > Phone: +44 1753 661 359  email: [email-masked]
> -------------------------------------------------------------------------
> for list subscription instructions,
> send email to [email-masked] with text "info"