rfc2543.txt

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

   Provisional response: A response used by the server to indicate
        progress, but that does not terminate a SIP transaction. 1xx
        responses are provisional, other responses are considered final.

   Proxy, proxy server: An intermediary program that acts as both a
        server and a client for the purpose of making requests on behalf
        of other clients. Requests are serviced internally or by passing
        them on, possibly after translation, to other servers. A proxy
        interprets, and, if necessary, rewrites a request message before
        forwarding it.

   Redirect server: A redirect server is a server that accepts a SIP
        request, maps the address into zero or more new addresses and
        returns these addresses to the client. Unlike a proxy server ,
        it does not initiate its own SIP request. Unlike a user agent
        server , it does not accept calls.

   Registrar: A registrar is a server that accepts REGISTER requests. A
        registrar is typically co-located with a proxy or redirect
        server and MAY offer location services.






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


   Ringback: Ringback is the signaling tone produced by the calling
        client's application indicating that a called party is being
        alerted (ringing).

   Server: A server is an application program that accepts requests in
        order to service requests and sends back responses to those
        requests.  Servers are either proxy, redirect or user agent
        servers or registrars.

   Session: From the SDP specification: "A multimedia session is a set
        of multimedia senders and receivers and the data streams flowing
        from senders to receivers. A multimedia conference is an example
        of a multimedia session." (RFC 2327 [6]) (A session as defined
        for SDP can comprise one or more RTP sessions.) As defined, a
        callee can be invited several times, by different calls, to the
        same session. If SDP is used, a session is defined by the
        concatenation of the user name , session id , network type ,
        address type and address elements in the origin field.

   (SIP) transaction: A SIP transaction occurs between a client and a
        server and comprises all messages from the first request sent
        from the client to the server up to a final (non-1xx) response
        sent from the server to the client. A transaction is identified
        by the CSeq sequence number (Section 6.17) within a single call
        leg.  The ACK request has the same CSeq number as the
        corresponding INVITE request, but comprises a transaction of its
        own.

   Upstream: Responses sent in the direction from the user agent server
        to the user agent client.

   URL-encoded: A character string encoded according to RFC 1738,
        Section 2.2 [13].

   User agent client (UAC), calling user agent: A user agent client is a
        client application that initiates the SIP request.

   User agent server (UAS), called user agent: A user agent server is a
        server application that contacts the user when a SIP request is
        received and that returns a response on behalf of the user. The
        response accepts, rejects or redirects the request.

   User agent (UA): An application which contains both a user agent
        client and user agent server.

   An application program MAY be capable of acting both as a client and
   a server. For example, a typical multimedia conference control
   application would act as a user agent client to initiate calls or to



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


   invite others to conferences and as a user agent server to accept
   invitations. The properties of the different SIP server types are
   summarized in Table 1.


    property                   redirect  proxy   user agent  registrar
                                server   server    server
    __________________________________________________________________
    also acts as a SIP client     no      yes        no         no
    returns 1xx status           yes      yes       yes         yes
    returns 2xx status            no      yes       yes         yes
    returns 3xx status           yes      yes       yes         yes
    returns 4xx status           yes      yes       yes         yes
    returns 5xx status           yes      yes       yes         yes
    returns 6xx status            no      yes       yes         yes
    inserts Via header            no      yes        no         no
    accepts ACK                  yes      yes       yes         no


   Table 1: Properties of the different SIP server types


1.4 Overview of SIP Operation

   This section explains the basic protocol functionality and operation.
   Callers and callees are identified by SIP addresses, described in
   Section 1.4.1. When making a SIP call, a caller first locates the
   appropriate server (Section 1.4.2) and then sends a SIP request
   (Section 1.4.3). The most common SIP operation is the invitation
   (Section 1.4.4). Instead of directly reaching the intended callee, a
   SIP request may be redirected or may trigger a chain of new SIP
   requests by proxies (Section 1.4.5). Users can register their
   location(s) with SIP servers (Section 4.2.6).

