A user agent represents an end system. It contains a user agent
client (UAC), which generates requests, and a user agent server
(UAS), which responds to them. A UAC is capable of generating a
request based on some external stimulus (the user clicking a button,
or a signal on a PSTN line) and processing a response. A UAS is
capable of receiving a request and generating a response based on
user input, external stimulus, the result of a program execution, or
some other mechanism.
When a UAC sends a request, the request passes through some number of
proxy servers, which forward the request towards the UAS. When the
UAS generates a response, the response is forwarded towards the UAC.
UAC and UAS procedures depend strongly on two factors. First, based
on whether the request or response is inside or outside of a dialog,
and second, based on the method of a request. Dialogs are discussed
thoroughly in Section 12; they represent a peer-to-peer relationship
between user agents and are established by specific SIP methods, such
as INVITE.
In this section, we discuss the method-independent rules for UAC and
UAS behavior when processing requests that are outside of a dialog.
This includes, of course, the requests which themselves establish a
dialog.
Security procedures for requests and responses outside of a dialog
are described in Section 26. Specifically, mechanisms exist for the
UAS and UAC to mutually authenticate. A limited set of privacy
features are also supported through encryption of bodies using
S/MIME.
This section covers UAC behavior outside of a dialog.
8.1.1. Generating the Request
A valid SIP request formulated by a UAC MUST, at a minimum, contain
the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
and Via; all of these header fields are mandatory in all SIP
requests. These six header fields are the fundamental building
blocks of a SIP message, as they jointly provide for most of the
critical message routing services including the addressing of
messages, the routing of responses, limiting message propagation,
ordering of messages, and the unique identification of transactions.
These header fields are in addition to the mandatory request line,
which contains the method, Request-URI, and SIP version.
Examples of requests sent outside of a dialog include an INVITE to
establish a session (Section 13) and an OPTIONS to query for
capabilities (Section 11).
The initial Request-URI of the message SHOULD be set to the value of
the URI in the To field. One notable exception is the REGISTER
method; behavior for setting the Request-URI of REGISTER is given in
Section 10. It may also be undesirable for privacy reasons or
convenience to set these fields to the same value (especially if the
originating UA expects that the Request-URI will be changed during
transit).
In some special circumstances, the presence of a pre-existing route
set can affect the Request-URI of the message. A pre-existing route
set is an ordered set of URIs that identify a chain of servers, to
which a UAC will send outgoing requests that are outside of a dialog.
Commonly, they are configured on the UA by a user or service provider
manually, or through some other non-SIP mechanism. When a provider
wishes to configure a UA with an outbound proxy, it is RECOMMENDED
that this be done by providing it with a pre-existing route set with
a single URI, that of the outbound proxy.
When a pre-existing route set is present, the procedures for
populating the Request-URI and Route header field detailed in Section
12.2.1.1 MUST be followed (even though there is no dialog), using the
desired Request-URI as the remote target URI.
8.1.1.2. To
The To header field first and foremost specifies the desired
"logical" recipient of the request, or the address-of-record of the
user or resource that is the target of this request. This may or may
not be the ultimate recipient of the request. The To header field
MAY contain a SIP or SIPS URI, but it may also make use of other URI
schemes (the tel URL (RFC 2806(-> 3966prop) [9]), for example) when appropriate.
All SIP implementations MUST support the SIP URI scheme. Any
implementation that supports TLS MUST support the SIPS URI scheme.
The To header field allows for a display name.
A UAC may learn how to populate the To header field for a particular
request in a number of ways. Usually the user will suggest the To
header field through a human interface, perhaps inputting the URI
manually or selecting it from some sort of address book. Frequently,
the user will not enter a complete URI, but rather a string of digits
or letters (for example, "bob"). It is at the discretion of the UA
to choose how to interpret this input. Using the string to form the
user part of a SIP URI implies that the UA wishes the name to be
resolved in the domain to the right-hand side (RHS) of the at-sign in
the SIP URI (for instance, sip:bob@example.com). Using the string to
form the user part of a SIPS URI implies that the UA wishes to
communicate securely, and that the name is to be resolved in the
domain to the RHS of the at-sign. The RHS will frequently be the
home domain of the requestor, which allows for the home domain to
process the outgoing request. This is useful for features like
"speed dial" that require interpretation of the user part in the home
domain. The tel URL may be used when the UA does not wish to specify
the domain that should interpret a telephone number that has been
input by the user. Rather, each domain through which the request
passes would be given that opportunity. As an example, a user in an
airport might log in and send requests through an outbound proxy in
the airport. If they enter "411" (this is the phone number for local
directory assistance in the United States), that needs to be
interpreted and processed by the outbound proxy in the airport, not
the user's home domain. In this case, tel:411 would be the right
choice.
A request outside of a dialog MUST NOT contain a To tag; the tag in
the To field of a request identifies the peer of the dialog. Since
no dialog is established, no tag is present.
For further information on the To header field, see Section 20.39.
The following is an example of a valid To header field:
To: Carol <sip:carol@chicago.com>
8.1.1.3. From
The From header field indicates the logical identity of the initiator
of the request, possibly the user's address-of-record. Like the To
header field, it contains a URI and optionally a display name. It is
used by SIP elements to determine which processing rules to apply to
a request (for example, automatic call rejection). As such, it is
very important that the From URI not contain IP addresses or the FQDN
of the host on which the UA is running, since these are not logical
names.
The From header field allows for a display name. A UAC SHOULD use
the display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
identity of the client is to remain hidden.
Usually, the value that populates the From header field in requests
generated by a particular UA is pre-provisioned by the user or by the
administrators of the user's local domain. If a particular UA is
used by multiple users, it might have switchable profiles that
include a URI corresponding to the identity of the profiled user.
Recipients of requests can authenticate the originator of a request
in order to ascertain that they are who their From header field
claims they are (see Section 22 for more on authentication).
The From field MUST contain a new "tag" parameter, chosen by the UAC.
See Section 19.3 for details on choosing a tag.
For further information on the From header field, see Section 20.20.
Examples:
From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
From: sip:+12125551212@phone2net.com;tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
The Call-ID header field acts as a unique identifier to group
together a series of messages. It MUST be the same for all requests
and responses sent by either UA in a dialog. It SHOULD be the same
in each registration from a UA.
In a new request created by a UAC outside of any dialog, the Call-ID
header field MUST be selected by the UAC as a globally unique
identifier over space and time unless overridden by method-specific
behavior. All SIP UAs must have a means to guarantee that the Call-
ID header fields they produce will not be inadvertently generated by
any other UA. Note that when requests are retried after certain
failure responses that solicit an amendment to a request (for
example, a challenge for authentication), these retried requests are
not considered new requests, and therefore do not need new Call-ID
header fields; see Section 8.1.3.5.
Use of cryptographically random identifiers (RFC 1750(-> 4086) [12]) in the
generation of Call-IDs is RECOMMENDED. Implementations MAY use the
form "localid@host". Call-IDs are case-sensitive and are simply
compared byte-by-byte.
Using cryptographically random identifiers provides some
protection against session hijacking and reduces the likelihood of
unintentional Call-ID collisions.
No provisioning or human interface is required for the selection of
the Call-ID header field value for a request.
For further information on the Call-ID header field, see Section
20.8.
Example:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
8.1.1.5. CSeq
The CSeq header field serves as a way to identify and order
transactions. It consists of a sequence number and a method. The
method MUST match that of the request. For non-REGISTER requests
outside of a dialog, the sequence number value is arbitrary. The
sequence number value MUST be expressible as a 32-bit unsigned
integer and MUST be less than 2**31. As long as it follows the above
guidelines, a client may use any mechanism it would like to select
CSeq header field values.
Section 12.2.1.1 discusses construction of the CSeq for requests
within a dialog.
Example:
CSeq: 4711 INVITE
8.1.1.6. Max-Forwards
The Max-Forwards header field serves to limit the number of hops a
request can transit on the way to its destination. It consists of an
integer that is decremented by one at each hop. If the Max-Forwards
value reaches 0 before the request reaches its destination, it will
be rejected with a 483(Too Many Hops) error response.
A UAC MUST insert a Max-Forwards header field into each request it
originates with a value that SHOULD be 70. This number was chosen to
be sufficiently large to guarantee that a request would not be
dropped in any SIP network when there were no loops, but not so large
as to consume proxy resources when a loop does occur. Lower values
should be used with caution and only in networks where topologies are
known by the UA.
8.1.1.7. Via
The Via header field indicates the transport used for the transaction
and identifies the location where the response is to be sent. A Via
header field value is added only after the transport that will be
used to reach the next hop has been selected (which may involve the
usage of the procedures in [4]).
When the UAC creates a request, it MUST insert a Via into that
request. The protocol name and protocol version in the header field
MUST be SIP and 2.0, respectively. The Via header field value MUST
contain a branch parameter. This parameter is used to identify the
transaction created by that request. This parameter is used by both
the client and the server.
The branch parameter value MUST be unique across space and time for
all requests sent by the UA. The exceptions to this rule are CANCEL
and ACK for non-2xx responses. As discussed below, a CANCEL request
will have the same value of the branch parameter as the request it
cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx
response will also have the same branch ID as the INVITE whose
response it acknowledges.
The uniqueness property of the branch ID parameter, to facilitate
its use as a transaction ID, was not part of RFC 2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop).
The branch ID inserted by an element compliant with this
specification MUST always begin with the characters "z9hG4bK". These
7 characters are used as a magic cookie (7 is deemed sufficient to
ensure that an older RFC 2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop) implementation would not pick such a
value), so that servers receiving the request can determine that the
branch ID was constructed in the fashion described by this
specification (that is, globally unique). Beyond this requirement,
the precise format of the branch token is implementation-defined.
The Via header maddr, ttl, and sent-by components will be set when
the request is processed by the transport layer (Section 18).
Via processing for proxies is described in Section 16.6 Item 8 and
Section 16.7 Item 3.
8.1.1.8. Contact
The Contact header field provides a SIP or SIPS URI that can be used
to contact that specific instance of the UA for subsequent requests.
The Contact header field MUST be present and contain exactly one SIP
or SIPS URI in any request that can result in the establishment of a
dialog. For the methods defined in this specification, that includes
only the INVITE request. For these requests, the scope of the
Contact is global. That is, the Contact header field value contains
the URI at which the UA would like to receive requests, and this URI
MUST be valid even if used in subsequent requests outside of any
dialogs.
If the Request-URI or top Route header field value contains a SIPS
URI, the Contact header field MUST contain a SIPS URI as well.
For further information on the Contact header field, see Section
20.10.
8.1.1.9. Supported and Require
If the UAC supports extensions to SIP that can be applied by the
server to the response, the UAC SHOULD include a Supported header
field in the request listing the option tags (Section 19.2) for those
extensions.
The option tags listed MUST only refer to extensions defined in
standards-track RFCs. This is to prevent servers from insisting that
clients implement non-standard, vendor-defined features in order to
receive service. Extensions defined by experimental and
informational RFCs are explicitly excluded from usage with the
Supported header field in a request, since they too are often used to
document vendor-defined extensions.
If the UAC wishes to insist that a UAS understand an extension that
the UAC will apply to the request in order to process the request, it
MUST insert a Require header field into the request listing the
option tag for that extension. If the UAC wishes to apply an
extension to the request and insist that any proxies that are
traversed understand that extension, it MUST insert a Proxy-Require
header field into the request listing the option tag for that
extension.
As with the Supported header field, the option tags in the Require
and Proxy-Require header fields MUST only refer to extensions defined
in standards-track RFCs.
After a new request has been created, and the header fields described
above have been properly constructed, any additional optional header
fields are added, as are any header fields specific to the method.
SIP requests MAY contain a MIME-encoded message-body. Regardless of
the type of body that a request contains, certain header fields must
be formulated to characterize the contents of the body. For further
information on these header fields, see Sections 20.11 through 20.15.
8.1.2. Sending the Request
The destination for the request is then computed. Unless there is
local policy specifying otherwise, the destination MUST be determined
by applying the DNS procedures described in [4] as follows. If the
first element in the route set indicated a strict router (resulting
in forming the request as described in Section 12.2.1.1), the
procedures MUST be applied to the Request-URI of the request.
Otherwise, the procedures are applied to the first Route header field
value in the request (if one exists), or to the request's Request-URI
if there is no Route header field present. These procedures yield an
ordered set of address, port, and transports to attempt. Independent
of which URI is used as input to the procedures of [4], if the
Request-URI specifies a SIPS resource, the UAC MUST follow the
procedures of [4] as if the input URI were a SIPS URI.
Local policy MAY specify an alternate set of destinations to attempt.
If the Request-URI contains a SIPS URI, any alternate destinations
MUST be contacted with TLS. Beyond that, there are no restrictions
on the alternate destinations if the request contains no Route header
field. This provides a simple alternative to a pre-existing route
set as a way to specify an outbound proxy. However, that approach
for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing
route set with a single URI SHOULD be used instead. If the request
contains a Route header field, the request SHOULD be sent to the
locations derived from its topmost value, but MAY be sent to any
server that the UA is certain will honor the Route and Request-URI
policies specified in this document (as opposed to those in RFC
2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop)). In particular, a UAC configured with an outbound proxy SHOULD
attempt to send the request to the location indicated in the first
Route header field value instead of adopting the policy of sending
all messages to the outbound proxy.
This ensures that outbound proxies that do not add Record-Route
header field values will drop out of the path of subsequent
requests. It allows endpoints that cannot resolve the first Route
URI to delegate that task to an outbound proxy.
The UAC SHOULD follow the procedures defined in [4] for stateful
elements, trying each address until a server is contacted. Each try
constitutes a new transaction, and therefore each carries a different
topmost Via header field value with a new branch parameter.
Furthermore, the transport value in the Via header field is set to
whatever transport was determined for the target server.
8.1.3. Processing Responses
Responses are first processed by the transport layer and then passed
up to the transaction layer. The transaction layer performs its
processing and then passes the response up to the TU. The majority
of response processing in the TU is method specific. However, there
are some general behaviors independent of the method.
In some cases, the response returned by the transaction layer will
not be a SIP message, but rather a transaction layer error. When a
timeout error is received from the transaction layer, it MUST be
treated as if a 408 (Request Timeout) status code has been received.
If a fatal transport error is reported by the transport layer
(generally, due to fatal ICMP errors in UDP or connection failures in
TCP), the condition MUST be treated as a 503 (Service Unavailable)
status code.
8.1.3.2. Unrecognized Responses
A UAC MUST treat any final response it does not recognize as being
equivalent to the x00 response code of that class, and MUST be able
to process the x00 response code for all classes. For example, if a
UAC receives an unrecognized response code of 431, it can safely
assume that there was something wrong with its request and treat the
response as if it had received a 400 (Bad Request) response code. A
UAC MUST treat any provisional response different than 100 that it
does not recognize as 183 (Session Progress). A UAC MUST be able to
process 100 and 183 responses.
8.1.3.3. Vias
If more than one Via header field value is present in a response, the
UAC SHOULD discard the message.
The presence of additional Via header field values that precede
the originator of the request suggests that the message was
misrouted or possibly corrupted.
8.1.3.4. Processing 3xx Responses
Upon receipt of a redirection response (for example, a 301 response
status code), clients SHOULD use the URI(s) in the Contact header
field to formulate one or more new requests based on the redirected
request. This process is similar to that of a proxy recursing on a
3xx class response as detailed in Sections 16.5 and 16.6. A client
starts with an initial target set containing exactly one URI, the
Request-URI of the original request. If a client wishes to formulate
new requests based on a 3xx class response to that request, it places
the URIs to try into the target set. Subject to the restrictions in
this specification, a client can choose which Contact URIs it places
into the target set. As with proxy recursion, a client processing
3xx class responses MUST NOT add any given URI to the target set more
than once. If the original request had a SIPS URI in the Request-
URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD
inform the user of the redirection to an insecure URI.
Any new request may receive 3xx responses themselves containing
the original URI as a contact. Two locations can be configured to
redirect to each other. Placing any given URI in the target set
only once prevents infinite redirection loops.
As the target set grows, the client MAY generate new requests to the
URIs in any order. A common mechanism is to order the set by the "q"
parameter value from the Contact header field value. Requests to the
URIs MAY be generated serially or in parallel. One approach is to
process groups of decreasing q-values serially and process the URIs
in each q-value group in parallel. Another is to perform only serial
processing in decreasing q-value order, arbitrarily choosing between
contacts of equal q-value.
If contacting an address in the list results in a failure, as defined
in the next paragraph, the element moves to the next address in the
list, until the list is exhausted. If the list is exhausted, then
the request has failed.
Failures SHOULD be detected through failure response codes (codes
greater than 399); for network errors the client transaction will
report any transport layer failures to the transaction user. Note
that some response codes (detailed in 8.1.3.5) indicate that the
request can be retried; requests that are reattempted should not be
considered failures.
When a failure for a particular contact address is received, the
client SHOULD try the next contact address. This will involve
creating a new client transaction to deliver a new request.
In order to create a request based on a contact address in a 3xx
response, a UAC MUST copy the entire URI from the target set into the
Request-URI, except for the "method-param" and "header" URI
parameters (see Section 19.1.1 for a definition of these parameters).
It uses the "header" parameters to create header field values for the
new request, overwriting header field values associated with the
redirected request in accordance with the guidelines in Section
19.1.5.
Note that in some instances, header fields that have been
communicated in the contact address may instead append to existing
request header fields in the original redirected request. As a
general rule, if the header field can accept a comma-separated list
of values, then the new header field value MAY be appended to any
existing values in the original redirected request. If the header
field does not accept multiple values, the value in the original
redirected request MAY be overwritten by the header field value
communicated in the contact address. For example, if a contact
address is returned with the following value:
sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>
Then any Subject header field in the original redirected request is
overwritten, but the HTTP URL is merely appended to any existing
Call-Info header field values.
It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID
used in the original redirected request, but the UAC MAY also choose
to update the Call-ID header field value for new requests, for
example.
Finally, once the new request has been constructed, it is sent using
a new client transaction, and therefore MUST have a new branch ID in
the top Via field as discussed in Section 8.1.1.7.
In all other respects, requests sent upon receipt of a redirect
response SHOULD re-use the header fields and bodies of the original
request.
In some instances, Contact header field values may be cached at UAC
temporarily or permanently depending on the status code received and
the presence of an expiration interval; see Sections 21.3.2 and
21.3.3.
8.1.3.5. Processing 4xx Responses
Certain 4xx response codes require specific UA processing,
independent of the method.
If a 401 (Unauthorized) or 407 (Proxy Authentication Required)
response is received, the UAC SHOULD follow the authorization
procedures of Section 22.2 and Section 22.3 to retry the request with
credentials.
If a 413 (Request Entity Too Large) response is received (Section
21.4.11), the request contained a body that was longer than the UAS
was willing to accept. If possible, the UAC SHOULD retry the
request, either omitting the body or using one of a smaller length.
If a 415 (Unsupported Media Type) response is received (Section
21.4.13), the request contained media types not supported by the UAS.
The UAC SHOULD retry sending the request, this time only using
content with types listed in the Accept header field in the response,
with encodings listed in the Accept-Encoding header field in the
response, and with languages listed in the Accept-Language in the
response.
If a 416 (Unsupported URI Scheme) response is received (Section
21.4.14), the Request-URI used a URI scheme not supported by the
server. The client SHOULD retry the request, this time, using a SIP
URI.
If a 420 (Bad Extension) response is received (Section 21.4.15), the
request contained a Require or Proxy-Require header field listing an
option-tag for a feature not supported by a proxy or UAS. The UAC
SHOULD retry the request, this time omitting any extensions listed in
the Unsupported header field in the response.
In all of the above cases, the request is retried by creating a new
request with the appropriate modifications. This new request
constitutes a new transaction and SHOULD have the same value of the
Call-ID, To, and From of the previous request, but the CSeq should
contain a new sequence number that is one higher than the previous.
With other 4xx responses, including those yet to be defined, a retry
may or may not be possible depending on the method and the use case.
When a request outside of a dialog is processed by a UAS, there is a
set of processing rules that are followed, independent of the method.
Section 12 gives guidance on how a UAS can tell whether a request is
inside or outside of a dialog.
Note that request processing is atomic. If a request is accepted,
all state changes associated with it MUST be performed. If it is
rejected, all state changes MUST NOT be performed.
UASs SHOULD process the requests in the order of the steps that
follow in this section (that is, starting with authentication, then
inspecting the method, the header fields, and so on throughout the
remainder of this section).
8.2.1. Method Inspection
Once a request is authenticated (or authentication is skipped), the
UAS MUST inspect the method of the request. If the UAS recognizes
but does not support the method of a request, it MUST generate a 405
(Method Not Allowed) response. Procedures for generating responses
are described in Section 8.2.6. The UAS MUST also add an Allow
header field to the 405 (Method Not Allowed) response. The Allow
header field MUST list the set of methods supported by the UAS
generating the message. The Allow header field is presented in
Section 20.5.
If the method is one supported by the server, processing continues.
8.2.2. Header Inspection
If a UAS does not understand a header field in a request (that is,
the header field is not defined in this specification or in any
supported extension), the server MUST ignore that header field and
continue processing the message. A UAS SHOULD ignore any malformed
header fields that are not necessary for processing requests.
The To header field identifies the original recipient of the request
designated by the user identified in the From field. The original
recipient may or may not be the UAS processing the request, due to
call forwarding or other proxy operations. A UAS MAY apply any
policy it wishes to determine whether to accept requests when the To
header field is not the identity of the UAS. However, it is
RECOMMENDED that a UAS accept requests even if they do not recognize
the URI scheme (for example, a tel: URI) in the To header field, or
if the To header field does not address a known or current user of
this UAS. If, on the other hand, the UAS decides to reject the
request, it SHOULD generate a response with a 403 (Forbidden) status
code and pass it to the server transaction for transmission.
However, the Request-URI identifies the UAS that is to process the
request. If the Request-URI uses a scheme not supported by the UAS,
it SHOULD reject the request with a 416 (Unsupported URI Scheme)
response. If the Request-URI does not identify an address that the
UAS is willing to accept requests for, it SHOULD reject the request
with a 404 (Not Found) response. Typically, a UA that uses the
REGISTER method to bind its address-of-record to a specific contact
address will see requests whose Request-URI equals that contact
address. Other potential sources of received Request-URIs include
the Contact header fields of requests and responses sent by the UA
that establish or refresh dialogs.
8.2.2.2. Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
8.2.2.3. Require
Assuming the UAS decides that it is the proper element to process the
request, it examines the Require header field, if present.
The Require header field is used by a UAC to tell a UAS about SIP
extensions that the UAC expects the UAS to support in order to
process the request properly. Its format is described in Section
20.32. If a UAS does not understand an option-tag listed in a
Require header field, it MUST respond by generating a response with
status code 420 (Bad Extension). The UAS MUST add an Unsupported
header field, and list in it those options it does not understand
amongst those in the Require header field of the request.
Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL
request, or in an ACK request sent for a non-2xx response. These
header fields MUST be ignored if they are present in these requests.
An ACK request for a 2xx response MUST contain only those Require and
Proxy-Require values that were present in the initial request.
Example:
UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel
This behavior ensures that the client-server interaction will
proceed without delay when all options are understood by both
sides, and only slow down if options are not understood (as in the
example above). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes ambiguity
when the client requires features that the server does not
understand. Some features, such as call handling fields, are only
of interest to end systems.
8.2.3. Content Processing
Assuming the UAS understands any extensions required by the client,
the UAS examines the body of the message, and the header fields that
describe it. If there are any bodies whose type (indicated by the
Content-Type), language (indicated by the Content-Language) or
encoding (indicated by the Content-Encoding) are not understood, and
that body part is not optional (as indicated by the Content-
Disposition header field), the UAS MUST reject the request with a 415
(Unsupported Media Type) response. The response MUST contain an
Accept header field listing the types of all bodies it understands,
in the event the request contained bodies of types not supported by
the UAS. If the request contained content encodings not understood
by the UAS, the response MUST contain an Accept-Encoding header field
listing the encodings understood by the UAS. If the request
contained content with languages not understood by the UAS, the
response MUST contain an Accept-Language header field indicating the
languages understood by the UAS. Beyond these checks, body handling
depends on the method and type. For further information on the
processing of content-specific header fields, see Section 7.4 as well
as Section 20.11 through 20.15.
8.2.4. Applying Extensions
A UAS that wishes to apply some extension when generating the
response MUST NOT do so unless support for that extension is
indicated in the Supported header field in the request. If the
desired extension is not supported, the server SHOULD rely only on
baseline SIP and any other extensions supported by the client. In
rare circumstances, where the server cannot process the request
without the extension, the server MAY send a 421 (Extension Required)
response. This response indicates that the proper response cannot be
generated without support of a specific extension. The needed
extension(s) MUST be included in a Require header field in the
response. This behavior is NOT RECOMMENDED, as it will generally
break interoperability.
Any extensions applied to a non-421 response MUST be listed in a
Require header field included in the response. Of course, the server
MUST NOT apply extensions not listed in the Supported header field in
the request. As a result of this, the Require header field in a
response will only ever contain option tags defined in standards-
track RFCs.
8.2.5. Processing the Request
Assuming all of the checks in the previous subsections are passed,
the UAS processing becomes method-specific. Section 10 covers the
REGISTER request, Section 11 covers the OPTIONS request, Section 13
covers the INVITE request, and Section 15 covers the BYE request.
8.2.6. Generating the Response
When a UAS wishes to construct a response to a request, it follows
the general procedures detailed in the following subsections.
Additional behaviors specific to the response code in question, which
are not detailed in this section, may also be required.
Once all procedures associated with the creation of a response have
been completed, the UAS hands the response back to the server
transaction from which it received the request.
8.2.6.1. Sending a Provisional Response
One largely non-method-specific guideline for the generation of
responses is that UASs SHOULD NOT issue a provisional response for a
non-INVITE request. Rather, UASs SHOULD generate a final response to
a non-INVITE request as soon as possible.
When a 100 (Trying) response is generated, any Timestamp header field
present in the request MUST be copied into this 100 (Trying)
response. If there is a delay in generating the response, the UAS
SHOULD add a delay value into the Timestamp value in the response.
This value MUST contain the difference between the time of sending of
the response and receipt of the request, measured in seconds.
The From field of the response MUST equal the From header field of
the request. The Call-ID header field of the response MUST equal the
Call-ID header field of the request. The CSeq header field of the
response MUST equal the CSeq field of the request. The Via header
field values in the response MUST equal the Via header field values
in the request and MUST maintain the same ordering.
If a request contained a To tag in the request, the To header field
in the response MUST equal that of the request. However, if the To
header field in the request did not contain a tag, the URI in the To
header field in the response MUST equal the URI in the To header
field; additionally, the UAS MUST add a tag to the To header field in
the response (with the exception of the 100 (Trying) response, in
which a tag MAY be present). This serves to identify the UAS that is
responding, possibly resulting in a component of a dialog ID. The
same tag MUST be used for all responses to that request, both final
and provisional (again excepting the 100 (Trying)). Procedures for
the generation of tags are defined in Section 19.3.
A stateless UAS is a UAS that does not maintain transaction state.
It replies to requests normally, but discards any state that would
ordinarily be retained by a UAS after a response has been sent. If a
stateless UAS receives a retransmission of a request, it regenerates
the response and resends it, just as if it were replying to the first
instance of the request. A UAS cannot be stateless unless the request
processing for that method would always result in the same response
if the requests are identical. This rules out stateless registrars,
for example. Stateless UASs do not use a transaction layer; they
receive requests directly from the transport layer and send responses
directly to the transport layer.
The stateless UAS role is needed primarily to handle unauthenticated
requests for which a challenge response is issued. If
unauthenticated requests were handled statefully, then malicious
floods of unauthenticated requests could create massive amounts of
transaction state that might slow or completely halt call processing
in a UAS, effectively creating a denial of service condition; for
more information see Section 26.1.5.
The most important behaviors of a stateless UAS are the following:
o A stateless UAS MUST NOT send provisional (1xx) responses.
o A stateless UAS MUST NOT retransmit responses.
o A stateless UAS MUST ignore ACK requests.
o A stateless UAS MUST ignore CANCEL requests.
o To header tags MUST be generated for responses in a stateless
manner - in a manner that will generate the same tag for the
same request consistently. For information on tag construction
see Section 19.3.
In all other respects, a stateless UAS behaves in the same manner as
a stateful UAS. A UAS can operate in either a stateful or stateless
mode for each new request.
In some architectures it may be desirable to reduce the processing
load on proxy servers that are responsible for routing requests, and
improve signaling path robustness, by relying on redirection.
Redirection allows servers to push routing information for a request
back in a response to the client, thereby taking themselves out of
the loop of further messaging for this transaction while still aiding
in locating the target of the request. When the originator of the
request receives the redirection, it will send a new request based on
the URI(s) it has received. By propagating URIs from the core of the
network to its edges, redirection allows for considerable network
scalability.
A redirect server is logically constituted of a server transaction
layer and a transaction user that has access to a location service of
some kind (see Section 10 for more on registrars and location
services). This location service is effectively a database
containing mappings between a single URI and a set of one or more
alternative locations at which the target of that URI can be found.
A redirect server does not issue any SIP requests of its own. After
receiving a request other than CANCEL, the server either refuses the
request or gathers the list of alternative locations from the
location service and returns a final response of class 3xx. For
well-formed CANCEL requests, it SHOULD return a 2xx response. This
response ends the SIP transaction. The redirect server maintains
transaction state for an entire SIP transaction. It is the
responsibility of clients to detect forwarding loops between redirect
servers.
When a redirect server returns a 3xx response to a request, it
populates the list of (one or more) alternative locations into the
Contact header field. An "expires" parameter to the Contact header
field values may also be supplied to indicate the lifetime of the
Contact data.
The Contact header field contains URIs giving the new locations or
user names to try, or may simply specify additional transport
parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily)
response may also give the same location and username that was
targeted by the initial request but specify additional transport
parameters such as a different server or multicast address to try, or
a change of SIP transport from UDP to TCP or vice versa.
However, redirect servers MUST NOT redirect a request to a URI equal
to the one in the Request-URI; instead, provided that the URI does
not point to itself, the server MAY proxy the request to the
destination URI, or MAY reject it with a 404.
If a client is using an outbound proxy, and that proxy actually
redirects requests, a potential arises for infinite redirection
loops.
Note that a Contact header field value MAY also refer to a different
resource than the one originally called. For example, a SIP call
connected to PSTN gateway may need to deliver a special informational
announcement such as "The number you have dialed has been changed."
A Contact response header field can contain any suitable URI
indicating where the called party can be reached, not limited to SIP
URIs. For example, it could contain URIs for phones, fax, or irc (if
they were defined) or a mailto: (RFC 2368prop [32]) URL. Section 26.4.4
discusses implications and limitations of redirecting a SIPS URI to a
non-SIPS URI.
The "expires" parameter of a Contact header field value indicates how
long the URI is valid. The value of the parameter is a number
indicating seconds. If this parameter is not provided, the value of
the Expires header field determines how long the URI is valid.
Malformed values SHOULD be treated as equivalent to 3600.
This provides a modest level of backwards compatibility with RFC
2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop), which allowed absolute times in this header field. If an
absolute time is received, it will be treated as malformed, and
then default to 3600.
Redirect servers MUST ignore features that are not understood
(including unrecognized header fields, any unknown option tags in
Require, or even method names) and proceed with the redirection of
the request in question.
