rfc3261.txt

这是介绍RFC协议的一个重要技术文档

   INVITE, which allows Alice's softphone to correlate this response to
   the sent INVITE.  The atlanta.com proxy server locates the proxy
   server at biloxi.com, possibly by performing a particular type of DNS
   (Domain Name Service) lookup to find the SIP server that serves the
   biloxi.com domain.  This is described in [4].  As a result, it
   obtains the IP address of the biloxi.com proxy server and forwards,
   or proxies, the INVITE request there.  Before forwarding the request,
   the atlanta.com proxy server adds an additional Via header field
   value that contains its own address (the INVITE already contains
   Alice's address in the first Via).  The biloxi.com proxy server
   receives the INVITE and responds with a 100 (Trying) response back to
   the atlanta.com proxy server to indicate that it has received the
   INVITE and is processing the request.  The proxy server consults a
   database, generically called a location service, that contains the
   current IP address of Bob.  (We shall see in the next section how
   this database can be populated.)  The biloxi.com proxy server adds
   another Via header field value with its own address to the INVITE and
   proxies it to Bob's SIP phone.

   Bob's SIP phone receives the INVITE and alerts Bob to the incoming
   call from Alice so that Bob can decide whether to answer the call,
   that is, Bob's phone rings.  Bob's SIP phone indicates this in a 180
   (Ringing) response, which is routed back through the two proxies in
   the reverse direction.  Each proxy uses the Via header field to
   determine where to send the response and removes its own address from
   the top.  As a result, although DNS and location service lookups were
   required to route the initial INVITE, the 180 (Ringing) response can
   be returned to the caller without lookups or without state being

   maintained in the proxies.  This also has the desirable property that
   each proxy that sees the INVITE will also see all responses to the
   INVITE.

   When Alice's softphone receives the 180 (Ringing) response, it passes
   this information to Alice, perhaps using an audio ringback tone or by
   displaying a message on Alice's screen.

   In this example, Bob decides to answer the call.  When he picks up
   the handset, his SIP phone sends a 200 (OK) response to indicate that
   the call has been answered.  The 200 (OK) contains a message body
   with the SDP media description of the type of session that Bob is
   willing to establish with Alice.  As a result, there is a two-phase
   exchange of SDP messages: Alice sent one to Bob, and Bob sent one
   back to Alice.  This two-phase exchange provides basic negotiation
   capabilities and is based on a simple offer/answer model of SDP
   exchange.  If Bob did not wish to answer the call or was busy on
   another call, an error response would have been sent instead of the
   200 (OK), which would have resulted in no media session being
   established.  The complete list of SIP response codes is in Section
   21.  The 200 (OK) (message F9 in Figure 1) might look like this as
   Bob sends it out:

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP server10.biloxi.com
         ;branch=z9hG4bKnashds8;received=192.0.2.3
      Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
         ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
      Via: SIP/2.0/UDP pc33.atlanta.com
         ;branch=z9hG4bK776asdhds ;received=192.0.2.1
      To: Bob <sip:[e-mail]>;tag=a6c85cf
      From: Alice <sip:[e-mail]>;tag=1928301774
      Call-ID: [e-mail]
      CSeq: 314159 INVITE
      Contact: <sip:bob@192.0.2.4>
      Content-Type: application/sdp
      Content-Length: 131

      (Bob's SDP not shown)

   The first line of the response contains the response code (200) and
   the reason phrase (OK).  The remaining lines contain header fields.
   The Via, To, From, Call-ID, and CSeq header fields are copied from
   the INVITE request.  (There are three Via header field values - one
   added by Alice's SIP phone, one added by the atlanta.com proxy, and
   one added by the biloxi.com proxy.)  Bob's SIP phone has added a tag
   parameter to the To header field.  This tag will be incorporated by
   both endpoints into the dialog and will be included in all future

   requests and responses in this call.  The Contact header field
   contains a URI at which Bob can be directly reached at his SIP phone.
   The Content-Type and Content-Length refer to the message body (not
   shown) that contains Bob's SDP media information.

   In addition to DNS and location service lookups shown in this
   example, proxy servers can make flexible "routing decisions" to
   decide where to send a request.  For example, if Bob's SIP phone
   returned a 486 (Busy Here) response, the biloxi.com proxy server
   could proxy the INVITE to Bob's voicemail server.  A proxy server can
   also send an INVITE to a number of locations at the same time.  This
   type of parallel search is known as forking.

   In this case, the 200 (OK) is routed back through the two proxies and
   is received by Alice's softphone, which then stops the ringback tone
   and indicates that the call has been answered.  Finally, Alice's
   softphone sends an acknowledgement message, ACK, to Bob's SIP phone
   to confirm the reception of the final response (200 (OK)).  In this
   example, the ACK is sent directly from Alice's softphone to Bob's SIP
   phone, bypassing the two proxies.  This occurs because the endpoints
   have learned each other's address from the Contact header fields
   through the INVITE/200 (OK) exchange, which was not known when the
   initial INVITE was sent.  The lookups performed by the two proxies
   are no longer needed, so the proxies drop out of the call flow.  This
   completes the INVITE/200/ACK three-way handshake used to establish
   SIP sessions.  Full details on session setup are in Section 13.

   Alice and Bob's media session has now begun, and they send media
   packets using the format to which they agreed in the exchange of SDP.
   In general, the end-to-end media packets take a different path from
   the SIP signaling messages.

   During the session, either Alice or Bob may decide to change the
   characteristics of the media session.  This is accomplished by
   sending a re-INVITE containing a new media description.  This re-
   INVITE references the existing dialog so that the other party knows
   that it is to modify an existing session instead of establishing a
   new session.  The other party sends a 200 (OK) to accept the change.
   The requestor responds to the 200 (OK) with an ACK.  If the other
   party does not accept the change, he sends an error response such as
   488 (Not Acceptable Here), which also receives an ACK.  However, the
   failure of the re-INVITE does not cause the existing call to fail -
   the session continues using the previously negotiated
   characteristics.  Full details on session modification are in Section
   14.

   At the end of the call, Bob disconnects (hangs up) first and
   generates a BYE message.  This BYE is routed directly to Alice's
   softphone, again bypassing the proxies.  Alice confirms receipt of
   the BYE with a 200 (OK) response, which terminates the session and
   the BYE transaction.  No ACK is sent - an ACK is only sent in
   response to a response to an INVITE request.  The reasons for this
   special handling for INVITE will be discussed later, but relate to
   the reliability mechanisms in SIP, the length of time it can take for
   a ringing phone to be answered, and forking.  For this reason,
   request handling in SIP is often classified as either INVITE or non-
   INVITE, referring to all other methods besides INVITE.  Full details
   on session termination are in Section 15.

   Section 24.2 describes the messages shown in Figure 1 in full.

   In some cases, it may be useful for proxies in the SIP signaling path
   to see all the messaging between the endpoints for the duration of
   the session.  For example, if the biloxi.com proxy server wished to
   remain in the SIP messaging path beyond the initial INVITE, it would
   add to the INVITE a required routing header field known as Record-
   Route that contained a URI resolving to the hostname or IP address of
   the proxy.  This information would be received by both Bob's SIP
   phone and (due to the Record-Route header field being passed back in
   the 200 (OK)) Alice's softphone and stored for the duration of the
   dialog.  The biloxi.com proxy server would then receive and proxy the
   ACK, BYE, and 200 (OK) to the BYE.  Each proxy can independently
   decide to receive subsequent messages, and those messages will pass
   through all proxies that elect to receive it.  This capability is
   frequently used for proxies that are providing mid-call features.

   Registration is another common operation in SIP.  Registration is one
   way that the biloxi.com server can learn the current location of Bob.
   Upon initialization, and at periodic intervals, Bob's SIP phone sends
   REGISTER messages to a server in the biloxi.com domain known as a SIP
   registrar.  The REGISTER messages associate Bob's SIP or SIPS URI
   (sip:[e-mail]) with the machine into which he is currently
   logged (conveyed as a SIP or SIPS URI in the Contact header field).
   The registrar writes this association, also called a binding, to a
   database, called the location service, where it can be used by the
   proxy in the biloxi.com domain.  Often, a registrar server for a
   domain is co-located with the proxy for that domain.  It is an
   important concept that the distinction between types of SIP servers
   is logical, not physical.

   Bob is not limited to registering from a single device.  For example,
   both his SIP phone at home and the one in the office could send
   registrations.  This information is stored together in the location

   service and allows a proxy to perform various types of searches to
   locate Bob.  Similarly, more than one user can be registered on a
   single device at the same time.

   The location service is just an abstract concept.  It generally
   contains information that allows a proxy to input a URI and receive a
   set of zero or more URIs that tell the proxy where to send the
   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.

   The second layer is the transport layer.  It defines how a client
   sends requests and receives responses and how a server receives