rfc3261 session initiation protocol (sip) extension.txt

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

           party to engage in communications;

      User capabilities: determination of the media and media parameters
           to be used;

      Session setup: "ringing", establishment of session parameters at
           both called and calling party;

      Session management: including transfer and termination of
           sessions, modifying session parameters, and invoking
           services.

   SIP is not a vertically integrated communications system.  SIP is
   rather a component that can be used with other IETF protocols to
   build a complete multimedia architecture.  Typically, these
   architectures will include protocols such as the Real-time Transport
   Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and
   providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC
   2326 [29]) for controlling delivery of streaming media, the Media



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


   Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling
   gateways to the Public Switched Telephone Network (PSTN), and the
   Session Description Protocol (SDP) (RFC 2327 [1]) for describing
   multimedia sessions.  Therefore, SIP should be used in conjunction
   with other protocols in order to provide complete services to the
   users.  However, the basic functionality and operation of SIP does
   not depend on any of these protocols.

   SIP does not provide services.  Rather, SIP provides primitives that
   can be used to implement different services.  For example, SIP can
   locate a user and deliver an opaque object to his current location.
   If this primitive is used to deliver a session description written in
   SDP, for instance, the endpoints can agree on the parameters of a
   session.  If the same primitive is used to deliver a photo of the
   caller as well as the session description, a "caller ID" service can
   be easily implemented.  As this example shows, a single primitive is
   typically used to provide several different services.

   SIP does not offer conference control services such as floor control
   or voting and does not prescribe how a conference is to be managed.
   SIP can be used to initiate a session that uses some other conference
   control protocol.  Since SIP messages and the sessions they establish
   can pass through entirely different networks, SIP cannot, and does
   not, provide any kind of network resource reservation capabilities.

   The nature of the services provided make security particularly
   important.  To that end, SIP provides a suite of security services,
   which include denial-of-service prevention, authentication (both user
   to user and proxy to user), integrity protection, and encryption and
   privacy services.

   SIP works with both IPv4 and IPv6.

3 Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [2] and indicate requirement levels for
   compliant SIP implementations.

