Red Bank Meeting Minutes
Zacharias.Bilalis at ICN.SIEMENS.DE
Thu Oct 28 07:06:42 EDT 1999
I support the intention, but I can understand why TD-17 would have had
I don't know of anybody closing the call-signalling channel while trying to
keep up calls, but I don't (and wouldn't expect to!) know about all products
everybody in the world is working on, and it's tricky with the ITU to introduce
something that will make future versions potentially incompatible with earlier
With the TD-17 text, an implementor of a new device would be justified in
believing that closure of a call-signalling channel without ReleaseComplete
was always an error condition and hence that it should consider the call over.
The fact that at least some endpoints do this anyway is irrelevant - THEY are
not compliant with current versions of the recommendation.
However we can get round this, by the old adage of about being strict about
what you send and flexible about what you receive - in other words it needs to
be made clear that:
A v4 (or should I be talking about v5 yet?)-compliant device shall not close
the call-signalling channel without sending ReleaseComplete and closing the
In the event of the call-signalling channel being closed during a call, if:
a) there is an active connection-control (H.245) channel AND
b) no ReleaseComplete has been sent or received
THEN no error should be considered to have occurred and the call should
continue until EndSession is sent or received on the H.245 channel or the H.245
channel is closed.
I believe that this way we don't break interoperability with devices compliant
with current versions of the recommendation, while stopping closure of the
call-control channel in future (which will, for example, murder supplementary
services, as you say).
Incidentally, fast connect is a red herring in my opinion. If there is no
separate H.245 channel then closing the call-control channel already terminates
IF anybody objects to the intention that future endpoints shall not close
call-signalling wihtout closing the call could they PLEASE voice their
opinions on this mailing list!
A technical question on the second paragraph of your mail: how do endpoints
KNOW that they're connected directly rather than through a gatekeeper, in order
to decide whether they can (under the current system) drop the call-signalling
"Paul E. Jones" wrote:
> 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 the
> 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 the
> 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 is
> no supporting text that says that an endpoint using fast connect cannot
> close the call signaling channel (anybody-- correct me if I am wrong). This
> 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 signaling
> 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. It
> 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 the
> > 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 answer,
> > 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 retain
> > call signaling channel?
> > With regards,
> > Sunil Chandra
> > Hughes Software System
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire. RG42 6LY ENGLAND
Phone: +44 1344 899 007
Fax: +44 1344 899 001
More information about the sg16-avd