Subject: RE: [SIP] REFER revision

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Sat, 3 Feb 2001 17:48:52 -0800

To start with, a couple of small oversights in the document.

Call flow 4.5.2 : Protects transfer target.

1/ I would think that the 200 level response for REFER issued by Transfer
Target should read 200 OK (it says 200 trying).

2/ The response for NOTIFY (refersuccess) should go to the transfer target
and not to the transferee.

I had some questions for which some clarifications would help.

Section 4.2 Requirements:

I think the statement saying "the draft preserves current transfer
experience" is not totally true. I do see that end user experiences are
indeed quite different in the two cases 

First of all, todays transfer don't request the transferee if it should
proceed with a transfer request(although the doc says that one might
over-ride this with configuration). 

Two, as regards billing (I am sure that this statement is going to cause
people to beat me up, but nevertheless here I go :-)), the transferee ends
up paying for the transferred call leg, quite untrue in the current PSTN
world.......

Three, based on the type of transfer (protect target, exposes target) et al,
call flows/messages exchanged are totally different, so I would imagine that
an UA would have to prompt the end user what type of transfer he/she intends
to perform, protect transfer target, expose transfer target et al, unless an
UA is hardcoded to perform only one type of transfer "all" the time(which is
again different in current transfer call scenarios where a user can perform
any type of transfer that he/she desires to, and may be convert that to a
conference later).

So also, in the call flow where the transfer target's number is not
protected, the transfer target first gets a call from the transferor, he/she
has to hang up and then a answer a new call from the transferree to get
connected, not quite the way current PSTN transfers work. I don't know how
an UA "may" preserve the end user experience here? 

So, based on all of these, I think we should remove the paragraph which says
"call flows preserve current end user experience" ! 

Finally, I wouldn't know how one would implement the the same, if gateways
that spoke SIP on one end, and provided analog end points on the other were
on the transferee side of the call(or on the transfer target side in case
where the transfer target was to be protected). Meaning, would gateways be
able to preserve end user experience? Manage multiple sessions, speech
paths, et al for a single call? Think Rohan said he knows of one that does
it :-), but just getting a re-assurance from others on this list as well....

Just my two cents.

Venkatesh

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Friday, February 02, 2001 2:33 PM
To: [email-masked]
Subject: [SIP] REFER revision

Here is REFER using NOTIFYs from implicit Subscriptions
to get around the transaction timeout problem. I've submitted
this to the draft repository, but wanted to get it into
the hands of those attending next week's meeting as early
as I could.

RjS

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer'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 sip-implementors" in the body.

---

From: Robert Sparks <[email-masked]>
Date: Sun, 4 Feb 2001 22:20:17 -0500

> From: Venkatesh Venkataramanan
> 

Fixed - thanks!

RjS