Subject: [sipcore] RFC 3261, question on provisional timer

From: "Goren, Ofer (Ofer)" <[email-masked]>
Date: Thu, 3 Oct 2013 08:16:00 +0000

Hi.

According to RFC 3261, section 13.3.1.1:
   If the UAS desires an extended period of time to answer the INVITE,
   it will need to ask for an "extension" in order to prevent proxies
   from canceling the transaction.  A proxy has the option of canceling
   a transaction when there is a gap of 3 minutes between responses in a
   transaction.  To prevent cancellation, the UAS MUST send a non-100
   provisional response at every minute, to handle the possibility of
   lost provisional responses.

Does this mean that UACs should also reset their timer when receiving sequential provisional responses, or does this section only relevant to proxies?

Thanks!

Ofer

---

From: Brett Tate <[email-masked]>
Date: Thu, 3 Oct 2013 11:16:27 +0000

> Does this mean that UACs should also reset their timer 
> when receiving sequential provisional responses, or 
> does this section only relevant to proxies?

As shown within appendix A table 4, Timer C has been defined as a proxy INVITE transaction timer.

The UAC has other mechanisms to determine if a dialog is still active.  For instance, it can send UPDATE.  However, some vendors may choose to use Timer C since the alternative mechanisms are not always possible (e.g. UPDATE support is not mandatory).  Within the following link, Jonathan indicates that the UAs do whatever they want.

http://bugs.sipit.net/show_bug.cgi?id=706 

If you are not aware of it, you may interested in the following mailing list:

https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Thanks,
Brett

---

From: "Goren, Ofer (Ofer)" <[email-masked]>
Date: Thu, 3 Oct 2013 11:53:38 +0000

Hi Brett.

Thank you for the answer. It means that as a UAC, I can use timer C to "allow" the UAS extending the timer on its side, but this was not the original intension of the authors.
Correct?

Ofer

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: Thursday, October 03, 2013 2:16 PM
To: Goren, Ofer (Ofer); [email-masked]
Subject: RE: RFC 3261, question on provisional timer

> Does this mean that UACs should also reset their timer when receiving 
> sequential provisional responses, or does this section only relevant 
> to proxies?

Thanks,
Brett

---

From: Brett Tate <[email-masked]>
Date: Thu, 3 Oct 2013 12:06:40 +0000

> It means that as a UAC, I can use timer C to "allow" the 
> UAS extending the timer on its side, but this was not the
> original intension of the authors.
> Correct?

Yes.  However, a UAC can typically use a better mechanism such as UPDATE.  Timer C was introduced by RFC 3261.  Thus a UAC relying just upon Timer C would have interoperability issues with RFC 2543 devices.

> The UAC has other mechanisms to determine if a dialog is still active.
> For instance, it can send UPDATE.  However, some vendors may choose to
> use Timer C since the alternative mechanisms are not always possible
> (e.g. UPDATE support is not mandatory).  Within the following link,
> Jonathan indicates that the UAs do whatever they want.
>