rfc2543.txt

中、英文RFC文档大全打包下载完全版 .

   The SIP message format and operation is independent of the transport
   protocol.

1.4.4 SIP Invitation

   A successful SIP invitation consists of two requests, INVITE followed
   by ACK. The INVITE (Section 4.2.1) request asks the callee to join a
   particular conference or establish a two-party conversation. After
   the callee has agreed to participate in the call, the caller confirms
   that it has received that response by sending an ACK (Section 4.2.2)
   request. If the caller no longer wants to participate in the call, it
   sends a BYE request instead of an ACK.

   The INVITE request typically contains a session description, for
   example written in SDP (RFC 2327 [6]) format, that provides the
   called party with enough information to join the session. For
   multicast sessions, the session description enumerates the media
   types and formats that are allowed to be distributed to that session.
   For a unicast session, the session description enumerates the media
   types and formats that the caller is willing to use and where it
   wishes the media data to be sent. In either case, if the callee
   wishes to accept the call, it responds to the invitation by returning
   a similar description listing the media it wishes to use. For a
   multicast session, the callee SHOULD only return a session
   description if it is unable to receive the media indicated in the
   caller's description or wants to receive data via unicast.

   The protocol exchanges for the INVITE method are shown in Fig. 1 for
   a proxy server and in Fig. 2 for a redirect server. (Note that the
   messages shown in the figures have been abbreviated slightly.) In
   Fig. 1, the proxy server accepts the INVITE request (step 1),
   contacts the location service with all or parts of the address (step
   2) and obtains a more precise location (step 3). The proxy server
   then issues a SIP INVITE request to the address(es) returned by the
   location service (step 4). The user agent server alerts the user
   (step 5) and returns a success indication to the proxy server (step



Handley, et al.             Standards Track                    [Page 15]

RFC 2543            SIP: Session Initiation Protocol          March 1999


   6). The proxy server then returns the success result to the original
   caller (step 7). The receipt of this message is confirmed by the
   caller using an ACK request, which is forwarded to the callee (steps
   8 and 9). Note that an ACK can also be sent directly to the callee,
   bypassing the proxy. All requests and responses have the same Call-
   ID.





                                         +....... cs.columbia.edu .......+
                                         :                               :
                                         : (~~~~~~~~~~)                  :
                                         : ( location )                  :
                                         : ( service  )                  :
                                         : (~~~~~~~~~~)                  :
                                         :     ^    |                    :
                                         :     | hgs@lab                 :
                                         :    2|   3|                    :
                                         :     |    |                    :
                                         : henning  |                    : 
+.. cs.tu-berlin.de ..+ 1: INVITE        :     |    |                    :
:                     :    [e-mail]:     |   \/ 4: INVITE  5: ring :
: [e-mail] ========================>(~~~~~~)=========>(~~~~~~) :
:                    <........................(      )<.........(      ) :
:                     : 7: 200 OK        :    (      )6: 200 OK (      ) :
:                     :                  :    ( work )          ( lab  ) :
:                     : 8: ACK           :    (      )9: ACK    (      ) :
:                    ========================>(~~~~~~)=========>(~~~~~~) :
+.....................+                  +...............................+

  ====> SIP request                                                         
  ....> SIP response                                                       
  
   ^
   |    non-SIP protocols                                                  
   |
  

   Figure 1: Example of SIP proxy server



   The redirect server shown in Fig. 2 accepts the INVITE request (step
   1), contacts the location service as before (steps 2 and 3) and,
   instead of contacting the newly found address itself, returns the
   address to the caller (step 4), which is then acknowledged via an ACK



Handley, et al.             Standards Track                    [Page 16]

RFC 2543            SIP: Session Initiation Protocol          March 1999


   request (step 5). The caller issues a new request, with the same
   call-ID but a higher CSeq, to the address returned by the first
   server (step 6). In the example, the call succeeds (step 7). The
   caller and callee complete the handshake with an ACK (step 8).


   The next section discusses what happens if the location service
   returns more than one possible alternative.

