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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 19 Jan 2001 17:19:31 -0800

Hi Rick & Billy,

I refer to the following change:

   HANDOFF is designed to proceed quickly at the end of conferencing,
   thus media mixing in the transferee is not required.

I agree that this is better than saying that the transferee MAY mix audio
but should not be expected to; however, I believe that more description is
needed of the behaviour when the transferor does _not_ place the transferee
on hold. 

I beleive that it should say: If the transferor does not place the
transferee on hold in the HANDOFF, then the voice/media connection with the
transferor should be maintained whilst the HANDOFF has not connected or
completed. If the transferor does place the transferee on hold, then the
transferee should apply/display (local or media-based) session progress
indications of the spawned INVITE to the user. In the former case, the
transferee is of course free to display or audio mix these session progress
indications whilst still in communication with the transferor.

I can think of many attended trasnfer & operator assisted calling situations
where this would be useful. You statement "HANDOFF is designed to proceed
quickly" is also ambiguous. If you actually mean that the spawned INIVTE
should proceed quickly then I think you may be unnecessarily only
considering a subset of potential applications.

I disagree with your change about leaving out the SDP in the HANDOFF or 200
OK to mean on-hold. This goes against the prevailing idea that where SDP is
possible, no SDP means no change. That is, if there is no SDP in the HANDOFF
then the transferee will remain connected with the transferor until the
HANDOFF connects or completes. [Which is IMO a good idea.]

In fact, I beleive that your HANDOFF draft goes against the
mandate/assumption that all (primary) session state should be changed
through re-INVITE exchanges. By allowing SDP in HANDOFF requests (at all)
you are violating this non-trivial property and creating potential
contentions between HANDOFF and re-INVITE transactions - whilst this is a
not unsolvable problem I do agree with the original motivation of the
mandate. 

Rick, from your postings it seems as though you "by default" wish to place
the transferee on hold and have the assumption that HANDOFF completes
quickly. Given these conditions how different then is the situation that 
- The HANDOFF may not contain SDP (thereby not violatign any state
assumptions or creating contention). Thus the transferee and transferor
remain in communication while waiting for the spawned iNVITE to connect or
complete.
- When the spawned invite connects or completes, the transferee sends a
re-INVITE with a Handoff-Status and may also place each other onhold if they
desire (or BYE).

Your motivation for allowing SDP in HANDOFF seems to be that you do not want
lots of messages or queues of pending requests, so I'll be interested to see
what you think of this suggestion (which has neither).

Regards,

Robert.

PS. I like the name HANDOFF I think it succinctly conveys the jist of what
the method does.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. --

