Call Transfer

[Wuerfel, Randy P]

See the modifications proposed below to Karl's Implementor's Guide text for
Endpoint B exceptional procedures.
==========================================================
Randy Wuerfel
Enterprise Network Systems Development
Unisphere Solutions, Inc.               E-mail:
Randy.P.Wuerfel at icn.siemens.com
4900 Old Ironsides Drive                Fax: (408) 492-4666
M/S 200                         Tel: (408) 492-4375
P.O. Box 58075
Santa Clara, CA 95052-8075


-----Original Message-----
From:   Klaghofer Karl ICN IB NL IP 7 [mailto:Karl.Klaghofer at ICN.SIEMENS.DE]
Sent:   Friday, March 26, 1999 2:33 AM
To:     ITU-SG16 at mailbag.cps.intel.com
Subject:        AW: Call Transfer

Transfer with Consultation:
As Ernst pointed out, we need the ctSetup Invoke as it is defined in case of
Transfer with Consultation.
Transfer without Consultation (i.e. no secondary call exists):
Some history:
H.450.2 has chosen to use the same operation (ctSetup Invoke) in both cases.
Transfer with and Transfer without Consultation in order to avoid having
different procedures / state events within endpoint B for those two cases
(with and without Consult).  However, the point Espen raised is a valid
question.
We should put some exceptional procedure handling to the implementors guide
(based on the suggestions made by Ernst) that clarify the usage of Transfer
without Consultation in conjunction with an endpoint C that does not support
Transfer.
If endpoint C does not support H.450 at all, a basic call ALERTING, CONNECT
would be received in endpoint B.  This would lead to a FACILITY with
ctInitiate Return error being sent to A (since ctSetup operation needs
explicit confirmation).  Endpoint B would end up with two calls A and C.  To
avoid this, the implementors guide should state some exceptional procedure
handling that would apply to Transfer without Consultation (i.e. no
secondary call exists).

"
Endpoint B exceptional procedures:
a)      When receiving an ALERTING or CONNECT message from endpoint C (that
does not include a response to the ctSetup Invoke) while being in state
CT-Await-Setup-Response, the transferred endpoint B shall (or may ?)
continue as if a ctSetup Return Result had been received.  This allows
endpoint B to successfully continue with the Call Transfer procedures (i.e.
appropriate internal call transfer state handling and clearing of the
primary call to the transferring endpoint A).  This exceptional procedure
enables successful Call Transfer when the transferred-to endpoint C does not
support H.450.
b)      When a RELEASE COMPLETE message is received (possibly containing a
ctSetup return error APDU) in response to a SETUP message that contained a
ctSetup Invoke sent by endpoint B (which happens if endpoint C supports
H.450.1, but not H.450.2), then endpoint B may retry call establishment to
endpoint C using a normal basic call (i.e. by sending a SETUP message
without a ctSetup invoke APDU).  Upon receiving an ALERTING or CONNECT
message from endpoint C on this new call, the procedures as described above
in a) shall apply.
"

Remark: If endpoint C supports H.450.1 but no H.450.2, I would NOT start
ignoring the i-apdu "clear call". I-apdu always shall be honoured (if
H.450.1 is supported), since C does not know that this is about call
transfer (so it can not really be an exceptional procedure as part of a Call
Transfer standard). This would cause problems when further supplementary
services are inroduced that also use i-apdu "clear call".


Any comments ?
Regards,
Karl Klaghofer
Siemens AG

        ------------------------------------------------------

The simplest option is to just relax the 'clearCall' requirement in case of
single-step transfer. The effect would be that a ctInitiate error is
returned to user A and the primary call is not cleared. User B would have
two calls to handle.
Another alternative is the simple option plus adding the clearing of the
primary call to the exceptional procedures for the transferred endpoint.
This leaves a clean situation for all users, with B and C having an active
call.
        For the consultation case H.450.2 should stay as it is.


        > -----Ursprüngliche Nachricht-----
        > Von:  Ernst Horvath [SMTP:ernst.horvath at SIEMENS.AT]
<mailto:[SMTP:ernst.horvath at SIEMENS.AT]>
        > Gesendet am:  Mittwoch, 24. März 1999 10:58
        > An:   ITU-SG16 at mailbag.cps.intel.com
<mailto:ITU-SG16 at mailbag.cps.intel.com>
        > Betreff:      AW: Call Transfer
        >
        > 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 at siemens.at <mailto:ernst.horvath at siemens.at>
        >
        >
        >
        > -----Ursprüngliche Nachricht-----
        > Von: Espen.Skjaeran [SMTP:Espen.Skjaeran at ERICSSON.COM]
<mailto:[SMTP:Espen.Skjaeran at 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