SIP参考大全

Description:

Protocol suite:	TCP/IP.
Protocol type:	Application layer protocol.
Multicast addresses:	224.0.1.75 (all servers).
Ports:	5060 (SCTP, TCP, UDP) server default. 5061 (TLS).
URI:	sip:, sips:.
MIMEsubtype:	application/dialog-info+xml application/poc-settings+xml application/simple-message-summary message/sip message/sipfrag.
SNMPMIBs:
Working groups:	bliss, Basic Level of Interoperability for SIP Services. enum, Telephone Number Mapping. mmusic, Multiparty Multimedia Session Control. simple, SIP for Instant Messaging and Presence Leveraging. sip, Session Initiation Protocol. sipcore, Session Initiation Protocol Core. sipping, Session Initiation Proposal Investigation.
Links:	Columbia University of Computer Science SIP page. IANA: SIP parameters.

SIP is a text based control protocol intended for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. The protocol can be compressed by using Signaling Compression.

SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.

SIP uses the ISO 10646 character set in UTF-8 encoding. Senders MUST terminate lines with a CRLF, but receivers MUST also interpret CR and LF by themselves as line terminators.

SIP can be used overIPv4orIPv6.

---

MAC header

IPheader

SCTP|TCP|UDPheader

SIP message

---

SIP methods:

Method References

ACK	RFC 3261
BYE	RFC 3261
CANCEL	RFC 3261
INFO	RFC 2976
INVITE	RFC 3261
MESSAGE	RFC 3428
NOTIFY	RFC 3265
OPTIONS	RFC 3261
PRACK	RFC 3262
PUBLISH	RFC 3903
REFER	RFC 3515
REGISTER	RFC 3261
SUBSCRIBE	RFC 3265
UPDATE	RFC 3311

---

Header fields:

Header field Abbreviation References

Accept		RFC 3261
Accept-Contact	a	RFC 3841
Accept-Encoding		RFC 3261
Accept-Language		RFC 3261
Accept-Resource-Priority		RFC 4412
Alert-Info		RFC 3261
Allow		RFC 3261
Allow-Events	u	RFC 3265
Answer-Mode		RFC 5373
Authentication-Info		RFC 3261
Authorization		RFC 3261
Call-ID	i	RFC 3261
Call-Info		RFC 3261
Contact	m	RFC 3261
Content-Disposition		RFC 3261
Content-Encoding	e	RFC 3261
Content-Language		RFC 3261
Content-Length	l	RFC 3261
Content-Type	c	RFC 3261
CSeq		RFC 3261
Date		RFC 3261
Encryption	(deprecated)	RFC 3261
Error-Info		RFC 3261
Event	o	RFC 3265
Expires		RFC 3261
Flow-Timer		RFC 5626
From	f	RFC 3261
Hide	(deprecated)	RFC 3261
History-Info		RFC 4244
Identity	y	RFC 4474
Identity-Info	n	RFC 4474
In-Reply-To		RFC 3261
Join		RFC 3911
Max-Forwards		RFC 3261
MIME-Version		RFC 3261
Min-Expires		RFC 3261
Min-SE		RFC 4028
Organization		RFC 3261
P-Access-Network-Info		RFC 3455
P-Answer-State		RFC 4964
P-Asserted-Identity		RFC 3325
P-Associated-URI		RFC 3455
P-Called-Party-ID		RFC 3455
P-Charging-Function-Addresses		RFC 3455
P-Charging-Vector		RFC 3455
P-DCS-Billing-Info		RFC 5503
P-DCS-LAES		RFC 5503
P-DCS-OSPS		RFC 5503
P-DCS-Redirect		RFC 5503
P-DCS-Trace-Party-ID		RFC 3603
P-Early-Media		RFC 5009
P-Media-Authorization		RFC 3313
P-Preferred-Identity		RFC 3325
P-Profile-Key		RFC 5002
P-Refused-URI-List		RFC 5318
P-Served-User		RFC 5502
P-User-Database		RFC 4457
P-Visited-Network-ID		RFC 3455
Path		RFC 3327
Permission-Missing		RFC 5360
Priority		RFC 3261
Priv-Answer-Mode		RFC 5373
Privacy		RFC 3323
Proxy-Authenticate		RFC 3261
Proxy-Authorization		RFC 3261
Proxy-Require		RFC 3261
RAck		RFC 3262
Reason		RFC 3326
Record-Route		RFC 3261
Refer-Sub		RFC 4488
Referred-By		RFC 3892
Replaces		RFC 3891
Resource-Priority		RFC 4412
Response-Key	(deprecated)	RFC 3261
Retry-After		RFC 3261
Route		RFC 3261
RSeq		RFC 3262
Security-Client		RFC 3329
SIP-If-Match		RFC 3903
Subject	s	RFC 3261
Subscription-State		RFC 3265
Supported	k	RFC 3261
Suppress-If-Match
Target-Dialog		RFC 4538
Timestamp		RFC 3261
To	t	RFC 3261
Trigger-Consent		RFC 5360
Unsupported		RFC 3261
User-Agent		RFC 3261
Via	v	RFC 3261
Warning		RFC 3261
WWW-Authenticate		RFC 3261

Accept.
If the Accept header field is not present, the server SHOULD assume a default MIME value of application/sdp. An empty Accept header field means that no formats are acceptable.

Accept-Contact, a.

Accept-Encoding.
This field is similar to Accept, but restricts the content-codings that are acceptable in the response. An empty Accept-Encoding header field is permissible. It is equivalent to Accept-Encoding: identity, that is, only the identity encoding, meaning no encoding, is permissible. If an Accept-Encoding header field is not present, the server SHOULD assume a default value of identity.

