GK-handled call diversion.

Korpi Markku PN VS LP3 Markku.Korpi at PN.SIEMENS.DE
Wed Mar 11 13:33:32 EST 1998


See my in-line comments below:
--Markku Korpi

>-----Original Message-----
>From:  Michele Bozier WVdevmt-WS [SMTP:mbozier at MADGE.COM]
>Sent:  Wednesday, March 11, 1998 6:19 PM
>To:    ITU-SG16 at mailbag.jf.intel.com
>Subject:       Fwd:  GK-handled call diversion.
>
>Hi all,
>
>I have a question about the H450.3 Call Diversion recommendation when the
>gatekeeper handles the diversion.
>
>Figure 12 in section 10 shows the signalling flow for Call forwarding
>unconditional being handled by a gatekeeper.  My concern is that the figure
>shows the gatekeeper informing the 'called' user that the call has been
>diverted away from it, using an H.225 Setup message.   In order for this not
>to create confusion, the gatekeeper must know that the called user
>understands H450.2  (e.g. if the called user were a Version 1 endpoint then
>it would surely wrongly interpret this Setup as an incoming call).
>[MKo]  The Notification Setup of H.450.2 contains in the Bearer
>Capability/Octet 3  "call independent signaling connection". Since the BC is
>a mandatory IE in H.323 version 1,  the correct response should be Release
>Complete message with Cause=Mandatory information element error. Therefore
>the interpretation of the Notification as an incoming call is not legal
>according to H.323 V.1.
>
>The text in the standard which relates to the sending of this information to
>the called user (H450.2 APDU divertingLegInformation4), states that this
>message is sent by the gatekeeper only if the option 'served user
>notification' applies.  As far as I can see, this option is a local
>configuration matter at the served endpoint.  My question is, how does a
>gatekeeper work out whether or not this option is set in a standard way?
>[MKo]  The GK would have some network management functions, by means of which
>the local configuration can be influenced either by the user or by the
>network manager or by both.
>Therefore we do not need signaling capabilities in the H.450.3 for this
>purpose.
>
>Thanks for your help
>Michele
>----------------------------------------
>Michele Bozier
>Principal Development Engineer
>Madge Networks, Wexham Springs, Framewood Rd, Wexham,
>Slough SL3 6PJ, England
>Tel: +44(0)1753 661331  Fax: +44(0)1753 661011
>email:mbozier at madge.com




More information about the sg16-avd mailing list