1.4.1 SIP Addressing

   The "objects" addressed by SIP are users at hosts, identified by a
   SIP URL. The SIP URL takes a form similar to a mailto or telnet URL,
   i.e., user@host.  The user part is a user name or a telephone number.
   The host part is either a domain name or a numeric network address.
   See section 2 for a detailed discussion of SIP URL's.

   A user's SIP address can be obtained out-of-band, can be learned via
   existing media agents, can be included in some mailers' message
   headers, or can be recorded during previous invitation interactions.
   In many cases, a user's SIP URL can be guessed from their email
   address.




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


   A SIP URL address can designate an individual (possibly located at
   one of several end systems), the first available person from a group
   of individuals or a whole group. The form of the address, for
   example, sip:[e-mail] , is not sufficient, in general, to
   determine the intent of the caller.

   If a user or service chooses to be reachable at an address that is
   guessable from the person's name and organizational affiliation, the
   traditional method of ensuring privacy by having an unlisted "phone"
   number is compromised. However, unlike traditional telephony, SIP
   offers authentication and access control mechanisms and can avail
   itself of lower-layer security mechanisms, so that client software
   can reject unauthorized or undesired call attempts.

1.4.2 Locating a SIP Server

   When a client wishes to send a request, the client either sends it to
   a locally configured SIP proxy server (as in HTTP), independent of
   the Request-URI, or sends it to the IP address and port corresponding
   to the Request-URI.

   For the latter case, the client must determine the protocol, port and
   IP address of a server to which to send the request. A client SHOULD
   follow the steps below to obtain this information, but MAY follow the
   alternative, optional procedure defined in Appendix D. At each step,
   unless stated otherwise, the client SHOULD try to contact a server at
   the port number listed in the Request-URI. If no port number is
   present in the Request-URI, the client uses port 5060. If the
   Request-URI specifies a protocol (TCP or UDP), the client contacts
   the server using that protocol. If no protocol is specified, the
   client tries UDP (if UDP is supported). If the attempt fails, or if
   the client doesn't support UDP but supports TCP, it then tries TCP.

   A client SHOULD be able to interpret explicit network notifications
   (such as ICMP messages) which indicate that a server is not
   reachable, rather than relying solely on timeouts. (For socket-based
   programs: For TCP, connect() returns ECONNREFUSED if the client could
   not connect to a server at that address. For UDP, the socket needs to
   be bound to the destination address using connect() rather than
   sendto() or similar so that a second write() fails with ECONNREFUSED
   if there is no server listening) If the client finds the server is
   not reachable at a particular address, it SHOULD behave as if it had
   received a 400-class error response to that request.

   The client tries to find one or more addresses for the SIP server by
   querying DNS. The procedure is as follows:





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


        1.   If the host portion of the Request-URI is an IP address,
             the client contacts the server at the given address.
             Otherwise, the client proceeds to the next step.

        2.   The client queries the DNS server for address records for
             the host portion of the Request-URI. If the DNS server
             returns no address records, the client stops, as it has
             been unable to locate a server. By address record, we mean
             A RR's, AAAA RR's, or other similar address records, chosen
             according to the client's network protocol capabilities.


        There are no mandatory rules on how to select a host name
        for a SIP server. Users are encouraged to name their SIP
        servers using the sip.domainname (i.e., sip.example.com)
        convention, as specified in RFC 2219 [16]. Users may only
        know an email address instead of a full SIP URL for a
        callee, however. In that case, implementations may be able
        to increase the likelihood of reaching a SIP server for
        that domain by constructing a SIP URL from that email
        address by prefixing the host name with "sip.". In the
        future, this mechanism is likely to become unnecessary as
        better DNS techniques, such as the one in Appendix D,
        become widely available.

   A client MAY cache a successful DNS query result. A successful query
   is one which contained records in the answer, and a server was
   contacted at one of the addresses from the answer. When the client
   wishes to send a request to the same host, it MUST start the search
   as if it had just received this answer from the name server. The
   client MUST follow the procedures in RFC1035 [15] regarding DNS cache
   invalidation when the DNS time-to-live expires.

1.4.3 SIP Transaction

   Once the host part has been resolved to a SIP server, the client
   sends one or more SIP requests to that server and receives one or
   more responses from the server. A request (and its retransmissions)
   together with the responses triggered by that request make up a SIP
   transaction.  All responses to a request contain the same values in
   the Call-ID, CSeq, To, and From fields (with the possible addition of
   a tag in the To field (section 6.37)). This allows responses to be
   matched with requests. The ACK request following an INVITE is not
   part of the transaction since it may traverse a different set of
   hosts.






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


   If TCP is used, request and responses within a single SIP transaction
   are carried over the same TCP connection (see Section 10). Several
   SIP requests from the same client to the same server MAY use the same
   TCP connection or MAY use a new connection for each request.

   If the client sent the request via unicast UDP, the response is sent
   to the address contained in the next Via header field (Section 6.40)
   of the response. If the request is sent via multicast UDP, the
   response is directed to the same multicast address and destination
   port. For UDP, reliability is achieved using retransmission (Section
   10).