Subject: [SIP] Solving the REFER retransmit issue

From: "Robert Sparks" <[email-masked]>
Date: Tue, 12 Dec 2000 11:53:22 -0600

The presentation of status of REFER and the discussion of the
REFER timeout issue is at
http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe
r-02.htm

Rohan Mahy also proposed an optimization of 2 where the REFER
was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress
of the REFERed action would just happen and could be ignored/481'ed
if the the REFERing agent didn't care.

Jonathan R. stated that 2) requires any agent accepting a REFER to
implement being an event server (must implement accepting and
managing subscriptions), and this is asking too much.

Discussion?

RjS

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

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Wed, 13 Dec 2000 14:37:25 +0530

Well, I go back to my suggestion(rather a question I posed for Rohan) of
forwarding provisionals received for INVITES initiated by the UA that is
processing the INVITE :-) instead of using an explicit SUBSCRIBE/NOTIFY
mechanism. With this approach all the UA would do have to do is to forward
any message that it receives in response to an INVITE it issued (after
suitably modifying the callID/From and To fields to match the one for the
REFER request which triggered this INVITE). Any UA that doesn't want to
about what happened to a REFER request it issues could explicitely specify
so using the Request-Disposition header (caller preferences).
Any repercussions with this ?
Venkatesh

---

From: "Robert Sparks" <[email-masked]>
Date: Wed, 13 Dec 2000 11:31:35 -0600

The problem is that the REFER transaction itself will timeout
if the referred action (INVITE for example) takes longer than
the run of REFER retransmits to complete.

RjS

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Venkatesh
> Venkataramanan
> Sent: Wednesday, December 13, 2000 3:07 AM
> To: Robert Sparks; [email-masked]
> Subject: Re: [SIP] Solving the REFER retransmit issue
>
>

---

From: "Steve Donovan" <[email-masked]>
Date: Wed, 13 Dec 2000 22:59:39 -0600

It seems to me that we have another alternative that I believe has been
presented previously and maybe prematurely dismissed.

Part of the problem is that we have two state machines upon which to base
new methods.  One is modeled after the INVITE transaction and the other
modeled after the BYE transaction.  The first allows for indefinite wait
periods before a final response.  The second does not.

Option number three from the SIP WG meeting was -

"Use the current mechanism if the requested action completes within ~1/2 the
UDP timer retransmission runout, otherwise use solution 2."

This implies the creation of a REFER specific state machine, with the
addition of sending something like a 202 final response if the real final
response is not known.

If we are entertaining adding a new state machine, why not add the one that
solves the real problem and create a third transaction model that is a mix
of the two existing models.  This would be a request, response transaction
that allows for indefinite wait periods between the request and the final
response.

I suspect the knee jerk reaction will be against this proposal.  But before
reacting, please consider the probability that the most viable solution that
does not require a new state machine is mandating that user agents
supporting REFER also implement SIP Events.  This will likely either slow
down the implementation of REFER or result in many clients that do not
support it at all (something that would not be good).

I would rather have the flexibility of a third transaction state machine
model then to increase the complexity of user agents supporting REFER.

Regards,

Steve

> [mailto:[email-masked]]On Behalf Of Robert Sparks
> Sent: Tuesday, December 12, 2000 11:53 AM
> To: [email-masked]

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Thu, 14 Dec 2000 11:33:09 +0530

----- Original Message -----
From: "Steve Donovan" <[email-masked]>
To: "Robert Sparks" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 14, 2000 10:29 AM
Subject: RE: [SIP] Solving the REFER retransmit issue

> that allows for indefinite wait periods between the request and the final

If I interpret this correctly, this new state machine removes any timer
restrictions for receiving a final response. The retransmission of the REFER
continues until the final response is received to ensure reliability of the
final response?

---

From: "Steve Donovan" <[email-masked]>
Date: Thu, 14 Dec 2000 11:06:42 -0600

<snip>

> continues until the final response is received to ensure

Yes, this is the wart associated with this solution.  If we do away with the
ACK as a method of confirming receipt of the final response then we need to
periodically retry the request.  This would need to be done frequently
enough that the UAS will receive it before it deletes the transaction.  This
would likely be every 16 seconds.

