Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
RFC 4321

Document Type RFC - Informational (January 2006; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4321 (Informational)
Telechat date
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: 4321                              Estacado Systems
Category: Informational                                     January 2006

                Problems Identified Associated with the
       Session Initiation Protocol's (SIP) Non-INVITE Transaction

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes several problems that have been identified
   with the Session Initiation Protocol's (SIP) non-INVITE transaction.

Table of Contents

   1. Problems under the Current Specifications .......................2
      1.1. NITs must complete immediately or risk losing a race .......2
      1.2. Provisional responses can delay recovery from lost
           final responses ............................................3
      1.3. Delayed responses will temporarily blacklist an element ....4
      1.4. 408 for non-INVITE is not useful ...........................6
      1.5. Non-INVITE timeouts doom forking proxies ...................7
      1.6. Mismatched timer values make winning the race harder .......7
   2. Security Considerations .........................................8
   3. Acknowledgements ................................................8
   4. Informative References ..........................................9

Sparks                       Informational                      [Page 1]
RFC 4321                SIP Non-INVITE Problems             January 2006

1.  Problems under the Current Specifications

   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 as currently defined.

1.1.  NITs must complete immediately or risk losing a race

   The non-INVITE transaction defined in RFC 3261 [1] is designed to
   have a fixed and finite duration (dependent on T1).  A consequence of
   this design is that participants must strive to complete the
   transaction as quickly as possible.  Consider the race condition
   shown in Figure 1.

                         UAC           UAS
                          |   request   |
                     ---  |---.         |
                      ^   |    `---.    |
                      |   |         `-->|  ---
                      |   |             |   ^
                      |   |             |   |
                    64*T1 |             |   |
                      |   |             |   |
                      |   |             | 64*T1
                      |   |             |   |
                      |   |             |   |
                      v   |             |   |
        timeout <=== ---  |   200 OK    |   |
                          |         .---|   v
                          |    .---'    |  ---
                          |<--'         |

                Figure 1: Non-Invite Race Condition

   The User Agent Server (UAS) in this figure believes it has responded
   to the request in time, and that the request succeeded.  The User
   Agent Client (UAC), on the other hand, believes the request has
   timed-out, hence failed.  No longer having a matching client
   transaction, the UAC core will ignore what it believes to be a
   spurious response.  As far as the UAC is concerned, it received no
   response at all to its request.  The ultimate result is that the UAS
   and UAC have conflicting views of the outcome of the transaction.

Sparks                       Informational                      [Page 2]
RFC 4321                SIP Non-INVITE Problems             January 2006

   Therefore, a UAS cannot wait until the last possible moment to send a
   final response within a NIT.  It must, instead, send its response so
   that it will arrive at the UAC before that UAC times out.
   Unfortunately, the UAS has no way to accurately measure the
   propagation time of the request or predict the propagation time of
   the response.  The uncertainty it faces is compounded by each proxy
   that participates in the transaction.  Thus, the UAS's only choice is
   to send its final response as soon as it possibly can and hope for
   the best.

   This result constrains the set of problems that can be solved with a
   single NIT.  Any delay introduced during processing of a request
   increases the probability of losing the race.  If the timing
   characteristics of that processing are not predictable and
Show full document text