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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Dec 2000 02:11:07 -0500

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, December 16, 2000 5:27 PM
> To: William Marshall
> Cc: [email-masked]
> Subject: Re: [SIP] Solving the REFER retransmit issue
> 
> 
> While I have some sympathy for allowing the 3-way handshake for REFER,
> I'm very concerned about the proxy backward compatibility issue. An
> "old" proxy that thinks REFER is just another non-INVITE and a new UAS
> that retransmits 200s until it gets an ACK will get not be happy
> together. (A UAS that doesn't know REFER is likely to respond
> immediately with a 400 and will likely just dump the ACK, so that
> variation seems less of a concern.) Thus, we at least need a
> Proxy-Require

Correct. And, according to the guidelines draft:

The Proxy-Require header should be avoided at all costs. The
          failure likelihood in an individual proxy stays constant, but
          the path failure grows exponentially with the number of hops.
          On the other hand, the Require header only mandates that a
          single entity, the UAS, support the extension. Usage of
          Proxy-Require is thus considered exponentially worse than
          usage of the Require header.

As we have other alternatives (basically, a "four-way" handshake, using a
two-way in each direction, works fine), this is simply a no go. So, lets
forget about any definitions of new reliability mechanisms or anything of
the sort.

Brett Tate writes:
> How about including a parameter or header in REFER
> which would indicate an ordered request preference for
> when to send 200 response?
> 
> Refer-Response-Disposition: 1#refer-response-param
> refer-response-param =
>  "refer" | "18x-final" | "final" | "notify" | "notify-failure" | token
> 
> "refer" means send 200 when get REFER.
> 
> "18x-final" means send final response when get 18x or final
> response for method request.
> 
> "final" means send final response when success or failure
> of method request is determined.
> 
> "notify" send 200 when get REFER and send NOTIFY
> with method final response.
> 
> "notify-failure" send 200 when get REFER and send
> NOTIFY when a failure of the method request is
> determined.

There is another axiom of IETF protocol design to consider here, from
rfc1958, which i think everyone should read:

3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

3.8 Avoid options and parameters whenever possible.  Any options and
   parameters should be configured or negotiated dynamically rather than
   manually.

A solution as Brett has proposed requires a whole lot of things to be
implemented, and will likely suffer from interop problems. Lets pick a
single solution. Whilst I still kind of like the hybrid "respond within 16
seconds, a 202 if you didn't get a response to the triggered request, 200 if
you did", I appreciate that this is also more of the protocol options I have
just argued against.

So, back to basics. The reason we built in this simple two way handshake
into non-INVITE methods was the assumption that they would be responded to
immediately, since an automata would answer, not a human. Lets keep with
that. REFER should generate an immediate response. I like Rohan's idea of
the NOTIFY (or something else) being sent later on when the request is
answered. This is easier than needing to support an actual presence server
in the UA, which would need to wait for SUBSCRIBE requests. 

-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

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

---

From: "Robert Sparks" <[email-masked]>
Date: Tue, 19 Dec 2000 12:57:59 -0600

> in the UA, which would need to wait for SUBSCRIBE requests.

I disagree with adding an implicit subscription with REFER. Assuming
we pull the events work together quickly (which I have no reason to
believe we won't), we have a solid primative in SUBSCRIBE that meets
the need.

If we pursued the implicit subscribe, I anticipate needing to add
parameters, starting with one to let the UA sending the REFER know
whether or not it should expect notifications.

Further, what would be different between this and REFERPROGRESS/REFERDONE
(that would be the "(or something else)" that would get sent later, yes)?

I'm leaning strongly towards REFER with a subsequent SUBSCRIBE if you
are interested in the results. Something like Require: referstatus could
be included in the REFER if the application knows it can't work without
status information. UAs that don't want to deal with receiving SUBSCRIBEs
can decline REFERs with that header. If the submitting UA wants to proceed
without status, it can resubmit the request without the Require:.

A UA receiving a REFER without that header can still offer progress
information by providing something to subscribe to in the response
(A Subscribe-To: header in the response or the like). The originating
UA can then choose whether or not SUBSCRIBE.

RjS

---

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

>believe we won't), we have a solid primative in SUBSCRIBE that meets

But it requires a) extra work on behalf of the referrer to send the
SUBSCRIBE, b) extra work on behalf of the referred to maintain the
subscription, and c) 4 extra unneeded messages (SUB, 200, and then the new
immediate NOTIFY/200 that says there is no information yet).

If folks don't like unsolicited NOTIFY / implicit SUBSCRIBE, then lets just
use a new method  (but please make it otherwise look like a NOTIFY).

