Call Clearing related

Paul E. Jones paul.jones at ties.itu.int
Wed Oct 27 20:05:09 EDT 1999


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 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
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 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
the
> call signaling channel?
>
> With regards,
> Sunil Chandra
> Hughes Software System
>
>



More information about the sg16-avd mailing list