rfc2543.txt

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

   12.3.7     Stateless, Non-Forking Proxy ........................  100
   12.4       Forking Proxy .......................................  100
   13         Security Considerations .............................  104
   13.1       Confidentiality and Privacy: Encryption .............  104
   13.1.1     End-to-End Encryption ...............................  104
   13.1.2     Privacy of SIP Responses ............................  107
   13.1.3     Encryption by Proxies ...............................  108
   13.1.4     Hop-by-Hop Encryption ...............................  108
   13.1.5     Via field encryption ................................  108
   13.2       Message Integrity and Access Control:
              Authentication ......................................  109



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


   13.2.1     Trusting responses ..................................  112
   13.3       Callee Privacy ......................................  113
   13.4       Known Security Problems .............................  113
   14         SIP Authentication using HTTP Basic and Digest
              Schemes .............................................  113
   14.1       Framework ...........................................  113
   14.2       Basic Authentication ................................  114
   14.3       Digest Authentication ...............................  114
   14.4       Proxy-Authentication ................................  115
   15         SIP Security Using PGP ..............................  115
   15.1       PGP Authentication Scheme ...........................  115
   15.1.1     The WWW-Authenticate Response Header ................  116
   15.1.2     The Authorization Request Header ....................  117
   15.2       PGP Encryption Scheme ...............................  118
   15.3       Response-Key Header Field for PGP ...................  119
   16         Examples ............................................  119
   16.1       Registration ........................................  119
   16.2       Invitation to a Multicast Conference ................  121
   16.2.1     Request .............................................  121
   16.2.2     Response ............................................  122
   16.3       Two-party Call ......................................  123
   16.4       Terminating a Call ..................................  125
   16.5       Forking Proxy .......................................  126
   16.6       Redirects ...........................................  130
   16.7       Negotiation .........................................  131
   16.8       OPTIONS Request .....................................  132
   A          Minimal Implementation ..............................  134
   A.1        Client ..............................................  134
   A.2        Server ..............................................  135
   A.3        Header Processing ...................................  135
   B          Usage of the Session Description Protocol (SDP)......  136
   B.1        Configuring Media Streams ...........................  136
   B.2        Setting SDP Values for Unicast ......................  138
   B.3        Multicast Operation .................................  139
   B.4        Delayed Media Streams ...............................  139
   B.5        Putting Media Streams on Hold .......................  139
   B.6        Subject and SDP "s=" Line ...........................  140
   B.7        The SDP "o=" Line ...................................  140
   C          Summary of Augmented BNF ............................  141
   C.1        Basic Rules .........................................  143
   D          Using SRV DNS Records ...............................  146
   E          IANA Considerations .................................  148
   F          Acknowledgments .....................................  149
   G          Authors' Addresses ..................................  149
   H          Bibliography ........................................  150
   I          Full Copyright Statement ............................  153





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


1 Introduction

