RFC3261: SIP: Session Initiation Protocol¶
Obsoletes:
rfc2543Category: Standards Track
June 2002
From: dynamicsoft, Columbia U., Ericsson, WorldCom, Neustar, ICIR, AT&T
Abstract¶
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.
These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.
SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types.
SIP makes use of elements called proxy servers to help route requests to the user’s current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users.
SIP also provides a registration function that allows users to upload their current locations for use by proxy servers.
SIP runs on top of several different transport protocols.
1 Introduction¶
There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants.
The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously.
Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages.
The Session Initiation Protocol (SIP) works in concert with these protocols by enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share.
For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy servers) to which user agents can send registrations, invitations to sessions, and other requests.
SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established.
2 Overview of SIP Functionality¶
SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session.
SIP supports five facets of establishing and terminating multimedia communications:
1. User location:
determination of the end system to be used for communication;
2. User availability:
determination of the willingness of the called party to engage in communications;
3. User capabilities:
determination of the media and media parameters to be used;
4. Session setup:
"ringing", establishment of session parameters at both called and calling party;
5. Session management:
including transfer and termination of sessions, modifying session parameters, and invoking services.
SIP is not a vertically integrated communications system.
SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.
Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, the Media Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions.
4 Overview of Operation¶
备注
This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature and does not contain any normative statements.
The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established.
In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet.
Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment.
Figure 1: SIP session setup example with SIP trapezoid:
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
URI:
sip:bob@biloxi.com
sips:bob@biloxi.com
SIP is based on an HTTP-like request/response transaction model.
Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response.
The INVITE (message F1 in Figure 1) might look like this:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Viacontains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction.Max-Forwardsserves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.Call-IDcontains a globally unique identifier for this call, generated by the combination of a random string and the softphone’s host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog.CSeqor Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP.
[F2、F3步说明]The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice’s softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination.
[F6步说明]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. 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.
[F9步说明]When Bob 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. 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 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:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
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.
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.
Not every element specified by the protocol contains every layer.
Furthermore, the elements specified by SIP are logical elements, not physical ones.
layers of SIP:
1. The lowest layer of SIP is its `syntax and encoding`.
2. The second layer is the `transport layer`.
3. The third layer is the `transaction layer`.
4. The toppest layer is called the `transaction user (TU)`.
transaction layer:
Transactions are a fundamental component of SIP.
A transaction is a request sent by a client transaction to a server transaction,
along with all responses to that request sent from the server transaction back to the client.
The transaction layer handles application-layer retransmissions,
matching of responses to requests, and application-layer timeouts.
Any task that a user agent client (UAC) accomplishes takes place using a series of transactions.
User agents contain a transaction layer, as do stateful proxies.
Stateless proxies do not contain a transaction layer.
The transaction layer has a client component and a server component,
each of which are represented by a finite state machine that is constructed to process a particular request.
6 Definitions¶
Address-of-Record(AOR): is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available.
Back-to-Back User Agent (B2BUA): is a logical entity that receives a request and processes it as a user agent server (UAS).
待处理
待后续完善
7 SIP Messages¶
A SIP message is either a request from a client to a server, or a response from a server to a client.
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line
Except some character set and syntax specifics, much of SIP’s message and header field syntax is identical to HTTP/1.1.
However, SIP is not an extension of HTTP.
7.1 Requests¶
Request-Line = Method SP Request-URI SP SIP-Version CRLF
参数:
Method:
REGISTER for registering contact information,
INVITE, ACK, and CANCEL for setting up sessions,
BYE for terminating sessions,
OPTIONS for querying servers about their capabilities.
7.2 Responses¶
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
SIP/2.0 allows six values for the first digit:
1xx: Provisional
request received, continuing to process the request;
2xx: Success
the action was successfully received, understood, and accepted;
3xx: Redirection
further action needs to be taken in order to complete the request;
4xx: Client Error
the request contains bad syntax or cannot be fulfilled at this server;
5xx: Server Error
the server failed to fulfill an apparently valid request;
6xx: Global Failure
the request cannot be fulfilled at any server.
7.3 Header Fields¶
header = "header-name" HCOLON header-value *(COMMA header-value)
7.4 Bodies¶
The Internet media type of the message body MUST be given by the Content-Type header field.
If the body has undergone any encoding such as compression, then this MUST be indicated by the Content- Encoding header field; otherwise, Content-Encoding MUST be omitted.
The body length in bytes is provided by the Content-Length header field.
7.5 Framing SIP Messages¶
Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols.
Each such datagram carries one request or response.
8 General User Agent Behavior¶
A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them.
UAC and UAS procedures depend strongly on two factors. First, based on whether the request or response is inside or outside of a dialog, and second, based on the method of a request.
8.1 UAC Behavior¶
Requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11).
8.1.1 Generating the Request¶
A valid SIP request formulated by a UAC MUST contain the following header fields:
1. To,
2. From,
3. CSeq,
4. Call-ID,
5. Max-Forwards,
6. Via
8.1.2 Sending the Request¶
The destination for the request is then computed.
Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows.
8.1.3 Processing Responses¶
Responses are first processed by the transport layer and then passed up to the transaction layer.
The transaction layer performs its processing and then passes the response up to the TU.
The majority of response processing in the TU is method specific.
However, there are some general behaviors independent of the method.
8.1.3.1 Transaction Layer Errors¶
In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error.
When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received.
If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code.
8.1.3.2 Unrecognized Responses¶
A UAC MUST treat any final response it does not recognize as being equivalent to the x00 response code of that class, and MUST be able to process the x00 response code for all classes.
For example, if a UAC receives an unrecognized response code of 431, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) response code.
8.1.3.3 Vias¶
If more than one Via header field value is present in a response, the UAC SHOULD discard the message.
The presence of additional Via header field values that precede the originator of the request suggests that the message was misrouted or possibly corrupted.
8.2 UAS Behavior¶
UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section).
8.2.1 Method Inspection¶
Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request.
If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response.
If the method is one supported by the server, processing continues.
8.2.2 Header Inspection¶
If a UAS does not understand a header field in a request, the server MUST ignore that header field and continue processing the message
8.2.2.1 To and Request-URI¶
If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response.
If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response.
8.2.2.2 Merged Requests¶
The same request has arrived at the UAS more than once, following different paths, most likely due to forking.
The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them.
8.2.2.3 Require¶
If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension).
Example:
UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel
8.2.3 Content Processing¶
If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content-Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response.
8.2.4 Applying Extensions¶
If the desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client.
In rare circumstances, where the server cannot process the request without the extension, the server MAY send a 421 (Extension Required) response.
8.2.5 Processing the Request¶
Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method-specific.
Section 10 covers the REGISTER request, Section 11 covers the OPTIONS request, Section 13 covers the INVITE request, and Section 15 covers the BYE request.
8.2.6 Generating the Response¶
8.2.6.1 Sending a Provisional Response¶
When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response.
8.2.7 Stateless UAS Behavior¶
A stateless UAS is a UAS that does not maintain transaction state.
A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical.
This rules out stateless registrars, for example. Stateless UASs do not use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer.
The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge response is issued.
If unauthenticated requests were handled statefully, then malicious floods of unauthenticated requests could create massive amounts of transaction state that might slow or completely halt call processing in a UAS, effectively creating a denial of service condition; for more information see Section 26.1.5.
The most important behaviors of a stateless UAS are the following:
A stateless UAS MUST NOT send provisional (1xx) responses.
A stateless UAS MUST NOT retransmit responses.
A stateless UAS MUST ignore ACK requests.
A stateless UAS MUST ignore CANCEL requests.
- To header tags MUST be generated for responses in a stateless manner
in a manner that will generate the same tag for the same request consistently.
8.3 Redirect Servers¶
In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection.
9 Canceling a Request¶
The previous section has discussed general UA behavior for generating requests and processing responses for requests of all methods. In this section, we discuss a general purpose method, called CANCEL.
The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would “stop ringing”, and then respond to the INVITE with a specific error response (a 487).
9.1 Client Behavior¶
A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE.
9.2 Server Behavior¶
The processing of a CANCEL request at a server depends on the type of server.
A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it.
10 Registrations¶
10.1 Overview¶
SIP offers a discovery capability.
If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable.
This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there.
To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain.
These address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, for example, to one or more URIs that are somehow “closer” to the desired user, sip:bob@engineering.biloxi.com, for example.
10.2 Constructing the REGISTER Request¶
Figure 2: REGISTER example:
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
| carol@chicago.com
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+---------+ +--------+=======>+-----+
A 5)Resp |
| |
1)REGISTER| |
| |
+----+ |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
+----+ carol@cube2214a.chicago.com
carol
UAs can use three ways to determine the address to which to send registrations:
1. by configuration,
2. using the address-of-record,
3. multicast.
10.3 Processing REGISTER Requests¶
A registrar is a UAS that responds to REGISTER requests and maintains a list of bindings that are accessible to proxy servers and redirect servers within its administrative domain.
11 Querying for Capabilities¶
The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities.
Example OPTIONS request:
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
Example OPTIONS response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
;received=192.0.2.4
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Contact: <mailto:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)
12 Dialogs¶
A key concept for a user agent is that of a dialog.
A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages.
A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called “secure”, and a route set, which is an ordered list of URIs.
12.1 Creation of a Dialog¶
Only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog.
A dialog established by a non-final response to a request is in the “early” state and it is called an early dialog.
12.2 Requests within a Dialog¶
Once a dialog has been established between two UAs, either of them MAY initiate new transactions as needed within the dialog.
The UA sending the request will take the UAC role for the transaction.
The UA receiving the request will take the UAS role.
Note that these may be different roles than the UAs held during the transaction that established the dialog.
12.3 Termination of a Dialog¶
In this specification, the BYE method terminates a session and the dialog associated with it.
13 Initiating a Session¶
13.1 Overview¶
When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request.
The INVITE request asks a server to establish a session.
13.2 UAC Processing¶
13.2.1 Creating the Initial INVITE¶
Since the initial INVITE represents a request outside of a dialog, Additional processing is required for the specific case of INVITE.
13.2.2 Processing INVITE Responses¶
Once the INVITE has been passed to the INVITE client transaction, the UAC waits for responses for the INVITE.
13.3 UAS Processing¶
13.3.1 Processing of the INVITE¶
The UAS core will receive INVITE requests from the transaction layer.
Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes of establishing a new session.
14 Modifying an Existing Session¶
A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a session using the offer-answer model.
This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a
re-INVITE.Either the caller or callee can modify an existing session.
14.1 UAC Behavior¶
As a result, a UAC that wants to add a media stream, for example, will create a new offer that contains this media stream, and send that in an INVITE request to its peer. It is important to note that the full description of the session, not just the change, is sent.
14.2 UAS Behavior¶
Section 13.3.1 describes the procedure for distinguishing incoming re-INVITEs from incoming initial INVITEs and handling a re-INVITE for an existing dialog.
15 Terminating a Session¶
The state of the session and the state of the dialog are very closely related.
When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, it also creates a session.
As a result, each session is “associated” with a single dialog - the one which resulted in its creation.
15.1 Terminating a Session with a BYE Request¶
15.1.1 UAC Behavior¶
Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction.
If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated.
15.1.2 UAS Behavior¶
If the BYE does not match an existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction Does Not Exist) response and pass that to the server transaction.
A UAS core receiving a BYE request for an existing dialog, Once done, the UAS SHOULD terminate the session (and therefore stop sending and listening for media).
16 Proxy Behavior¶
16.1 Overview¶
SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients.
A proxy can operate in either a stateful or stateless mode for each new request. When stateless, a proxy acts as a simple forwarding element. A stateful proxy remembers information (specifically, transaction state) about each incoming request and any requests it sends as a result of processing the incoming request.
16.2 Stateful Proxy¶
When stateful, a proxy is purely a SIP transaction processing engine.
For all new requests, including any with unknown methods, an element intending to proxy the request MUST:
1. Validate the request (Section 16.3)
2. Preprocess routing information (Section 16.4)
3. Determine target(s) for the request (Section 16.5)
4. Forward the request to each target (Section 16.6)
5. Process all responses (Section 16.7)
16.3 Request Validation¶
A valid message must pass the following checks:
1. Reasonable Syntax
2. URI scheme
3. Max-Forwards
4. (Optional) Loop Detection
5. Proxy-Require
6. Proxy-Authorization
16.4 Route Information Preprocessing¶
This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router.
16.5 Determining Request Targets¶
Next, the proxy calculates the target(s) of the request. The set of targets will either be predetermined by the contents of the request or will be obtained from an abstract location service.
16.6 Request Forwarding¶
For each target, the proxy forwards the request following these steps:
1. Make a copy of the received request
2. Update the Request-URI
3. Update the Max-Forwards header field
4. Optionally add a Record-route header field value
5. Optionally add additional header fields
6. Postprocess routing information
7. Determine the next-hop address, port, and transport
8. Add a Via header field value
9. Add a Content-Length header field if necessary
10. Forward the new request
11. Set timer C
16.7 Response Processing¶
As client transactions pass responses to the proxy layer, the following processing MUST take place:
1. Find the appropriate response context
2. Update timer C for provisional responses
3. Remove the topmost Via
4. Add the response to the response context
5. Check to see if this response should be forwarded immediately
6. When necessary, choose the best final response from the response context
The following processing MUST be performed on each response that is forwarded:
7. Aggregate authorization header field values if necessary
8. Optionally rewrite Record-Route header field values
9. Forward the response
10. Generate any necessary CANCEL requests
16.8 Processing Timer C¶
If timer C should fire, the proxy MUST either reset the timer with any value it chooses, or terminate the client transaction.
16.9 Handling Transport Errors¶
If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response.
If the proxy is notified of an error when forwarding a response, it drops the response.
16.10 CANCEL Processing¶
A proxy MUST cancel any pending client transactions associated with a response context when it receives a matching CANCEL request.
16.11 Stateless Proxy¶
When acting statelessly, a proxy is a simple message forwarder.
16.12 Summary of Proxy Route Processing¶
the processing a proxy performs on a request containing a Route header field can be summarized in the following steps:
1. The proxy will inspect the Request-URI.
2. The proxy will inspect the URI in the topmost Route header field value.
3. The proxy will forward the request to the resource indicated by the URI in the topmost Route header field value
or in the Request-URI if no Route header field is present.
16.12.1 Examples¶
16.12.1.1 Basic SIP Trapezoid¶
This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing
U1 sends msg to P1:
INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
P1 is not responsible for domain.com, so it looks it up in DNS and sends it there. It also adds a Record-Route header field value:
INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p1.example.com;lr>
P2 gets this. It is responsible for domain.com so it runs a location service and rewrites the Request-URI:
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>
The callee at u2.domain.com gets this and responds with a 200 OK:
SIP/2.0 200 OK
Contact: sip:callee@u2.domain.com
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>
The callee at u2 also sets its dialog state’s remote target URI to sip:caller@u1.example.com and its route set to:
(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
This is forwarded by P2 to P1 to U1 as normal.
Now, U1 sets its dialog state’s remote target URI to sip:callee@u2.domain.com and its route set to:
(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)
U1 constructs the following BYE request:
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
P1 notices that it is not responsible for the resource indicated in the Request-URI so it doesn’t change it. It does see that it is the first value in the Route header field, so it removes that value, and forwards the request to P2:
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p2.domain.com;lr>
P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for domain.com, not u2.domain.com), so it doesn’t change it.
It does see itself in the first Route header field value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the Request-URI:
BYE sip:callee@u2.domain.com SIP/2.0
16.12.1.2 Traversing a Strict-Routing Proxy¶
In this scenario, a dialog is established across four proxies, each of which adds Record-Route header field values. The third proxy implements the strict-routing procedures specified in RFC 2543 and many works in progress.
U1->P1->P2->P3->P4->U2
The INVITE arriving at U2 contains:
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
U2 responds to with a 200 OK. Later, U2 sends the following BYE request to P4 based on the first Route header field value:
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
P4 Notice <sip:p3.middle.com> does not contain the lr parameter, so before sending, it reformats the request to be::
BYE sip:p3.middle.com SIP/2.0
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Route: <sip:caller@u1.example.com>
P3 is a strict router, so it forwards the following to P2:
BYE sip:p2.example.com;lr SIP/2.0
Route: <sip:p1.example.com;lr>
Route: <sip:caller@u1.example.com>
P2:
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p1.example.com;lr>
P1:
BYE sip:caller@u1.example.com SIP/2.0
Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the request to u1.example.com based on the Request-URI.
16.12.1.3 Rewriting Record-Route Header Field Values¶
In this scenario, U1 and U2 are in different private namespaces and they enter a dialog through a proxy P1, which acts as a gateway between the namespaces.
U1->P1->U2
U1 sends:
INVITE sip:callee@gateway.rightprivatespace.com SIP/2.0
Contact: <sip:caller@u1.leftprivatespace.com>
P1 uses its location service and sends the following to U2:
INVITE sip:callee@rightprivatespace.com SIP/2.0
Contact: <sip:caller@u1.leftprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>
U2 sends this 200 (OK) back to P1:
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>
P1 rewrites its Record-Route header parameter to provide a value that U1 will find useful, and sends the following to U1:
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.leftprivatespace.com;lr>
Later, U1 sends the following BYE request to P1:
BYE sip:callee@u2.rightprivatespace.com SIP/2.0
Route: <sip:gateway.leftprivatespace.com;lr>
which P1 forwards to U2 as:
BYE sip:callee@u2.rightprivatespace.com SIP/2.0
17 Transactions¶
SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges.
Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses.
Transactions have a client side and a server side. The client side is known as a client transaction and the server side as a server transaction.
Figure 4: Transaction relationships:
+---------+ +---------+ +---------+ +---------+
| +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ |
| |C||------->||S| |C||------->||S| |C||------->||S| |
| |l|| ||e| |l|| ||e| |l|| ||e| |
| |i|| ||r| |i|| ||r| |i|| ||r| |
| |e|| ||v| |e|| ||v| |e|| ||v| |
| |n|| ||e| |n|| ||e| |n|| ||e| |
| |t|| ||r| |t|| ||r| |t|| ||r| |
| | || || | | || || | | || || | |
| |T|| ||T| |T|| ||T| |T|| ||T| |
| |r|| ||r| |r|| ||r| |r|| ||r| |
| |a|| ||a| |a|| ||a| |a|| ||a| |
| |n|| ||n| |n|| ||n| |n|| ||n| |
| |s||Response||s| |s||Response||s| |s||Response||s| |
| +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ |
+---------+ +---------+ +---------+ +---------+
UAC Outbound Inbound UAS
Proxy Proxy
17.1 Client Transaction¶
17.1.1 INVITE Client Transaction¶
The INVITE transaction consists of a three-way handshake:
1. The client transaction sends an INVITE,
2. the server transaction sends responses,
3. the client transaction sends an ACK.
Figure 5: INVITE client transaction:
|INVITE from TU
Timer A fires |INVITE sent
Reset A, V Timer B fires
INVITE sent +-----------+ or Transport Err.
+---------| |---------------+inform TU
| | Calling | |
+-------->| |-------------->|
+-----------+ 2xx |
| | 2xx to TU |
| |1xx |
300-699 +---------------+ |1xx to TU |
ACK sent | | |
resp. to TU | 1xx V |
| 1xx to TU -----------+ |
| +---------| | |
| | |Proceeding |-------------->|
| +-------->| | 2xx |
| +-----------+ 2xx to TU |
| 300-699 | |
| ACK sent, | |
| resp. to TU| |
| | | NOTE:
| 300-699 V |
| ACK sent +-----------+Transport Err. | transitions
| +---------| |Inform TU | labeled with
| | | Completed |-------------->| the event
| +-------->| | | over the action
| +-----------+ | to take
| ^ | |
| | | Timer D fires |
+--------------+ | - |
| |
V |
+-----------+ |
| | |
| Terminated|<--------------+
| |
+-----------+
Example, consider the following request:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITE
The ACK request for a non-2xx final response to this request would look like this:
ACK sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK
17.1.2 Non-INVITE Client Transaction¶
Non-INVITE transactions do not make use of ACK. They are simple request-response interactions.
17.1.3 Matching Responses to Client Transactions¶
When the transport layer in the client receives a response, it has to determine which client transaction will handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place.
The branch parameter in the top Via header field is used for this purpose.
17.1.4 Handling Transport Errors¶
Figure 6: non-INVITE client transaction:
|Request from TU
|send request
Timer E V
send request +-----------+
+---------| |-------------------+
| | Trying | Timer F |
+-------->| | or Transport Err.|
+-----------+ inform TU |
200-699 | | |
resp. to TU | |1xx |
+---------------+ |resp. to TU |
| | |
| Timer E V Timer F |
| send req +-----------+ or Transport Err. |
| +---------| | inform TU |
| | |Proceeding |------------------>|
| +-------->| |-----+ |
| +-----------+ |1xx |
| | ^ |resp to TU |
| 200-699 | +--------+ |
| resp. to TU | |
| | |
| V |
| +-----------+ |
| | | |
| | Completed | |
| | | |
| +-----------+ |
| ^ | |
| | | Timer K |
+--------------+ | - |
| |
V |
NOTE: +-----------+ |
| | |
transitions | Terminated|<------------------+
labeled with | |
the event +-----------+
over the action
to take
17.2 Server Transaction¶
The server transaction is responsible for the delivery of requests to the TU and the reliable transmission of responses. It accomplishes this through a state machine.
Figure 7: INVITE server transaction:
|INVITE
|pass INV to TU
INVITE V send 100 if TU won't in 200ms
send response+-----------+
+--------| |--------+101-199 from TU
| | Proceeding| |send response
+------->| |<-------+
| | Transport Err.
| | Inform TU
| |--------------->+
+-----------+ |
300-699 from TU | |2xx from TU |
send response | |send response |
| +------------------>+
| |
INVITE V Timer G fires |
send response+-----------+ send response |
+--------| |--------+ |
| | Completed | | |
+------->| |<-------+ |
+-----------+ |
| | |
ACK | | |
- | +------------------>+
| Timer H fires |
V or Transport Err.|
+-----------+ Inform TU |
| | |
| Confirmed | |
| | |
+-----------+ |
| |
|Timer I fires |
|- |
| |
V |
+-----------+ |
| | |
| Terminated|<---------------+
| |
+-----------+
18 Transport¶
The transport layer is responsible for the actual transmission of requests and responses over network transports.
This includes determination of the connection to use for a request or response in the case of connection-oriented transports
The transport layer is responsible for managing persistent connections for transport protocols like TCP and SCTP, or TLS over those, including ones opened to the transport layer.
This includes connections opened by the client or server transports, so that connections are shared between client and server transport functions.
19 Common Message Components¶
There are certain components of SIP messages that appear in various places within SIP messages (and sometimes, outside of them) that merit separate discussion.
19.1 SIP and SIPS Uniform Resource Indicators¶
A SIP or SIPS URI identifies a communications resource.
19.1.1 SIP and SIPS URI Components¶
Its general form, in the case of a SIP URI, is:
sip:user:password@host:port;uri-parameters?headers
示例:
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
19.1.2 Character Escaping Requirements¶
(1): The default port value is transport and scheme dependent. The default is 5060 for sip: using UDP, TCP, or SCTP. The default is 5061 for sip: using TLS over TCP and sips: over TCP.
(2): The default transport is scheme dependent. For sip:, it is UDP. For sips:, it is TCP.
19.1.3 Example SIP and SIPS URIs¶
sip:alice@atlanta.com
sip:alice:secretword@atlanta.com;transport=tcp
sips:alice@atlanta.com?subject=project%20x&priority=urgent
sip:+1-212-555-1212:1234@gateway.com;user=phone
sips:1212@gateway.com
sip:alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
sip:alice;day=tuesday@atlanta.com
19.1.4 URI Comparison¶
SIP and SIPS URIs are compared for equality according to the following rules:
- A SIP and SIPS URI are never equivalent.
- Comparison of the userinfo of SIP and SIPS URIs is case-sensitive.
- The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs.
- Characters other than those in the "reserved" set (see RFC 2396 [5]) are equivalent to their ""%" HEX HEX" encoding.
- An IP address that is the result of a DNS lookup of a host name does not match that host name.
- For two URIs to be equal, the user, password, host, and port components must match.
The URIs within each of the following sets are equivalent:
sip:%61lice@atlanta.com;transport=TCP
sip:alice@AtLanTa.CoM;Transport=tcp
sip:carol@chicago.com
sip:carol@chicago.com;newparam=5
sip:carol@chicago.com;security=on
sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
sip:alice@atlanta.com?subject=project%20x&priority=urgent
sip:alice@atlanta.com?priority=urgent&subject=project%20x
The URIs within each of the following sets are not equivalent:
SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames)
sip:alice@AtLanTa.CoM;Transport=UDP
sip:bob@biloxi.com (can resolve to different ports)
sip:bob@biloxi.com:5060
sip:bob@biloxi.com (can resolve to different transports)
sip:bob@biloxi.com;transport=udp
sip:bob@biloxi.com (can resolve to different port and transports)
sip:bob@biloxi.com:6000;transport=tcp
sip:carol@chicago.com (different header component)
sip:carol@chicago.com?Subject=next%20meeting
sip:bob@phone21.boxesbybob.com (even though that's what
sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to)
Note that equality is not transitive:
- sip:carol@chicago.com and sip:carol@chicago.com;security=on are equivalent
- sip:carol@chicago.com and sip:carol@chicago.com;security=off are equivalent
But
- sip:carol@chicago.com;security=on and sip:carol@chicago.com;security=off are not equivalent
19.1.5 Forming Requests from a URI¶
19.1.6 Relating SIP URIs and tel URLs¶
When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI.
Thus, tel:+358-555-1234567;postd=pp22 becomes:
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
or
sips:+358-555-1234567;postd=pp22@foo.com;user=phone
not
sip:+358-555-1234567@foo.com;postd=pp22;user=phone
or
sips:+358-555-1234567@foo.com;postd=pp22;user=phone
20 Header Fields¶
Values in this column are:
R: header field may only appear in requests;
r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response
codes with which the header field can be used;
c: header field is copied from the request to the response.
The “proxy” column describes the operations a proxy may perform on a header field:
a: A proxy can add or concatenate the header field if not present.
m: A proxy can modify an existing header field value.
d: A proxy can delete a header field value.
r: A proxy must be able to read the header field, and thus this
header field cannot be encrypted.
The next six columns relate to the presence of a header field in a method:
c: Conditional; requirements on the header field depend on the
context of the message.
m: The header field is mandatory.
m*: The header field SHOULD be sent, but clients/servers need to
be prepared to receive messages without that header field.
o: The header field is optional.
t: The header field SHOULD be sent, but clients/servers need to be
prepared to receive messages without that header field.
*: The header field is required if the message body is not empty.
See Sections 20.14, 20.15 and 7.4 for details.
-: The header field is not applicable.
Table 2: Summary of header fields:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c
Alert-Info R ar - - - o - -
Alert-Info 180 ar - - - o - -
Allow R - o - o o o
Allow 2xx - o - m* m* o
Allow r - o - o o o
Allow 405 - m - m m m
Authentication-Info 2xx - o - o o o
Authorization R o o o o o o
Call-ID c r m m m m m m
Call-Info ar - - - o o o
Contact R o - - m o o
Contact 1xx - - - o - -
Contact 2xx - - - m o o
Contact 3xx d - o - o o o
Contact 485 - o - o o o
Content-Disposition o o - o o o
Content-Encoding o o - o o o
Content-Language o o - o o o
Content-Length ar t t t t t t
Content-Type * * - * * *
CSeq c r m m m m m m
Date a o o o o o o
Error-Info 300-699 a - o o o o o
Expires - - - o - o
From c r m m m m m m
In-Reply-To R - - - o - -
Max-Forwards R amr m m m m m m
Min-Expires 423 - - - - - m
MIME-Version o o - o o o
Organization ar - - - o o o
Priority R ar - - - o - -
Proxy-Authenticate 407 ar - m - m m m
Proxy-Authenticate 401 ar - o o o o o
Proxy-Authorization R dr o o - o o o
Proxy-Require R ar - o - o o o
Record-Route R ar o o o o o -
Record-Route 2xx,18x mr - o o o o -
Reply-To - - - o - -
Require ar - c - c c c
Retry-After 404,413,480,486 - o o o o o
500,503 - o o o o o
600,603 - o o o o o
Route R adr c c c c c c
Server r - o o o o o
Subject R - - - o - -
Supported R - o o m* o o
Supported 2xx - o o m* m* o
Timestamp o o o o o o
To c(1) r m m m m m m
Unsupported 420 - m - m m m
User-Agent o o o o o o
Via R amr m m m m m m
Via rc dr m m m m m m
Warning r - o o o o o
WWW-Authenticate 401 ar - m - m m m
WWW-Authenticate 407 ar - o - o o o
20.1 Accept¶
Accept: application/sdp;level=1, application/x-private, text/html
20.2 Accept-Encoding¶
Accept-Encoding: gzip
20.3 Accept-Language¶
Accept-Language: da, en-gb;q=0.8, en;q=0.7
20.4 Alert-Info¶
Alert-Info: <http://www.example.com/sounds/moo.wav>
20.5 Allow¶
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
20.6 Authentication-Info¶
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
20.8 Call-ID¶
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
20.9 Call-Info¶
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
<http://www.example.com/alice/> ;purpose=info
20.10 Contact¶
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
m: <sips:bob@192.0.2.4>;expires=60
20.11 Content-Disposition¶
Content-Disposition: session
20.12 Content-Encoding¶
Content-Encoding: gzip
e: tar
20.13 Content-Language¶
Content-Language: fr
20.14 Content-Length¶
Content-Length: 349
l: 173
20.15 Content-Type¶
Content-Type: application/sdp
c: text/html; charset=ISO-8859-4
20.16 CSeq¶
CSeq: 4711 INVITE
20.17 Date¶
Date: Sat, 13 Nov 2010 23:29:00 GMT
20.18 Error-Info¶
SIP/2.0 404 The number you have dialed is not in service
Error-Info: <sip:not-in-service-recording@atlanta.com>
20.19 Expires¶
Expires: 5
20.20 From¶
From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
20.21 In-Reply-To¶
In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com
20.22 Max-Forwards¶
Max-Forwards: 6
20.23 Min-Expires¶
Min-Expires: 60
20.24 MIME-Version¶
MIME-Version: 1.0
20.25 Organization¶
Organization: Boxes by Bob
20.26 Priority¶
Subject: A tornado is heading our way!
Priority: emergency
or
Subject: Weekend plans
Priority: non-urgent
20.27 Proxy-Authenticate¶
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
20.29 Proxy-Require¶
Proxy-Require: foo
20.30 Record-Route¶
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
20.32 Require¶
Require: 100rel
20.33 Retry-After¶
Retry-After: 18000;duration=3600
Retry-After: 120 (I'm in a meeting)
20.34 Route¶
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
20.35 Server¶
Server: HomeServer v2
20.36 Subject¶
Subject: Need more boxes
s: Tech Support
20.37 Supported¶
Supported: 100rel
20.38 Timestamp¶
Timestamp: 54
20.39 To¶
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
20.40 Unsupported¶
Unsupported: foo
20.41 User-Agent¶
User-Agent: Softphone Beta1.5
20.42 Via¶
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
20.43 Warning¶
Warning: 307 isi.edu "Session parameter 'foo' not understood"
Warning: 301 isi.edu "Incompatible network address type 'E.164'"
20.44 WWW-Authenticate¶
WWW-Authenticate: Digest realm="atlanta.com",
domain="sip:boxesbybob.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
21 Response Codes¶
21.1 Provisional 1xx¶
Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response.
21.1.1 100 Trying
21.1.2 180 Ringing
21.1.3 181 Call Is Being Forwarded
21.1.4 182 Queued
21.1.5 183 Session Progress
21.2 Successful 2xx¶
The request was successful.
21.2.1 200 OK
21.3 Redirection 3xx¶
3xx responses give information about the user’s new location, or about alternative services that might be able to satisfy the call.
21.3.1 300 Multiple Choices
21.3.2 301 Moved Permanently
21.3.3 302 Moved Temporarily
21.3.4 305 Use Proxy
21.3.5 380 Alternative Service
21.4 Request Failure 4xx¶
4xx responses are definite failure responses from a particular server.
21.4.1 400 Bad Request
21.4.2 401 Unauthorized
21.4.3 402 Payment Required
21.4.4 403 Forbidden
21.4.5 404 Not Found
21.4.6 405 Method Not Allowed
21.4.7 406 Not Acceptable
21.4.8 407 Proxy Authentication Required
21.4.9 408 Request Timeout
21.4.10 410 Gone
21.4.11 413 Request Entity Too Large
21.4.12 414 Request-URI Too Long
21.4.13 415 Unsupported Media Type
21.4.14 416 Unsupported URI Scheme
21.4.15 420 Bad Extension
21.4.16 421 Extension Required
21.4.17 423 Interval Too Brief
21.4.18 480 Temporarily Unavailable
21.4.19 481 Call/Transaction Does Not Exist
21.4.20 482 Loop Detected
21.4.21 483 Too Many Hops
21.4.22 484 Address Incomplete
21.4.23 485 Ambiguous
21.4.24 486 Busy Here
21.4.25 487 Request Terminated
21.4.26 488 Not Acceptable Here
21.4.27 491 Request Pending
21.4.28 493 Undecipherable
21.5 Server Failure 5xx¶
5xx responses are failure responses given when a server itself has erred.
21.5.1 500 Server Internal Error
21.5.2 501 Not Implemented
21.5.3 502 Bad Gateway
21.5.4 503 Service Unavailable
21.5.5 504 Server Time-out
21.5.6 505 Version Not Supported
21.5.7 513 Message Too Large
21.6 Global Failures 6xx¶
6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI.
21.6.1 600 Busy Everywhere
21.6.2 603 Decline
21.6.3 604 Does Not Exist Anywhere
21.6.4 606 Not Acceptable
22 Usage of HTTP Authentication¶
SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP.
备注
Note that due to its weak security, the usage of “Basic” authentication has been deprecated(Use the “Digest” authentication mechanism). Servers MUST NOT accept credentials using the “Basic” authorization scheme, and servers also MUST NOT challenge with “Basic”. This is a change from RFC 2543.
22.1 Framework¶
realm string:
- Realm strings MUST be globally unique.
It is RECOMMENDED that a realm string contain a hostname or domain name
- Realm strings SHOULD present a human-readable identifier that can be rendered to a user.
Example:
INVITE sip:bob@biloxi.com SIP/2.0
Authorization: Digest realm="biloxi.com", <...>
22.2 User-to-User Authentication¶
When a UAS receives a request from a UAC, the UAS MAY authenticate the originator before the request is processed.
The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages:
WWW-Authenticate: Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
When the originating UAC receives the 401 (Unauthorized), it SHOULD re-originate the request with the proper credentials.
An example of the Authorization header field is:
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
22.3 Proxy-to-User Authentication¶
Similarly, when a UAC sends a request to a proxy server, the proxy server MAY authenticate the originator before the request is processed.
22.4 The Digest Authentication Scheme¶
The SIP scheme usage of Digest Authentication is almost completely identical to that for HTTP
23 S/MIME¶
SIP messages carry MIME bodies and the MIME standard includes mechanisms for securing MIME contents to ensure both integrity and confidentiality (including the ‘multipart/signed’ and ‘application/pkcs7-mime’ MIME types
23.1 S/MIME Certificates¶
The certificates that are used to identify an end-user for the purposes of S/MIME differ from those used by servers in one important respect - rather than asserting that the identity of the holder corresponds to a particular hostname, these certificates assert that the holder is identified by an end-user address.
23.2 S/MIME Key Exchange¶
SIP itself can also be used as a means to distribute public keys in the following manner.
23.3 Securing MIME bodies¶
The following is an example of an encrypted S/MIME SDP body within a SIP message(the text boxed in asterisks (“*”) is encrypted):
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Disposition: attachment; filename=smime.p7m
handling=required
*******************************************************
* Content-Type: application/sdp *
* *
* v=0 *
* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
* s=- *
* t=0 0 *
* c=IN IP4 pc33.atlanta.com *
* m=audio 3456 RTP/AVP 0 1 3 99 *
* a=rtpmap:0 PCMU/8000 *
*******************************************************
23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP¶
As a means of providing some degree of end-to-end authentication, integrity or confidentiality for SIP header fields, S/MIME can encapsulate entire SIP messages within MIME bodies of type “message/sip” and then apply MIME security to these bodies in the same manner as typical SIP bodies.
The following is an example of the use of a tunneled “message/sip” body:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
Content-Length: 568
--boundary42
Content-Type: message/sip
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <bob@biloxi.com>
From: Alice <alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
s=Session SDP
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42-
24 Examples¶
24.1 Registration¶
Bob registers on start-up:
biloxi.com Bob's
registrar softphone
| |
| REGISTER F1 |
|<---------------|
| 200 OK F2 |
|--------------->|
Figure 9: SIP Registration Example
F1 REGISTER Bob -> Registrar:
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 0
The registration expires after two hours. F2 200 OK Registrar -> Bob:
SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
From: Bob <sip:bob@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@192.0.2.4>
Expires: 7200
Content-Length: 0
24.2 Session Setup¶
This example contains the full details of the example session setup in Section 4.
待处理
具体看文档
25 Augmented BNF for the SIP Protocol¶
quoted-pair = "\" (%x00-09 / %x0B-0C
/ %x0E-7F)
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]
userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
password = *( unreserved / escaped /
"&" / "=" / "+" / "$" / "," )
hostport = host [ ":" port ]
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note,
however, that any characters allowed there that are not allowed in
the user part of the SIP URI MUST be escaped.
uri-parameters = *( ";" uri-parameter)
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / other-param
transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls"
/ other-transport)
other-transport = token
user-param = "user=" ( "phone" / "ip" / other-user)
other-user = token
method-param = "method=" Method
ttl-param = "ttl=" ttl
maddr-param = "maddr=" host
lr-param = "lr"
other-param = pname [ "=" pvalue ]
pname = 1*paramchar
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / escaped
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*( hnv-unreserved / unreserved / escaped )
hvalue = *( hnv-unreserved / unreserved / escaped )
hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$"
SIP-message = Request / Response
Request = Request-Line
*( message-header )
CRLF
[ message-body ]
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Request-URI = SIP-URI / SIPS-URI / absoluteURI
absoluteURI = scheme ":" ( hier-part / opaque-part )
hier-part = ( net-path / abs-path ) [ "?" query ]
net-path = "//" authority [ abs-path ]
abs-path = "/" path-segments
opaque-part = uric-no-slash *uric
uric = reserved / unreserved / escaped
uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@"
/ "&" / "=" / "+" / "$" / ","
path-segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved / escaped /
":" / "@" / "&" / "=" / "+" / "$" / ","
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = srvr / reg-name
srvr = [ [ userinfo "@" ] hostport ]
reg-name = 1*( unreserved / escaped / "$" / ","
/ ";" / ":" / "@" / "&" / "=" / "+" )
query = *uric
SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT
message-header = (Accept
/ Accept-Encoding
/ Accept-Language
/ Alert-Info
/ Allow
/ Authentication-Info
/ Authorization
/ Call-ID
/ Call-Info
/ Contact
/ Content-Disposition
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Type
/ CSeq
/ Date
/ Error-Info
/ Expires
/ From
/ In-Reply-To
/ Max-Forwards
/ MIME-Version
/ Min-Expires
/ Organization
/ Priority
/ Proxy-Authenticate
/ Proxy-Authorization
/ Proxy-Require
/ Record-Route
/ Reply-To
/ Require
/ Retry-After
/ Route
/ Server
/ Subject
/ Supported
/ Timestamp
/ To
/ Unsupported
/ User-Agent
/ Via
/ Warning
/ WWW-Authenticate
/ extension-header) CRLF
INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps
ACKm = %x41.43.4B ; ACK in caps
OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps
BYEm = %x42.59.45 ; BYE in caps
CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps
REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm
/ extension-method
extension-method = token
Response = Status-Line
*( message-header )
CRLF
[ message-body ]
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Code = Informational
/ Redirection
/ Success
/ Client-Error
/ Server-Error
/ Global-Failure
/ extension-code
extension-code = 3DIGIT
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
Informational = "100" ; Trying
/ "180" ; Ringing
/ "181" ; Call Is Being Forwarded
/ "182" ; Queued
/ "183" ; Session Progress
Success = "200" ; OK
Redirection = "300" ; Multiple Choices
/ "301" ; Moved Permanently
/ "302" ; Moved Temporarily
/ "305" ; Use Proxy
/ "380" ; Alternative Service
Client-Error = "400" ; Bad Request
/ "401" ; Unauthorized
/ "402" ; Payment Required
/ "403" ; Forbidden
/ "404" ; Not Found
/ "405" ; Method Not Allowed
/ "406" ; Not Acceptable
/ "407" ; Proxy Authentication Required
/ "408" ; Request Timeout
/ "410" ; Gone
/ "413" ; Request Entity Too Large
/ "414" ; Request-URI Too Large
/ "415" ; Unsupported Media Type
/ "416" ; Unsupported URI Scheme
/ "420" ; Bad Extension
/ "421" ; Extension Required
/ "423" ; Interval Too Brief
/ "480" ; Temporarily not available
/ "481" ; Call Leg/Transaction Does Not Exist
/ "482" ; Loop Detected
/ "483" ; Too Many Hops
/ "484" ; Address Incomplete
/ "485" ; Ambiguous
/ "486" ; Busy Here
/ "487" ; Request Terminated
/ "488" ; Not Acceptable Here
/ "491" ; Request Pending
/ "493" ; Undecipherable
Server-Error = "500" ; Internal Server Error
/ "501" ; Not Implemented
/ "502" ; Bad Gateway
/ "503" ; Service Unavailable
/ "504" ; Server Time-out
/ "505" ; SIP Version not supported
/ "513" ; Message Too Large
Global-Failure = "600" ; Busy Everywhere
/ "603" ; Decline
/ "604" ; Does not exist anywhere
/ "606" ; Not Acceptable
Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ]
accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*"
/ ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype )
) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param)
codings = content-coding / "*"
content-coding = token
Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ]
language = language-range *(SEMI accept-param)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param)
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
Allow = "Allow" HCOLON [Method *(COMMA Method)]
Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response)
/ other-response
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
username = "username" EQUAL username-value
username-value = quoted-string
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value = rquest-uri ; Equal to request-uri as specified
by HTTP/1.1
message-qop = "qop" EQUAL qop-value
cnonce = "cnonce" EQUAL cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
auth-param = auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
other-response = auth-scheme LWS auth-param
*(COMMA auth-param)
auth-scheme = token
Authentication-Info = "Authentication-Info" HCOLON ainfo
*(COMMA ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce" EQUAL nonce-value
response-auth = "rspauth" EQUAL response-digest
response-digest = LDQUOT *LHEX RDQUOT
Call-ID = ( "Call-ID" / "i" ) HCOLON callid
callid = word [ "@" word ]
Call-Info = "Call-Info" HCOLON info *(COMMA info)
info = LAQUOT absoluteURI RAQUOT *( SEMI info-param)
info-param = ( "purpose" EQUAL ( "icon" / "info"
/ "card" / token ) ) / generic-param
Contact = ("Contact" / "m" ) HCOLON
( STAR / (contact-param *(COMMA contact-param)))
contact-param = (name-addr / addr-spec) *(SEMI contact-params)
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = SIP-URI / SIPS-URI / absoluteURI
display-name = *(token LWS)/ quoted-string
contact-params = c-p-q / c-p-expires
/ contact-extension
c-p-q = "q" EQUAL qvalue
c-p-expires = "expires" EQUAL delta-seconds
contact-extension = generic-param
delta-seconds = 1*DIGIT
Content-Disposition = "Content-Disposition" HCOLON
disp-type *( SEMI disp-param )
disp-type = "render" / "session" / "icon" / "alert"
/ disp-extension-token
disp-param = handling-param / generic-param
handling-param = "handling" EQUAL
( "optional" / "required"
/ other-handling )
other-handling = token
disp-extension-token = token
Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON
content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag)
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
m-subtype = extension-token / iana-token
iana-token = token
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
Date = "Date" HCOLON SIP-date
SIP-date = rfc1123-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" / "Tue" / "Wed"
/ "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri)
error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
Expires = "Expires" HCOLON delta-seconds
From = ( "From" / "f" ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
from-param = tag-param / generic-param
tag-param = "tag" EQUAL token
In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid)
Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT
MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
Min-Expires = "Min-Expires" HCOLON delta-seconds
Organization = "Organization" HCOLON [TEXT-UTF8-TRIM]
Priority = "Priority" HCOLON priority-value
priority-value = "emergency" / "urgent" / "normal"
/ "non-urgent" / other-priority
other-priority = token
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ other-challenge
other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param)
digest-cln = realm / domain / nonce
/ opaque / stale / algorithm
/ qop-options / auth-param
realm = "realm" EQUAL realm-value
realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI
*( 1*SP URI ) RDQUOT
URI = absoluteURI / abs-path
nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess"
/ token )
qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
Proxy-Require = "Proxy-Require" HCOLON option-tag
*(COMMA option-tag)
option-tag = token
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
rec-route = name-addr *( SEMI rr-param )
rr-param = generic-param
Reply-To = "Reply-To" HCOLON rplyto-spec
rplyto-spec = ( name-addr / addr-spec )
*( SEMI rplyto-param )
rplyto-param = generic-param
Require = "Require" HCOLON option-tag *(COMMA option-tag)
Retry-After = "Retry-After" HCOLON delta-seconds
[ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds)
/ generic-param
Route = "Route" HCOLON route-param *(COMMA route-param)
route-param = name-addr *( SEMI rr-param )
Server = "Server" HCOLON server-val *(LWS server-val)
server-val = product / comment
product = token [SLASH product-version]
product-version = token
Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
Supported = ( "Supported" / "k" ) HCOLON
[option-tag *(COMMA option-tag)]
Timestamp = "Timestamp" HCOLON 1*(DIGIT)
[ "." *(DIGIT) ] [ LWS delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]
To = ( "To" / "t" ) HCOLON ( name-addr
/ addr-spec ) *( SEMI to-param )
to-param = tag-param / generic-param
Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag)
User-Agent = "User-Agent" HCOLON server-val *(LWS server-val)
Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ via-extension
via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address)
via-branch = "branch" EQUAL token
via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version
SLASH transport
protocol-name = "SIP" / token
protocol-version = token
transport = "UDP" / "TCP" / "TLS" / "SCTP"
/ other-transport
sent-by = host [ COLON port ]
ttl = 1*3DIGIT ; 0 to 255
Warning = "Warning" HCOLON warning-value *(COMMA warning-value)
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = hostport / pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
pseudonym = token
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
extension-header = header-name HCOLON header-value
header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
message-body = *OCTET
26 Security Considerations: Threat Model and Security Usage Recommendations¶
SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial.
待处理
todo
27 IANA Considerations¶
28 Changes From RFC 2543¶
28.1 Major Functional Changes¶
28.2 Minor Functional Changes¶
A Table of Timer Values¶
Table 4: Summary of timers:
Timer Value Section Meaning
----------------------------------------------------------------------
T1 500ms default Section 17.1.1.1 RTT Estimate
T2 4s Section 17.1.2.2 The maximum retransmit
interval for non-INVITE
requests and INVITE
responses
T4 5s Section 17.1.2.2 Maximum duration a
message will
remain in the network
Timer A initially T1 Section 17.1.1.2 INVITE request retransmit
interval, for UDP only
Timer B 64*T1 Section 17.1.1.2 INVITE transaction
timeout timer
Timer C > 3min Section 16.6 proxy INVITE transaction
bullet 11 timeout
Timer D > 32s for UDP Section 17.1.1.2 Wait time for response
0s for TCP/SCTP retransmits
Timer E initially T1 Section 17.1.2.2 non-INVITE request
retransmit interval,
UDP only
Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction
timeout timer
Timer G initially T1 Section 17.2.1 INVITE response
retransmit interval
Timer H 64*T1 Section 17.2.1 Wait time for
ACK receipt
Timer I T4 for UDP Section 17.2.1 Wait time for
0s for TCP/SCTP ACK retransmits
Timer J 64*T1 for UDP Section 17.2.2 Wait time for
0s for TCP/SCTP non-INVITE request
retransmits
Timer K T4 for UDP Section 17.1.2.2 Wait time for
0s for TCP/SCTP response retransmits