We must consider two cases:

First case: a secondary call exists. Here the new call from the transferred endpoint is to replace an existing call which is identified by the callIdentity value in the callTransferSetup invoke APDU. It is essential that the transferred-to endpoint matches the new call and the existing call, accepts the ne and releases the old call. Otherwise, if the new call is treated just as another basic call, the called user may be considered busy (with the old call).

Second case: No secondary call exists ("single step transfer"). Here the requirement could be relaxed, the new call could be treated as just a basic call if callTransferSetup is not understood. This would be the case anyway if H.450.1 is also not supported. The main consequence would be that the additional information about the call having been transferred is lost. Of course, also with the existing H.450.2, the transferred endpoint can always repeat the SETUP without a callTransferSetup APDU when the first SETUP fails.

Ernst Horvath Siemens AG maito: ernst.horvath@siemens.at

-----Ursprüngliche Nachricht----- Von: Espen.Skjaeran [SMTP:Espen.Skjaeran@ERICSSON.COM] Gesendet am: Dienstag, 23. März 1999 20:44 An: ITU-SG16 Cc: Espen.Skjaeran Betreff: Call Transfer

Hi,

I have a specific question to H.450.2 Call Transfer. -Why do the transferred-to endpoint have to support the service?

Section 6 of H.450.2 states "When conveying the invoke APDU of operation callTransferSetup, the Interpretation APDU shall contain value clearCallIfAnyInvokePduNotRecognized" which I find to mean "if you don't support the service, forget it"

The session between the transferred and the transferred-to endpoint follows a basic call, and no useful information is returned in the ctSetup. result operation. Why can't it be "dumb" and only believe it is doing a basic call? Isn't the receipt of ALERTING/CONNECT instead of RELEASE COMPLETE acknowledgement enough that the transfer was successfull?

Anyone to clear up this?

Thanks, Espen