The solution to this would be to use the INVITE transaction model and have
an ACK to the final response to a REFER request.

<snip>---

Steven R. Donovan
Architect                           dynamicsoft
mailto:[email-masked]     5100 Tennyson Parkway
sip:[email-masked]    Plano, Texas 75025
tel:+1-972-473-5469                 http://www.dynamicsoft.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Dec 2000 19:13:47 +0200

Hello,

If we go for the immediate complexion of the REFER transaction, a UA
implementing REFER but not SUBSCRIBE/NOTIFY can still make blind
transfer (the UA will not be aware of the result of the REFER). Thus, it
works for simple implementations. They can get the basic service.

If you want a more advanced implementation, you will have to implement
SUBSCRIBE/NOTIFY to get a report of the result of the REFER.

If we go for a third state machine, we have to update all the SIP server
in order to uderstand REFER. I do not like this idea. I would argue that
if you want to create a new state machine for REFER, there will be folks
that want to create a new state machine for PRACK (no 200 OK), and so
on...

I would go for the first solucion: The REFER transaction is finished as
soon as possible and the status report is sent using NOTIFY.

Regards,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: "Robert Sparks" <[email-masked]>
Date: Thu, 14 Dec 2000 11:50:44 -0600

> [mailto:[email-masked]]On Behalf Of Gonzalo Camarillo
> Hello,
> 
<snip>

Since you say the UA will not be aware of the result of the REFER,
I assume you are talking about the UA that issued the REFER. 

What about the UA that receives and responds to the REFER? What 
breaks if we go with option 2) from the slide and this UA chooses
not to implement SUBSCRIBE/NOTIFY? Certainly any application that
relies on getting the final result of the referred action back
to the referror. Does the referror need know ahead of time that
there's no way to get this information so that it doesn't offer those
applications? If so, can that need be met using Require:?

RjS

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 14 Dec 2000 22:44:08 -0500

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.

The 200 response could contain the same header to indicate
the meaning of the 200.  Notice that the new header would
only be a preference in request.  If the receiver does not
support or want to perform "notify", it could try the
next list preference.  If it doesn't support the header or it is
not present, it defaults to acting like header with "refer".

---

From: "Venkatesh Venkataramanan" <[email-masked]>
Date: Fri, 15 Dec 2000 14:07:58 +0530

I am kind of lost here. How does one provide reliability of final responses
with this scheme?  Say I initiated a refer with refer-disposition-response
as "final" or "notify" or "notify-failure". I am assuming that "final" in
the refer-disposition-response will automatically trigger a 200 OK for the
initial refer so as to prevent the REFER request from timing out (so a
"refer" in the refer-response-disposition is implied or should be added
explicitly to avoid timeouts which we are trying to address). But at a later
time, say the recipient of REFER wants to send a 200 OK to indicate
successful completion of the request (or alternatively failure of
completion). How would reliability of this response be assured?

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 15 Dec 2000 09:12:28 -0500

The choice of "final" would act as it does today and
thus would not be the most desirable choice unless
the request is expected to finish within 10 retries of
the REFER and the NOTIFY is not supported.
This would be idle when triggering a BYE or CANCEL.
It also accommodates Jonathan's concern about
requiring support of NOTIFY.  Notice that header
would also be include in the response to explicitly
state how the 200 should be interpreted.

The choice of "notify" would basically get a 200 REFER
immediately and a NOTIFY once a final response has
be determined for the REFER triggered method.
This would be ideal when triggering an INVITE.

The choice of "notify-failure" would act like "notify"
but the NOTIFY would only be sent only in failure
situations.  This would be useful in many situations
but especially useful for failed call transfer attempts.

----- Original Message -----
From: "Venkatesh Venkataramanan" <[email-masked]>
To: "Brett Tate" <[email-masked]>; "Sip Mail List"
<[email-masked]>
Sent: Friday, December 15, 2000 3:37 AM
Subject: Re: [SIP] Solving the REFER retransmit issue