Accept-Language.
This field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-Language header field is present, the server SHOULD assume all languages are acceptable to the client.

Accept-Resource-Priority.
This field enumerates the resource values a SIP user agent server is willing to process.

Alert-Info.
When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS. When present in a 180 (Ringing) response, the Alert-Info header field specifies an alternative ringback tone to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature. The Alert-Info header field can introduce security risks. In addition, a user SHOULD be able to disable this feature selectively.

Allow.
This field lists the set of methods supported by the UA generating the message. All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. The absence of an Allow header field MUST NOT be interpreted to mean that the UA sending the message supports no methods. Rather, it implies that the UA is not providing any information on what methods it supports. Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of messages needed.

Allow-Events, u.

Authentication-Info.
This field provides for mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field.

Authorization.
Contains authentication credentials of a UA. This header field, along with Proxy-Authorization, breaks the general rules about multiple header field values. Although not a comma-separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line.

Call-ID, i.
Used to uniquely identify a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte.

Call-Info.
This field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard or LDIF formats. Additional tokens can be registered using IANA. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests.

Contact, m.
Provides a URI whose meaning depends on the type of request or response it is in. The field value can contain a display name, a URI with URI parameters, and header parameters.

Content-Disposition.
Describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS.

Content-Encoding, e.
Used as a modifier to the "media-type". When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms MUST be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a body to be compressed without losing the identity of its underlying media type. If multiple encodings have been applied to an entity-body, the content codings MUST be listed in the order in which they were applied. All content-coding values are case-insensitive. IANA acts as a registry for content-coding value tokens. Clients MAY apply content encodings to the body in requests. A server MAY apply content encodings to the bodies in responses. The server MUST only use encodings listed in the Accept-Encoding header field in the request.

Content-Language.

Content-Length, l.
Indicates the size of the message-body, in decimal number of bytes, sent to the recipient. Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as transport, the header field MUST be used. The size of the message-body does not include the CRLF separating header fields and body. Any Content-Length greater than or equal to zero is a valid value. If no body is present in a message, then the Content-Length header field value MUST be cleared to zero.

Content-Type, c.
Indicates the media type of the message-body sent to the recipient. This header field MUST be present if the body is not empty. If the body is empty, and a Content-Type header field is present, it indicates that the body of the specific type has zero length (for example, an empty audio file).

CSeq.
A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. This header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical.

Date.
Contains the date and time. Unlike HTTP/1.1, SIP only supports the most recent RFC 1123 format for dates. SIP restricts the time zone in SIP-date to "GMT", while RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. The Date header field reflects the time when the request or response is first sent. The Date header field can be used by simple end systems without a battery-backed clock to acquire a notion of current time. However, in its GMT form, it requires clients to know their offset from GMT.

Encryption. Deprecated.
This field specifies that the content has been encrypted. This header field is intended for end-to-end encryption of requests and responses. Requests are encrypted based on the public key belonging to the entity named in the To header field. Responses are encrypted based on the public key conveyed in the Response-Key header field. Note that the public keys themselves may not be used for the encryption. This depends on the particular algorithms used.

Error-Info.
Provides a pointer to additional information about the error status response.

Event, o.
For the purposes of matching responses and NOTIFY messages with SUBSCRIBE messages, the event-type portion of the "Event" header is compared byte-by-byte, and the "id" parameter token (if present) is compared byte-by-byte. An "Event" header containing an "id" parameter never matches an "Event" header without an "id" parameter. No other parameters are considered when performing a comparison. There MUST be exactly one event type listed per event header. Multiple events per message are not allowed.

Expires.
Gives the relative time after which the message (or content) expires. The precise meaning of this is method dependent. The expiration time in an INVITE does not affect the duration of the actual session that may result from the invitation. Session description protocols may offer the ability to express time limits on the session duration, however. The value of this field is an integral number of seconds (in decimal) between 0 and (2**32)-1, measured from the receipt of the request.

From, f.
Indicates the initiator of the request. This may be different from the initiator of the dialog. Requests sent by the callee to the caller use the callee's address in the From header field. The optional "display-name" is meant to be rendered by a human user interface. A system SHOULD use the display name "Anonymous" if the identity of the client is to remain hidden. Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon. From header fields are equivalent if their URIs match, and their parameters match. Extension parameters in one header field, not present in the other are ignored for the purposes of comparison. This means that the display name and presence or absence of angle brackets do not affect matching.

Hide. Deprecated.
A client uses the Hide request header field to indicate that it wants the path comprised of the Via header fields to be hidden from subsequent proxies and user agents. It can take two forms: Hide: route and Hide: hop. Hide header fields are typically added by the client user agent, but MAY be added by any proxy along the path.

History-Info.
Optional. The fundamental functionality provided by the request history information is the ability to inform proxies and UAs involved in processing a request about the history or progress of that request. The solution is to capture the Request-URIs as a request is forwarded in this header. This allows for the capturing of the history of a request that would be lost with the normal SIP processing involved in the subsequent forwarding of the request. This header can appear in any request not associated with an established dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) and any valid response to these requests. The use ofTLSas a mandatory mechanism to ensure the overall confidentiality of the History-Info headers is strongly RECOMMENDED.

Identity, y.

Identity-Info, n.

In-Reply-To.
Enumerates the Call-IDs that this call references or returns. These Call-IDs may have been cached by the client then included in this header field in a return call. This allows automatic call distribution systems to route return calls to the originator of the first call. This also allows callees to filter calls, so that only return calls for calls they originated will be accepted. This field is not a substitute for request authentication.

Join.
Used to logically join an existing SIP dialog with a new SIP dialog.

