rfc3261 session initiation protocol (sip) extension.txt

有关IMS SIP及Presence应用的RFC文档包

   request.  Registrations are one way to create this information, but
   not the only way.  Arbitrary mapping functions can be configured at
   the discretion of the administrator.

   Finally, it is important to note that in SIP, registration is used
   for routing incoming SIP requests and has no role in authorizing
   outgoing requests.  Authorization and authentication are handled in
   SIP either on a request-by-request basis with a challenge/response
   mechanism, or by using a lower layer scheme as discussed in Section
   26.

   The complete set of SIP message details for this registration example
   is in Section 24.1.

   Additional operations in SIP, such as querying for the capabilities
   of a SIP server or client using OPTIONS, or canceling a pending
   request using CANCEL, will be introduced in later sections.

5 Structure of the Protocol

   SIP is structured as a layered protocol, which means that its
   behavior is described in terms of a set of fairly independent
   processing stages with only a loose coupling between each stage.  The
   protocol behavior is described as layers for the purpose of
   presentation, allowing the description of functions common across
   elements in a single section.  It does not dictate an implementation
   in any way.  When we say that an element "contains" a layer, we mean
   it is compliant to the set of rules defined by that layer.

   Not every element specified by the protocol contains every layer.
   Furthermore, the elements specified by SIP are logical elements, not
   physical ones.  A physical realization can choose to act as different
   logical elements, perhaps even on a transaction-by-transaction basis.

   The lowest layer of SIP is its syntax and encoding.  Its encoding is
   specified using an augmented Backus-Naur Form grammar (BNF).  The
   complete BNF is specified in Section 25; an overview of a SIP
   message's structure can be found in Section 7.






Rosenberg, et. al.          Standards Track                    [Page 18]

RFC 3261            SIP: Session Initiation Protocol           June 2002


   The second layer is the transport layer.  It defines how a client
   sends requests and receives responses and how a server receives
   requests and sends responses over the network.  All SIP elements
   contain a transport layer.  The transport layer is described in
   Section 18.

   The third layer is the transaction layer.  Transactions are a
   fundamental component of SIP.  A transaction is a request sent by a
   client transaction (using the transport layer) to a server
   transaction, along with all responses to that request sent from the
   server transaction back to the client.  The transaction layer handles
   application-layer retransmissions, matching of responses to requests,
   and application-layer timeouts.  Any task that a user agent client
   (UAC) accomplishes takes place using a series of transactions.
   Discussion of transactions can be found in Section 17.  User agents
   contain a transaction layer, as do stateful proxies.  Stateless
   proxies do not contain a transaction layer.  The transaction layer
   has a client component (referred to as a client transaction) and a
   server component (referred to as a server transaction), each of which
   are represented by a finite state machine that is constructed to
   process a particular request.

   The layer above the transaction layer is called the transaction user
   (TU).  Each of the SIP entities, except the stateless proxy, is a
   transaction user.  When a TU wishes to send a request, it creates a
   client transaction instance and passes it the request along with the
   destination IP address, port, and transport to which to send the
   request.  A TU that creates a client transaction can also cancel it.
   When a client cancels a transaction, it requests that the server stop
   further processing, revert to the state that existed before the
   transaction was initiated, and generate a specific error response to
   that transaction.  This is done with a CANCEL request, which
   constitutes its own transaction, but references the transaction to be
   cancelled (Section 9).

   The SIP elements, that is, user agent clients and servers, stateless
   and stateful proxies and registrars, contain a core that
   distinguishes them from each other.  Cores, except for the stateless
   proxy, are transaction users.  While the behavior of the UAC and UAS
   cores depends on the method, there are some common rules for all
   methods (Section 8).  For a UAC, these rules govern the construction
   of a request; for a UAS, they govern the processing of a request and
   generating a response.  Since registrations play an important role in
   SIP, a UAS that handles a REGISTER is given the special name
   registrar.  Section 10 describes UAC and UAS core behavior for the
   REGISTER method.  Section 11 describes UAC and UAS core behavior for
   the OPTIONS method, used for determining the capabilities of a UA.




Rosenberg, et. al.          Standards Track                    [Page 19]

