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

From: Robert Sparks <[email-masked]>
Date: Wed, 7 Feb 2001 15:07:23 -0500

Rick - characterizing the requirement to request
permission from the user before proceeding as
doing some form of interactive query is misleading.

The REFER draft (in fact, the original TRANSFER draft)
states:
      A UA receiving a well-formed REFER request
      SHOULD request approval from the user to
      proceed (this request could be interactive
      or through configuration). 

The parenthetical comment is there for a reason. 
Current generation clients will have configured
policy that grants this approval, then next round
will have at least that and maybe, hopefully, 
something more.

RjS

> -----Original Message-----
> From: Rick Dean [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 11:14 AM
> To: Ben Campbell
> Cc: [email-masked]
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 
> 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 :-)   
> 
> On Mon, Jan 29, 2001 at 04:00:54PM -0500, Ben Campbell wrote:
> > 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.
> 

_______________________________________________
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: Billy Biggs <[email-masked]>
Date: Wed, 7 Feb 2001 16:40:05 -0500

Robert Sparks ([email-masked]):

> Rick - characterizing the requirement to request permission from the
> user before proceeding as doing some form of interactive query is
> misleading.
>
> The REFER draft (in fact, the original TRANSFER draft) states:
>       A UA receiving a well-formed REFER request SHOULD request
>       approval from the user to proceed (this request could be
>       interactive or through configuration). 
> 
> The parenthetical comment is there for a reason.  Current generation
> clients will have configured policy that grants this approval, then
> next round will have at least that and maybe, hopefully, something
> more.

  We should rephrase it to say that any policy decisions must not ever
be interactive, but may be subject to local configuration policy.

  However, unlike your REFER draft, a HANDOFF (MOVE? TRANSFER?) is
useless if it cannot be performed immediately.  The intent is to
smoothly transition from a 3-way bridged conference to a 2-way call
between the unconnected participants.

  Regardless, in many (most?) cases the recipient of the HANDOFF will be
a call control server or PSTN gateway, which will be forced to rely on
local policy.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]