AW: H.450 support

Karl.Klaghofer at ICN.SIEMENS.DE Karl.Klaghofer at ICN.SIEMENS.DE
Wed Sep 22 05:52:32 EDT 1999


Alex,

The B side that does not support H.450 may just ignore the received
supplementary service request. I.e. ROSE at the originating side has to
figure out that the other side does not support H.450 (i.e. if no return
result, return error or return reject is received from B to a supplementary
service request).

Although the User-User Information element itself is mandatory, the
h4501SupplementaryService apdu is optional.   Even in Q.931, sending a
STATUS message in case of "optional, unrecognized Information elements
received" is just optional.   I.e., I recommend not to rely on receiving a
STATUS message from the B side in your scenario.
In a similar case - in case of optional information element received with
contents error - H.323 Implementers guide even requires to just ignore the
IE (but act on the rest of the message).

Note: If at least H.450.1 is supported by the B side, then B has to respond
according to the "interpretation apdu" setting.


Karl Klaghofer

> -----Ursprüngliche Nachricht-----
> Von:  Alex Chatilov [SMTP:achatilov at email.msn.com]
> Gesendet am:  Donnerstag, 16. September 1999 07:57
> An:   ITU-SG16 at mailbag.cps.intel.com
> Betreff:      H.450 support
>
> Hello,
>
> I have a question about how to detect does remote endpoint supports H.450
> (without using a timer)? Is it clear that receiving endpoint has to replay
> with a STATUS message in case when it receive an H.450 related FACILITY
> message?
>
> Assume that we have:
>
>      Originator side sent:
>      --------------------
>
>      FACILITY
>       FacilityIE
>       (length=0)
>        ...
>       User-UserIE
>        H323-UserInformation
>         h323-UU-PDU
>          h323-message-body = empty
>           ...
>          h4501SupplementaryService
>          (H.450.x request)
>           ...
>         ...
>        ...
>
> Remote side received FACILITY, here is no
> support for H.450, so we will respond with
> STATUS message where the causeIE  =
>        100 (invalid IE contents), or
>        99 (Information element/parameter non-existent
>        or not implemented), or
>        97 (Message type non-existent or not implemented)
>
>        STATUS
>        ...
>        CauseIE
>         ...
>         cause       = XX
>         diagnostics = YY
>         ...
>
> Am I right?
>
> Thank you,
> Alex



More information about the sg16-avd mailing list