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

From: Rohan Mahy <[email-masked]>
Date: Wed, 31 Jan 2001 08:32:43 -0800

Rick Dean wrote:
>> > > 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.

A couple years ago we went through the feature books of the leading PBX
brands, and asked the question "What was the customer need behind this
feature?".  For all the user-initiated features, we came up with some
pretty hideous interfaces to invoke these features (that we do not want to
reproduce), but concluded that customers still need/want to setup many of
the same call-leg relationships.

We absolutely want beter ways (UIs) to invoke features (and I have found
customers); we want general primitives instead of a monolithic blob of
"features"; but the customer experience of what happens when someone
invokes the "transfer" thing should be familiar.

Rick is right about one critical element--prompting.  A basic philosophy of
a call is that you get to change your end of the call as much as you like.
The other parties can stay in the call, disconnect, or change their end as
well.  Real-time prompting is not/should not be a part of equation.  Note
that this doesn't have anything to do with the method name.  A prompt for a
REFER is just as scary as a prompt for a HANDOFF.  Rick and Billy didn't
like my REFER Music on Hold flow because it took back a call.  According to
the current philosophy this should be fine in certain
circumstances--without prompting.  If you don't agree that prompting is an
impediment, try turning on manual cookie prompting for about an hour of web
surfing.

We should ask the question, "Why am I asking the user for permission?"  If
wecan come up with default rules of fair play for UA, the user should only
be prompted in extraordinary circumstances, or not at all.

thanks,
-rohan

>> > > 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.

_______________________________________________
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.