RFC 3487 (rfc3487) - Page 2 of 17


Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)



Alternative Format: Original Text Document



RFC 3487                IEPREP SIP Requirements            February 2003


1.  Introduction

   During emergencies, communications resources including telephone
   circuits, IP bandwidth and gateways between the circuit-switched and
   IP networks may become congested.  Congestion can occur due to heavy
   usage, loss of resources caused by the natural or man-made disaster
   and attacks on the network during man-made emergencies.  This
   congestion may make it difficult for persons charged with emergency
   assistance, recovery or law enforcement to coordinate their efforts.
   As IP networks become part of converged or hybrid networks along with
   public and private circuit-switched (telephone) networks, it becomes
   necessary to ensure that these networks can assist during such
   emergencies.

   There are many IP-based services that can assist during emergencies.
   This memo only covers requirements for real-time communications
   applications involving the Session Initiation Protocol (SIP) [1],
   including voice-over-IP, multimedia conferencing and instant
   messaging/presence.

   This document takes no position as to which mode of communication is
   preferred during an emergency, as such discussion appears to be of
   little practical value.  Based on past experience, real-time
   communications is likely to be an important component of any overall
   suite of applications, particularly for coordination of emergency-
   related efforts.

   As we will describe in detail below, such Session Initiation Protocol
   (SIP) [1] applications involve at least five different resources that
   may become scarce and congested during emergencies.  In order to
   improve emergency response, it may become necessary to prioritize
   access to such resources during periods of emergency-induced resource
   scarcity.  We call this "resource prioritization".

   This document describes requirements rather than possible existing or
   new protocol features.  Although it is scoped to deal with SIP-based
   applications, this should not be taken to imply that mechanisms have
   to be SIP protocol features such as header fields, methods or URI
   parameters.

   The document is organized as follows.  In Section 2, we explain core
   technical terms and acronyms that are used throughout the document.
   Section 3 describes the five types of resources that may be subject
   to resource prioritization.  Section 4 enumerates four network
   hybrids that determine which of these resources are relevant.  Since
   the design choices may be constrained by the assumptions placed on





Schulzrinne                  Informational