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