Subject: RE: [SIP] Solving the REFER retransmit issue

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 22 Dec 2000 16:18:33 -0500

We have some basic design principals we can use to help us here:

1. design general purpose mechanisms, not services
2. be explicit, not implicit
3. keep things independent so that they can be combined in different ways

Sometimes these are at odds with some of our design goals:

1. KISS
2. SIP is not a control protocol

However, I do not think we want to have REFER mean ONLY transfer. I'd rather
keep it generic with a fairly well defined scope, in particular, keeping it
away from the control protocol space. I'd also rather be explicit, in which
case REFER means refer, and nothing else; i.e., don't use a header in an
INVITE, since INVITE is not a transfer/refer function. There is something in
the sip guidelines document that says that headers should not alter the
basic functional processing of a request. This was one of the problems with
the original Also proposal.

So, I still believe that the best solution is REFER that generates an
automatic NOTIFY. I think the idea of including a header in the request
which tells you whether to send the notify or not is acceptable.

-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: Sean Olson [mailto:[email-masked]]
> Sent: Friday, December 22, 2000 3:33 PM
> To: Billy Biggs
> Cc: Henning G. Schulzrinne; Rohan Mahy; Robert Sparks; Jonathan
> Rosenberg; [email-masked]
> Subject: Re: [SIP] Solving the REFER retransmit issue
> 
> 
> 
> Billy Biggs wrote:
> > 
> > Sean Olson ([email-masked]):
> > 
> > > I have to confess that I prefer the notion of a REFER 
> that is outside
> > > of any active (INVITE) session. Separating the REFER and 
> INVITE seems
> > > the most natural to me. In this case, there would be no 
> re-INVITE to
> > > carry this header (if I understand your suggestion correctly)
> > 
> >   In order to perform transfer, the REFER must be related 
> to an active
> > session.  Otherwise you can't simulate PBX transfer where a 
> single line
> > is replaced with a new call to a seperate endpoint.
> 
> This is of course a very important application of REFER and as you 
> point out requires a way to relate the REFER to an ongoing session.
> What I am arguing for is simply an independence of the ongoing session
> and the REFER transaction. The failure or success of the REFER
> transaction
> should not imply a BYE. (This is in fact already a requirement in the 
> transfer draft). I think I may have misinterpreted your previous
> comments.
> 
> I also like the ability to use REFER for applications other than 
> call transfer. This may be completely out of scope for the REFER
> mechanism.
> If this is the consensus of the mailing list, I would like to see it 
> explicitly stated in the transfer draft (it would become a 
> MUST that if
> the Refer-To:
> URL was a SIP URL that contained a method parameter other 
> than "INVITE",
> the REFER
> would be rejected with a 4xx response).
> 
> > 
> >   I see REFER as a very point-to-point interaction, and therefore it
> > doesn't make sense with forking.  You want to REFER a 
> single endpoint to
> > a URI to avoid spamming the destination with multiple 
> requests.  This
> > doesn't make sense to me outside of an active session.
> > 
> 
> I don't agree. But even if you want a point-to-point mode of
> interaction,
> you don't necessarily need an active session to accomplish this. There
> are many ways to determine the Contact: address of a specific UA
> including
> "out-of-band" mechanisms that don't require an active session.
> 
> > > What I would prefer to see is a NOTIFY sent for responses with the
> > > REFER acting as an implicit SUBSCRIBE and a new 
> Refer-Notify: header
> > > in the REFER request which would indicate the desire to 
> receive such
> > > notifications.
> > >
> > > [...]
> > >
> > > I think this will allow for the most common cases without 
> incurring
> > > any great overhead or restricting the possibilities.
> > 
> >   Maybe if the NOTIFY and the REFER can both contain SDP, 
> and that a BYE
> > infers that no subsequent NOTIFY will be sent.  Otherwise 
> you have to
> > keep alot of state in the endpoints, and 
> post-transfer-failure recovery
> > will take quite a while.
> >
> 
> The type of information I envisioned being transferred in the NOTIFYs
> was
> zero or more provisional response codes and a single final response
> code.
> No SDP and no headers. Literally:
> 
> NOTIFY <Refer-Notify: address> SIP/2.0
> From: (The To: of the REFER)
> To:  (The From: of the REFER)
> Call-ID: (The Call-ID: of the REFER)
> CSeq: ...
> Event: refer-final-response;response="200 OK"
> Expires: 0
> Content-Length: 0
> 
> /sean
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Billy Biggs <[email-masked]>
Date: Fri, 22 Dec 2000 16:03:13 -0600

