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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 8 Feb 2001 08:19:03 -0500

Sorry for being absent from sipml discussions.... I was on vacation and
generally been swamped. Following sip is a lot of work these days.

Anyway, a few comments on this. I realize we are discussing it today during
the meeting, hopefully this note can help set the stage for those
discussions.

Here is my summary of the differences between this draft and the REFER
draft:

1. additional headers for the triggered invite are specified within a body
part of the HANDOFF. In REFER, they are specified as header parameters in
the target's URL.

  I personally dislike the approach taken in HANDOFF. I don't understand why
it is needed.
  There is some gripe about complexity with ? separated headers in a URL,
but multipart
  is, IMHO, far harder.

2. the body of the HANDOFF can have SDP, presumably for simultaneously
putting media on hold and initiating the transfer (I believe, please correct
if I'm wrong). SDP in REFER has no meaning.

  I also dislike the approach in HANDOFF. It is turning HANDOFF into a
re-INVITE + REFER
  function. Now, ALGs in firewalls need to process HANDOFF to modify media
stream information. B2BUas need to do the same. As a matter of design, sip's
approach has been to modularize and separate functions. This is why we
changed BYE/Also to REFER followed by BYE. The argument made for the HANDOFF
approach is latency and message overhead. I believe this is a red herring in
practice, but its a matter of personal taste in protocol design.

3. The reffered-by equivalent in HANDOFF is generated by the transferee, not
transferor, and they are not signed.

  This is a huge security hole. It will allow me to take over call legs that
other parties have with each other. Bad.

4. The status of the handoff is conveyed in a re-INVITE in the reverse
direction (presumably so that media on hold can be turned off?) if it fails,
else a BYE if it succeeds.

  I don't like the mis-use of INVITE as a means to convey status for a
previous transaction. What if there are multiple previous REFER? How is the
status correlated to the REFER? What if the triggered generates a 300, which
is recursed by the transferee, then a 400? Which is returned? Are reason
codes returned? What about warning headers? Sounds like a real notification
mechanism is needed here. 

5. The triggered INVITE from the HANDOFF can contain a Replaces used to
replace the existing call leg between the transferor and target. This causes
the target to send a BYE to the transferor. In REFER, the transferor would
send a BYE to the target, and this would be based on learning the successful
completion of the triggered INVITE. I suppose the argument here is message
overhead and latency, once more. 

I think that covers it.

On the issue of method names - if this draft is accepted as a wg document I
would definitely want to change the method name. I'm with Pat on this one;
it will cause confusion. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Wednesday, February 07, 2001 4:40 PM
> To: Robert Sparks
> Cc: Rick Dean; Ben Campbell; SIP List
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 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]
> 
> _______________________________________________
> 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: Fri, 16 Feb 2001 10:05:17 -0600

Jonathan,

Sorry for the delay.  This answers your questions
if you are still interested.

>   There is some gripe about complexity with ? separated headers in a URL,

I agree multipart is bad.   The current draft
does not use multipart.  http://phonectl.sfour.com/

> practice, but its a matter of personal taste in protocol design.

At the time of your writing it had already been discussed on 
the list that continuing audio to the HANDOFF/MOVE sender
should not be possible.  Thus, no SDP in the 
HANDOFF, but it still modifies the
media session which you probably won't like.  The motivation
is moving one end of a two-party call-leg.  Continuing media
to the old end point makes no sense.

As a general rule I do favor SDP in all SIP messages.  It makes
managing the media stream easier for implementations.  Your chatty
preference works fine in nice network conditions with
fast hosts (i.e. two PCs, same idle eithernet), but when things get
bad, the chatty technique goes to hell.  Add half a second for
each retry.  Add some more packets for authentication.  Lengthen
the sequence.  Increase latency.  Disallow overlapping transactions.  
My human customers will notice the delay.   

Of all the arguements my business team hates to hear, "The delay
has to be that long because the protocol requires it."  Then they
call the protocol broken.  They are right

SDP in non-INVITES helps make actions *atomic*.  I

> other parties have with each other. Bad.

The referred-by equivalent is for the transferee's protection.  If the
transferor and targe wish to authenticate each other with additional
headers, they are free to.  The security is just as good/bad as REFER,
that if I can snoop packets I can forge messages and hijack connections.
MOVE requests are only honored when received in call-legs
which are established.

> mechanism is needed here. 

Mis-use?  My code is much easier.  vs. what? protocol beauty.
More messages suck for end point complexity, round trip delay,
error cases, etc.

Multiple (thus overlapping) MOVEs do not make sense, and should not 
be permitted.  This guideline will be mentioned to the draft.  Thanks.

"If the triggered generates a 300 which recursed by the transferee then 400"
the transferee decides which code to return.  Mandating reports
fouls a privacy issue.

Hmmmm... I had not thought about warning headers.  Is there a reason
why they couldn't also be included in the INVITE?  privacy permitting
of course.

> overhead and latency, once more. 

If the transferor sends the BYE to the target, then
the target may have some time when he must support two simultaneous
connections, but this is a unnecessisary difficult requirement.  

The HANDOFF/MOVE draft does not mandate he sends a BYE, but
the replaces is requesting him to.  Your beef is with the Replaces
draft.  I believe this behavior will be used with REFER.

> would definitely want to change the method name. I'm with Pat on this one;

Okay, how about the name "MOVE"?

--
Rick