RFC 4320

Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction ✨

Okay bestie, let's get into RFC 4320 🎀. The title block is giving: it's by Robert J. Sparks (listed as R. Sparks) at Estacado Systems, dated January 2006. It's on the Standards Track 🔥, so it's specifying an actual protocol, not just vibing about one. It updates RFC 3261, and that's the only update listed. There's no obsoletes entry in the header, so it's not replacing anything 💜. It's a Network Working Group document, which is the Internet standards crew.

Status of This Memo 📜

Quick legal babe moment 💅: this is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🫶. If you want the official standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.

Copyright Notice 🌈

Copyright (C) The Internet Society (2006) ✨.

Abstract 🦋

This doc describes changes to SIP to fix problems that got identified with the SIP non-INVITE transaction 🔧. The changes cut down the chance that messages lose the race that's built into the non-INVITE transaction, and they cut down on useless network traffic 🙅‍♀️. They also make SIP networks more robust when elements stop responding 💪. These changes update behavior that was defined in RFC 3261.

Table of Contents 🧚

   1. Introduction ....................................................2
   2. Improving the Situation When Responses Are Only Delayed .........2
      2.1. Action 1: Make the best use of provisional responses .......2
      2.2. Action 2: Remove the useless late-response storm ...........3
   3. Improving the Situation When an Element Is Not Going to
      Respond .........................................................4
   4. Normative Updates to RFC 3261 ...................................4
      4.1. Action 1 ...................................................4
      4.2. Action 2 ...................................................5
   5. Security Considerations .........................................5
   6. Contributors ....................................................5
   7. Normative References ............................................6

1. Introduction 💖

Okay so the SIP non-INVITE transaction (NIT) model has a fixed duration, and that creates a bunch of unpleasant edge conditions 😭. Some of them get worse because provisional responses mess with the non-INVITE transaction state machines 💀. These problems are written up in [3]. The highlights:

• A non-INVITE transaction must complete immediately or risk losing a race
• Losing the race will cause the requester to stop sending traffic to the responder (the responder will be temporarily blacklisted)
• Provisional responses can delay recovery from lost final responses
• The 408 response is useless for the non-INVITE transaction
• As non-INVITE transactions through N proxies time-out, there can be an O(N^2) storm of the useless 408 responses

This document specifies updates to RFC 3261 [1] so SIP elements behave better when these edge conditions show up 🎀✨.

2. Improving the Situation When Responses Are Only Delayed ⏰

Here's the goal when we only look at the cases where every element is eventually responsive and the networks eventually deliver messages 🫶. There are two things we want:

• Reduce the probability of losing the race, preferably to the point that it is negligible
• Reduce or eliminate useless messaging

2.1. Action 1: Make the best use of provisional responses 🍓

• Disallow non-100 provisionals to non-INVITE requests
• Disallow 100 Trying to non-INVITE requests before Timer E reaches T2 (for UDP hops)
• Allow 100 Trying after Timer E reaches T2 (for UDP hops)
• Allow 100 Trying for hops over reliable transports

Since non-INVITE transactions have to finish fast ([3]), anything beyond "I'm here" (which a 100 Trying already covers) can wait and go in the final response, and it'll be just as useful 🧠. Sending non-100 provisionals just wastes bandwidth 🙄.

As shown in [3], sending any provisional response inside a NIT before Timer E reaches T2 messes up recovery from an unreliable transport failure 😬.

Without a provisional, a late final response is the same as no response at all, and that'll probably get the late-responding element blacklisted ([3]) 💔. If an element is delaying its final response at all, sending a 100 Trying after Timer E reaches T2 stops that blacklisting without wrecking recovery from unreliable transport failure 🙌.

Blacklisting on a late response also happens over reliable transports 👀. So if an element handling a request from a reliable transport is delaying its final response at all, sending a 100 Trying well before the timeout will prevent the blacklisting 💅. Sending a 100 Trying right away won't hurt the transaction the way it would over UDP, but sending one every single time creates unnecessary traffic. A reasonable compromise is to send the 100 Trying after the period of time in which Timer E would have reached T2 if this had been a UDP hop 🦋.

2.2. Action 2: Remove the useless late-response storm 🗑️

• Disallow 408 to non-INVITE requests
• Absorb stray non-INVITE responses at proxies

A 408 to a non-INVITE will always show up too late to be useful ([3]), since the client already knows exactly when the timeout is 🙃. The only info that message would carry is whether the server thought the transaction timed out. But with the current NIT design, a client can't do anything with that knowledge, so the 408 is just wasting network resources and adding to the response bombardment shown in [3] 💀.

Late non-INVITE responses, by definition, arrive after the client transaction's Timer F has fired and the client transaction has moved into the Terminated state 🕰️. That means they look exactly like strays and can't be told apart from them. Changing the behavior so proxies are not allowed to forward non-INVITE stray responses stops the late-response storm 🛑. It also makes the proxy's defenses better against malicious users who count on the RFC 3261 requirement to forward those strays 😤.

3. Improving the Situation When an Element Is Not Going to Respond 🚫

Now we zoom out to also deal with element or network failure, which means we have more goals 👑:

• Identifying when an element is non-responsive
• Minimizing or eliminating falsely identifying responsive elements as non-responsive
• Avoiding non-responsive elements with future requests

Action 1 handles the first two goals and totally levels up an element's ability to tell failure apart from a delayed response from the next downstream element 🔍. Some response, either provisional or final, will almost certainly come back before the transaction times out. So an element can more safely assume that no response at all means the peer isn't available, and then follow the existing requirements in [1] and [2] for that case 🫡.

The third goal needs more aggressive changes to the protocol 🥊. As [3] notes, future non-INVITE transactions are likely to fail again unless the implementation does more than what [1] and [2] define to remember non-responsive destinations between transactions 🧠. Standardizing those extra steps is left for future work 🔮.

4. Normative Updates to RFC 3261 📝

This is the part where the rules live, so pay attention bestie 👀.

4.1. Action 1 🍒

An SIP element MUST NOT send any provisional response with a Status-Code other than 100 to a non-INVITE request.

An SIP element MUST NOT respond to a non-INVITE request with a Status-Code of 100 over any unreliable transport, such as UDP, before the amount of time it takes a client transaction's Timer E to be reset to T2.

An SIP element MAY respond to a non-INVITE request with a Status-Code of 100 over a reliable transport at any time.

Without regard to transport, an SIP element MUST respond to a non-INVITE request with a Status-Code of 100 if it has not otherwise responded after the amount of time it takes a client transaction's Timer E to be reset to T2.

4.2. Action 2 🌸

A transaction-stateful SIP element MUST NOT send a response with Status-Code of 408 to a non-INVITE request. As a consequence, an element that cannot respond before the transaction expires will not send a final response at all.

A transaction-stateful SIP proxy MUST NOT send any response to a non-INVITE request unless it has a matching server transaction that is not in the Terminated state. As a consequence, this proxy will not forward any "late" non-INVITE responses.

Intellectual Property ✨

okay bestie, so the IETF is NOT picking a side 💅 on whether any intellectual property rights that might be claimed over the tech in this doc are valid, how far they reach, or whether any license for them is even available. it also doesn't claim it went looking for any of those rights on its own 🙈 if you want the rules on rights for RFC docs, check out BCP 78 and BCP 79 🎀

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of someone trying to get a general license or permission to use those proprietary rights for implementers or users of this spec, can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🦋

the IETF also invites any interested party to bring it up if there are any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. just send that info to ietf-ipr@ietf.org 💌🫶

Acknowledgement 🫶

funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 👑 and that's the whole tea, periodt 💖