Inclusion of H.323 Annex G in the main document
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 ties.itu.int>
To: <schandra at hss.hns.com>; Mailing list for parties associated with ITU-T
Study Group 16 <ITU-SG16 at mailbag.cps.intel.com>
Cc: h323implementors <h323implementors at imtc.org>
Sent: Wednesday, October 27, 1999 8:05 PM
Subject: Re: Call Clearing related
> 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,
> 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 hss.hns.com>
> To: <paul.jones at ties.itu.int>; Mailing list for parties associated with
> ITU-T Study Group 16 <ITU-SG16 at mailbag.cps.intel.com>
> Cc: h323implementors <h323implementors at imtc.org>
> 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
> > pregranted ARQs and the call is GK routed. If the GK closes the call
> > 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
> > the GK decides to poll the endpoint and gets no answer or negative
> > assumes that the call has been released. (But it may have serious
> > on billing.)
> > Question 2:
> > If the possibility (a) is TRUE, is the DRQ mandatory for a registered
> > 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
> > call signaling channel?
> > With regards,
> > Sunil Chandra
> > Hughes Software System
> for list subscription instructions,
> send email to h323implementors-request at imtc.org with text "info"
More information about the sg16-avd