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 choosen 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 a CONNECT 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 would have 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 even if the transferred-to endpoint C does not support H.450 at all. b) When a RELEASE COMPLETE as a response to ctSetup Invoke is received in endpoint B on the new call (which happens if the endpoint C supports H.450.1 but not H.450.2), then the endpoint B may retry call establishmet to endpoint C using a normal basic call. Upon receiving CONNECT from endpoint C, 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.
participants (1)
-
Klaghofer Karl ICN IB NL IP 7