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@email.msn.com] Gesendet am: Donnerstag, 16. September 1999 07:57 An: ITU-SG16@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