📄 rfc2543.txt
字号:
12.3 Proxy Server ........................................ 98
12.3.1 Proxying Requests ................................... 98
12.3.2 Proxying Responses .................................. 99
12.3.3 Stateless Proxy: Proxying Responses ................. 99
12.3.4 Stateful Proxy: Receiving Requests .................. 99
12.3.5 Stateful Proxy: Receiving ACKs ...................... 99
12.3.6 Stateful Proxy: Receiving Responses ................. 100
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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -