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

From: Rick Dean <[email-masked]>
Date: Wed, 17 Jan 2001 12:26:34 -0600

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.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 17 Jan 2001 17:33:45 -0800

Rick,

Thanks for preparing this so quickly.  A few questions are below.

-In section 5
>    The HANDOFF request may contain a body of MIME-type
>    application/sip-headers, which contains headers requested to be
>    copied into the spawned INVITE request.  For a HANDOFF request, the
>    "Refer-To" URI SHOULD NOT include question-mark delimited headers for
>    the subsequent INVITE.

What do you do if you get headers in the Refer-To (ignore, issue error x)?

>These headers SHOULD be copied to the
>    resulting INVITE without escaping processing.

By "These headers" do you mean the headers in the body or the headers that 
you SHOULD NOT put into the Refer-To URI?

>This MIME type MUST
>    NOT contain a header which begins with two dashes, "--".  This MIME
>    type MUST NOT include a call-id header, but instead use a "replaces"
>    header for this functionality.  This MIME type MUST NOT include a
>    "handoff" header.

What error should you return if you detect this stuff?

-The fact that you can have a "header body" and a session description 
implies multipart.  Do you really want to do that?

-The way you show the flows, the transferor sends the handoff, and then 
holds its call(s) up.  What happens if the transferee crashes after OKing 
the HANDOFF?  You would have to keep the call up "forever" 
right?  Presumably if the transferor wants to be rid of the call, it could 
send a BYE?

Take the following example where I begin an attended transfer, but I get 
tired of waiting.

A               B               C
INVITE ->
<- 180
<- 200
ACK ->

INVITE ------------->
<---------180--------

(several rings later)
HANDOFF ->
<- 200
                 INVITE ----->
                 replaces:
                 <--- 180 ----
<- NOTIFY
handoff-status: 180
200 ->
BYE ->
<- 200

-HANDOFF seeks to fill a much smaller role in the call control framework 
than some of us advocate for REFER. It seems you are advocating a framework 
with a larger number of more specific/smaller primitives.  PHONECTL would 
be one of these primitives.  What primitive (what would it look like in 
your version of hte framework) do you advocate to replace/unreplace 
yourself [as in the Music on Hold example I gave]?  How about a primitive 
for ad-hoc conferencing?

thanks,
-rohan

---

From: Billy Biggs <[email-masked]>
Date: Wed, 17 Jan 2001 20:58:39 -0500

Rohan Mahy ([email-masked]):

> > copied into the spawned INVITE request.  For a HANDOFF request,
> > the "Refer-To" URI SHOULD NOT include question-mark delimited
> > headers for the subsequent INVITE.
> 

  Any time a UA is asked to dial a URI with ?-headers, it has a choice
of whether or not to honour them.  The UA can do whatever it wants.

  Some implementations may choose not to honour them because of the
added complexity.  To accomodate this, we want to ask implementors to
place to-be-copied headers in an 'application/sip-headers' body to
decrease handoff failure.

> > These headers SHOULD be copied to the resulting INVITE without
> > escaping processing.
> 
> By "These headers" do you mean the headers in the body or the headers
> that you SHOULD NOT put into the Refer-To URI?

  We mean the headers in the body.  This text will be cleaned up,
thanks.

> > This MIME type MUST NOT contain a header which begins with two
> > dashes, "--".  This MIME type MUST NOT include a call-id header, but
> > instead use a "replaces" header for this functionality.  This MIME
> > type MUST NOT include a "handoff" header.
> 

  How about a 400, that's what it is for.  I would rather have
implementations ignore them.  This text will be cleaned up.

> - The fact that you can have a "header body" and a session description

  I think so.

> -The way you show the flows, the transferor sends the handoff, and
>  then holds its call(s) up.  What happens if the transferee crashes
>  after OKing the HANDOFF?  You would have to keep the call up "forever"
>  right?  Presumably if the transferor wants to be rid of the call, it
>  could send a BYE?

  The transferor can have a timeout and send a BYE.  The transferee can
