Frank,
The basic model for determining busy in H.450.x features is User Determined
User-Busy. That is, only the endpoint can truly determine if it is not able
to handle additional calls. It is easy for an endpoint to be equipped to
handle multiple call instances in a manner similar to keyset operation.
In the case of H.450.6 (Call Waiting), this is a destination endpoint
controlled feature. The destination endpoint is indicating that it can
handle an additional call. However there will be a short delay. If the
endpoint cannot handle the call, then it should indicate busy.
I fail to see the logic of having the destination GK process Call Waiting.
This denies the endpoint the ability to place the existing call on hold and
to process the new call.
>From an operational viewpoint, I fail to see how a FACILITY message can be
sent from the GK to the endpoint when there is no signaling path. In that
each call is independent, it is invalid to send signaling for a call on the
signaling path for another call. This signaling independence is key to the
handling of feature interaction between different calls.
Bob
--------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
5500 Broken Sound Blvd, Boca Raton, Fl 33487
Tel: +1 561 923-1756 Fax: +1 561 923-1403
Email: Robert.Callaghan(a)ICN.Siemens.com
-----------------------------------------------------------------
-----Original Message-----
From: Frank Derks [mailto:frank.derks@PHILIPS.COM]
Sent: Thursday, September 06, 2001 5:33 AM
To: ITU-SG16(a)mailbag.cps.INTEL.COM
Subject: H.450.6 and Gatekeeper actions
In many of the H.450 Recommendations, the Gatekeeper (in a GK-routed model)
can take on the role of one or more of the parties involved in a call and/or
supplementary service.
In H.450.6, however, this role is limited to the extent that the GK can only
act on behalf of the served endpoint towards the calling user. What this
means,
is that the call to the served user must always be propagated towards the
served ednpoint, to be able to _notify_ the served user about an incoming
call.
Since the GK (in the GK-routed) model knows that the served user is busy, it
may not want to propagate the new call to the served user, but it may also
want to be able to notify the served user the call. This does not seem to be
possible.
As a consequence of the reception of the call setup, the served endpoint may
invoke some supplementary service (e.g. CFB). This may create a situation of
undesired supplementary service interaction, in which both the served
endpoint
and the GK act on the situation.
One possible way out of this situation is to allow for the served endpoint
to
receive the callWaiting.Invoke in a FACILITY message from the GK. This
allows
the GK to notify the served user about the fact that there is a call waiting
and how many calls are waiting. It, however, does not provide the served
endpoint with sufficient information to be able to, e.g., pickup a specific
call!
Maybe it would be better to introduce a new operation
callWaitingNotification,
that can be used towards the served user and that will include information
(e.g. a list of the Calling Party number(s) and/or Alias(es)) of the calling
party(s)) that the served endpoint can use to refer to such a call.
Any views?
Regards,
Frank
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