Max-Forwards.
This header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain. The Max-Forwards value is an integer in the range 0 to 255 indicating the remaining number of times this request message is allowed to be forwarded. This count is decremented by each server that forwards the request. The recommended initial value is 70. This field should be inserted by elements that can not otherwise guarantee loop detection.

MIME-Version.

Min-Expires.
Conveys the minimum refresh interval supported for soft-state elements managed by that server. This includes Contact header fields that are stored by a registrar. The header field contains a decimal integer number of seconds from 0 to (2**32) - 1.

Min-SE.
This field indicates the minimum value for the session interval in units of delta-seconds. When used in an INVITE or UPDATE request, it indicates the smallest value of the session interval that can be used for that session. When present in a request or response, the value MUST NOT be less than 90 seconds.

Organization.
Conveys the name of the organization to which the SIP element issuing the request or response belongs. This field MAY be used by client software to filter calls.

P-Access-Network-Info.
This header is useful in SIP based networks that also provide layer 2/layer 3 connectivity through different access technologies. SIP User Agents may use this header to relay information about the access technology to proxies that are providing services. The serving proxy may then use this information to optimize services for the UA.

P-Answer-State.

P-Asserted-Identity.
Used among trusted SIP entities, typically intermediaries, to carry the identity of the user sending a SIP message as it was verified by authentication.

P-Associated-URI.
This extension allows a registrar to return a set of associated URIs for a registered address-of-record.

P-Called-Party-ID.
A proxy server inserts this header, typically in anINVITErequest, en-route to its destination. The header is populated with the Request-URI received by the proxy in the request. The UAS identifies which address-of-record, out of several registered address-of-records, the invitation was sent to (for example, the user may be simultaneously using a personal and a business SIP URIs to receive invitation to sessions). The UAS may use the information to render different distinctive audiovisual alerting tones, depending on the URI used to receive the invitation to the session.

P-Charging-Function-Addresses.
A proxy MAY include this header, if not already present, in either the initial request or response for a dialog, or in the request and response of a standalone transaction outside a dialog. Only one instance of the header MUST be present in a particular request or response.

P-Charging-Vector.
This header is used to convey charging related information, such as the globally unique IMS charging identifier (ICID) value. A proxy MAY include this header, if not already present, in either the initial request or response for a dialog, or in the request and response of a standalone transaction outside a dialog. Only one instance of the header MUST be present in a particular request or response.

P-Early-Media.

P-Media-Authorization.

P-Preferred-Identity.
Used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wishes to be used for theP-Asserted-Headerfield value that the trusted element will insert.

P-Profile-Key.

P-Refused-URI-List.
(RFC 5318) This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list.

P-User-Database.

P-Visited-Network-ID.
This header field is used to convey to the registrar or home proxy in the home network the identifier of a visited network. The identifier is a text string or token that is known by both the registrar or the home proxy at the home network and the proxies in the visited network.

Path.
This is a SIP extension header field with syntax very similar to theRecord-Routeheader field. It is used in conjunction with SIPREGISTERrequests and with 200 class messages in response toREGISTER. APathheader field MAY be inserted into aREGISTERby any SIP node traversed by that request. Like theRouteheader field, sequentialPathheader fields are evaluated in the sequence in which they are present in the request, andPathheader fields MAY be combined into compoundPathheader in a singlePathheader field. The registrar reflects the accumulated Path back into theREGISTERresponse, and intermediate nodes propagate this back toward the originating UA. The originating UA is therefore informed of the inclusion of nodes on its registered Path, and MAY use that information in other capacities outside the scope of this document. The difference betweenPathandRecord-Routeis thatPathapplies toREGISTERand 200 class responses toREGISTER.Record-Routedoesn't, and can't be defined inREGISTERfor reasons of backward compatibility. Furthermore, the vector established byRecord-Routeapplies only to requests within the dialog that established that Record-Route, whereas the vector established byPathapplies to future dialogs.

Permission-Missing.

Priority.
Indicates the urgency of the request as perceived by the client. This field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. For these decisions, a message containing no Priority header field SHOULD be treated as if it specified a Priority of "normal". The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways. The header field can have the values "non-urgent", "normal", "urgent", and "emergency", but additional values can be defined elsewhere. It is RECOMMENDED that the value of "emergency" only be used when life, limb, or property are in imminent danger. Otherwise, there are no semantics defined for this header field.

Privacy.
Allows a user agent to request a certain degree of privacy for a message.

Proxy-Authenticate.
Contains an authentication challenge.

Proxy-Authorization.
Allows the client to identify itself (or its user) to a proxy that requires authentication. A Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. This header field, along with Authorization, breaks the general rules about multiple header field names. Although not a comma-separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line.

Proxy-Require.
Used to indicate proxy-sensitive features that must be supported by the proxy.

RAck.
The RAck header is sent in a PRACK request to support reliability of provisional responses. It contains two numbers and a method tag. The first number is the value from the RSeq header in the provisional response that is being acknowledged. The next number, and the method, are copied from the CSeq in the response that is being acknowledged. The method name in the RAck header is case sensitive.

Reason.
This field MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field.

Record-Route.
Inserted by proxies in a request to force future requests in the dialog to be routed through the proxy.

Referred-By, b.

Refer-Sub.

Refer-To, r.
This field only appears in a REFER request. It provides a URL to reference.

Reject-Contact, j.

Replaces.
Used to logically replace an existing SIP dialog with a new SIP dialog.

Reply-To.
Contains a logical return URI that may be different from the From header field. For example, the URI MAY be used to return missed calls or unestablished sessions. If the user wished to remain anonymous, the header field SHOULD either be omitted from the request or populated in such a way that does not reveal any private information. Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon.

Request-Disposition, d.
Specifies caller preferences for how a server should process a request.

