Call Clearing related

Paul E. Jones paul.jones at ties.itu.int
Wed Oct 27 23:21:24 EDT 1999


Sunil,

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
TD-27.

Paul

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


> 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
> >
> >
>
> -------------------------------------------------------------------------
> for list subscription instructions,
> send email to h323implementors-request at imtc.org with text "info"
>



More information about the sg16-avd mailing list