Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt

From: Ben Campbell <[email-masked]>
Date: Mon, 29 Jan 2001 16:00:54 -0500

Sorry for the lateness of my comments. I just came back from back to back
vacation and flu.

I am concerned about the statement that a UA should automatically process a
HANDOFF without asking the user. This seems dangerous to me; I envision a
scenario where someone calls me, then transfers me to a billable service
without my consent. 

I did notice the section about being able to administratively block such
things at a proxy. I am still thinking about whether that is sufficient
protection, as it would require some level of administrative forethought. I
suspect we would find a lot of cases of closing the barn door after the
horses have left.

I realize you added this requirement because of timing issues, but it seems
to be a rather harsh presumption of decisions that at least sometimes should
be left to the user.

> -----Original Message-----
> From: Rick Dean [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2001 12:27 PM
> To: [email-masked]
> Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 
> Dear SIP list,
> 
> Although we would like more time to 
> edit this poor draft, we feel a sneak
> peek is warranted due to its urgent nature
> with the upcomming meeting.
> 
> http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> 
> Some significant differences from REFER are:
>   * narrower scope
>   * method completes without prompting
>   * referred-by like header generated by transferee
>   * location of headers for spawned invite
>   * error processing & final notification
> 
> Cheers,
> Rick
> [email-masked]
> 
> 
> _______________________________________________
> 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.
> 

_______________________________________________
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: Rick Dean <[email-masked]>
Date: Tue, 30 Jan 2001 11:13:39 -0600

Amazon does sessions by a fake directory at the end of
URL's.  This technique has the advantage of never eliciting
a dialog box for any browser with any setting.  Please 
do not underestimate how unfamiliar* an end user can be.

If a UA is worried about destinations which badly handle
INVITEs with "handoff" headers.  That UA should deny 
HANDOFFs.  This will force the transferor to B2BUA, try
another strategy, or give up.  If the transferee already
pops up a message this is too late, and transferors
will B2BUA to begin with.  

We predict frequently the HANDOFF will be intercepted
by a B2BUA call controller and thus hidden from the 
transferee.  This is for privacy and reliability considerations,
and works most like the existing PSTN.

We confess, our goal is to build a transfer which works exactly
like the existing phone system, but happens to use SIP.  When
we complete this task, feel free to build a phone system
which works differently.  We hope you find some customers.

Yes, proxies should be able to administratively block
HANDOFF requests like any other.  Good point.  Do we need another 
sentence to cover this?  Are you proposing a special header or 
response code to indicate the proxy and not the end UA blocked it?
Does it make a difference to the HANDOFF sending UA?

We already have another method which is "prompt the remote human".
REFER to a web page does this best.  An audible
question does not need a SIP extension.  

Wouldn't the REFER request to a web page need two promptings?  
The first one is do you want to follow the URL and the second is the 
question on the web page.  I can do more damage
with a HTTP GET than a SIP INVITE, but most browsers follow 
302 redirects automatically anyway.

BTW, I am scared of what
a REFER with method=REFER prompt would look like to an end
user.  Clearly, the designers don't intend this.

Yes, sophisticated UA's with 19" monitors in expert mode will defy the 
draft and prompt the user.  It is their choice, and the IETF tries hard
not to mandate this behavior outside the protocol.  Hopefully the 
UA will prompt after the HANDOFF final response, but before the 
handoff-status, for timing reasons as you stated.

Thanks for the feedback.  

--
Rick
3Com

P.S.  I will be largely unreacable from Feb 1-6 due to
a vacation.  (Jackson Hole Wyoming :-)