thanks,
-rohan

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 21 Dec 2000 18:46:11 -0500

I agree.

I'm not exactly sure why it is wrong to allow notifications without
SUBSCRIBE. Much of the SUBSCRIBE machinery, such as the ability to do
something useful when the UA is off-line, coupling to REGISTER, etc. are
not applicable here. Authorization of the subscription isn't relevant
since the subscription request has been made already. Thus, is there
anything that breaks by allowing NOTIFYs without the explicit
subscription?

One minor objection is that simple end systems might want to REFER
without being bothered by NOTIFYs. However, given the SUBSCRIBE
overhead, I suspect that the overall message volume is still lower even
if some systems end up ditching NOTIFYs unopened. The first 405 will
presumably shut up the notifier.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

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

Rohan Mahy ([email-masked]):

> subscription, and c) 4 extra unneeded messages (SUB, 200, and then the
> new immediate NOTIFY/200 that says there is no information yet).
> 
> If folks don't like unsolicited NOTIFY / implicit SUBSCRIBE, then lets
> just use a new method  (but please make it otherwise look like a
> NOTIFY).

  Sending any other request is added work on behalf of the everybody,
and more unneeded messages.

  In all cases, after the new call is accepted or rejected the referred
party will send a re-INVITE to regain the session or a BYE to tear it
down.  The appropriate optimization is to place the REFER response as a
header in the re-INVITE.

  If you haven't yet, please see my 'Simple REFER Solution' post.  We
have implemented this and it works cleanly.

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 21 Dec 2000 18:59:18 -0500

Billy Biggs wrote:

> have implemented this and it works cleanly.

I think part of the problem might be that some of us differ in what we
would like to use REFER for. If only for transferring calls, a simple
mechanism of "call back if it didn't work out" (which I interpret
Billy's method to be) seems to work. It is not clear that this is
workable if REFER is treated as a means of executing a generic request
somewhere else, not limited to INVITE.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

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

Henning G. Schulzrinne ([email-masked]):

> Billy's method to be) seems to work.

  Close.  My method is re-INVITE if it didn't work out.  The session
remains until one of the two parties sends a BYE.

> It is not clear that this is workable if REFER is treated as a means
> of executing a generic request somewhere else, not limited to INVITE.

  And obfuscate this request in a URI?

  Is this a specific feature or just for protocol cleanness?  Executing
a generic request may have dangerous security implications.

  Regardless, you only need to know the "response" for INVITE requests
(for added security, simply 'success' or 'failure').  I like having no
implicit response method for the REFER.  If the referred party still
wants to talk to you, they can re-INVITE.

---

From: Sean Olson <[email-masked]>
Date: Fri, 22 Dec 2000 09:43:12 -0600

> a generic request may have dangerous security implications.

This is no more insecure than a REFER with INVITE as the method.
I actually like the idea of being able to REFER a SUBSCRIBE or
even a REGISTER. I realize the implications of this but I don't
think it's much different than receiving a REFER with an INVITE
for which you might be billed.

/sean

---

From: Billy Biggs <[email-masked]>
Date: Fri, 22 Dec 2000 10:29:53 -0600

Sean Olson ([email-masked]):

> > > It is not clear that this is workable if REFER is treated as a
> > > means of executing a generic request somewhere else, not limited
> > > to INVITE.
> > 
> >   Is this a specific feature or just for protocol cleanness?
> > Executing a generic request may have dangerous security
> > implications.
> 
> This is no more insecure than a REFER with INVITE as the method.  I
> actually like the idea of being able to REFER a SUBSCRIBE or even a
> REGISTER. I realize the implications of this but I don't think it's
> much different than receiving a REFER with an INVITE for which you
> might be billed.

  Do you need to know the response to the SUBSCRIBE/REGISTER?  If so,
can you live with it as a header in a re-INVITE?  It will save alot of
trouble, and optimizes the most common case.

---

From: Sean Olson <[email-masked]>
Date: Fri, 22 Dec 2000 10:56:27 -0600

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)

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. 

Refer-Notify: (name-addr | addr-spec)

If the Refer-Notify: header is present in the request, 
it indicates the desire to receive NOTIFYs for the responses.
If the Refer-Notify: header is present in the response,
it indicates that the receiver is willing to send NOTIFYs (of
course only applicable to a 2xx response to the REFER)

I think this will allow for the most common cases without
incurring any great overhead or restricting the possibilities.

/sean

---

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

Sean Olson ([email-masked]):

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

  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.

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

---

From: Sean Olson <[email-masked]>
Date: Fri, 22 Dec 2000 14:32:42 -0600

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

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

> keep alot of state in the endpoints, and post-transfer-failure recovery

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