SIP参考大全
2010-03-25 14:32
218 查看
Description
:
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 over IPv4
or IPv6
.
SIP methods:
Header fields:
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 of TLS
as 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 an INVITE
request, 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 the P-Asserted-Header
field 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 the Record-Route
header field.
It is used in conjunction with SIP REGISTER
requests and with 200
class messages in response to REGISTER
.
A Path
header field MAY be inserted into a REGISTER
by any
SIP node traversed by that request.
Like the Route
header field, sequential Path
header
fields are evaluated in the sequence in which they are present in the
request,
and Path
header fields MAY be combined into compound Path
header in a single Path
header field.
The registrar reflects the accumulated
Path back into the REGISTER
response, 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
between Path
and Record-Route
is that Path
applies to REGISTER
and 200
class responses to REGISTER
. Record-Route
doesn't, and
can't be
defined in REGISTER
for reasons of backward compatibility.
Furthermore,
the vector established by Record-Route
applies only to requests
within
the dialog that established that Record-Route, whereas the vector
established by Path
applies 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 in RFC
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.
100rel.
This option tag is used for reliability of provisional responses.
When present in a Supported
header, it indicates that the UA can
send or receive reliable provisional responses.
When present in a Require
header in a request it indicates that
the UAS MUST send all provisional responses reliably.
When present in a Require
header 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 the Path
extension header field includes
this
option tag as a header field value in a Supported
header field in
all requests generated by that UA.
Intermediate proxies may use the presence of this option
tag in a REGISTER
request 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 a Requires
header field in that request.
precondition.
(RFC 3312
)
An offerer MUST include this tag in the Require
header 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 a Supported
header
field or in a Require
header 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 the Proxy-Require
header, 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 or Supported
headers.
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 the Require
or Proxy-Require
headers, it
indicates that
proxy servers are required to use the Security Agreement mechanism.
When used in the Supported
header, it indicates that the User
Agent Client supports the Security Agreement mechanism.
When used in the Require
header 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.
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.
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
joe@example.com.
The example.com proxy forwards it to Joe's PC, which in turn, forwards
it to bob@example.com.
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
.
:
| 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:. |
| MIME subtype: | application/dialog-info+xml application/poc-settings+xml application/simple-message-summary message/sip message/sipfrag. |
| SNMP MIBs : | |
| 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 . |
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 over IPv4
or IPv6
.
| MAC header | IP header | SCTP | TCP | UDP header | SIP message |
| 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 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 |
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 of TLS
as 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 an INVITE
request, 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 the P-Asserted-Header
field 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 the Record-Route
header field.
It is used in conjunction with SIP REGISTER
requests and with 200
class messages in response to REGISTER
.
A Path
header field MAY be inserted into a REGISTER
by any
SIP node traversed by that request.
Like the Route
header field, sequential Path
header
fields are evaluated in the sequence in which they are present in the
request,
and Path
header fields MAY be combined into compound Path
header in a single Path
header field.
The registrar reflects the accumulated
Path back into the REGISTER
response, 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
between Path
and Record-Route
is that Path
applies to REGISTER
and 200
class responses to REGISTER
. Record-Route
doesn't, and
can't be
defined in REGISTER
for reasons of backward compatibility.
Furthermore,
the vector established by Record-Route
applies only to requests
within
the dialog that established that Record-Route, whereas the vector
established by Path
applies 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 in RFC
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 |
This option tag is used for reliability of provisional responses.
When present in a Supported
header, it indicates that the UA can
send or receive reliable provisional responses.
When present in a Require
header in a request it indicates that
the UAS MUST send all provisional responses reliably.
When present in a Require
header 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 the Path
extension header field includes
this
option tag as a header field value in a Supported
header field in
all requests generated by that UA.
Intermediate proxies may use the presence of this option
tag in a REGISTER
request 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 a Requires
header field in that request.
precondition.
(RFC 3312
)
An offerer MUST include this tag in the Require
header 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 a Supported
header
field or in a Require
header 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 the Proxy-Require
header, 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 or Supported
headers.
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 the Require
or Proxy-Require
headers, it
indicates that
proxy servers are required to use the Security Agreement mechanism.
When used in the Supported
header, it indicates that the User
Agent Client supports the Security Agreement mechanism.
When used in the Require
header 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 | Trying. | RFC 3261 |
| 101 - 179 | ||
| 180 | Ringing. | RFC 3261 |
| 181 | Call is being forwarded. | RFC 3261 |
| 182 | Queued. | RFC 3261 |
| 183 | Session progress. | RFC 3261 |
The action was successfully received, understood, and accepted.
| Code | Description | References |
|---|---|---|
| 200 | OK. | |
| 201 | ||
| 202 | Accepted. | RFC 3265 |
| 204 | No Notification. |
Further action needs to be taken in order to complete the request.
| Code | Description | References |
|---|---|---|
| 300 | Multiple choices. | RFC 3261 |
| 301 | Moved permanently. | |
| 302 | Moved temporarily. | |
| 303 | ||
| 304 | ||
| 305 | Use proxy. | |
| 306 - 379 | ||
| 380 | Alternative service. |
The request contains bad syntax or cannot be fulfilled at this server.
| Code | Description | References |
|---|---|---|
| 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. | |
| 409 | ||
| 410 | Gone. | |
| 411 | ||
| 412 | Conditional request failed. | RFC 3903 |
| 413 | Request entity too large. | |
| 414 | Request-URI too long. | |
| 415 | Unsupported media type. | |
| 416 | Unsupported URI scheme. | |
| 417 | Unknown Resource-Priority. | RFC 4412 |
| 418 419 | ||
| 420 | Bad extension. | |
| 421 | Extension required. | |
| 422 | Session Interval too small. | RFC 4028 |
| 423 | Interval too brief. | |
| 424 - 427 | ||
| 428 | Use Identity Header. | RFC 4474 |
| 429 | Provide referrer identity. | RFC 3892 |
| 430 - 432 | ||
| 433 | Anonymity Disallowed. | RFC 5079 |
| 434 435 | ||
| 436 | Bad Identity-Info. | RFC 4474 |
| 437 | Unsupported Certificate. | RFC 4474 |
| 438 | Invalid Identity Header. | RFC 4474 |
| 439 - 469 | ||
| 470 | Consent needed. | RFC 5360 |
| 471 - 479 | ||
| 480 | Temporarily unavailable. | |
| 481 | Call/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. | |
| 489 | Bad event. | RFC 3265 |
| 490 | ||
| 491 | Request pending. | |
| 492 | ||
| 493 | Undecipherable. | |
| 494 | Security agreement required. | RFC 3329 |
The server failed to fulfill an apparently valid request.
| Code | Description | References |
|---|---|---|
| 500 | Server internal error. | |
| 501 | Not implemented. | |
| 502 | Bad gateway. | |
| 503 | Service unavailable. | RFC 3261 |
| 504 | Server timeout. | |
| 505 | Version not supported. | |
| 506 - 512 | ||
| 513 | Message too large. | |
| 514 - 579 | ||
| 580 | Precondition Failure. | RFC 3312 |
The request cannot be fulfilled at any server.
| Code | Description |
|---|---|
| 600 | Busy everywhere. |
| 601 602 | |
| 603 | Decline. |
| 604 | Does not exist anywhere. |
| 605 | |
| 606 | Not acceptable. |
:
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
joe@example.com.
The example.com proxy forwards it to Joe's PC, which in turn, forwards
it to bob@example.com.
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
.
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- sip参考大全
- SIP参考大全
- SIP参考大全
- 基础html代码大全参考
- JNI语法 JNI参考 JNI函数大全
- c# 笔试题及参考答案大全
- Java技术体系大全，准备面试的可以参考一下！
- 网站开发技巧参考大全
- 网站开发技巧参考大全
- [网页设计制作]javascript技巧参考大全
- 网站开发技巧参考大全<转>
- 网站开发技巧参考大全
- javascript属性方法参考大全
- c# 笔试题及参考答案大全
- JavaScript对象与数组参考大全
- IP协议号大全---备份参考
- JavaScript 对象与数组参考大全
- JavaScript对象与数组参考大全
- JavaScript 对象与数组参考大全
- HTML标记大全参考手册