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