MSCs in H.450.5

Frank Derks frank.derks at PHILIPS.COM
Thu Sep 6 05:35:22 EDT 2001

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

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

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?



For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list