Subject: [SIP] Simple REFER Solution

From: Billy Biggs <[email-masked]>
Date: Tue, 19 Dec 2000 15:32:39 -0600

Keep REFER simple:  Have no REFER-response method and no subscription.

  We have found the following algorithm to be smallest, simplest,
easiest to understand, and least verbose.

  1.  The REFER is responded to immediately.

  2.  If the Referred Party wishes to resume the call later (usually if
      the REFER-spawned call failed), then they send an INVITE with a
      'Refer-Response' header containing the response code from the
      spawned INVITE.

  3.  If the Referred Party wishes to end the old call (the
      REFER-spawned call succeeded), then they BYE the referrer.

  4.  To keep the number of messages down, REFER and its response may
      contain SDP (such as hold SDP).

  Rationalle:

  Avoids queues in either device.  A "first send NOTIFY then send BYE to
shut down the call" proposal has difficult error cases.  Want to keep
recovery of the old session from a failed transfer as speedy as
possible.

  Comments appreciated.

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 21 Dec 2000 15:35:07 -0800

Hi,

I must be missing something.  If I send the REFER, how do I find out if it
is successful?  By the absence of a BYE?

thanks,
-rohan

---

From: Billy Biggs <[email-masked]>
Date: Thu, 21 Dec 2000 17:46:04 -0600

Rohan Mahy ([email-masked]):

> I must be missing something.  If I send the REFER, how do I find out
> if it is successful?  By the absence of a BYE?

  If the far end still wants to talk to you, they will re-INVITE with a
Refer-Response header containing the response code from the spawned
INVITE.  This can of course be "200 OK".

  If you see a BYE it may also mean it's successful, but at that point
what do you care?  If there is a legitimate requirement, it may justify
a Refer-Response header in the BYE too.

  I really like this algorithm.  Thoughts?

>>  2.  If the Referred Party wishes to resume the call later (usually
>>      if the REFER-spawned call failed), then they send an INVITE with
>>      a 'Refer-Response' header containing the response code from the
>>      spawned INVITE.
>>
>>   Avoids queues in either device.  A "first send NOTIFY then send BYE
>> to shut down the call" proposal has difficult error cases.  Want to
>> keep recovery of the old session from a failed transfer as speedy as
>> possible.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 21 Dec 2000 17:26:31 -0800

>  I really like this algorithm.  Thoughts?

OK,

So this all hangs together nicely if you use REFER just for transfers,
INVITEs with the Members header for full-mesh conferences, PHONECTL for
controlling other UAs....

There is still an issue with music on hold (see [6])

>1) Retransmission problem:
solved

>2) Cancellation:
>If REFER returns a final response before a long INVITE transaction
>completes, how do you cancel that INVITE?  
this would only happen in unusual cases (blind transfer to conference
bridge that just crashed) if we limit this to transfers, but we still need
some solution here.

>3) Call-leg matching:
>(b) use a Replaces header

>4) If we choose Replaces or the like, how do we express that we want to
>*join* 2 legs via REFER?
some header

>5) If Refer-To contains parameters (method, transport), or potentially
>contradictory headers, what do we do with them?
>(c) send an error mesage
>(d) ignore the headers/parameters
>(e) ignore the whole message
>
>6) If we don't allow  ;method=BYE, how do we solve the problem described in
>the Music on Hold flow?

is this what you had in mind here?

INVITE (call-id: foo) c=0.0.0.0 ->
REFER Refer-to: Music?Join=foo ->
	INVITE Music (call-id: bar) ->

INVITE (call-id: foo) Replaces: bar  or Replace: Music
**	BYE Music

>7) How do we ask devices to do stuff for us?
>(b) PHONECTL

thanks,
-rohan

---

From: Billy Biggs <[email-masked]>
Date: Thu, 21 Dec 2000 20:29:13 -0600

Rohan Mahy ([email-masked]):

> bridge that just crashed) if we limit this to transfers, but we still
> need some solution here.

  I'm ok with having some other request, from the referrer to the
referred party, like REFERCANCEL.  This I can happily 501 and nobody has
a waiting message queue or ugly state or whatever.

  It's a bit of a security no-no to let a 3rd party stop you from making
a call outside of some device control protocol.

> > 6) If we don't allow  ;method=BYE, how do we solve the problem
> > described in the Music on Hold flow?

  Is this really a problem?  Why do you want to use this method for
music on hold?

> INVITE (call-id: foo) Replaces: bar  or Replace: Music

  That's pretty ugly.  If you're trying to orchestrate a remote UA,
that's a dangerous road to full device control.  I want to keep that out
of REFER, otherwise it is too complicated to implement and still protect
yourself from the security nightmare.