always call back later if it likes, implementation specific.  I'm not
worried.

> Take the following example where I begin an attended transfer, but I
> get tired of waiting.
> 
> [...]
> <- NOTIFY, handoff-status: 180
> 200 ->
> BYE ->
> <- 200

  I don't like this.  You're giving the transferor more information than
it needs.  This has security implications.  If you want to know the
progress of the call being setup, you should use a control protocol such
as PhoneControl.

> -HANDOFF seeks to fill a much smaller role in the call control
> framework than some of us advocate for REFER.

  Yes.

> It seems you are advocating a framework with a larger number of more
> specific/smaller primitives.

  Not necessarily.  Call handoff is a necessary primitive for building
many services.  I want it to be small and specific because we need
everyone to implement it.

> PHONECTL would be one of these primitives.  What primitive (what would
> it look like in your version of hte framework) do you advocate to
> replace/unreplace yourself [as in the Music on Hold example I gave]?

  If you want to replace/unreplace yourself, you need a strong control
protocol such as PhoneControl.

> How about a primitive for ad-hoc conferencing?

  This is a different problem.  In my opinion, ad-hoc conferencing needs
a higher protocol for negotiating setup and teardown of the individual
SIP sessions of the conference.

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

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 17 Jan 2001 18:31:59 -0800

>implementations ignore them.  This text will be cleaned up.

presumably the transferor is trying to find/exploit a security loophole.

>protocol such as PhoneControl.

It is pretty standard stuff to replace yourself with someone/thing else and 
then be able to undo the replacement.  This doesn't usually imply the 
strong control relationship you would have with PHONECTL.

>SIP sessions of the conference.

All fine and good, but what is it?

---

From: Billy Biggs <[email-masked]>
Date: Wed, 17 Jan 2001 21:54:11 -0500

Rohan Mahy ([email-masked]):

> > > > dashes, "--".  This MIME type MUST NOT include a call-id header,
> > > > but instead use a "replaces" header for this functionality.
> > > > This MIME type MUST NOT include a "handoff" header.
> > >

  If you think so, then return a 400.  Maybe you can have your UA call
911 automatically.  I'm unsure that it needs to be specified, it seems
implementation specific.  But as promised I will try and clean this up.

> It is pretty standard stuff to replace yourself with someone/thing
> else and then be able to undo the replacement.  This doesn't usually
> imply the strong control relationship you would have with PHONECTL.

  I'm unconvinced that replace/unreplace is standard stuff.  Your music
on hold example is much more easily (and properly) solved by having the
music-sending phone dial a music server and give it the far-end SDP
(3pcc/b2bua style).

> > This is a different problem.  In my opinion, ad-hoc conferencing
> > needs a higher protocol for negotiating setup and teardown of the
> > individual SIP sessions of the conference.
> 

  Wasn't there a BOF regarding ad-hoc/multiparty conferencing using SIP?
I was waiting for minutes, but never saw any.

  If you want my opinion, I can give it.  I did do some work researching
the topic.  We should really setup an egroups list or something to bang
on it.  There always seems to be interest in the topic...

  Regardless, there is definitely a seperate and specific need to
handoff a 3-way bridged call and connect the participants.  The HANDOFF
draft seeks to fill this gap.

---

From: Rick Dean <[email-masked]>
Date: Thu, 18 Jan 2001 01:56:04 -0600

> What do you do if you get headers in the Refer-To (ignore, issue error x)?

I am a byte slut. -- I would write the HANDOFF receiver however it 
turned out to be smallest.  The draft allows that.  My test scripts
would throw a big error if they receive it.  

What is your recomendation?  

> you SHOULD NOT put into the Refer-To URI?

ooops.  thanks.

> implies multipart.  Do you really want to do that?

The multipart is ugly.  I don't like the code for it.
People need to construct it carefully to fit it into one datagram.  

If I fanticized about syntax, I would ditch the 
multipart and place a second blank line after the spawned 
INVITE's headers, separating the true content-type body (SDP).
This won't be popular with the non-implementors. :-)

