Paul, I support the intention, but I can understand why TD-17 would have had problems. 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 versions. 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 call. But... 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 the call. 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 channel? Regards, Chris "Paul E. Jones" wrote:

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 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, Paul

PS- My proposal is available here: ftp://standard.pictel.com/avc-site/9910_Red/TD-27.zip 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@hss.hns.com> To: <paul.jones@ties.itu.int>; Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16@mailbag.cps.intel.com> Cc: h323implementors <h323implementors@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 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 the 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 answer, 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 retain

have the

...

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