Subject: [Sip] SIP Transfer Failure

From: Huybrighs Joseph <[email-masked]>
Date: Fri, 7 May 2004 12:58:38 +0200

Both draft-ietf-sipping-cc-transfer-02 and
draft-ietf-sipping-service-examples-06 not really describe how the
Transferor, after having invoked transfer, can be re-invited in case the
transfer failed (e.g.  the Transfer-Target failed to answer, wrong address
in case of a blind transfer, etc.).

Consider the following scenario:
A establishes a dialog with B.
B transfers to C.
The dialog between A and C terminates with a 4xx.

Solution from draft:
	B                        A                  C
	| (D1) REFER/202         |                  |
	|----------------------->|  INVITE/18x      |
	|                        |----------------->|
	|                        |  4xx             |
	| (D1) NOTIFY (4xx)/200  |<-----------------|
	|<-----------------------|                  |
	| (D1) BYE/200           |                  |
	|----------------------->|                  |
	|                        |                  |
	| (D1) re-INVITE/200     |                  |
	|----------------------->|                  |
	|         RTP            |                  |
	|<---------------------->|                  |
The proposal puts the responsibility to re-connect A and B on the
Transferor.
This works fine in case the Transferor still has an established dialog with
the Transferee and an active User Interface that keeps track of what
happened with the transfer request. Depending on the type of device the
Transferor is using, this will not always be the case. E.g. if the
Transferor is using a simple POTS phone, the transfer might have been
initiated by going on hook during the consultation call with C.
To get the Transferor back to the Transferee we will have to ring the
Transferor's phone.
This is not obvious with the proposed solution.   

Alternative Solution:
	B                        A                  C
	| (D1) REFER/202         |                  |
	|----------------------->|  INVITE/18x      |
	|                        |----------------->|
	|                        |  4xx             |
	| (D1) NOTIFY (4xx)/200  |<-----------------|
	|<-----------------------|                  |
	| (D1) BYE/200           |                  |
	|----------------------->|                  |
	|                        |                  |
	| (D2) INVITE/18x/200    |                  |
	|<-----------------------|                  |
	|         RTP            |                  |
	|<---------------------->|                  |
I would think that re-connecting the Transferor back to the Transferee is a
feature that has to be controlled by the Transferee. This is indicated in
the above diagram by the A party sending an new INVITE request to B
resulting in the creation of a new dialog (D2). The original dialog (D1) can
then be terminated when a final response is passed through the NOTIFY
request.
It also nicely solves ringing the Transferor when he or she would have gone
on-hook before the transfer request finished. E.g. the A party being the
initiator of the new 'call' would get ring-back tone if it is a POTS phone.

Does this make sense?

Jos Huybrighs
Siemens

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip