Subject: [SIP] Multiple-Transaction REFER

From: Billy Biggs <[email-masked]>
Date: Tue, 28 Nov 2000 12:31:10 -0600

As pointed out earlier by Jonathan, the single-transaction REFER
mechanism fails as the REFER may time out.  To clean things up, the
suggestion is to split up REFER into a sequence of transactions.

  To start discussion, here are some ideas:

1. REFER looks the same, but it is responded with a 2xx if the far end
   accepts the REFER and intends to act upon it.

2. A REFERDONE request which signals back that the spawned INVITE
   completed.  Success or failure is indicated in some header (or in the
   body?).  This request requires a header, Refer-CSeq or similar, to
   indicate which REFER transaction is being completed.

  Optionally:

3. A REFERSTATUS request which can signal back the call setup progress.
   Requires a Refer-CSeq header.  Optional support by both UAs.

4. A REFERCANCEL request which can attempt to cancel a pending REFER.
   Requires a Refer-CSeq header.  Optional support by both UAs.

-- 
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: "Robert Sparks" <[email-masked]>
Date: Wed, 29 Nov 2000 10:57:20 -0600

Lets revisit the root of the time-out problem mentioned below.

REFER as currently written waits until the referenced action
completes before returning its final response. This runs into
trouble if any of the participating UAs (including any proxies
in the path of the request) decide the request has been pending
too long and do whatever they do on a time-out.

I've been reviewing 10.4.1 and 10.4.2 and currently I can't see
where that time-out (for non-INVITE messages) is defined by the
protocol. It seems to be left up to the application.

10.4.1 specifies when the request will stop being retransmitted
in absence of a final response, but doesn't say when the client
gives up on the request after the last retransmission.

10.4.2 even more explicitly leaves this in the applications hands:
  Clients using a reliable transport protocol such as TCP, SCTP
  or TLS do not need to retransmit requests, but MAY give up
  after receiving no response for an extended period of time.

Perhaps we need clarification of behavior here. Would it be worth
standardizing a default interpretation of Expires (using the
INVITE behavior) for all requests where it doesn't have specialized
meaning (like REGISTER).

If we went down that path, we could also recommend behavior for how
long to wait after that last retransmission. In particular, recommend
extending that timeout in the face of provisional responses.

There are places other than REFER where this issue will cause grief.

The response to the sip-events SUBSCRIBE request might need time to
obtain authorizations. Processing QAUTH in sip-for-presence may involve
user interaction.

Comments?

RjS

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Billy Biggs
> Sent: Tuesday, November 28, 2000 12:31 PM
> To: Robert Sparks
> Cc: SIP List
> Subject: [SIP] Multiple-Transaction REFER
> 
>

---

From: Billy Biggs <[email-masked]>
Date: Wed, 29 Nov 2000 11:20:02 -0600

Robert Sparks ([email-masked]):

> I've been reviewing 10.4.1 and 10.4.2 and currently I can't see where
> that time-out (for non-INVITE messages) is defined by the protocol. It
> seems to be left up to the application.
> 
> 10.4.1 specifies when the request will stop being retransmitted in
> absence of a final response, but doesn't say when the client gives up
> on the request after the last retransmission.

  If the retransmissions stop, there is no way to reliably receive the
response.

> standardizing a default interpretation of Expires (using the INVITE
> behavior) for all requests where it doesn't have specialized meaning
> (like REGISTER).

  I like Expires how it is.  For SUBSCRIBE, Expires dictates how long
the subscription should last.  I'm sure new extensions will have uses
for Expires.

  In my multi-transaction proposal, an expires in the original REFER
could mean the time in which it must receive a REFERDONE.  This seems
more clean.

> obtain authorizations. Processing QAUTH in sip-for-presence may
> involve user interaction.

  I don't like having transactions outstanding for too long.  The
retransmission model breaks for everything except INVITE.  If half a
minute doesn't seem reasonable for these authorizations or user
interaction, then the process must be extended to multiple transactions.