1.4.5 Locating a User

   A callee may move between a number of different end systems over
   time.  These locations can be dynamically registered with the SIP
   server (Sections 1.4.7, 4.2.6). A location server MAY also use one or
   more other protocols, such as finger (RFC 1288 [17]), rwhois (RFC
   2167 [18]), LDAP (RFC 1777 [19]), multicast-based protocols [20] or
   operating-system dependent mechanisms to actively determine the end
   system where a user might be reachable. A location server MAY return
   several locations because the user is logged in at several hosts
   simultaneously or because the location server has (temporarily)
   inaccurate information. The SIP server combines the results to yield
   a list of a zero or more locations.

   The action taken on receiving a list of locations varies with the
   type of SIP server. A SIP redirect server returns the list to the
   client as Contact headers (Section 6.13). A SIP proxy server can
   sequentially or in parallel try the addresses until the call is
   successful (2xx response) or the callee has declined the call (6xx
   response). With sequential attempts, a proxy server can implement an
   "anycast" service.

   If a proxy server forwards a SIP request, it MUST add itself to the
   beginning of the list of forwarders noted in the Via (Section 6.40)
   headers. The Via trace ensures that replies can take the same path
   back, ensuring correct operation through compliant firewalls and
   avoiding request loops. On the response path, each host MUST remove
   its Via, so that routing internal information is hidden from the
   callee and outside networks. A proxy server MUST check that it does
   not generate a request to a host listed in the Via sent-by, via-
   received or via-maddr parameters (Section 6.40). (Note: If a host has
   several names or network addresses, this does not always work.  Thus,
   each host also checks if it is part of the Via list.)

   A SIP invitation may traverse more than one SIP proxy server. If one
   of these "forks" the request, i.e., issues more than one request in
   response to receiving the invitation request, it is possible that a
   client is reached, independently, by more than one copy of the




Handley, et al.             Standards Track                    [Page 17]

RFC 2543            SIP: Session Initiation Protocol          March 1999


   invitation request. Each of these copies bears the same Call-ID. The
   user agent MUST return the same status response returned in the first
   response. Duplicate requests are not an error.

1.4.6 Changing an Existing Session

   In some circumstances, it is desirable to change the parameters of an
   existing session. This is done by re-issuing the INVITE, using the
   same Call-ID, but a new or different body or header fields to convey
   the new information. This re INVITE MUST have a higher CSeq than any
   previous request from the client to the server.

   For example, two parties may have been conversing and then want to
   add a third party, switching to multicast for efficiency.  One of the
   participants invites the third party with the new multicast address
   and simultaneously sends an INVITE to the second party, with the new
   multicast session description, but with the old call identifier.

1.4.7 Registration Services

   The REGISTER request allows a client to let a proxy or redirect
   server know at which address(es) it can be reached. A client MAY also
   use it to install call handling features at the server.

1.5 Protocol Properties

1.5.1 Minimal State

   A single conference session or call involves one or more SIP
   request-response transactions. Proxy servers do not have to keep
   state for a particular call, however, they MAY maintain state for a
   single SIP transaction, as discussed in Section 12. For efficiency, a
   server MAY cache the results of location service requests.

1.5.2 Lower-Layer-Protocol Neutral

   SIP makes minimal assumptions about the underlying transport and
   network-layer protocols. The lower-layer can provide either a packet
   or a byte stream service, with reliable or unreliable service.

   In an Internet context, SIP is able to utilize both UDP and TCP as
   transport protocols, among others. UDP allows the application to more
   carefully control the timing of messages and their retransmission, to
   perform parallel searches without requiring TCP connection state for
   each outstanding request, and to use multicast. Routers can more
   readily snoop SIP UDP packets. TCP allows easier passage through
   existing firewalls.




Handley, et al.             Standards Track                    [Page 18]

RFC 2543            SIP: Session Initiation Protocol          March 1999






                                         +....... cs.columbia.edu .......+
                                         :                               :
                                         : (~~~~~~~~~~)                  :
                                         : ( location )                  :
                                         : ( service  )                  :
                                         : (~~~~~~~~~~)                  :
                                         :    ^   |                      :
                                         :    | hgs@lab                  :
                                         :   2|  3|                      :
                                         :    |   |                      :
                                         : henning|                      : 
+.. cs.tu-berlin.de ..+ 1: INVITE        :    |   |                      :
:                     :    [e-mail]:    |   \/                     : 
: [e-mail] =======================>(~~~~~~)                    : 
:       | ^ |        <.......................(      )                    :
:       | . |         : 4: 302 Moved     :   (      )                    :
:       | . |         :    hgs@lab       :   ( work )                    :
:       | . |         :                  :   (      )                    :
:       | . |         : 5: ACK           :   (      )                    :
:       | . |        =======================>(~~~~~~)                    :
:       | . |         :                  :                               :
+.......|...|.........+                  :                               :
        | . |                            :                               :
        | . |                            :                               :
        | . |                            :                               :
        | . |                            :                               :
        | . | 6: INVITE [e-mail]                 (~~~~~~) : 
        | . ==================================================> (      ) :
        | ..................................................... (      ) :
        |     7: 200 OK                  :                      ( lab  ) : 
        |                                :                      (      ) :
        |     8: ACK                     :                      (      ) :
        ======================================================> (~~~~~~) :
                                         +...............................+ 
                                                                          
  ====> SIP request                                                        
  ....> SIP response                                                       
    
    ^
    |   non-SIP protocols                                                  
    |




   Figure 2: Example of SIP redirect server

Handley, et al.             Standards Track                    [Page 19]

RFC 2543            SIP: Session Initiation Protocol          March 1999