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@ICN.Siemens.com -----------------------------------------------------------------

-----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Thursday, September 06, 2001 5:33 AM To: ITU-SG16@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@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com