RFC 3261            SIP: Session Initiation Protocol           June 2002


   Certain other requests are sent within a dialog.  A dialog is a
   peer-to-peer SIP relationship between two user agents that persists
   for some time.  The dialog facilitates sequencing of messages and
   proper routing of requests between the user agents.  The INVITE
   method is the only way defined in this specification to establish a
   dialog.  When a UAC sends a request that is within the context of a
   dialog, it follows the common UAC rules as discussed in Section 8 but
   also the rules for mid-dialog requests.  Section 12 discusses dialogs
   and presents the procedures for their construction and maintenance,
   in addition to construction of requests within a dialog.

   The most important method in SIP is the INVITE method, which is used
   to establish a session between participants.  A session is a
   collection of participants, and streams of media between them, for
   the purposes of communication.  Section 13 discusses how sessions are
   initiated, resulting in one or more SIP dialogs.  Section 14
   discusses how characteristics of that session are modified through
   the use of an INVITE request within a dialog.  Finally, section 15
   discusses how a session is terminated.

   The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
   entirely with the UA core (Section 9 describes cancellation, which
   applies to both UA core and proxy core).  Section 16 discusses the
   proxy element, which facilitates routing of messages between user
   agents.

6 Definitions

   The following terms have special significance for SIP.

      Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
         that points to a domain with a location service that can map
         the URI to another URI where the user might be available.
         Typically, the location service is populated through
         registrations.  An AOR is frequently thought of as the "public
         address" of the user.

      Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
         logical entity that receives a request and processes it as a
         user agent server (UAS).  In order to determine how the request
         should be answered, it acts as a user agent client (UAC) and
         generates requests.  Unlike a proxy server, it maintains dialog
         state and must participate in all requests sent on the dialogs
         it has established.  Since it is a concatenation of a UAC and
         UAS, no explicit definitions are needed for its behavior.






Rosenberg, et. al.          Standards Track                    [Page 20]

RFC 3261            SIP: Session Initiation Protocol           June 2002


      Call: A call is an informal term that refers to some communication
         between peers, generally set up for the purposes of a
         multimedia conversation.

      Call Leg: Another name for a dialog [31]; no longer used in this
         specification.

      Call Stateful: A proxy is call stateful if it retains state for a
         dialog from the initiating INVITE to the terminating BYE
         request.  A call stateful proxy is always transaction stateful,
         but the converse is not necessarily true.

      Client: A client is any network element that sends SIP requests
         and receives SIP responses.  Clients may or may not interact
         directly with a human user.  User agent clients and proxies are
         clients.

      Conference: A multimedia session (see below) that contains
         multiple participants.

      Core: Core designates the functions specific to a particular type
         of SIP entity, i.e., specific to either a stateful or stateless
         proxy, a user agent or registrar.  All cores, except those for
         the stateless proxy, are transaction users.

      Dialog: A dialog is a peer-to-peer SIP relationship between two
         UAs that persists for some time.  A dialog is established by
         SIP messages, such as a 2xx response to an INVITE request.  A
         dialog is identified by a call identifier, local tag, and a
         remote tag.  A dialog was formerly known as a call leg in RFC
         2543.

      Downstream: A direction of message forwarding within a transaction
         that refers to the direction that requests flow from the user
         agent client to user agent server.

      Final Response: A response that terminates a SIP transaction, as
         opposed to a provisional response that does not.  All 2xx, 3xx,
         4xx, 5xx and 6xx responses are final.

      Header: A header is a component of a SIP message that conveys
         information about the message.  It is structured as a sequence
         of header fields.

      Header Field: A header field is a component of the SIP message
         header.  A header field can appear as one or more header field
         rows. Header field rows consist of a header field name and zero
         or more header field values. Multiple header field values on a



Rosenberg, et. al.          Standards Track                    [Page 21]

RFC 3261            SIP: Session Initiation Protocol           June 2002


         given header field row are separated by commas. Some header
         fields can only have a single header field value, and as a
         result, always appear as a single header field row.

      Header Field Value: A header field value is a single value; a
         header field consists of zero or more header field values.

      Home Domain: The domain providing service to a SIP user.
         Typically, this is the domain present in the URI in the
         address-of-record of a registration.

      Informational Response: Same as a provisional response.

      Initiator, Calling Party, Caller: The party initiating a session
         (and dialog) with an INVITE request.  A caller retains this
         role from the time it sends the initial INVITE that established
         a dialog until the termination of that dialog.

      Invitation: An INVITE request.

      Invitee, Invited User, Called Party, Callee: The party that
         receives an INVITE request for the purpose of establishing a
         ne