Inclusion of H.323 Annex G in the main document

Gunnar Hellström Gunnar.Hellstrom at OMNITOR.SE
Thu Oct 28 03:02:57 EDT 1999


It was just pointed out to me that I referred to the wrong document number
in my previous e-mail.  The document I intended to refer to is TD-17, not


----- Original Message -----
From: Paul E. Jones <paul.jones at>
To: <schandra at>; Mailing list for parties associated with ITU-T
Study Group 16 <ITU-SG16 at>
Cc: h323implementors <h323implementors at>
Sent: Wednesday, October 27, 1999 8:05 PM
Subject: Re: Call Clearing related

> Sunil,
> Sorry for the delayed response.  I was attending the ITU Rapporteur's
> meeting last week and am just now catching up on e-mail.
> I do not think it is legal for the endpoints to close the call signaling
> channel when routed through a GK.  Section 7.3.1/H.323 states that "Only
> Gatekeeper shall close the Call Signalling Channel and it should not be
> closed when a Gateway is involved in the call".  Endpoints are allowed to
> close the channel when connected directly to one another.
> Prior to fast connect, this was not such a big issue from a specifications
> point of view, although I know most people do not support the closure of
> call signaling channel-- they drop the call.  Prior fast connect, the call
> was still considered to be active even with the call signaling channel
> closed, since the H.245 connection then represented the call.
> However, with the introduction of Fast Connect, this is an issue.  There
> no supporting text that says that an endpoint using fast connect cannot
> close the call signaling channel (anybody-- correct me if I am wrong).
> closure of the call signaling channel would result in a total drop of the
> call, as one cannot rely on the RTP streams to indicate call activity in
> H.323 (silence suppression in some endpoints, for example, is indicated by
> sending absolutely no RTP traffic).
> So... I contend that this feature is "broken" and that the call signaling
> channel should never be closed.  Not only is this a problem area, but
> closing the call signaling channel means that one cannot use supplementary
> services, etc.  There is no defined way to "re-establish" the call
> channel, etc.
> During the meeting last week, I presented a document that outlined the
> changes to be made to prevent the closure of the call signaling channel.
> was not accepted, but I intend to continue my effort.
> Best Regards,
> Paul
> PS- My proposal is available here:
> Feel free to review it and make comments to me so that I can prepare a
> (potentially) better one next time!
> ----- Original Message -----
> From: <schandra at>
> To: <paul.jones at>; Mailing list for parties associated with
> ITU-T Study Group 16 <ITU-SG16 at>
> Cc: h323implementors <h323implementors at>
> Sent: Saturday, October 23, 1999 5:10 PM
> Subject: Call Clearing related
> >
> >
> > Dear Paul,
> >
> > Question 1:
> >
> > This is specifically in regards to call clearing in which both endpoints
> have
> > pregranted ARQs and the call is GK routed. If the GK closes the call
> signalling
> > channel, how would the GK know of the call clearing?
> >
> > possibilities :
> > a) both endpoints send a DRQ (even if they have pregranted ARQ).
> > b) GK peeps into the H.245 channel and treats the EndSessionCommand as
> > request for call clearing.
> > c) (Assuming that GK has requested for IRRs.) On detection of 'n' missed
> IRRs,
> > the GK decides to poll the endpoint and gets no answer or negative
> Gk
> > assumes that the call has been released. (But it may have serious
> implications
> > on billing.)
> >
> > Question 2:
> > If the possibility (a) is TRUE, is the DRQ mandatory for a registered
> endpoint
> > whether it has sent ARQ or not and whether it sends a subsequent RELEASE
> > COMPLETE or not.
> >
> > Question 3:
> > If the possibilty (c) is TRUE, should it not be mandatory to specify
> > irrFrequencyInCall in either ACF or RCF, if the GK does not want to
> the
> > call signaling channel?
> >
> > With regards,
> > Sunil Chandra
> > Hughes Software System
> >
> >
> -------------------------------------------------------------------------
> for list subscription instructions,
> send email to h323implementors-request at with text "info"

More information about the sg16-avd mailing list