Subject: [SIP] Comments on draft-ietf-sip-cc-transfer-04

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Mar 2001 10:56:55 +0000

I have read the above draft with interest and have a number of comments on
which I would appreciate opinions.

1. In 4.4.1 (unattended transfer without consultation) and elsewhere, an
INVITE (hold) sequence occurs before the REFER sequence. My assumption is
that this is not mandatory and that a server may accept a REFER request even
if not preceded by INVITE (hold). Is this assumption correct?

2. In 4.5.1 (unattended transfer with consultation, variation 1), call 2 is
cleared (BYE) before REFER is invoked. This has a number of implications:

*	From the viewpoint of the target user, his call is cleared and then
he experiences a new call arrival. This is a different experience from that
of a conventional telephone user, who generally expects his call to remain
in place even though the distant user changes. 
*	Although the nature of the user interface is outside the scope of
SIP, it is important that SIP be able to work with any reasonable user
interface that might be encountered, particularly in legacy equipment, e.g.,
a conventional telephone with a SIP adapter. In this case, the phone at the
target user may not become free and able to accept the new invite until the
user takes some action, e.g., replacing the handset. Therefore depending on
the speed of user response, the transfer may fail.
*	Between the clearing of call 2 and the arrival of the new call, the
target may become busy on a new incoming or outgoing call, and therefore the
transfer may fail.
*	Because call 2 is cleared before REFER is started rather than after
REFER completes, if REFER fails call 2 is lost and the transferor loses
contact with the target user. Some existing telephony systems may retain
communication between the transferor and target in this situation, allowing
for example apologies to be given.
*	The SIP entity representing the target may be a gateway to a
switched circuit network (SCN). The sequences shown in 4.5.1 might seem to
imply that call 2 would be cleared all the way to the target in the SCN.
This implies re-establishing the call through the SCN to the target when the
INVITE from the transferee arrives. Firstly this gives rise to the problems
in the bullets above. Secondly, it implies an ability to ensure that the
re-established call through the SCN reaches the same target. In some cases
this will be impossible, because the SIP network does not have sufficient
addressing information. For example, prior to the transfer attempt, call 2
may have been diverted or transferred within the SCN without the SCN
disclosing the new destination address to the SIP network. Even if the SIP
network does know the address of the target, there is no guarantee that the
SCN will route the call to that same target, e.g., it might forward it if
the target is busy.
*	An alternative is to clear call 2 only as far as the SIP entity
representing the target, i.e., as far as the gateway. This then gives a
problem how can the gateway link the new call from the transferee to the
retained leg of call 2 in the SCN. Also how long does the gateway wait for
this call to arrive before the gateway clears the remaining leg of call 2?
*	One way of overcoming these problems would be to retain call 2 and
provide some means of call identification so that the SIP entity
representing the target can associate the new INVITE from the transferer
with the existing call 2. Once this association has been achieved, call 2
can be cleared. The target address in the Refer-To header would need to be
that of the gateway.

3. In 4.5.2 (unattended transfer with consultation, variation 2), the
situation is not so very different. Although call 1 and call 2 are both
retained until after successful REFER, there are still the following
problems:

*	The new INVITE from the target to the transferee is in the "wrong"
direction and could lead to incorrect charging.
*	If the transferee is connected through an SCN, the new INVITE from
the target SIP entity could go either directly to the transferee in the SCN
or to the gateway SIP entity. To go directly to the transferee in the SCN
implies knowing the address of the transferee (not necessarily the case -
the SCN may not have disclosed the caller ID). It also may encounter a busy
condition at the transferee, who is still involved in call 1. Finally there
is a charging issue - who pays for the call?
*	Therefore it would seem that the new INVITE needs to go to the
gateway and link up with call 1 there, after which the SIP leg of call 1 can
be cleared. This again requires a means of associating the INVITE with call
1.

In conclusion, I believe that some sort of linkage mechanism is needed to
allow the new INVITE resulting from REFER to link up with the other existing
call. Firstly this would allow more flexibility for services using the REFER
method and would allow existing user experiences of call transfer to be
retained when they use a SIP network. Secondly it would allow transfer to
operate when the transferee or target is in an SCN.  The draft
biggs-sip-replaces-00.txt seems to be suggesting this sort of approach, but
I see no reference to this in the transfer draft.

--------------------------------------------------------------
John Elwell ([email-masked])
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the contents
of this message. Any views or opinions presented are solely those of the
author and do not necessarily represent those of Siemens Communications
Limited unless otherwise specifically stated.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Suheel Hussain <[email-masked]>
Date: Fri, 16 Mar 2001 14:33:15 -0500

John,
I think there is some confusion between actual REFER protocol and its 
usage. John the scenarios you have described is more relavant to how REFER 
can be used in telephony and elsewhere.

There were some emails about separating REFER method from its usage post 
draft-ietf-sip-cc-transfer-04.

> if not preceded by INVITE (hold). Is this assumption correct?
Correct. REFER does not specify that transferror has to put tranferee on 
hold. For voice, unless transferee has mixing capability hold may be 
necessary. But again it is a function of transaction type.

> cleared (BYE) before REFER is invoked. This has a number of implications:
I think example was to show that that transferror could quickly ping 
(INVITE immediately followed by BYE) the target before deciding to transfer 
the call. What transfer target does with this quick ping would be a 
function of co-located gateway (telephony??).

> I see no reference to this in the transfer draft.

I think from past emails, 'replaces' header for smooth call transfer is 
under discussion. See following snippet from Jonathan Rosenberg.

<--- deleted --->

| Subject: RE: [SIP] REFER feature with 'replaces' header
| Date: Wed, 14 Mar 2001 07:48:22 -0500
| From: Jonathan Rosenberg <[email-masked]>
| To: "'Venkatesh Venkataramanan'" <[email-masked]>,
|         Suheel Hussain <[email-masked]>, Billy Biggs<[email-masked]>
| CC: SIP List <[email-masked]>Regarding the original thread,
| usage of Replaces is still under debate, so I
| would warn people against shipping implementations of it at this time.
| REFER has nearly 30 minutes of discussion time at IETF 50, and this is
| one issue we need to tackle.
|
| -Jonathan R.
| ---
| Jonathan D. Rosenberg                       72 Eagle Rock Ave.

<---deleted---->

-- 

Suheel Hussain
[email-masked]
Work # (919) 392-2312