Jonathan Rosenberg ([email-masked]):

> case REFER means refer, and nothing else; i.e., don't use a header in
> an INVITE, since INVITE is not a transfer/refer function. There is
> something in the sip guidelines document that says that headers should
> not alter the basic functional processing of a request. This was one
> of the problems with the original Also proposal.

  In our proposal, the INVITE semantics are preserved.  The referred
user wishes to renegotiate the old session, and wishes the phone at the
far end to ring.  The header does not alter the functional processing,
but rather indicates that this re-INVITE is because a response arrived
to the spawned call.

  This is both simple and explicit.

> automatic NOTIFY. I think the idea of including a header in the
> request which tells you whether to send the notify or not is
> acceptable.

  This might be alright, but how about:

  1) No NOTIFY is sent if the referred party shuts down the call leg
     with a BYE.

  2) The NOTIFY and REFER may contain SDP.

  I want, for a failed transfer scenario:

       Referrer             Referred Party
         ---- REFER (hold SDP) -->
         <--- OK (hold SDP) ------

             (after failed INVITE)
         <- NOTIFY (active SDP) --
         -- OK (active SDP) ----->

  Message Count: 4

  I want to avoid this:

       Referrer             Referred Party
         --- INVITE/OK/ACK (hold) -->
         ------ REFER -------------->
         <----- OK ------------------

             (after failed INVITE)
         <-- NOTIFY -----------------
         --- OK -------------------->
         <-- INVITE/OK/ACK (active) -

   Message Count: 10

  Each device has to maintain state for where it is in the sequence, and
recovering the old session from a failed transfer now takes alot more
time (the NOTIFY and then the INVITE).

-- 
Billy Biggs                         [email-masked]
http://www.div8.net/billy/      [email-masked]

---

From: Billy Biggs <[email-masked]>
Date: Fri, 22 Dec 2000 16:03:13 -0600

Referrer             Referred Party

             (after failed INVITE)

  Message Count: 4

  I want to avoid this:

       Referrer             Referred Party

             (after failed INVITE)

   Message Count: 10

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 29 Dec 2000 14:16:11 -0600

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, December 22, 2000 3:19 PM
> To: 'Sean Olson'; Billy Biggs
> Subject: RE: [SIP] Solving the REFER retransmit issue
>
>

These are very good principles which we should try to follow more often.

> which tells you whether to send the notify or not is acceptable.

It seems to me that an automatic NOTIFY is an implied subscription, thus at
odds with your design principle number 2. From a software perspective, I
find Robert's proposal of an explicit SUBSCRIBE _if_you_care_ to be a very
elegant approach.

I realize this creates additional message overhead in the case where the
REFER-or cares about the results. However, if present day PSTN stuff is an
example, I fully expect the vast majority of REFER applications to _not_
care about the results (e.g. blind transfer or similar). In this case, the
implied subscription actually creates additional message overhead. If my
assumption that the trivial case will be the most common proves correct,
then the explicit-subscription-if-one-cares approach becomes the most
efficient overall.

Also, the explicit subscribe approach is a _good_ example of principle 3, to
keep things separate so they can be recombined in new ways. This is in fact
a creative combination of the separate mechanism of REFER and SUBSCRIBE.

Finally (see, I will get all three principles in here) what we really have
here is a transaction model where the results are determined asynchronously.
This is a general problem which we are likely to see occur again with other
extensions (and in fact we have in SIMPLE, with SUBSCRIBE/QAUTH). If I
recall correctly (which is not a given) from early discussions, one of your
early ideas for SUBSCRIBE/QAUTH was almost identical to this approach (i.e.
explicit subscription for results). I think I opposed it then as too
complex, but in light of the REFER issue, I see it's value.

Thanks!
Ben Campbell.

---

From: Billy Biggs <[email-masked]>
Date: Fri, 29 Dec 2000 15:30:44 -0600

Ben Campbell ([email-masked]):

> I realize this creates additional message overhead in the case where
> the REFER-or cares about the results. However, if present day PSTN
> stuff is an example, I fully expect the vast majority of REFER
> applications to _not_ care about the results (e.g. blind transfer or
> similar). In this case, the implied subscription actually creates
> additional message overhead. [...]

  Attended transfer (call handoff) is the primitve necessary for most