> -----Original Message-----
> From: Rick Dean [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 9:46 PM
> To: [email-masked]
> Subject: Re: [SIP] draft-ietf-sip-handoff-00.txt
> 
> 
> 
> Please forgive my mistake.  The correct name for
> this draft is draft-dean-handoff-00.txt.
> http://phonectl.sfour.com/draft-dean-handoff-00.txt 
> 
> --
> Rick
> 
> 
> On Fri, Jan 19, 2001 at 03:18:29PM -0600, Rick Dean wrote:
> > 
> > draft-ietf-sip-handoff-00.txt is now available at
> > http://phonectl.sfour.com/draft-ietf-sip-handoff-00.txt 
> > 
> > Protocol changes since draft-ietf-handoff-00pre8.txt are...
> > 
> > * Refer-To changed to Handoff-To
> > * Additional headers made not allowed in application/sip-headers.
> > * more definitions including B2BUA.
> > * Explicitly allow provisional refer-status
> > * Explicitly allow transferor to send BYE before "Refer-Status"
> >   received without affecting HANDOFF.
> > * Section added to describe supervised transfer strategy.
> > * Section added for music-on-hold strategy
> > * Audio mixing in the transferee depreciated.
> > * HANDOFF 200 OK implicitly mutes audio unless overridden with SDP.
> > 
> > Cheers,
> > Rick
> > 
> > 
> > 
> > _______________________________________________
> > 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: Sat, 20 Jan 2001 01:28:29 -0500

My opinions may differ slightly from Rick's.  You discuss two of our
proposed behaviors:

  1. "HANDOFF is designed to proceed quickly at the end of conferencing,
      thus media mixing in the transferee is not required."

  2. "If the HANDOFF request or response does not include SDP
      then a media description of no media is implied. [...] The
      anticipated use of transferor-transferee media after HANDOFF is
      minimal, so default hold simplifies most messages."

  These behaviors are to optimize for handoff of a 3-way call.  We
strongly believe that this is the most important problem to solve.
3-way call handoff involves the mixer leaving the call, connecting the
two remote endpoints.  In the case of failure, the transferee
re-INVITEs, asking the transferror to continue the original 3-way call.

      A       B                  A ----- B
        \   /         ====>
          C                          C

  The handoff should be instantaneous.  When C gets a 200-class response
to the HANDOFF, the call disappears from C's UI (suspended).  When B
receives the INVITE, it should accept immediately without sending a 180.
If the call between A and B fails, A re-INVITEs C with a Handoff-Status.
C will send back a 180 Ringing to the re-INVITE as the phone asks C's
user to resume the 3-way call.

  In this situation, the media should be muted immediately when the
HANDOFF is accepted, and dependant on whether the HANDOFF is accepted.
This is why we need the HANDOFF transaction to affect the session
description.  There is no reason for the transferee to mix, since the
conferencing stage was already performed by C who is leaving.

  To perform an attended transfer you also need to specify some headers
to copy into the spawned INVITE.  I want these in the body, not the URI.
Defaulting to hold SDP avoids forcing implementors to deal with
receiving multipart bodies.

  The reason to allow retaining the pre-HANDOFF session is to accomodate
different styles of unattended transfer.  I believe it is extremely
important that the transferor-transferee session only remains active if
both parties _explicitly_ agree to it.

  To achieve this, the session only survives when both the transferor
and transferee specify a non-hold session description.  No
Handoff-Status is ever sent in the call-leg as it is now unnecessary (we
know we are performing unattended transfer, and we know the far-end
still wants to talk to us).  The transferee is free to mix in the audio
from the spawned INVITE.  I plan to clarify this in the draft.

  The only issue is whether a blank HANDOFF implies a hold (no media)
session description.  I believe the optimization is useful and cheap.

> transferee on hold in the HANDOFF, then the voice/media connection
> with the transferor should be maintained whilst the HANDOFF has not
> connected or completed.

  If the connection stays up, it shouldn't be tied to the spawned call.
This is why no Handoff-Status messages are sent if the session remains
active (not in the current draft, but I intend to change it).  Of
course, the transferee can just send a BYE when the new call connects,
if it wants this behavior.

  I don't want a blank HANDOFF to keep the connection active, since I
want to perform attended transfer without requiring multipart bodies.

> I disagree with your change about leaving out the SDP in the HANDOFF
> or 200 OK to mean on-hold. This goes against the prevailing idea that
> where SDP is possible, no SDP means no change.

  HANDOFF is a new method.  I think this is a reasonable thing to
specify.

> through re-INVITE exchanges.

  The audio must be muted immediately when the HANDOFF is accepted, and
dependant on whether the HANDOFF is accepted.  Since SIP is for
sessions, I find it hard to imagine that extensions should not modify
the session. :)

  PRACK is another extension which allows session descriptions...

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

---

From: Rick Dean <[email-masked]>
Date: Mon, 22 Jan 2001 03:12:36 -0600

Robert,

If you are looking to me for defending non-mute
SDP in a HANDOFF, you are asking the wrong guy.
I can build everything I need without it.  

I am lazy, so I am trying to keep HANDOFF simple.
Even our limited scope handoff is unbelievably
complex.

Implying mute on HANDOFF without SDP lets the 
simplest implementations have the simplest messages.
It is also a good suggestion for implementors.

I have said before that mixing audio in the
transferee is a recipe for pain.   Besides
being a security, syntaxtic, and privacy nitemare, 
it works better with audio-free B2BUAs who 
intercept the transferee's role.  

Billy made some good arguments that continued 
transferer-transferee audio should be moved into 
a non-HANDOFF draft.  I am starting to agree more.

> considering a subset of potential applications.

Thanks. Sorry. We mean the HANDOFF transaction should proceed
quickly.  As you noted, handoff-status may frequently take some time.

> not unsolvable problem I do agree with the original motivation of the

How can a re-INVITE race with a HANDOFF traveling the same
direction in the same call-leg?  They can't overlap right?
BTW, this non-overlap (and a little packet loss) adds nasty 
complexity for phones whos humans get spaztic on the hold key, 
but is better than the alternative.  Was this your point?

Protocol beauty caries no weight with me in the face of simpler
code.  If the transferee doesn't mix audio, the current draft
is easiest.  Our real diagreement is transferee mixing.

Please ask your DSP people, "A proposal allows SIP phones to have
supervised transfer, but they gateways never have to mix audio.  Do you 
like it?"

> remain in communication while waiting for the spawned iNVITE to connect or

Yeah, if you can eliminate early media.  :-)  Otherwise, no.

If the transferor is not done listening to the transferee, he
should not send the HANDOFF yet.

I can't see switching the mixer in the middle of the conference.
Are you going to have a switch-mixer-to-far-end key?  No
idiot end user of ours would understand this.  So you are
sending the HANDOFF at the beginning of the conference?
This should be different method.... or something.

> PS. I like the name HANDOFF I think it succinctly conveys the jist of what

Thanks.  The method name thread with Pat Calhoun was resolved
off the list.

--
Rick
[email-masked]