Actually, that is my second choice.  My first choice would
be a successful HANDOFF mutes audio, period.  (i.e. HANDOFF
response not handoff-status).  You need a re-INVITE if you 
want it back.   I predict this would be less popular.

What do you prefer?

> Take the following example where I begin an attended transfer, but I get 

Yes, both sides can BYE early.  The handoff-status
mentioned "if the call-leg still exists" ...
but I can't find it now.  It will go back in.

Excellent suggestion.  Provisional handoff-statuses (statum?) 
should be explicitly allowed.  Although, my implementaion
might lie "handoff-status: 200 OK" when it
receives the 180 ringing, and BYE when it receives
a provisional handoff-status.  I still have more
testing to decide.

> be one of these primitives.  

IMHO, SIP is for sessions.  With handoff
SIP is done.   If I can use SIP as a transport layer
for other protocols, I need nothing more from SIP.

Inbetween this ability to create sessions and
the PHONECTL API, sits the logic of a phone.  I like
this layered approach.  Can you think of any protocol
which tries to cross more network layers than SIP?  
Ironically, a SIP WG chair wouldn't consider the 
PHONECTL draft because he claimed it wasn't
in their mandate.

Thanks for the soapbox.

> What primitive (what would it look like in 
> yourself [as in the Music on Hold example I gave]?  

If the transferer wants to maintain control (like 
unreplace) then he should B2BUA.  If he works the SDP
correctly, he doesn't need to touch the media.
This is how I will do music-on-hold.  No contest.

The direct answer: no new primative.

> How about a primitive for ad-hoc conferencing?

Forgive me for not being sure of a definition for 
ad-hoc conferencing?  I am thinking it is when I, as
the middle of a three way call, move
it to a conference bridge to add more people.

1.  Call conference bridge.
2.  HANDOFF to conference bridge with "conference: call-id" 
    instead of "replaces: call-id"
3.  Phonectl to kick & mute.

Authentication for #1 determines billing.  The Phonectl passes
down that same call leg for authentication/simplicity.  The
conference bridge doesn't show its other independent meetings 
in the phonectl.  If new people want to join, they
call me, and I HANDOFF them in.  The server help is transparent
to the human.

I suppose this plan has the problem of other conference
members inviting more people themselves once they see the
"conference: call-id".  This could be
a feature for chained 3-way calls, and the billing contract 
might not make me pay for any guests I kick out within five 
seconds.

We will need to fix the mute stuff of PHONECTL.  

Cheers,
Rick
[email-masked]

---

From: Christoph Reichert <[email-masked]>
Date: Thu, 18 Jan 2001 14:13:16 +0100

[...]

[...]

I am also very interested in the results of this BOF and/or the egroup list.

chris

---

From: "???" <[email-masked]>
Date: Sun, 28 Jan 2001 18:48:56 +0900

Dear all. 

I am some curious about HANDOFF method. 
I think, HANDOFF method is required when SIP terminal moves from one network to other network. 

In 3GPP TR23.821, the sentense,
" As a consequence, the behaviour of the multimedia call control server (CSCF) can be the same whatever the access technology (radio or wired-line). Multimedia call control/mobility management shall not be aware of the access technology: the multimedia Call Control (CSCF) does not handle notions such as Hand-Over, RA, "

It means that handoff is the problem of GGSN and SGSN not CSCF which support SIP protocol. It is not the business of CSCF. 

Therefore I think HANDOFF method is not required at least 3GPP. 

What do you think about this? 

  ----- Original Message ----- 
  From: Rohan Mahy 
  To: Rick Dean 
  Cc: [email-masked] 
  Sent: Thursday, January 18, 2001 10:33 AM
  Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt

  Rick,

  -In section 5

  By "These headers" do you mean the headers in the body or the headers that you SHOULD NOT put into the Refer-To URI?  

    This MIME type MUST

  -The fact that you can have a "header body" and a session description implies multipart.  Do you really want to do that?

  -The way you show the flows, the transferor sends the handoff, and then holds its call(s) up.  What happens if the transferee crashes after OKing the HANDOFF?  You would have to keep the call up "forever" right?  Presumably if the transferor wants to be rid of the call, it could send a BYE?

  Take the following example where I begin an attended transfer, but I get tired of waiting.  

  A               B               C
  INVITE ->
  <- 180
  <- 200
  ACK ->

  INVITE ------------->
  <---------180--------

  (several rings later)
  HANDOFF ->
  <- 200
                  INVITE ----->
                  replaces:
                  <--- 180 ----
  <- NOTIFY
  handoff-status: 180
  200 ->
  BYE ->
  <- 200
                  
  -HANDOFF seeks to fill a much smaller role in the call control framework than some of us advocate for REFER. It seems you are advocating a framework with a larger number of more specific/smaller primitives.  PHONECTL would be one of these primitives.  What primitive (what would it look like in your version of hte framework) do you advocate to replace/unreplace yourself [as in the Music on Hold example I gave]?  How about a primitive for ad-hoc conferencing?

  thanks,
  -rohan

    Dear SIP list,

    Cheers,
    Rick
    [email-masked]

---

From: Sean Olson <[email-masked]>
Date: Sun, 28 Jan 2001 11:45:50 -0600

??? wrote:

> " As a consequence, the behaviour of the multimedia call control server 
> (CSCF) can be the same whatever the access technology (radio or 
> wired-line). Multimedia call control/mobility management shall not be 
> aware of the access technology: the multimedia Call Control (CSCF) does 
> not handle notions such as Hand-Over, RA, "
> 
> It means that handoff is the problem of GGSN and SGSN not CSCF which 
> support SIP protocol. It is not the business of CSCF.

A couple of comments:

1) The SIP working group is not responsible for determining the
    applicability of various SIP extensions to the 3GPP architecture.
    This is the responsibility of 3GPP as they have the detailed
    knowledge of that architecture.

