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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 21 Jan 2001 17:24:14 -0800

Hi Billy,
> 
>   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."
> 

Thansk for the reply. I'm surprised more people are weighting into the
discussion.

>   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

Right. You are optimizing for a particular scenario so that this scenario
does not need multiple queued requests or multipart. Thought still needs to
be given to other ways in which HANDOFF can be used.

>   The handoff should be instantaneous.  When C gets a 
> 200-class response
> to the HANDOFF, the call disappears from C's UI (suspended).  
... 
>   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.
...
>   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.

I don't see how this is at odds with what I was suggesting. 

Additionally, in your application subspace the spawned INVITE completes
quickly ... so why does it matter if the initial call leg is muted before
you receive or when you receive a 200 OK response (since the time difference
should be very small any any case). 

The transferee either has three options on receiving the 200 OK to the
spawned INVITE:
	- send re-INVITE with Handoff-Status and held-media.
	- send re-INVITE with Handoff-Status and unheld-media (in which case
the transferee shoudl probably support mix - but remember it is the
transferee's choice to send this).
	- send BYE with Handoff-Status.

In the second case, if the transferee does not want to maintain the original
media session in an unheld state, then it would place a held SDP in the
200OK of the re-INVITE. Thus we have your condition. Simple. 

This approach also furthers your motivation that the HANDOFF does not
"control" the original session.

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

Exactly but if the session remains active then it should be mixed to the
user right? Otherwise it is placed on hold or released (by either party).
Regardless, it needs to be defined.

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

Agreed. You want this to be as simple yet flexible as possible. No SDP means
not multipart.

> > 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.
...
>   PRACK is another extension which allows session descriptions...

I don't agree. Handling the glare/contention resolution adds a lot of hidden
complexity to the implementation. This probably means people will not bother
addressing the problem (especially since the current glare resolution is
pretty broken anyway). PRACK is special method that excutes under an INVITE
transaction and remember that it is never in contention with that request,
right. I simply don't think that HANDOFF needs to do this.
 
>   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. :)
> 

Why? Please give your reasoning behind why audio muting must be performed
when the HANDOFF is accepted (rather than when the spawned INVITE is
accepted). Exactly, SIP is for modifying sessions - that's what its for. If
you must for whatever reason mute the audio when you send the HANDOFF
(rather than when the spawned re-INVITE is accepted) then send a re-INVITE
(with held SDP) before you send the HANDOFF.

Here are a few scenarios:
-If the transferor doesn't care about the result of the call then it can
simply send a BYE after the HANDOFF 200 Ok is received (trivial case). 
-In the case where the HANDOFF completes quickly it doesn't matter if the
hold/BYE occurs before or after the spawned INVITE connects; 
-If the spawned INVITE takes some time to connect the operator will probably
want to say "Hang on, I'm having some problem ..." to the transferee? Under
your assumptions the spawned INVITE completes quickly so this is obviously
an error condition (in your model). [So not holding when receiving the
HANDOFF is the easiest action to achieve this.]

If the system must be able to work with plain-vanilla SIP clients, the
transferor needs someway of identifying whether the target supports
Replaces; otherwise the transferor will have to default back to B2BUA
transfers mode. The draft should address this.

If the transferor decides it wants to CANCEL the spawned INVITE (eg because
it is not connecting quickly or probperly), can it put a ?method=CANCEL in
the Handoff header of a second HANDOFF message?

Cheers,

Robert.

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

---

From: Billy Biggs <[email-masked]>
Date: Sun, 21 Jan 2001 23:14:48 -0500

I'll try and add more text about the reasons for not requiring the
transferee to ever perform mixing.

  You don't want the HANDOFF transaction affect the session description
at all, and to instead always transmit these via re-INVITEs.  The
problem is that this creates message queues, since the transferor must
first put the transferee on hold, then send the HANDOFF.

  I expect that the most common implementation of blind (unattended)
transfer with recovery will be:

  1.  HANDOFF (hold) sent and accepted.
  2.  Call disappears from transferor's UI.
  3.  Time passes
  4.  re-INVITE arrives, Handoff-Status: 486 Busy, (non-hold SDP)
  5.  Transferor sends 180 Ringing and the phone rings.
  6.  Transferor picks up and old call resumes.

  Anyways, I will think about this issue and try to clarify the draft.

> transfers mode. The draft should address this.

  This is explained in the Replaces draft.  We should merge the two.

> If the transferor decides it wants to CANCEL the spawned INVITE (eg
> because it is not connecting quickly or probperly), can it put a
> ?method=CANCEL in the Handoff header of a second HANDOFF message?

  No.

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