advanced phone services.  Say B is in a 3-way call:

                       A       C
                         \   /
                           B

  B needs to know when A has successfully contacted C so it can
terminate its calls.

  In any reasonable phone system, the handoff has to be close to
instantaneous.  This is at odds with suggestions that:

 - B SUBSCRIBE'ing to A before getting back a response.
 - A sending a NOTIFY before a re-INVITE or BYE.
 - ...

  Please, consider implementation pain and message verbosity.

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

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 29 Dec 2000 15:54:39 -0600

> From: Billy Biggs [mailto:[email-masked]]
> Sent: Friday, December 29, 2000 3:31 PM
> To: Ben Campbell
> Cc: Jonathan Rosenberg; Henning G. Schulzrinne; Rohan Mahy; Robert
> Sparks; SIP List; Sean Olson

I do not suggest that attended transfer is unimportant, merely that blind
transfers will probably happen more often in the SIP world at large. While
attended transfer is a primitive of advanced services, blind transfer is an
extremely commonly used _simple_ service. I prefer to optimize for the
simple case, and make the advanced case do a bit more work than the other
way around. The timing expectations for an attended transfer may be tight,
but they are even tighter for an unattended transfer.

>   Please, consider implementation pain and message verbosity.

I did not see any proposal that said B _must_ wait for the notify to send a
BYE. I suspect that would be a common implementation, but B _could_ send a
bye immediately, then if it later received a NOTIFY indicating failure, it
could notify the user, invite A to a new call, or whatever behavior makes
the most sense in the situation.

---

From: Billy Biggs <[email-masked]>
Date: Fri, 29 Dec 2000 16:20:17 -0600

Ben Campbell ([email-masked]):

> >   Attended transfer (call handoff) is the primitve necessary for
> > most advanced phone services.  Say B is in a 3-way call:
> 
> I do not suggest that attended transfer is unimportant, merely that
> blind transfers will probably happen more often in the SIP world at
> large. While attended transfer is a primitive of advanced services,
> blind transfer is an extremely commonly used _simple_ service. I
> prefer to optimize for the simple case, and make the advanced case do
> a bit more work than the other way around. The timing expectations for
> an attended transfer may be tight, but they are even tighter for an
> unattended transfer.

  I want a BYE to indicate that no indication of success or failure will
be sent, and a BYE from the referrer to indicate that no indication
should be sent.  This solves everything nicely.

> I did not see any proposal that said B _must_ wait for the notify to
> send a BYE. I suspect that would be a common implementation, but B
> _could_ send a bye immediately, then if it later received a NOTIFY
> indicating failure, it could notify the user, invite A to a new call,
> or whatever behavior makes the most sense in the situation.

  That seems a little backwards.  To me, the referred party should
decide if it still wants to talk to the referrer.

  In my proposal, an INVITE with a 'Refer-Response' header indicates
'I'm done so please re-negotiate this session'.  This is both explicit
and simple.

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 29 Dec 2000 16:25:43 -0600

> 'I'm done so please re-negotiate this session'.  This is both explicit

But not general. It seems to me to only make sense if the REFER is for a
transfer, or at least as a result of an existing call leg. The SUBSCRIBE
approach could be useful for any situation where the results of a request
can not be determined in a specific (short) time period.

---

From: Billy Biggs <[email-masked]>
Date: Sat, 30 Dec 2000 10:01:22 -0500

Ben Campbell ([email-masked]):

> > 'I'm done so please re-negotiate this session'.  This is both
> > explicit and simple.
> 
> But not general. It seems to me to only make sense if the REFER is for
> a transfer, or at least as a result of an existing call leg. The
> SUBSCRIBE approach could be useful for any situation where the results
> of a request can not be determined in a specific (short) time period.

  Using REFER to do anything other than transfer turns it into a control
protocol.  Using REFER outside of an existing call leg doesn't make
sense.

---

From: "Ben Campbell" <[email-masked]>
Date: Sat, 30 Dec 2000 10:07:23 -0600

The current REFER draft very specifically does not require a call leg
context. That is a different argument than this one entirely. If we wish to
change that, we can, but until we choose to do so, the solution to the
retransmit problem should not restrict this usage.

> Sent: Saturday, December 30, 2000 9:01 AM
> To: Ben Campbell