4 Overview of Operation

   This section introduces the basic operations of SIP using simple
   examples.  This section is tutorial in nature and does not contain
   any normative statements.





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


   The first example shows the basic functions of SIP: location of an
   end point, signal of a desire to communicate, negotiation of session
   parameters to establish the session, and teardown of the session once
   established.

   Figure 1 shows a typical example of a SIP message exchange between
   two users, Alice and Bob.  (Each message is labeled with the letter
   "F" and a number for reference by the text.)  In this example, Alice
   uses a SIP application on her PC (referred to as a softphone) to call
   Bob on his SIP phone over the Internet.  Also shown are two SIP proxy
   servers that act on behalf of Alice and Bob to facilitate the session
   establishment.  This typical arrangement is often referred to as the
   "SIP trapezoid" as shown by the geometric shape of the dotted lines
   in Figure 1.

   Alice "calls" Bob using his SIP identity, a type of Uniform Resource
   Identifier (URI) called a SIP URI. SIP URIs are defined in Section
   19.1.  It has a similar form to an email address, typically
   containing a username and a host name.  In this case, it is
   sip:[e-mail], where biloxi.com is the domain of Bob's SIP
   service provider.  Alice has a SIP URI of sip:[e-mail].
   Alice might have typed in Bob's URI or perhaps clicked on a hyperlink
   or an entry in an address book.  SIP also provides a secure URI,
   called a SIPS URI.  An example would be sips:[e-mail].  A call
   made to a SIPS URI guarantees that secure, encrypted transport
   (namely TLS) is used to carry all SIP messages from the caller to the
   domain of the callee.  From there, the request is sent securely to
   the callee, but with security mechanisms that depend on the policy of
   the domain of the callee.

   SIP is based on an HTTP-like request/response transaction model.
   Each transaction consists of a request that invokes a particular
   method, or function, on the server and at least one response.  In
   this example, the transaction begins with Alice's softphone sending
   an INVITE request addressed to Bob's SIP URI.  INVITE is an example
   of a SIP method that specifies the action that the requestor (Alice)
   wants the server (Bob) to take.  The INVITE request contains a number
   of header fields.  Header fields are named attributes that provide
   additional information about a message.  The ones present in an
   INVITE include a unique identifier for the call, the destination
   address, Alice's address, and information about the type of session
   that Alice wishes to establish with Bob.  The INVITE (message F1 in
   Figure 1) might look like this:








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


                     atlanta.com  . . . biloxi.com
                 .      proxy              proxy     .
               .                                       .
       Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's
      softphone                                        SIP Phone
         |                |                |                |
         |    INVITE F1   |                |                |
         |--------------->|    INVITE F2   |                |
         |  100 Trying F3 |--------------->|    INVITE F4   |
         |<---------------|  100 Trying F5 |--------------->|
         |                |<-------------- | 180 Ringing F6 |
         |                | 180 Ringing F7 |<---------------|
         | 180 Ringing F8 |<---------------|     200 OK F9  |
         |<---------------|    200 OK F10  |<---------------|
         |    200 OK F11  |<---------------|                |
         |<---------------|                |                |
         |                       ACK F12                    |
         |------------------------------------------------->|
         |                   Media Session                  |
         |<================================================>|
         |                       BYE F13                    |
         |<-------------------------------------------------|
         |                     200 OK F14                   |
         |------------------------------------------------->|
         |                                                  |

         Figure 1: SIP session setup example with SIP trapezoid

      INVITE sip:[e-mail] SIP/2.0
      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
      Max-Forwards: 70
      To: Bob <sip:[e-mail]>
      From: Alice <sip:[e-mail]>;tag=1928301774
      Call-ID: [e-mail]
      CSeq: 314159 INVITE
      Contact: <sip:[e-mail]>
      Content-Type: application/sdp
      Content-Length: 142

      (Alice's SDP not shown)

   The first line of the text-encoded message contains the method name
   (INVITE).  The lines that follow are a list of header fields.  This
   example contains a minimum required set.  The header fields are
   briefly described below:






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


   Via contains the address (pc33.atlanta.com) at which Alice is
   expecting to receive responses to this request.  It also contains a
   branch parameter that identifies this transaction.

   To contains a display name (Bob) and a SIP or SIPS URI
   (sip:[e-mail]) towards which the request was originally
   directed.  Display names are described in RFC 2822 [3].

   From also contains a display name (Alice) and a SIP or SIPS URI
   (sip:[e-mail]) that indicate the originator of the request.
   This header field also has a tag parameter containing a random string
   (1928301774) that was added to the URI by the softphone.  It is used
   for identification purposes.

   Call-ID contains a globally unique identifier for this call,
   generated by the combination of a random string and the softphone's
   host name or IP address.  The combination of the To tag, From tag,
   and Call-ID completely defines a peer-to-peer SIP relationship
   between Alice and Bob and is referred to as a dialog.

   CSeq or Command Sequence contains an integer and a method name.  The
   CSeq number is incremented for each new request within a dialog and
   is a traditional sequence number.

   Contact contains a SIP or SIPS URI that represents a direct route to
   contact Alice, usually composed of a username at a fully qualified
   domain name (FQDN).  While an FQDN is preferred, many end systems do
   not have registered domain names, so IP addresses are permitted.
   While the Via header field tells other elements where to send the
   response, the Contact header field tells other elements where to send
   future requests.

   Max-Forwards serves to limit the number of hops a request can make on
   the way to its destination.  It consists of an integer that is
   decremented by one at each hop.

   Content-Type contains a description of the message body (not shown).

   Content-Length contains an octet (byte) count of the message body.

   The complete set of SIP header fields is defined in Section 20.

   The details of the session, such as the type of media, codec, or
   sampling rate, are not described using SIP.  Rather, the body of a
   SIP message contains a description of the session, encoded in some
   other protocol format.  One such format is the Session Description