2) HANDOFF in the aforementioned draft does not address mobility
    management in the sense which you are thinking of. It is not
    about access level handoff, eg. handoff between SGSNs or the like.
    Because it is a call signalling mechanism it is best suited for
    call services (as mentioned in the draft). For example:

       * Call Transfer, both Attended and Unattended
       * Call Park/Un-Park
       * Multi-Stage Dialing
       * Operator Services
       * Conference Call Management
       * Call Pickup

/sean

---

From: Patrice Calhoun <[email-masked]>
Date: Sun, 28 Jan 2001 10:46:06 -0800 (PST)

Ahhh, I see that the misuse of terminology is biting this WG in the a..

This isn't a handoff as you, or I, or anyone else involved in mobility
management understands it. It is rather a form of call transfer. You are
correct that the handoff will occur at the GGSN/SGSN.

I have asked that the WG refrain from using the term handoff, or handover,
given that the mobility folks will have serious issues with it (as they have
had with SIP Mobility, when it fact it is really portability). However, the WG
does not seem to be willing to listen to our requests :(

I suppose we will simply have to deal with the constant confusion we are
creating in the marketplace by abusing terminology.

PatC
> (CSCF) can be the same whatever the access technology (radio or wired-line).
> Multimedia call control/mobility management shall not be aware of the access
> technology: the multimedia Call Control (CSCF) does not handle notions such
> as Hand-Over, RA, "
> 
> It means that handoff is the problem of GGSN and SGSN not CSCF which support
> SIP protocol. It is not the business of CSCF. 
>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 28 Jan 2001 12:02:01 -0800

Patrice,

1) the HANDOFF proposal is an individual submission to the SIP working
group.  People can propose whatever names they like.  The IETF WG as a
whole had nothing to do with the selection of the method name.

2) We are beginning to run out of names to describe the various features,
and even the different variations on some fairly basic functionality.
Someone has a problem with every name which is proposed, so please propose
an alternate, or understand that the english language is full of words with
multiple, somtimes confusing names, and that is just the way it is.

thanks,
-rohan