Require.
Used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. Although an optional header field, the Require MUST NOT be ignored if it is present. The Require header field contains a list of option tags. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs.

Resource-Priority.
Defined inRFC 4412.

Response-Key.
Deprecated. This field can be used by a client to request the key that the called user agent SHOULD use to encrypt the response with.

Retry-After.
Can be used with a 500 (Server Internal Error) or 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client and with a 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 (Decline) response to indicate when the called party anticipates being available again. The value of this field is a positive integer number of seconds (in decimal) after the time of the response. An optional comment can be used to indicate additional information about the time of callback. An optional "duration" parameter indicates how long the called party will be reachable starting at the initial time of availability. If no duration parameter is given, the service is assumed to be available indefinitely.

Route.
Used to force routing for a request through the listed set of proxies.

RSeq.
Used in provisional responses in order to transmit them reliably. It contains a single numeric value from 1 to 2**32 - 1.

Security-Client.

Security-Server.

Security-Verify.

Server.
Contains information about the software used by the UAS to handle the request. Revealing the specific software version of the server might allow the server to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the Server header field a configurable option.

Service-Route.

Session-Expires, x.
This field defines the session interval for a SIP session. It is placed only in INVITE or UPDATE requests, as well as in any 2xx response to an INVITE or UPDATE.

SIP-ETag.

SIP-If-Match.

Subject, s.
Provides a summary or indicates the nature of the call, allowing call filtering without having to parse the session description. The session description does not have to use the same subject indication as the invitation.

Subscription-State.

Supported, k.
Enumerates all the extensions supported by the UAC or UAS. The Supported header field contains a list of option tags that are understood by the UAC or UAS. A UA compliant to this specification MUST only include option tags corresponding to standards-track RFCs. If empty, it means that no extensions are supported.

Target-Dialog.
This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness.

Timestamp.
Describes when the UAC sent the request to the UAS. Although there is no normative behavior defined here that makes use of the header, it allows for extensions or SIP applications to obtain RTT estimates.

To, t.
Specifies the logical recipient of the request. The optional "display-name" is meant to be rendered by a human-user interface. The "tag" parameter serves as a general mechanism for dialog identification.

Trigger-Consent.

Unsupported.
Lists the features not supported by the UAS.

User-Agent.
Contains information about the UAC originating the request. Revealing the specific software version of the user agent might allow the user agent to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the User-Agent header field a configurable option.

Via, v.
Indicates the path taken by the request so far and indicates the path that should be followed in routing responses.

Warning.
Used to carry additional information about the status of a response. Warning header field values are sent with responses and contain a three-digit warning code, host name, and warning text. The "warn-text" should be in a natural language that is most likely to be intelligible to the human user receiving the response. This decision can be based on any available knowledge, such as the location of the user, the Accept-Language field in a request, or the Content-Language field in a response. The default language is i-default.

WWW-Authenticate.
Contains an authentication challenge.

---

Option tags.
Option tags are used in header fields in support of SIP compatibility mechanisms for extensions. The option tag itself is a string that is associated with a particular SIP option. It identifies the option to SIP endpoints.

Option tag References

100rel.	RFC 3262
answermode	RFC 5373
early-session	RFC 3959
eventlist	RFC 4662
from-change	RFC 4916
gruu	RFC 5627
histinfo	RFC 4244
ice
join	RFC 3911
multiple-refer	RFC 5368
norefersub	RFC 4488
outbound	RFC 5626
path	RFC 3327
precondition	RFC 3312
pref.	RFC 3840
privacy	RFC 3323
recipient-list-invite	RFC 5366
recipient-list-message	RFC 5365
recipient-list-subscribe	RFC 5367
replaces	RFC 3891
resource-priority	RFC 4412
sdp-anat	RFC 4092
sec-agree	RFC 3329
tdialog	RFC 4538
timer	RFC 4028

100rel.
This option tag is used for reliability of provisional responses. When present in aSupportedheader, it indicates that the UA can send or receive reliable provisional responses. When present in aRequireheader in a request it indicates that the UAS MUST send all provisional responses reliably. When present in aRequireheader in a reliable provisional response, it indicates that the response is to be sent reliably.

answermode.
This option tag is for support of the Answer-Mode and Priv-Answer-Mode extensions used to negotiate automatic or manual answering of a request.

early-session.
A UA adding this tag to a message indicates that it understands the early-session content disposition.

eventlist.
Extension to allow subscriptions to lists of resources.

from-change.
Used to indicate that a UA supports changes to URIs in From and To header fields during a dialog.

gruu.
This option tag is used to identify the GRUU, Globally Routable User Agent URI extension. When used in a Supported header, it indicates that a User Agent understands the extension. When used in a Require header field of a REGISTER request, it indicates that the registrar is not expected to process the registration unless it supports the GRUU extension.

histinfo.
When used with the Supported header, this option tag indicates support for the History Information to be captured for requests and returned in subsequent responses. This tag is not used in a Proxy-Require or Require header field since support of History-Info is optional.

join.
Support for the SIP Join Header.

multiple-refer.
This option tag indicates support for REFER requests that contain a resource list document describing multiple REFER targets.

norefersub.
Specifies a User Agent ability of accepting a REFER request without establishing an implicit subscription.

outbound.
This option-tag is used to identify UAs and Registrars which support extensions for Client Initiated Connections. A UA places this option in a Supported header to communicate its support for this extension. A Registrar places this option-tag in a Require header to indicate to the registering User Agent that the Registrar used registrations using the binding rules defined in this extension.

path.
A SIP UA that supports thePathextension header field includes this option tag as a header field value in aSupportedheader field in all requests generated by that UA. Intermediate proxies may use the presence of this option tag in aREGISTERrequest to determine whether to offer Path service for for that request. If an intermediate proxy requires that the registrar support Path for a request, then it includes this option tag as a header field value in aRequiresheader field in that request.

