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

From: Rick Dean <[email-masked]>
Date: Thu, 1 Feb 2001 00:45:13 -0600

On Wed, Jan 31, 2001 at 08:32:43AM -0800, Rohan Mahy wrote:
> 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.

Agreed.  For many advanced PBX features the switchhook+DTMF 
interface sucks.  In this case the legacy PSTN paradigm
is not DTMF.  Digital PBX phones use additional
keys and a display.

--
Rick

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