datatracker.ietf.org
Sign in
Version 5.12.0, 2015-02-26
Report a bug

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

Document type: RFC - Proposed Standard (January 2006; No errata)
Updates RFC 3261
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4320 (Proposed Standard)
Responsible AD: Allison Mankin
Send notices to: rohan@ekabal.com, rsparks@nostrum.com, dean.willis@softarmor.com

Network Working Group                                          R. Sparks
Request for Comments: 4320                              Estacado Systems
Updates: 3261                                               January 2006
Category: Standards Track

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

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes modifications to the Session Initiation
   Protocol (SIP) to address problems that have been identified with the
   SIP non-INVITE transaction.  These modifications reduce the
   probability of messages losing the race condition inherent in the
   non-INVITE transaction and reduce useless network traffic.  They also
   improve the robustness of SIP networks when elements stop responding.
   These changes update behavior 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

Sparks                      Standards Track                     [Page 1]
RFC 4320                 SIP Non-INVITE Actions             January 2006

1.  Introduction

   There are a number of unpleasant edge conditions created by the SIP
   non-INVITE transaction (NIT) model's fixed duration.  The negative
   aspects of some of these are exacerbated by the effect that
   provisional responses have on the non-INVITE transaction state
   machines.  These problems are documented in [3].  In summary:

      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] to improve the
   behavior of SIP elements when these edge conditions arise.

2.  Improving the Situation When Responses Are Only Delayed

   There are two goals to achieve when we constrain the problem to those
   cases where all elements are ultimately responsive and networks
   ultimately deliver messages:

   o  Reduce the probability of losing the race, preferably to the point
      that it is negligible

   o  Reduce or eliminate useless messaging

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

   o  Disallow non-100 provisionals to non-INVITE requests

   o  Disallow 100 Trying to non-INVITE requests before Timer E reaches
      T2 (for UDP hops)

   o  Allow 100 Trying after Timer E reaches T2 (for UDP hops)

   o  Allow 100 Trying for hops over reliable transports

Sparks                      Standards Track                     [Page 2]
RFC 4320                 SIP Non-INVITE Actions             January 2006

   Since non-INVITE transactions must complete rapidly ([3]), any
   information beyond "I'm here" (which can be provided by a 100 Trying)
   can be just as usefully delayed to the final response.  Sending non-
   100 provisionals wastes bandwidth.

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

   Without a provisional, a late final response is the same as no
   response at all and will likely result in blacklisting the late-

[include full document text]