precondition.
(RFC 3312) An offerer MUST include this tag in theRequireheader field if the offer contains one or more "mandatory" strength-tags. If all the strength-tags in the description are "optional" or "none" the offerer MUST include this tag either in aSupportedheader field or in aRequireheader field.

pref.
This tag is used to ensure that a server understands the callee capabilities parameters used in the request.

privacy.
This option tag indicates support for the Privacy mechanism. When used in theProxy-Requireheader, it indicates that proxy servers do not forward the request unless they can provide the requested privacy service. This tag is not used in the Required orSupportedheaders. Proxies remove this option tag before forwarding the request if the desired privacy function has been performed.

recipient-list-invite.
The body contains a list of URIs that indicates the recipients of the SIP INVITE request.

recipient-list-message.
The body contains a list of URIs that indicates the recipients of the SIP MESSAGE request.

recipient-list-subscribe.
This option tag is used to ensure that a server can process the recipient-list body used in a SUBSCRIBE request.

replaces.
This tag indicates support for the SIP Replaces header.

resource-priority.
Indicates or requests support for the resource priority mechanism.

sdp-anat.
This tag is defined for use in the Require and Supported SIP header fields. SIP user agents that place this option tag in a Supported header field understand the ANAT semantics.

sec-agree.
This option tag indicates support for the Security Agreement mechanism. When used in theRequireorProxy-Requireheaders, it indicates that proxy servers are required to use the Security Agreement mechanism. When used in theSupportedheader, it indicates that the User Agent Client supports the Security Agreement mechanism. When used in theRequireheader in the 494 (Security Agreement Required) or 421 (Extension Required) responses, it indicates that the User Agent Client must use the Security Agreement Mechanism.

tdialog.
Used to identify the target dialog header field extension. When used in a Require header field, it implies that the recipient needs to support the Target-Dialog header field. When used in a Supported header field, it implies that the sender of the message supports it.

timer.
This tag is for support of the session timer extension. Inclusion in a Supported header field in a request or response indicates that the UA is capable of performing refreshes according to that specification. Inclusion in a Require header in a request means that the UAS must understand the session timer extension to process the request. Inclusion in a Require header field in a response indicates that the UAC must look for the Session-Expires header field in the response, and process accordingly.

---

Response codes:

1xx: Provisional.
Request received, continuing to process the request.

Code Description References 100 101
-
179 180 181 182 183

Trying.	RFC 3261
Ringing.	RFC 3261
Call is being forwarded.	RFC 3261
Queued.	RFC 3261
Session progress.	RFC 3261

2xx: Success.
The action was successfully received, understood, and accepted.

Code Description References 200 201 202 204

OK.
Accepted.	RFC 3265
No Notification.

3xx: Redirection.
Further action needs to be taken in order to complete the request.

Code Description References 300 301 302 303 304 305 306
-
379 380

Multiple choices.	RFC 3261
Moved permanently.
Moved temporarily.
Use proxy.
Alternative service.

4xx: Client error.
The request contains bad syntax or cannot be fulfilled at this server.

Code Description References 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418
419 420 421 422 423 424
-
427 428 429 430
-
432 433 434
435 436 437 438 439
-
469 470 471
-
479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494

Bad request.
Unauthorized.
Payment required.
Forbidden.
Not found.
Method not allowed.
Not acceptable.
Proxy authentication required.
Request timeout.
Gone.
Conditional request failed.	RFC 3903
Request entity too large.
Request-URI too long.
Unsupported media type.
Unsupported URI scheme.
Unknown Resource-Priority.	RFC 4412
Bad extension.
Extension required.
Session Interval too small.	RFC 4028
Interval too brief.
Use Identity Header.	RFC 4474
Provide referrer identity.	RFC 3892
Anonymity Disallowed.	RFC 5079
Bad Identity-Info.	RFC 4474
Unsupported Certificate.	RFC 4474
Invalid Identity Header.	RFC 4474
Consent needed.	RFC 5360
Temporarily unavailable.
Call/Transaction does not exist.
Loop detected.
Too many hops.
Address incomplete.
Ambiguous.
Busy here.
Request terminated.
Not acceptable here.
Bad event.	RFC 3265
Request pending.
Undecipherable.
Security agreement required.	RFC 3329

5xx: Server error.
The server failed to fulfill an apparently valid request.

Code Description References 500 501 502 503 504 505 506
-
512 513 514
-
579 580

Server internal error.
Not implemented.
Bad gateway.
Service unavailable.	RFC 3261
Server timeout.
Version not supported.
Message too large.
Precondition Failure.	RFC 3312

6xx: Global failure.
The request cannot be fulfilled at any server.

Code Description 600 601
602 603 604 605 606

Busy everywhere.

Decline.

Does not exist anywhere.

Not acceptable.

---

Glossary:

AOR, Address-of-Record.
(RFC 3261) 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. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user.

B2BUA, Back-to-Back User Agent.
(RFC 3261) A logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.

Call.
(RFC 3261) An informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation.

Call Stateful.
(RFC 3261) A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true.

Client.
(RFC 3261) A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients.

Conference.
(RFC 3261) A multimedia session (see below) that contains multiple participants.

Core.
(RFC 3261) Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users.

Dialog.
(RFC 3261) A peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg.

Downstream.
(RFC 3261) A direction of message forwarding within a transaction that refers to the direction that requests flow from the user agent client to user agent server.

Event package.
(RFC 3265) An event package is an additional specification which defines a set of state information to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by this document required to convey such state information.

