AW: Call Transfer
ernst.horvath at SIEMENS.AT
Wed Mar 24 04:58:21 EST 1999
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
maito: ernst.horvath at siemens.at
Von: Espen.Skjaeran [SMTP:Espen.Skjaeran at ERICSSON.COM]
Gesendet am: Dienstag, 23. März 1999 20:44
Betreff: Call Transfer
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
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?
More information about the sg16-avd