1.1 Overview of SIP Functionality

   The Session Initiation Protocol (SIP) is an application-layer control
   protocol that can establish, modify and terminate multimedia sessions
   or calls. These multimedia sessions include multimedia conferences,
   distance learning, Internet telephony and similar applications. SIP
   can invite both persons and "robots", such as a media storage
   service.  SIP can invite parties to both unicast and multicast
   sessions; the initiator does not necessarily have to be a member of
   the session to which it is inviting. Media and participants can be
   added to an existing session.

   SIP can be used to initiate sessions as well as invite members to
   sessions that have been advertised and established by other means.
   Sessions can be advertised using multicast protocols such as SAP,
   electronic mail, news groups, web pages or directories (LDAP), among
   others.

   SIP transparently supports name mapping and redirection services,
   allowing the implementation of ISDN and Intelligent Network telephony
   subscriber services. These facilities also enable personal mobility.
   In the parlance of telecommunications intelligent network services,
   this is defined as: "Personal mobility is the ability of end users to
   originate and receive calls and access subscribed telecommunication
   services on any terminal in any location, and the ability of the
   network to identify end users as they move. Personal mobility is
   based on the use of a unique personal identity (i.e., personal
   number)." [1]. Personal mobility complements terminal mobility, i.e.,
   the ability to maintain communications when moving a single end
   system from one subnet to another.

   SIP supports five facets of establishing and terminating multimedia
   communications:

   User location: determination of the end system to be used for
        communication;

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

   User availability: determination of the willingness of the called
        party to engage in communications;

   Call setup: "ringing", establishment of call parameters at both
        called and calling party;




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


   Call handling: including transfer and termination of calls.

   SIP can also initiate multi-party calls using a multipoint control
   unit (MCU) or fully-meshed interconnection instead of multicast.
   Internet telephony gateways that connect Public Switched Telephone
   Network (PSTN) parties can also use SIP to set up calls between them.

   SIP is designed as part of the overall IETF multimedia data and
   control architecture currently incorporating protocols such as RSVP
   (RFC 2205 [2]) for reserving network resources, the real-time
   transport protocol (RTP) (RFC 1889 [3]) for transporting real-time
   data and providing QOS feedback, the real-time streaming protocol
   (RTSP) (RFC 2326 [4]) for controlling delivery of streaming media,
   the session announcement protocol (SAP) [5] for advertising
   multimedia sessions via multicast and the session description
   protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions.
   However, the functionality and operation of SIP does not depend on
   any of these protocols.

   SIP can also be used in conjunction with other call setup and
   signaling protocols. In that mode, an end system uses SIP exchanges
   to determine the appropriate end system address and protocol from a
   given address that is protocol-independent. For example, SIP could be
   used to determine that the party can be reached via H.323 [7], obtain
   the H.245 [8] gateway and user address and then use H.225.0 [9] to
   establish the call.

   In another example, SIP might be used to determine that the callee is
   reachable via the PSTN and indicate the phone number to be called,
   possibly suggesting an Internet-to-PSTN gateway to be used.

   SIP does not offer conference control services such as floor control
   or voting and does not prescribe how a conference is to be managed,
   but SIP can be used to introduce conference control protocols. SIP
   does not allocate multicast addresses.

   SIP can invite users to sessions with and without resource
   reservation.  SIP does not reserve resources, but can convey to the
   invited system the information necessary to do this.

1.2 Terminology

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





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


1.3 Definitions

   This specification uses a number of terms to refer to the roles
   played by participants in SIP communications. The definitions of
   client, server and proxy are similar to those used by the Hypertext
   Transport Protocol (HTTP) (RFC 2068 [11]). The terms and generic
   syntax of URI and URL are defined in RFC 2396 [12]. The following
   terms have special significance for SIP.

   Call: A call consists of all participants in a conference invited by
        a common source. A SIP call is identified by a globally unique
        call-id (Section 6.12). Thus, if a user is, for example, invited
        to the same multicast session by several people, each of these
        invitations will be a unique call. A point-to-point Internet
        telephony conversation maps into a single SIP call. In a
        multiparty conference unit (MCU) based call-in conference, each
        participant uses a separate call to invite himself to the MCU.

   Call leg: A call leg is identified by the combination of Call-ID, To
        and From.

   Client: An application program that sends SIP requests. Clients may
        or may not interact directly with a human user.  User agents and
        proxies contain clients (and servers).

   Conference: A multimedia session (see below), identified by a common
        session description. A conference can have zero or more members
        and includes the cases of a multicast conference, a full-mesh
        conference and a two-party "telephone call", as well as
        combinations of these.  Any number of calls can be used to
        create a conference.

   Downstream: Requests sent in the direction from the caller to the
        callee (i.e., 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.

   Initiator, calling party, caller: The party initiating a conference
        invitation. Note that the calling party does not have to be the
        same as the one creating the conference.

   Invitation: A request sent to a user (or service) requesting
        participation in a session. A successful SIP invitation consists
        of two transactions: an INVITE request followed by an ACK
        request.




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


   Invitee, invited user, called party, callee: The person or service
        that the calling party is trying to invite to a conference.

   Isomorphic request or response: Two requests or responses are defined
        to be isomorphic for the purposes of this document if they have
        the same values for the Call-ID, To, From and CSeq header
        fields. In addition, isomorphic requests have to have the same
        Request-URI.

   Location server: See location service.

   Location service: A location service is used by a SIP redirect or
        proxy server to obtain information about a callee's possible
        location(s). Location services are offered by location servers.
        Location servers MAY be co-located with a SIP server, but the
        manner in which a SIP server requests location services is
        beyond the scope of this document.

   Parallel search: In a parallel search, a proxy issues several
        requests to possible user locations upon receiving an incoming
        request.  Rather than issuing one request and then waiting for
        the final response before issuing the next request as in a
        sequential search , a parallel search issues requests without
        waiting for the result of previous requests.