Event template-package.
(RFC 3265) An event template-package is a special kind of event package which defines a set of states which may be applied to all possible event packages, including itself.

Final response.
(RFC 3261) 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.

Header.
(RFC 3261) A component of a SIP message that conveys information about the message. It is structured as a sequence of header fields.

Header field.
(RFC 3261) A component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row.

Header field value.
A single value.

Home Domain.
(RFC 3261) The domain providing service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of a registration.

Informational Response.
(RFC 3261) Same as a provisional response.

Initiator, Calling Party, Caller.
(RFC 3261) The party initiating a session (and dialog) with an INVITE request. A caller retains this role from the time it sends the initial INVITE that established a dialog until the termination of that dialog.

Invitation.
(RFC 3261) An INVITE request.

Invitee, Invited User, Called Party, Callee.
(RFC 3261) The party that receives an INVITE request for the purpose of establishing a new session. A callee retains this role from the time it receives the INVITE until the termination of the dialog established by that INVITE.

Location Service.
(RFC 3261) A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings.

Loop.
(RFC 3261) A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors, and the procedures for detecting them and handling them are described by the protocol.

Loose routing.
(RFC 3261) A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.

Message.
(RFC 3261) Data sent between SIP elements as part of the protocol. SIP messages are either requests or responses.

Method.
(RFC 3261) The primary function that a request is meant to invoke on a server. The method is carried in the request message itself. Example methods are INVITE and BYE.

Notification.
(RFC 3265) Notification is the act of a notifier sending a NOTIFY message to a subscriber to inform the subscriber of the state of a resource.

Notifier.
(RFC 3265) A notifier is a user agent which generates NOTIFY requests for the purpose of notifying subscribers of the state of a resource. Notifiers typically also accept SUBSCRIBE requests to create subscriptions.

Outbound proxy.
(RFC 3261) A proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols.

Parallel search.
(RFC 3261) 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.

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

Proxy, Proxy server.
(RFC 3261) An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it.

Recursion.
(RFC 3261) A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response.

Redirect server.
(RFC 3261) A user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs.

Registrar.
(RFC 3261) A server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles.

Regular transaction.
(RFC 3261) Any transaction with a method other than INVITE, ACK, or CANCEL.

Request.
(RFC 3261) A SIP message sent from a client to a server, for the purpose of invoking a particular operation.

Response.
(RFC 3261) A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server.

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

Route set.
(RFC 3261) A collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured.

Security-Client.

Security-Server.

Security-Verify.

Server.
(RFC 3261) A network element that receives requests in order to service them and sends back responses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and registrars.

Sequential search.
(RFC 3261) A proxy server attempts each contact address in sequence, proceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final response always terminates a sequential search.

Session.
(RFC 3261) A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session. As defined, a callee can be invited several times, by different calls, to the same session. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field.

SigComp, Signaling Compression.
A technique for compressing SIP.

SIP transaction.
(RFC 3261) A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.

Spiral.
(RFC 3261) A SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls [e-mail]. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to [e-mail]. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition.

State agent.
(RFC 3265) A state agent is a notifier which publishes state information on behalf of a resource; in order to do so, it may need to gather such state information from multiple sources. State agents always have complete state information for the resource for which they are creating notifications.

Stateful proxy.
(RFC 3261) A logical entity that maintains the client and server transaction state machines defined by this specification during the processing of a request, also known as a transaction stateful proxy. A transaction stateful proxy is not the same as a call stateful proxy.

Stateless proxy.
(RFC 3261) A logical entity that does not maintain the client or server transaction state machines defined in this specification when it processes requests. A stateless proxy forwards every request it receives downstream and every response it receives upstream.

Strict routing.
(RFC 3261) A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in this specification, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers.

Subscriber.
(RFC 3265) A subscriber is a user agent which receives NOTIFY requests from notifiers; these NOTIFY requests contain information about the state of a resource in which the subscriber is interested. Subscribers typically also generate SUBSCRIBE requests and send them to notifiers to create subscriptions.

Subscription.
(RFC 3265) A subscription is a set of application state associated with a dialog. This application state includes a pointer to the associated dialog, the event package name, and possibly an identification token. Event packages will define additional subscription state information. By definition, subscriptions exist in both a subscriber and a notifier.

Subscription migration.
(RFC 3265) Subscription migration is the act of moving a subscription from one notifier to another notifier.

Target refresh request.
(RFC 3261) A target refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog.

TU, Transaction user.
(RFC 3261) The layer of protocol processing that resides above the transaction layer. Transaction users include the UAC core, UAS core, and proxy core.

Upstream.
(RFC 3261) A direction of message forwarding within a transaction that refers to the direction that responses flow from the user agent server back to the user agent client.

UA, User agent.
(RFC 3261) A logical entity that can act as both a user agent client and user agent server.

UAC, User agent client.
(RFC 3261) A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction.

UAC core.
(RFC 3261) The set of processing functions required of a UAC that reside above the transaction and transport layers.

UAS, User agent server.
(RFC 3261) A logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction.

UAS core.
(RFC 3261) The set of processing functions required at a UAS that resides above the transaction and transport layers.

URL-encoded.
(RFC 3261) A character string encoded according to RFC 2396, Section 2.4.

Watcher.
An entity that requests information about a resource using the SIP event framework. Watcher information is an XML document that MUST be well-formed and SHOULD be valid. These documents MUST be based on XML 1.0 and MUST be encoded using UTF-8.

---

RFCs:

[RFC 2848]The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services.

• Category: Standards Track.

[RFC 2976]The SIP INFO Method.

• Category: Standards Track.

[RFC 3027]Protocol Complications with the IP Network Address Translator.

• Category: Informational.

[RFC 3050]Common Gateway Interface for SIP.

• Category: Informational.

[RFC 3087]Control of Service Context using SIP Request-URI.

• Category: Informational.

[RFC 3261]SIP: Session Initiation Protocol.

• Category: Standards Track.
• Defines URI schemes sip: and sips:.
• Updated by:
  RFC 3853,RFC 4320,RFC 5621.
• Obsoletes:
  RFC 2543.

[RFC 3262]Reliability of Provisional Responses in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Obsoletes:
  RFC 2543.

[RFC 3263]Session Initiation Protocol (SIP): Locating SIP Servers.

• Category: Standards Track.
• Obsoletes:
  RFC 2543.

[RFC 3265]Session Initiation Protocol (SIP)-Specific Event Notification.

• Category: Standards Track.
• Defines SIP header fields Allow-Events, Event, Subscription-State.
• Defines SIP methods NOTIFY, SUBSCRIBE.
• Defines SIP response codes 202 (Accepted), 489 (Bad Event).
• Updated by:
  RFC 5367.
• Updates:
  RFC 2543.

[RFC 3311]The Session Initiation Protocol (SIP) UPDATE Method.

• Category: Standards Track.
• Defines SIP method UPDATE.

[RFC 3312]Integration of Resource Management and Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP Quality of Service preconditions.
• Updated by:
  RFC 4032.

[RFC 3313]Private Session Initiation Protocol (SIP) Extensions for Media Authorization.

• Category: Informational.
• Defines SIP header field P-Media-Authorization.

[RFC 3323]A Privacy Mechanism for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header Privacy and option tag privacy.

[RFC 3324]Short Term Requirements for Network Asserted Identity.

• Category: Informational.

[RFC 3325]Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks.

• Category: Informational.
• Defines SIP header fields P-Asserted-Identity and P-Preferred-Identity.

[RFC 3326]The Reason Header Field for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header field Reason.

[RFC 3327]Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts.

• Category: Standards Track.
• Defines the SIP header field Path and option tag path.

[RFC 3329]Security Mechanism Agreement for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header fields Security-Client, Security-Server, Security-Verify.

[RFC 3351]User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals.

• Category: Informational.

[RFC 3372]Session Initiation Protocol for Telephones (SIP-T): Context and Architectures.

• BCP: 63.

[RFC 3398]Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping.

• Category: Standards Track.

[RFC 3420]Internet Media Type message/sipfrag.

• Category: Standards Track.
• Defines MIME media subtype message/sipfrag.

[RFC 3427]Change Process for the Session Initiation Protocol (SIP).

• BCP: 67.
• Updated by:
  RFC 3968,RFC 3969.

[RFC 3428]Session Initiation Protocol (SIP) Extension for Instant Messaging.

• Category: Standards Track.
• Defines the SIP method MESSAGE.

[RFC 3455]Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP).

• Category: Informational.
• Defines SIP header fields P-Associated-URI, P-Called-Party-ID, P-Visited-Network-ID, P-Access-Network-Info, P-Charging-Function-Addresses, P-Charging-Vector.

[RFC 3485]The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp).

• Category: Standards Track.
• Defines the SIP/SDP specific static dictionary for SigComp.

[RFC 3486]Compressing the Session Initiation Protocol (SIP).

• Category: Standards Track.

[RFC 3487]Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 3515]The Session Initiation Protocol (SIP) Refer Method.

• Category: Standards Track.
• Defines SIP method REFER and header field Refer-To.

[RFC 3578]Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP).

• Category: Standards Track.

[RFC 3581]An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing.

• Category: Standards Track.
• Defines the SIP Via header field parameter rport.

[RFC 3603]Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture.

• Category: Informational.
• Defines SIP extension headers P-DCS-Trace-Party-ID, P-DCS-OSPS, P-DCS-Billing-Info, P-DCS-LAES, P-DCS-Redirect.

[RFC 3608]Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration.

• Category: Standards Track.
• Defines SIP extension header field Service-Route.

[RFC 3665]Session Initiation Protocol (SIP) Basic Call Flow Examples.

• BCP: 75.

[RFC 3666]Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows.

• BCP: 76.

[RFC 3680]A Session Initiation Protocol (SIP) Event Package for Registrations.

• Category: Standards Track.
• Defines MIME media subtype application/reginfo+xml.

[RFC 3702]Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 3725]Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP).

• BCP: 85.

[RFC 3764]enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record.

• Category: Standards Track.

[RFC 3840]Indicating User Agent Capabilities in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP option tag pref.

[RFC 3841]Caller Preferences for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP request header fields Accept-Contact, Reject-Contact, Request-Disposition.

[RFC 3842]A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines MIME media subtype application/simple-message-summary.

[RFC 3842]A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines MIME media subtype application/simple-message-summary.

[RFC 3853]S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP).

• Category: Standards Track
• Updates:
  RFC 3261.

[RFC 3856]A Presence Event Package for the Session Initiation Protocol (SIP).

• Category: Standards Track.

[RFC 3857]A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP).

• Category: Standards Track.

[RFC 3858]An Extensible Markup Language (XML) Based Format for Watcher Information.

• Category: Standards Track.
• Defines MIME media subtype application/watcherinfo+xml.

[RFC 3891]The Session Initiation Protocol (SIP) "Replaces" Header.

• Category: Standards Track.
• Defines SIP request header field Replaces.

[RFC 3892]The Session Initiation Protocol (SIP) Referred-By Mechanism.

• Category: Standards Track.
• Defines SIP request header field Referred-By.

[RFC 3893]Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format.

• Category: Standards Track.

[RFC 3903]Session Initiation Protocol (SIP) Extension for Event State Publication.

• Category: Standards Track.
• Defines SIP method PUBLISH.
• Defines SIP header fields SIP-ETag and SIP-If-Match.

[RFC 3911]The Session Initiation Protocol (SIP) "Join" Header.

• Category: Standards Track.
• Defines SIP header field Join.

[RFC 3959]The Early Session Disposition Type for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP option tag early-session.

[RFC 3960]Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 3968]The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP).

• BCP: 98.
• Updates:
  RFC 3427.

[RFC 3969]The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP).

• BCP: 99.
• Updates:
  RFC 3427.

[RFC 3976]Interworking SIP and Intelligent Network (IN) Applications.

• Category: Informational.

[RFC 4028]Session Timers in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header fields Min-SE and Session-Expires.

[RFC 4032]Update to the Session Initiation Protocol (SIP) Preconditions Framework.

• Category: Standards Track
• Updates:
  RFC 3312.

[RFC 4083]Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 4092]Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP option tag sdp-anat.

[RFC 4117]Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc).

• Category: Informational.

[RFC 4123]Session Initiation Protocol (SIP)-H.323 Interworking Requirements.

• Category: Informational.

[RFC 4168]The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP).

• Category: Standards Track.

[RFC 4189]Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 4235]An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines MIME media subtype application/dialog-info+xml.
• Defines XML namespace urn:ietf:params:xml:ns:dialog-info.
• Defines SIP Media Feature Tags sip.byeless and sip.rendering.

[RFC 4240]Basic Network Media Services with SIP.

• Category: Informational.

[RFC 4244]An Extension to the Session Initiation Protocol (SIP) for Request History Information.

• Category: Standards Track.
• Defines SIP header History-Info.

[RFC 4245]High-Level Requirements for Tightly Coupled SIP Conferencing.

• Category: Informational.

[RFC 4320]Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction.

• Category: Standards Track.
• Updates:
  RFC 3261.

[RFC 4321]Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction.

• Category: Informational.

[RFC 4353]A Framework for Conferencing with the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 4354]A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service.

• Category: Informational.
• Defines MIME media subtype application/poc-settings+xml.

[RFC 4508]Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method.

• Category: Standards Track.

[RFC 4579]Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents.

• BCP: 119.

[RFC 4411]Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events.

• Category: Standards Track.

[RFC 4412]Communications Resource Priority for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header fields Resource-Priority and Accept-Resource-Priority.
• Defines SIP option tag resource-priority.

[RFC 4453]Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 4457]The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header).

• Category: Informational.
• Defines SIP header field P-User-Database.

[RFC 4458]Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR).

• Category: Informational.

[RFC 4474]Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header fields Identity and Identity-Info.
• Defines SIP Response codes 428 (Use Identity Header), 436 (Bad Identity-Info), 437 (Unsupported Certificate), 438 (Invalid Identity Header).

[RFC 4475]Session Initiation Protocol (SIP) Torture Test Messages.

• Category: Informational.

[RFC 4479]A Data Model for Presence.

• Category: Standards Track.
• Defines URN sub-namespace urn:ietf:params:xml:ns:pidf:data-model.

[RFC 4483]A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages.

• Category: Standards Track.

[RFC 4484]Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 4485]Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 4488]Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription.

• Category: Standards Track.
• Defines SIP header field Refer-Sub.
• Defines SIP option tag norefersub.

[RFC 4497]Interworking between the Session Initiation Protocol (SIP) and QSIG.

• BCP: 117.

[RFC 4504]SIP Telephony Device Requirements and Configuration.

• Category: Informational.

[RFC 4538]Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header field Target-Dialog.
• Defines SIP option tag tdialog.

[RFC 5318]The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header).

• Category: Informational.
• Defines SIP header field P-Refused-URI-List.

[RFC 5359]Session Initiation Protocol Service Examples.

• BCP: 144.

[RFC 5360]A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header fields Permission-Missing, Trigger-Consent.
• Defines SIP response code 470 (Consent needed).

[RFC 5361]A Document Format for Requesting Consent.

• Category: Standards Track.

[RFC 5362]The Session Initiation Protocol (SIP) Pending Additions Event Package.

• Category: Standards Track.
• Defines MIME media subtype application/resource-lists-diff+xml.

[RFC 5363]Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services.

• Category: Standards Track.

[RFC 5364]Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists.

• Category: Standards Track.

[RFC 5365]Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP option tag recipient-list-message.

[RFC 5366]Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP option tag recipient-list-invite.

[RFC 5367]Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP option tag recipient-list-subscribe.
• Updates:
  RFC 3265.

[RFC 5368]Referring to Multiple Resources in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP option tag multiple-refer.

[RFC 5369]Framework for Transcoding with the Session Initiation Protocol (SIP).

• Category: Informational.

[RFC 5370]The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model.

• Category: Standards Track.

[RFC 5373]Requesting Answering Modes for the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Defines SIP header fields Answer-Mode, Priv-Answer-Mode.
• Defines SIP option tag answermode.

[RFC 5390]Requirements for Management of Overload in the Session Initiation Protocol.

• Category: Informational.
• Normative references:
  RFC 2119.

[RFC 5606]Implications of 'retransmission-allowed' for SIP Location Conveyance.

• Category: Informational.

[RFC 5621]Message Body Handling in the Session Initiation Protocol (SIP).

• Category: Standards Track.
• Updates:
  RFC 3204,RFC 3261,RFC 3459.

[RFC 5638]Simple SIP Usage Scenario for Applications in the Endpoints.

• Category: Informational.

Obsolete RFCs:

[RFC 2543] SIP: Session Initiation Protocol.

• Category: Standards Track.
• Defines the SIP protocol.
• Obsoleted by:
  RFC 3261,RFC 3262,RFC 3263,RFC 3264,RFC 3265.