Network Working Group S. Donovan
Request for Comments: 4028 J. Rosenberg
Category: Standards Track Cisco Systems
April 2005
Session Timers in the Session Initiation Protocol (SIP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines an extension to the Session Initiation Protocol
(SIP). This extension allows for a periodic refresh of SIP sessions
through a re-INVITE or UPDATE request. The refresh allows both user
agents and proxies to determine whether the SIP session is still
active. The extension defines two new header fields:
Session-Expires, which conveys the lifetime of the session, and
Min-SE, which conveys the minimum allowed value for the session
timer.
Donovan & Rosenberg Standards Track [Page 1]
RFC 4028 Session Timer April 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. Session-Expires Header Field Definition . . . . . . . . . . 6
5. Min-SE Header Field Definition . . . . . . . . . . . . . . . 8
6. 422 Response Code Definition . . . . . . . . . . . . . . . . 8
7. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Generating an Initial Session Refresh Request . . . . 9
7.2. Processing a 2xx Response . . . . . . . . . . . . . . 9
7.3. Processing a 422 Response . . . . . . . . . . . . . . 11
7.4. Generating Subsequent Session Refresh Requests . . . . 11
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Processing of Requests . . . . . . . . . . . . . . . . 13
8.2. Processing of Responses . . . . . . . . . . . . . . . 14
8.3. Session Expiration . . . . . . . . . . . . . . . . . . 15
9. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Performing Refreshes . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . 18
11.1. Inside Attacks . . . . . . . . . . . . . . . . . . . . 18
11.2. Outside Attacks . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12.1. IANA Registration of Min-SE and Session-Expires
Header Fields . . . . . . . . . . . . . . . . . . . . 19
12.2. IANA Registration of the 422 (Session Interval Too
Small) Response Code . . . . . . . . . . . . . . . . . 20
12.3. IANA Registration of the 'timer' Option Tag . . . . . 20
13. Example Call Flow . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
The Session Initiation Protocol (SIP) [2] does not define a keepalive
mechanism for the sessions it establishes. Although the user agents
may be able to determine whether the session has timed out by using
session specific mechanisms, proxies will not be able to do so. The
result is that call stateful proxies will not always be able to
determine whether a session is still active. For instance, when a
user agent fails to send a BYE message at the end of a session, or
when the BYE message gets lost due to network problems, a call
stateful proxy will not know when the session has ended. In this
situation, the call stateful proxy will retain state for the call and
Donovan & Rosenberg Standards Track [Page 2]
RFC 4028 Session Timer April 2005
has no method to determine when the call state information no longer
applies.
To resolve this problem, this extension defines a keepalive mechanism
for SIP sessions. UAs send periodic re-INVITE or UPDATE [3] requests
(referred to as session refresh requests) to keep the session alive.
The interval for the session refresh requests is determined through a
negotiation mechanism defined here. If a session refresh request is
not received before the interval passes, the session is considered
terminated. Both UAs are supposed to send a BYE, and call stateful
proxies can remove any state for the call.
This refresh mechanism has additional applications. A user agent
would like to determine whether the session is still active for the
same reasons a call stateful proxy server would. This determination
can be made at a user agent without the use of SIP level mechanisms;
for audio sessions, periodic RTCP packets serve as an indication of
liveness [5]. However, it is desirable to separate indications of
SIP session liveness from the details of the particular session.
Another application of the session timer is in the construction of a
SIP Network Address Translator (NAT) Application Level Gateway (ALG)
[6]. The ALG embedded in a NAT will need to maintain state for the
duration of a call. This state must eventually be removed. Relying
on a BYE to trigger the removal of state, besides being unreliable,
introduces a potential denial of service attack.
This document provides an extension to SIP that defines a session
expiration mechanism. Periodic refreshes, through re-INVITEs or
UPDATEs, are used to keep the session active. The extension is
sufficiently backward compatible with SIP that it works as long as
either one of the two participants in a dialog understands the
extension. Two new header fields (Session-Expires and Min-SE) and a
new response code (422) are defined. Session-Expires conveys the
duration of the session, and Min-SE conveys the minimum allowed value
for the session expiration. The 422 response code indicates that the
session timer duration was too small.
2. Terminology
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED',
'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant SIP implementations.
Donovan & Rosenberg Standards Track [Page 3]
RFC 4028 Session Timer April 2005
Additionally, we define the following terms:
Session Interval: The maximum amount of time that can occur between
session refresh requests in a dialog before the session will be
considered timed out. The session interval is conveyed in the
Session-Expires header field, which is defined here. The UAS
obtains this value from the Session-Expires header field in a 2xx
response to a session refresh request that it sends. Proxies and
UACs determine this value from the Session-Expires header field in
a 2xx response to a session refresh request that they receive.
Minimum Timer: Because of the processing load of mid-dialog requests,
all elements (proxy, UAC, UAS) can have a configured minimum value
for the session interval that they are willing to accept. This
value is called the minimum timer.
Session Expiration: The time at which an element will consider the
session timed out, if no successful session refresh transaction
occurs beforehand.
Session Refresh Request: An INVITE or UPDATE request processed
according to the rules of this specification. If the request
generates a 2xx response, the session expiration is increased to
the current time plus the session interval obtained from the
response. A session refresh request is not to be confused with a
target refresh request, defined in Section 6 of [2], which is a
request that can update the remote target of a dialog.
Initial Session Refresh Request: The first session refresh request
sent with a particular Call-ID value.
Subsequent Session Refresh Request: Any session refresh request sent
with a particular Call-ID after the initial session refresh
request.
Refresh: Same as a session refresh request.
3. Overview of Operation
This section provides a brief overview of the operation of the
extension. It is tutorial in nature and should not be considered
normative.
This extension has the property that it works even when only one UA
in a dialog supports it. The processing steps differ for handling
each of the four cases (the UAC does or doesn't support it, and the
UAS does or doesn't support it). For simplicity's sake, this section
Donovan & Rosenberg Standards Track [Page 4]
RFC 4028 Session Timer April 2005
will describe basic operation in the case where both sides support
the extension.
A UAC starts by sending an INVITE. This includes a Supported header
field with the option tag 'timer', indicating support for this
extension.
This request passes through proxies, any one of which may have an
interest in establishing a session timer. Each proxy can insert a
Session-Expires header field and a Min-SE header field into the
request (if none is already there) or alter the value of existing
Session-Expires and Min-SE header fields as described below.
The Min-SE header field establishes the lower bound for the session
refresh interval; i.e., the fastest rate any proxy servicing this
request will be allowed to require. The purpose of this header field
is to prevent hostile proxies from setting arbitrarily short refresh
intervals so that their neighbors are overloaded. Each proxy
processing the request can raise this lower bound (increase the
period between refreshes) but is not allowed to lower it.
The Session-Expires header field establishes the upper bound for the
session refresh interval; i.e., the time period after processing a
request for which any session-stateful proxy must retain its state
for this session. Any proxy servicing this request can lower this
value, but it is not allowed to decrease it below the value specified
in the Min-SE header field.
If the Session-Expires interval is too low for a proxy (i.e., lower
than the value of Min-SE that the proxy would wish to assert), the
proxy rejects the request with a 422 response. That response
contains a Min-SE header field identifying the minimum session
interval it is willing to support. The UAC will try again, this time
including the Min-SE header field in the request. The header field
contains the largest Min-SE header field it observed in all 422
responses previously received. This way, the minimum timer meets the
constraints of all proxies along the path.
After several INVITE/422 iterations, the request eventually arrives
at the UAS. The UAS can adjust the value of the session interval as
if it were a proxy; when done, it places the final session interval
into the Session-Expires header field in a 2xx response. The
Session-Expires header field also contains a 'refresher' parameter,
which indicates who is doing the refreshing -- the UA that is
currently the UAC, or the UA that is currently the UAS. As the 2xx
response travels back through the proxy chain, each proxy can observe
the final session interval but can't change it.
Donovan & Rosenberg Standards Track [Page 5]
RFC 4028 Session Timer April 2005
From the Session-Expires header field in the response, both UAs know
that a session timer is active, when it will expire, and who is
refreshing. At some point before the expiration, the currently
active refresher generates a session refresh request, which is a
re-INVITE or UPDATE [3] request. If the refresher never gets a
response to that session refresh request, it sends a BYE to terminate
the session. Similarly, if the other side never gets the session
refresh request before the session expires, it sends a BYE.
The refresh requests sent once the session is established are
processed identically to the initial requests, as described above.
This means that a successful session refresh request will extend the
session, as desired.
The extension introduces additional complications beyond this basic
flow to support cases where only one of the UAs supports it. One
such complication is that a proxy may need to insert the
Session-Expires header field into the response, in the event that the
UAS doesn't support the extension. The negotiation of the role of
refresher is also affected by this capability; it takes into
consideration which participants support the extension.
Note that the session timer refreshes the session, not the dialog
used to establish the session. Of course, the two are related. If
the session expires, a BYE is sent, which terminates the session and,
generally, the dialog.
4. Session-Expires Header Field Definition
The Session-Expires header field conveys 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. Like the SIP Expires
header field, it contains a delta-time.
The absolute minimum for the Session-Expires header field is 90
seconds. This value represents a bit more than twice the duration
that a SIP transaction can take in the event of a timeout. This
allows sufficient time for a UA to attempt a refresh at the halfpoint
of the session interval, and for that transaction to complete
normally before the session expires. However, 1800 seconds (30
minutes) is RECOMMENDED as the value for the Session-Expires header
field. In other words, SIP entities MUST be prepared to handle
Session-Expires header field values of any duration greater than 90
seconds, but entities that insert the Session-Expires header field
SHOULD NOT choose values of less than 30 minutes.
Donovan & Rosenberg Standards Track [Page 6]
RFC 4028 Session Timer April 2005
Small session intervals can be destructive to the network. They
cause excessive messaging traffic that affects both user agents and
proxy servers. They increase the possibility of 'glare' that can
occur when both user agents send a re-INVITE or UPDATE at the same
time. Since the primary purpose of the session timer is to provide a
means to time out state in SIP elements, very small values won't
generally be needed. 30 minutes was chosen because 95% of phone
calls are shorter than this duration. However, the 30 minute minimum
is listed as a SHOULD, and not as a MUST, since the exact value for
this number is dependent on many network factors, including network
bandwidths and latencies, computing power, memory availability,
network topology, and, of course, the application scenario. After
all, SIP can set up any kind of session, not just a phone call. At
the time of publication of this document, 30 minutes seems
appropriate. Advances in technologies may result in the number being
excessively large five years in the future.
The default value of the Session-Expires header field is undefined.
This means that the absence of the Session-Expires header field
implies no expiration of the session, using the mechanism defined in
this specification. Note that other mechanisms not defined in this
specification, such as locally configured timers, may apply.
The syntax of the Session-Expires header field is as follows:
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
Note that a compact form, the letter x, has been reserved for
Session-Expires. The BNF for delta-seconds and generic-param is
defined in Section 25 of RFC 3261 [2].
Table 1 is an extension of Tables 2 and 3 in [2] for the
Session-Expires and Min-SE header fields. The column 'PRA' is for
the PRACK method [7], 'UPD' is for the UPDATE method [3], 'SUB' is
for the SUBSCRIBE method [8], and 'NOT' is for the NOTIFY method [8].
Donovan & Rosenberg Standards Track [Page 7]
RFC 4028 Session Timer April 2005
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
| Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
|Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - |
| | | | | | | | | | | | | |
|Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - |
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
Table 1: Session-Expires and Min-SE Header Fields
5. Min-SE Header Field Definition
The Min-SE header 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, its value MUST NOT be less than 90 seconds.
When the header field is not present, its default value for is 90
seconds.
The Min-SE header field MUST NOT be used in responses except for
those with a 422 response code. It indicates the minimum value of
the session interval that the server is willing to accept.
The syntax of the Min-SE header field is as follows:
Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)
6. 422 Response Code Definition
This extension introduces the 422 (Session Interval Too Small)
response code. It is generated by a UAS or proxy when a request
contains a Session-Expires header field with a duration below the
minimum timer for the server. The 422 response MUST contain a Min-SE
header field with the minimum timer for that server.
Donovan & Rosenberg Standards Track [Page 8]
RFC 4028 Session Timer April 2005
7. UAC Behavior
7.1. Generating an Initial Session Refresh Request
A UAC that supports the session timer extension defined here MUST
include a Supported header field in each request (except ACK),
listing the option tag 'timer' [2]. It MUST do so even if the UAC is
not requesting usage of the session timer for this session.
The UAC MAY include a Require header field in the request with the
value 'timer' to indicate that the UAS must support the session timer
to participate in the session. This does not mean that the UAC is
requiring the UAS to perform the refreshes, only that it is requiring
the UAS to support the extension. In addition, the UAC MAY include a
Proxy-Require header field in the request with the value 'timer' to
indicate that proxies must support the session timer in order to
correctly process the request. However, usage of either Require or
Proxy-Require by the UAC is NOT RECOMMENDED. They are not needed,
since the extension works even when only the UAC supports the
extension. The Supported header field containing 'timer' MUST still
be included, even if the Require or Proxy-Require header fields are
present containing 'timer'.
A UAC MAY include the Min-SE header field in the initial INVITE
request.
A UAC MAY include a Session-Expires header field in an initial
session refresh request if it wants a session timer applied to the
session. The value of this header field indicates the session
interval desired by the UAC. If a Min-SE header is included in the
initial session refresh request, the value of the Session-Expires
MUST be greater than or equal to the value in Min-SE.
The UAC MAY include the refresher parameter with value 'uac' if it
wants to perform the refreshes. However, it is RECOMMENDED that the
parameter be omitted so that it can be selected by the negotiation
mechanisms described below.
7.2. Processing a 2xx Response
The session timer requires a UA to create and maintain state. This
state includes the session interval, the session expiration, and the
identity of the refresher. This state is associated with the dialog
on which the session has been negotiated.
Donovan & Rosenberg Standards Track [Page 9]
RFC 4028 Session Timer April 2005
When a 2xx response to a session refresh request arrives, it may or
may not contain a Require header field with the value 'timer'. If it
does, the UAC MUST look for the Session-Expires header field to
process the response.
If there was a Require header field in the response with the value
'timer', the Session-Expires header field will always be present.
UACs MUST be prepared to receive a Session-Expires header field in a
response, even if none were present in the request. The 'refresher'
parameter will be present in the Session-Expires header field,
indicating who will perform the refreshes. The UAC MUST set the
identity of the refresher to the value of this parameter. If the
parameter contains the value 'uac', the UAC will perform them. It is
possible that the UAC requested the session timer (and thus included
a Session-Expires header field in the request) and that there was no
Require or Session-Expires header field in the 2xx response. This
will happen when the UAS doesn't support the session timer extension
and only the UAC has asked for a session timer (no proxies have
requested it). In this case, if the UAC still wishes to use the
session timer (which is purely for its benefit alone), it has to
perform them. To do this, the UAC follows the procedures defined in
this specification as if the Session-Expires header field were in the
2xx response, and its value was the same as that in the request, but
with a refresher parameter of 'uac'.
If the 2xx response did not contain a Session-Expires header field,
there is no session expiration. In this case, no refreshes need to
be sent. A 2xx without a Session-Expires can come for both initial
and subsequent session refresh requests. This means that the session
timer can be 'turned-off' in mid dialog by receiving a response
without a Session-Expires header field.
The UAC remembers the session interval for a session as the value of
the delta-time from the Session-Expires header field in the most
recent 2xx response to a session refresh request on a dialog. It is
explicitly allowed for there to be differing session intervals (or
none at all) on differing dialogs established as a result of a single
INVITE. The UAC also remembers whether it or its peer is the
refresher on for the session.
If the UAC must perform the refreshes, it computes the session
expiration for that session. The session expiration is the time of
reception of the last 2xx response to a session refresh request on
that dialog plus the session interval for that session. If the UA
seeks to continue with the session beyond the session expiration, it
MUST generate a refresh before the session expiration. It is
Donovan & Rosenberg Standards Track [Page 10]
RFC 4028 Session Timer April 2005
RECOMMENDED that this refresh be sent once half the session interval
has elapsed. Additional procedures for this refresh are described in
Section 10.
Similarly, a re-INVITE or UPDATE request sent within a dialog for
purposes other than session refreshes will also have the effect of
refreshing the session, and its processing will follow the procedures
defined in this specification.
7.3. Processing a 422 Response
If the response to a session refresh request is a 422 (Session
Interval Too Small) response message, then the UAC MAY retry the
request. The procedures for retrying are described in Section 7.4.
This new request constitutes a new transaction and SHOULD have the
same value as 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.
7.4. Generating Subsequent Session Refresh Requests
The values of Supported, Require, and Proxy-Require used in the
initial Session refresh request MUST be used.
The UAC MUST insert the Min-SE header field into a session refresh
request for a particular dialog if it has ever received a 422
response to a previous session refresh request on the same dialog, or
if it has received a session refresh request on that dialog that
contained a Min-SE header field. Similarly, if no dialog has been
established yet, a UAC MUST insert the Min-SE header field into an
INVITE request if it has ever received a 422 response to a previous
INVITE request with the same Call-ID.
The value of the Min-SE header field present in a session refresh
request MUST be the largest value among all Min-SE header field
values returned in all 422 responses or received in session refresh
requests, on the same dialog, if a dialog has been established. If
no dialog has been established, the Min-SE header field value is set
to the largest value among all Min-SE header field values returned in
all 422 responses for an INVITE request with the same Call-ID. A
result of this rule is that the maximum value of the Min-SE is
effectively 'cleared' once the dialog is established, and from that
point on, only the values from proxies known to be on the proxy path
will end up being used.
The UAC may have its own opinions about the minimum session interval.
In that case, if the value above is too small, the UAC MAY increase
it.
Donovan & Rosenberg Standards Track [Page 11]
RFC 4028 Session Timer April 2005
In a session refresh request sent within a dialog with an active
session timer, the Session-Expires header field SHOULD be present.
When present, it SHOULD be equal to the maximum of the Min-SE header
field (recall that its default value when not present is 90 seconds)
and the current session interval. Inclusion of the Session-Expires
header field with this value avoids certain denial-of-service
attacks, as documented in Section 11. As such, a UA should only
ignore the SHOULD in unusual and singular cases where it is desirable
to change the session interval mid-dialog.
If the session refresh request is not the initial one, it is
RECOMMENDED that the refresher parameter be set to 'uac' if the
element sending the request is currently performing refreshes, and to
'uas' if its peer is performing the refreshes. This way, the role of
refresher does not change on each refresh. However, if it wishes to
explicitly change the roles, it MAY use a value of 'uas' if it knows
that the other side supports the session timer. It could know this
by having received a request from its peer with a Supported header
field containing the value 'timer'. If it seeks to reselect the
roles, it MAY omit the parameter.
A re-INVITE generated to refresh the session is a normal re-INVITE,
and an UPDATE generated to refresh a session is a normal UPDATE. If
a UAC knows that its peer supports the UPDATE method, it is
RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can
make this determination if it has seen an Allow header field from its
peer with the value 'UPDATE', or through a mid-dialog OPTIONS
request. It is RECOMMENDED that the UPDATE request not contain an
offer [4], but a re-INVITE SHOULD contain one, even if the details of
the session have not changed. In that case, the offer MUST indicate
that it has not changed. In the case of SDP, this is accomplished by
including the same value for the origin field as did previous SDP
messages to its peer. The same is true for an answer exchanged as a
result of a session refresh request; if it has not changed, that MUST
be indicated.
8. Proxy Behavior
Session timers are mostly of interest to call stateful proxy servers
(that is, to servers that maintain the state of calls and dialogs
established through them). However, a stateful proxy server (that
is, a server which is aware of transaction state but does not retain
call or dialog state) MAY also follow the rules described here.
Stateless proxies MUST NOT attempt to request session timers.
Proxies that ask for session timers SHOULD record-route, as they
won't receive refreshes if they don't.
Donovan & Rosenberg Standards Track [Page 12]
RFC 4028 Session Timer April 2005
The proxy processing rules require the proxy to remember
information between the request and response, ruling out stateless
proxies.
8.1. Processing of Requests
Processing of requests is identical for all session refresh requests.
To request a session timer for a session, a proxy makes sure that a
Session-Expires header field is present in a session refresh request
for that session. A proxy MAY insert a Session-Expires header field
in the request before forwarding it if none was present in the
request. This Session-Expires header field may contain any desired
expiration time the proxy would like, but not with a duration lower
than the value in the Min-SE header field in the request, if it is
present. The proxy MUST NOT include a refresher parameter in the
header field value.
If the request already had a Session-Expires header field, the proxy
MAY reduce its value but MUST NOT set it to a duration lower than the
value in the Min-SE header field in the request, if it is present.
If the value of the Session-Expires header field is greater than or
equal to the value in the Min-SE header field (recall that the
default is 90 seconds when the Min-SE header field is not present),
the proxy MUST NOT increase the value of the Session-Expires header
field. If the value of the Session-Expires header field is lower
than the value of the Min-SE header field (possibly because the proxy
increased the value of the Min-SE header field, as described below),
the proxy MUST increase the value of the Session-Expires header field
to make it equal to Min-SE header field value. The proxy MUST NOT
insert or modify the value of the 'refresher' parameter in the
Session-Expires header field.
If the request contains a Supported header field with a value
'timer', the proxy MAY reject the INVITE request with a 422 (Session
Interval Too Small) response if the session interval in the
Session-Expires header field is smaller than the minimum interval
defined by the proxy's local policy. When sending the 422 response,
the proxy MUST include a Min-SE header field with the value of its
minimum interval. That minimum MUST NOT be lower than 90 seconds.
If the request doesn't indicate support for the session timer but
contains a session interval that is too small, the proxy cannot
usefully reject the request, as this would result in a call failure.
Rather, the proxy SHOULD insert a Min-SE header field containing its
minimum interval. If a Min-SE header field is already present, the
proxy SHOULD increase (but MUST NOT decrease) the value to its
minimum interval. The proxy MUST then increase the Session-Expires
Donovan & Rosenberg Standards Track [Page 13]
RFC 4028 Session Timer April 2005
header field value to be equal to the value in the Min-SE header
field, as described above. A proxy MUST NOT insert a Min-SE header
field or modify the value of an existing header field in a proxied
request if that request contains a Supported header field with the
value 'timer'. This is needed to protect against certain denial of
service attacks, described in Section 11.
Assuming that the proxy has requested a session timer (and thus has
possibly inserted the Session-Expires header field or reduced it),
the proxy MUST remember that it is using a session timer, and also
remember the value of the Session-Expires header field from the
proxied request. This MUST be remembered for the duration of the
transaction.
The proxy MUST remember, for the duration of the transaction, whether
the request contained the Supported header field with the value
'timer'. If the request did not contain a Supported header field
with the value 'timer', the proxy MAY insert a Require header field
with the value 'timer' into the request. However, this is NOT
RECOMMENDED. This allows the proxy to insist on a session timer for
the session. This header field is not needed if a Supported header
field was in the request; in this case, the proxy would already be
sure the session timer can be used for the session.
8.2. Processing of Responses
When the final response to the request arrives, it is examined by the
proxy.
If the response does not contain a Session-Expires header field but
the proxy remembers that it requested a session timer in the request
(by inserting, modifying, or examining and accepting the
Session-Expires header field in the proxied request), this means that
the UAS did not support the session timer. If the proxy remembers
that the UAC did not support the session timer either, the proxy
forwards the response upstream normally. There is no session
expiration for this session. If, however, the proxy remembers that
the UAC did support the session timer, additional processing is
needed.
Because there is no Session-Expires or Require header field in the
response, the proxy knows that it is the first session-timer-aware
proxy to receive the response. This proxy MUST insert a
Session-Expires header field into the response with the value it
remembered from the forwarded request. It MUST set the value of the
'refresher' parameter to 'uac'. The proxy MUST add the 'timer'
Donovan & Rosenberg Standards Track [Page 14]
RFC 4028 Session Timer April 2005
option tag to any Require header field in the response, and if none
was present, add the Require header field with that value before
forwarding it upstream.
If the received response contains a Session-Expires header field, no
modification of the response is needed.
In all cases, if the 2xx response forwarded upstream by the proxy
contains a Session-Expires header field, its value represents the
session interval for the session associated with that response. The
proxy computes the session expiration as the time when the 2xx
response is forwarded upstream, plus the session interval. This
session expiration MUST update any existing session expiration for
the session. The refresher parameter in the Session-Expires header
field in the 2xx response forwarded upstream will be present, and it
indicates which UA is performing the refreshes. There can be
multiple 2xx responses to a single INVITE, each representing a
different dialog, resulting in multiple session expirations, one for
each session associated with each dialog.
The proxy MUST NOT modify the value of the Session-Expires header
field received in the response (assuming one was present) before
forwarding it upstream.
8.3. Session Expiration
When the current time equals or passes the session expiration for a
session, the proxy MAY remove associated call state, and MAY free any
resources associated with the call. Unlike the UA, it MUST NOT send
a BYE.
9. UAS Behavior
The UAS must respond to a request for a session timer by the UAC or a
proxy in the path of the request, or it may request that a session
timer be used itself.
If an incoming request contains a Supported header field with a value
'timer' and a Session Expires header field, the UAS MAY reject the
INVITE request with a 422 (Session Interval Too Small) response if
the session interval in the Session-Expires header field is smaller
than the minimum interval defined by the UAS' local policy. When
sending the 422 response, the UAS MUST include a Min-SE header field
with the value of its minimum interval. This minimum interval MUST
NOT be lower than 90 seconds.
If the UAS wishes to accept the request, it copies the value of the
Session-Expires header field from the request into the 2xx response.
Donovan & Rosenberg Standards Track [Page 15]
RFC 4028 Session Timer April 2005
The UAS response MAY reduce its value but MUST NOT set it to a
duration lower than the value in the Min-SE header field in the
request, if it is present; otherwise the UAS MAY reduce its value but
MUST NOT set it to a duration lower than 90 seconds. The UAS MUST
NOT increase the value of the Session-Expires header field.
If the incoming request contains a Supported header field with a
value 'timer' but does not contain a Session-Expires header, it means
that the UAS is indicating support for timers but is not requesting
one. The UAS may request a session timer in the 2XX response by
including a Session-Expires header field. The value MUST NOT be set
to a duration lower than the value in the Min-SE header field in the
request, if it is present.
The UAS MUST set the value of the refresher parameter in the
Session-Expires header field in the 2xx response. This value
specifies who will perform refreshes for the dialog. The value is
based on the value of this parameter in the request, and on whether
the UAC supports the session timer extension. The UAC supports the
extension if the 'timer' option tag was present in a Supported header
field in the request. Table 2 defines how the value in the response
is set. A value of 'none' in the 2nd column means that there was no
refresher parameter in the request. A value of 'NA' in the third
column means that this particular combination shouldn't happen, as it
is disallowed by the protocol.
UAC supports? refresher parameter refresher parameter
in request in response
-------------------------------------------------------
N none uas
N uac NA
N uas NA
Y none uas or uac
Y uac uac
Y uas uas
Table 2: UAS Behavior
The fourth row of Table 2 describes a case where both the UAC and UAS
support the session timer extension, and where the UAC did not select
who will perform refreshes. This allows the UAS to decide whether it
or the UAC will perform the refreshes. However, as the table
indicates, the UAS cannot override the UAC's choice of refresher, if
it made one.
If the refresher parameter in the Session-Expires header field in the
2xx response has a value of 'uac', the UAS MUST place a Require
header field into the response with the value 'timer'. This is
Donovan & Rosenberg Standards Track [Page 16]
RFC 4028 Session Timer April 2005
because the uac is performing refreshes and the response has to be
processed for the UAC to know this. If the refresher parameter in
the 2xx response has a value of 'uas' and the Supported header field
in the request contained the value 'timer', the UAS SHOULD place a
Require header field into the response with the value 'timer'. In
this case, the UAC is not refreshing, but it is supposed to send a
BYE if it never receives a refresh. Since the call will still
succeed without the UAC sending a BYE, insertion of the Require is a
SHOULD here, and not a MUST.
Just like the UAC, the UAS stores state for the session timer. This
state includes the session interval, the session expiration, and the
identity of the refresher. This state is bound to the dialog used to
set up the session. The session interval is set to the value of the
delta-time from the Session-Expires header field in the most recent
2xx response to a session refresh request on that dialog. It also
remembers whether it or its peer is the refresher on the dialog,
based on the value of the refresher parameter from the most recent
2xx response to a session refresh request on that dialog. If the
most recent 2xx response had no Session-Expires header field, there
is no session expiration, and no refreshes have to be performed.
If the UAS must refresh the session, it computes the session
expiration. The session expiration is the time of transmission of
the last 2xx response to a session refresh request on that dialog
plus the session interval. If UA wishes to continue with the session
beyond the session expiration, it MUST generate a refresh before the
session expiration. It is RECOMMENDED that this refresh be sent once
half the session interval has elapsed. Additional procedures for
this refresh are described in Section 10.
10. Performing Refreshes
The side generating a refresh does so according to the UAC procedures
defined in Section 7. Note that only a 2xx response to a session
refresh request extends the session expiration. This means that a UA
could attempt a refresh and receive a 422 response with a Min-SE
header field that contains a value much larger than the current
session interval. The UA will still have to send a session refresh
request before the session expiration (which has not changed), even
though this request will contain a value of the Session-Expires that
is much larger than the current session interval.
If the session refresh request transaction times out or generates a
408 or 481 response, then the UAC sends a BYE request as per Section
12.2.1.2 of RFC 3261 [2]. If the session refresh request does not
generate a 2xx response (and, as a result, the session is not
refreshed), and a response other than 408 or 481 is received, the UAC
Donovan & Rosenberg Standards Track [Page 17]
RFC 4028 Session Timer April 2005
SHOULD follow the rules specific to that response code and retry if
possible. For example, if the response is a 401, the UAC would retry
the request with new credentials. However, the UAC SHOULD NOT
continuously retry the request if the server indicates the same error
response.
Similarly, if the side not performing refreshes does not receive a
session refresh request before the session expiration, it SHOULD send
a BYE to terminate the session, slightly before the session
expiration. The minimum of 32 seconds and one third of the session
interval is RECOMMENDED.
Firewalls and NAT ALGs may be very unforgiving about allowing SIP
traffic to pass after the expiration time of the session. This is
why the BYE should be sent before the expiration.
11. Security Considerations
The session timer introduces the capability of a proxy or UA element
to force compliant UAs to send refreshes at a rate of the element's
choosing. This introduces the possibility of denial-of-service
attacks with significant amplification properties. These attacks can
be launched from 'outsiders' (elements that attempt to modify
messages in transit) or by 'insiders' (elements that are legitimately
in the request path but are intent on doing harm). Fortunately, both
cases are adequately handled by this specification.
11.1. Inside Attacks
This introduces the possibility of rogue proxies or UAs introducing
denial-of-service attacks. However, the mechanisms in this
specification prevent that from happening.
First, consider the case of a rogue UAC that wishes to force a UAS to
generate refreshes at a rapid rate. To do so, it inserts a
Session-Expires header field into an INVITE with a low duration and a
refresher parameter equal to uas. Assume it places a Supported
header field into the request. The UAS or any proxy that objects to
this low timer will reject the request with a 422, thereby preventing
the attack. If no Supported header field was present, the proxies
will insert a Min-SE header field into the request before forwarding
it. As a result, the UAS will not choose a session timer lower than
the minimum allowed by all elements on the path. This too prevents
the attack.
Next, consider the case of a rogue UAS that wishes to force a UAC to
generate refreshes at a rapid rate. In that case, the UAC has to
support session timer. The initial INVITE arrives at the rogue UAS,
Donovan & Rosenberg Standards Track [Page 18]
RFC 4028 Session Timer April 2005
which returns a 2xx with a very small session interval. The UAC uses
this timer and quickly sends a refresh. Section 7.4 requires that
the UAC copy the current session interval into the Session-Expires
header field in the request. This enables the proxies to see the
current value. The proxies will reject this request and provide a
Min-SE with a higher minimum, which the UAC will then use. Note,
that if the proxies did not reject the request, but rather proxied
the request with a Min-SE header field, an attack would still be
possible. The UAS could discard this header field in a 2xx response
and force the UAC to continue to generate rapid requests.
In a similar fashion, a rogue proxy cannot force either the UAC or
UAS to generate refreshes unless the proxy remains on the signaling
path and sees every request and response.
11.2. Outside Attacks
An element that can observe and modify a request or response in
transit can force rapid session refreshes. To prevent this, requests
and responses have to be protected by message integrity. Since the
session timer header fields are not end-to-end and are manipulated by
proxies, the SIP S/MIME capabilities are not suitable for this task.
Rather, integrity has to be protected by using hop-by-hop mechanisms.
As a result, it is RECOMMENDED that an element send a request with a
Session-Expires header field or a Supported header field with the
value 'timer' by using TLS. As adequate protection is obtained only
if security is applied on each hop, it is RECOMMENDED that the SIPS
URI scheme be used in conjunction with this extension. This means
that proxies that record-route and request session timer SHOULD
record-route with a SIPS URI. A UA that inserts a Session-Expires
header into a request or response SHOULD include a Contact URI that
is a SIPS URI.
12. IANA Considerations
This extension defines two new header fields, a new response code,
and a new option tag. SIP [2] defines IANA procedures for
registering these.
12.1. IANA Registration of Min-SE and Session-Expires Header Fields
The following is the registration for the Min-SE header field:
RFC Number: RFC 4028
Header Name: Min-SE
Compact Form: none
Donovan & Rosenberg Standards Track [Page 19]
RFC 4028 Session Timer April 2005
The following is the registration for the Session-Expires header
field:
RFC Number: RFC 4028
Header Name: Session-Expires
Compact Form: x
12.2. IANA Registration of the 422 (Session Interval Too Small)
Response Code
The following is the registration for the 422 (Session Interval Too
Small) response code:
Response Code: 422
Default Reason Phrase: Session Interval Too Small
RFC Number: RFC 4028
12.3. IANA Registration of the 'timer' Option Tag
The following is the registration for the 'timer' option tag:
Name: timer
Description: This option tag is for support of the session timer
extension. Inclusion in a Supported header field in a request or
response indicates that the UA can perform 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 it accordingly.
13. Example Call Flow
Example Session Timer Flow
Alice Proxy P1 Proxy P2 Bob
|(1) INVITE | | |
|SE: 50 | | |
|----------->| | |
|(2) 422 | | |
|MSE: 3600 | | |
|<-----------| | |
|(3) ACK | | |
|----------->| | |
|(4) INVITE | | |
|SE:3600 | | |
|MSE:3600 | | |
|----------->| | |
Donovan & Rosenberg Standards Track [Page 20]
RFC 4028 Session Timer April 2005
| |(5) INVITE | |
| |SE:3600 | |
| |MSE:3600 | |
| |----------->| |
| |(6) 422 | |
| |MSE:4000 | |
| |<-----------| |
| |(7) ACK | |
| |----------->| |
|(8) 422 | | |
|MSE:4000 | | |
|<-----------| | |
|(9) ACK | | |
|----------->| | |
|(10) INVITE | | |
|SE:4000 | | |
|MSE:4000 | | |
|----------->| | |
| |(11) INVITE | |
| |SE:4000 | |
| |MSE:4000 | |
| |----------->| |
| | |(12) INVITE |
| | |SE:4000 |
| | |MSE:4000 |
| | |----------->|
| | |(13) 200 OK |
| | |SE:4000 |
| | |<-----------|
| |(14) 200 OK | |
| |SE:4000 | |
| |<-----------| |
|(15) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
|(16) ACK | | |
|----------->| | |
| |(17) ACK | |
| |------------------------>|
|(18) UPDATE | | |
|SE:4000 | | |
|----------->| | |
| |(19) UPDATE | |
| |SE:4000 | |
| |------------------------>|
| |(20) 200 OK | |
| |SE:4000 | |
| |<------------------------|
Donovan & Rosenberg Standards Track [Page 21]
RFC 4028 Session Timer April 2005
|(21) 200 OK | | |
|SE:4000 | | |
|<-----------| | |
| |(22) BYE | |
| |<------------------------|
|(23) BYE | | |
|<-----------| | |
| |(24) 408 | |
| |------------------------>|
Figure 1: Example Session Timer Flow
Figure 1 gives an example of a call flow that makes use of the
session timer. In this example, both the UAC and UAS support the
session timer extension. The initial INVITE request generated by the
UAC, Alice (message 1), might look like this:
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
Supported: timer
Session-Expires: 50
Max-Forwards: 70
To: Bob
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
This request indicates that Alice supports the session timer, and is
requesting session refreshes every 50 seconds. This arrives at the
first proxy, P1. This session interval is below the minimum allowed
value of 3600. So P1 rejects the request with a 422 (message 2):
SIP/2.0 422 Session Interval Too Small
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Min-SE: 3600
To: Bob ;tag=9a8kz
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Donovan & Rosenberg Standards Track [Page 22]
RFC 4028 Session Timer April 2005
This response contains a Min-SE header field with the value 3600.
Alice then retries the request. This time, the request contains a
Min-SE header, as Alice has received a 422 for other INVITE requests
with the same Call-ID. The new request (message 4) might look like
this:
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9
Supported: timer
Session-Expires: 3600
Min-SE: 3600
Max-Forwards: 70
To: Bob
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Proxy P1 record-routes. Since the session interval is now acceptable
to it, it forwards the request to P2 (message 5). However, the
session interval is below its minimum configured amount of 4000. So
it rejects the request with a 422 response code (message 6) and
includes a Min-SE header field with the value of 4000. Once more,
Alice retries the INVITE. This time, the Min-SE header field in her
INVITE is the maximum of all Min-SE she has received (3600 and 4000).
Message 10 might look like this:
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
Supported: timer
Session-Expires: 4000
Min-SE: 4000
Max-Forwards: 70
To: Bob
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Donovan & Rosenberg Standards Track [Page 23]
RFC 4028 Session Timer April 2005
P1 record-routes once again, but P2 does not (this wouldn't normally
happen; presumably, if it asked for session timer, it would
record-route the subsequent request). The UAS receives the request.
It copies the Session-Expires header from the request to the response
and adds a refresher parameter with value 'uac'. This 200 OK is
forwarded back to Alice. The response she receives (message 15)
might look like this:
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10
;received=192.0.2.1
Require: timer
Supported: timer
Record-Route: sips:p1.atlanta.example.com;lr
Session-Expires: 4000;refresher=uac
To: Bob ;tag=9as888nd
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact:
Content-Type: application/sdp
Content-Length: 142
(Bob's SDP not shown)
Alice generates an ACK (message 16), which is routed through P1 and
then to Bob. Since Alice is the refresher, around 2000 seconds later
Alice sends an UPDATE request to refresh the session. Because this
request is part of an established dialog and Alice has not received
any 422 responses or requests on that dialog, there is no Min-SE
header field in her request (message 18):
UPDATE sips:bob@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
Route: sips:p1.atlanta.example.com;lr
Supported: timer
Session-Expires: 4000;refresher=uac
Max-Forwards: 70
To: Bob ;tag=9as888nd
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact:
Donovan & Rosenberg Standards Track [Page 24]
RFC 4028 Session Timer April 2005
This is forwarded through P1 to Bob. Bob generates a 200 OK, copying
the Session-Expires header field into the response. This is
forwarded through P1 and arrives at Alice. The response she receives
(message 21) might look like this:
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12
;received=192.0.2.1
Require: timer
Session-Expires: 4000;refresher=uac
To: Bob ;tag=9as888nd
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314162 UPDATE
Contact:
Shortly afterward, Alice's UA crashes. As a result, she never sends
a session refresh request. 3968 seconds later, Bob times out and
sends a BYE request (message 22). This is sent to P1. P1 attempts
to deliver it but fails (because Alice's UA has crashed). P1 then
returns a 408 (Request Timeout) to Bob.
14. Acknowledgements
The authors wish to thank Brett Tate for his contributions to this
work. Brian Rosen completed the editing of the document.
15. References
15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
Donovan & Rosenberg Standards Track [Page 25]
RFC 4028 Session Timer April 2005
15.2. Informative References
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
Authors' Addresses
Steve Donovan
Cisco Systems, Inc.
2200 E. President George Bush Turnpike
Richardson, Texas 75082
US
EMail: srd@cisco.com
Jonathan Rosenberg
Cisco Systems, Inc.
600 Lanidex Plaza
Parsippany, NJ 07054
US
EMail: jdrosen@cisco.com
Donovan & Rosenberg Standards Track [Page 26]
RFC 4028 Session Timer April 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
sexta-feira, 11 de maio de 2012
Session Expires
terça-feira, 8 de maio de 2012
ISDN Cause Codes
ISDN Cause Codes
Cause No. 0
This is usually given by the router when none of the other codes apply. This cause usually occurs in the same type of situations as cause 1, cause 88, and cause 100.
Cause No. l - Unallocated (unassigned) number.
This cause indicates that the destination requested by the calling user cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated).
What it usually means:
Cause No. 2 - No route to specified transit network (national use).
- The SPIDS may be incorrectly entered in the router or the Telco switch, giving a SPID failure in the router logs.
- The ISDN phone number being dialed by the router is invalid and the telco switch cannot locate the number to complete the call, as it is invalid.
- On long distance calls, the call cannot be properly routed to its destination.
This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network not serve the equipment which is sending this cause.
Cause No. 3 - No route to destination.
This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network dependent basis.
Cause No. 4 - send special information tone.
This cause indicates that the called party cannot be reached for reasons that are of a long term nature and that the special information tone should be returned to the calling party.
Cause No. 5 - misdialed trunk prefix (national use).
This cause indicates the erroneous inclusion of a trunk prefix in the called party number. This number is to sniped from the dialed number being sent to the network by the customer premises equipment.
Cause No. 6 - channel unacceptable.
This cause indicates that the channel most recently identified is not acceptable to the sending entity for use in this call.
Cause No. 7 - call awarded. being delivered in an established channel.
This cause indicates that the user has been awarded the incoming call and that the incoming call is being connected to a channel already established to that user for similar calls (e.g. packet-mode x.25 virtual calls).
Cause No. 8 - preemption.
This cause indicates the call is being preempted.
Cause No. 9 - preemption - circuit reserved for reuse.
This cause indicates that the call is being preempted and the circuit is reserved for reuse by the preempting exchange.
Cause No. 16 - normal call clearing.
This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared.
What it means:
This could be almost anything; it is the vaguest of the cause codes. The call comes down normally, but the reasons for it could be:
Cause No. 17 - user busy.
- Bad username or password
- Router's settings do not match what is expected by the remote end.
- Telephone line problems.
- Hung session on remote end.
This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.
What is means:
Calling end is busy.
Cause No. 18 - no user responding.
This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.
What it means:
The equipment on the other end does not answer the call. Usually this is a misconfiguration on the equipment being called.
Cause No. 19 - no answer from user (user alerted).
This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. Note - This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers.
Cause No. 20 - subscriber absent.
This cause value is used when a mobile station has logged off. Radio contact is not obtained with a mobile station or if a personal telecommunication user is temporarily not addressable at any user-network interface.
Cause No. 21 - call rejected.
This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.
What it means:
This is usually a telco issue. The call never reaches the final destination, which can be caused by a bad switch translation, or a misconfiguration on the equipment being called.
Cause No. 22 - number changed.
This cause is returned to a calling party when the called party number indicated by the calling party is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this cause, cause no. 1, unallocated (unassigned) number shall be used.
Cause No. 26 - non-selected user clearing.
This cause indicates that the user has not been awarded the incoming call.
Cause No. 27 - destination out of order.
This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signal message was unable to be delivered to the remote party; e.g., a physical layer or data link layer failure at the remote party or user equipment off-line.
Cause No. 28 - invalid number format (address incomplete).
This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete.
Cause No. 29 - facilities rejected.
This cause is returned when a supplementary service requested by the user cannot be provide by the network.
Cause No. 30 - response to STATUS INQUIRY.
This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS INQUIRY.
Cause No. 31 - normal. unspecified.
This cause is used to report a normal event only when no other cause in the normal class applies.
Cause No. 34 - no circuit/channel available.
This cause indicates that there is no appropriate circuit/channel presently available to handle the call.
What it means:
There is no place on the Public Telephone network to place the call; the call never gets to its destiation. This is usually a temporary problem.
Cause No. 35 - Call Queued.
Cause No. 38 - network out of order.
This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time e.g., immediately re-attempting the call is not likely to be successful.
Cause No. 39 - permanent frame mode connection out-of-service.
This cause is included in a STATUS message to indicate that a permanently established frame mode connection is out-of-service (e.g. due to equipment or section failure)
Cause No. 40 - permanent frame mode connection operational.
This cause is included in a STATUS message to indicate that a permanently established frame mode connection is operational and capable of carrying user information.
Cause No. 41 - temporary failure.
This cause indicates that the network is not functioning correctly and that the condition is no likely to last a long period of time; e.g., the user may wish to try another call attempt almost immediately.
What it means:
This means that there is a temporary failure at the physical layer on the ISDN network. If you remove the ISDN cable from the Netopia, you would see this. It's usually temporary.
Cause No. 42 - switching equipment congestion.
This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic.
What it means:
Just too much going on at this point on the ISDN network to get the call through to its destination.
Cause No. 43 - access information discarded.
This cause indicates that the network could not deliver access information to the remote user as requested. i.e., user-to-user information, low layer compatibility, high layer compatibility or sub-address as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic.
Cause No. 44 - requested circuit/channel not available.
This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface.
Cause No. 46 - precedence call blocked.
This cause indicates that there are no predictable circuits or that the called user is busy with a call of equal or higher preventable level.
Cause No. 47 - resource unavailable, unspecified.
This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies.
Cause No. 49 - Quality of Service not available.
This cause is used to report that the requested Quality of Service, as defined in Recommendation X.213. cannot be provided (e.g., throughput of transit delay cannot be supported).
Cause No. 50 - requested facility not subscribed.
This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated this cause but the user is not authorized to use.
What it means:
The switch looks at the number being dialed and thinks it is for another service rather than ISDN. If the phone number is put in the correct format, the call should be placed properly. There are no standards for this, all Telcos have their own system for programming the number formats that the switches will recognize. Some systems want to see 7 digits, some 10, and others 11.
Cause No. 52 - outgoing calls barred.
Cause No. 53 - outgoing calls barred within CUG.
This cause indicates that although the calling party is a member of the CUG for the outgoing CUG call. Outgoing calls are not allowed for this member of the CUG.
Cause No. 54 - incoming calls barred
Cause No. 55 - incoming calls barred within CUG.
This cause indicates that although the calling party is a member of the CUG for the incoming CUG call. Incoming calls are not allowed for this member of the CUG.
Cause No. 57 - bearer capability not authorized.
This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use.
Cause No. 58 - bearer capability not presently available.
This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time.
Cause No. 62 - inconsistency in outgoing information element.
This cause indicates an inconsistency in the designated outgoing access information and subscriber class.
Cause No. 63 - service or option not available. unspecified.
This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies.
Cause No. 65 - bearer capability not implemented.
This cause indicates that the equipment sending this cause does not support the bearer capability requested.
What it means:
Cause No. 66 - channel type not implemented.
- In most cases, the number being called is not an ISDN number but an analog destination.
- The equipment is dialing at a faster rate than the circuitry allows, for example, dialing at 64K when only 56K is supported.
This cause indicates that the equipment sending this cause does not support the channel type requested.
Cause No. 69 - requested facility not implemented.
This cause indicates that the equipment sending this cause does not support the requested supplementary services.
Cause No. 70 - only restricted digital information bearer capability is available.
This cause indicates that the calling party has requested an unrestricted bearer service but the equipment sending this cause only supports the restricted version of the requested bearer capability.
Cause No. 79 - service or option not implemented unspecified.
This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies.
Cause No. 81 - invalid call reference value.
This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the user-network interface.
Cause No. 82 - identified channel does not exist.
This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the interface for a call. For example, if a user has subscribed to those channels on a primary rate interface numbered from l to 12 and the user equipment or the network attempts to use channels 3 through 23, this cause is generated.
Cause No. 83 - a suspended call exists, but this call identify does not. This cause indicates that a call resume has been attempted with a call identity which differs from that in use for any presently suspended call(s).
Cause No. 84 - call identity in use.
This cause indicates that the network has received a call suspended request containing a call identity (including the null call identity) which is already in use for a suspended call within the domain of interfaces over which the call might be resumed.
Cause No. 85 - no call suspended.
This cause indicates that the network has received a call resume request containing a call identity information element which presently does not indicate any suspended call within the domain of interfaces over which calls may be resumed.
Cause No. 86 - call having the requested call identity has been cleared.
This cause indicates that the network has received a call resume request containing a call identity information element indicating a suspended call that has in the meantime been cleared while suspended (either by network time-out or by the remote user).
Cause No. 87 - user not a member of CUG.
This cause indicates that the called user for the incoming CUG call is not a member of the specified CUG or that the calling user is an ordinary subscriber calling a CUG subscriber.
Cause No. 88 - incompatible destination.
This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility. high layer compatibility or other compatibility attributes (e.g., data rate) which cannot be accommodated.
What it means:
Cause No. 90 - non-existent CUG.
- This usually means that the Number To Dial in the Connection Profile is in the wrong format. You may need to dial a 10 or 11 digit number, or dial a 9 in front of the number if it is a Centrex line.
- This problem may also give a Cause 111.
- Dialing at the wrong line speed can also give this Cause.
This cause indicates that the specified CUG does not exist.
Cause No. 91 - invalid transit network selection (national use).
This cause indicates that a transit network identification was received which is of an incorrect format as defined in Annex C/Q.931
Cause No. 95 - invalid message, unspecified.
This cause is used to report an invalid message event only when no other cause in the invalid message class applies.
Cause No. 96 - mandatory information element is missing.
This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before that message can be processed.
What it means:
This is rarely seen in North America but usually means that the number that is being dialed is in the wrong format, (similar to cause 88). Some part of the format being used is not understood by either the remote side equipment or the switching equipment between the source and destination of the call.
Cause No. 97 - message type non-existent or not implemented.
This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined of defined but not implemented by the equipment sending this cause.
Cause No. 98 - message not compatible with call state or message type non-existent.
This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the call state, or a STATUS message was received indicating an incompatible call state.
Cause No. 99 - Information element / parameter non-existent or not implemented.
This cause indicates that the equipment sending this cause has received a message which includes information element(s)/parameter(s) not recognized because the information element(s)/parameter name(s) are not defined or are defined but not implemented by the equipment sending the cause. This cause indicates that the information element(s)/parameter(s) were discarded. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message.
Cause No. 100 - Invalid information element contents.
This cause indicates that the equipment sending this cause has received and information element which it has implemented; however, one or more of the fields in the information element are coded in such a way which has not been implemented by the equipment sending this cause.
What it means:
Like cause 1 and cause 88, this usually indicates that the ISDN number being dialed is in a format that is not understood by the equipment processing the call. SPIDs will sometimes fail to initialize with a Cause 100, or a call will fail with this cause.
Cause No. 101 - message not compatible with call state.
This cause indicates that a message has been received which is incompatible with the call state.
Cause No. 102 - recovery on timer expiry.
This cause indicates that a procedure has been initiated by the expiration of a timer in association with error handling procedures.
What it means:
This is seen in situations where ACO (Alternate Call Offering) is being used. With this type of call pre-emption, the Telco switch operates a timer. For example, when an analog call is placed to a Netopia router that has two B Data Channels in place, the router relinquishes the second channel, but if it doesn't happen in the time allotted by the switch programming, the call will not ring through and will be discarded by the switch.
Cause No. 103 - parameter non-existent or not implemented - passed on (national use).
This cause indicates that the equipment sending this cause has received a message which includes parameters not recognized because the parameters are not defined or are defined but not implemented by the equipment sending this cause. The cause indicates that the parameter(s) were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates that the parameter(s) were passed unchanged.
Cause No. 110 - message with unrecognized parameter discarded.
This cause indicates that the equipment sending this cause has discarded a received message which includes a parameter that is not recognized.
Cause No. 111 - protocol error, unspecified.
This cause is used to report a protocol error event only when no other cause in the protocol error class applies.
Cause No. 127 - Intel-working, unspecified.
This cause indicates that an interworking call (usually a call to 5W56 service) has ended.
Notes about Cause Codes over 128
Cause code values of 128 and higher aren't sent over the network. A terminal displaying a value 128 or higher and claiming it is a cause code arguably has a bug or is implementing some proprietary diagnostic code (not necessarily bad). Some commendation has cause codes listed with numbers higher than 128, but at this time they are proprietary in nature.
The PRI equipment vendors are the most likely to use these codes as they have been using proprietary messages in the facilities data link for some time now (there is an as yet undefined area in the FDL which is big enough to carry small datagrams or messages). It is typically used to pass proprietary control or maintenance messages between multiplexers.
Retirado de: http://networking.ringofsaturn.com/Routers/isdncausecodes.php
Todos os créditos ao autor.
segunda-feira, 12 de março de 2012
SIP Timers
SIP timers settings
T1
Specifies the amount of time, in milliseconds, for a network round trip delay for timer T1 for the RFC 3261 specification. The value is used as a base for calculating some timers and is relevant for all types of transactions, such as client, server, invite, and non-invite transactions.
| Data type | Integer |
| Default | 500 |
T2
Specifies the maximum amount of time, in milliseconds, before retransmitting non-invite requests and invite responses for timer T2 for the RFC 3261 specification.
| Data type | Integer |
| Default | 4000 |
T4
Specifies the maximum amount of time, in milliseconds, for a message to remain in the network. This value is used as a base for calculating other timers for timer T4 for the RFC 3261 specification.
| Data type | Integer |
| Default | 5000 |
sexta-feira, 28 de outubro de 2011
TOS - Type of Service
TOS - Type of service é um campo do cabeçalho IP utilizado para definir o tipo de pacote a ser transportado. Seguem algumas configurações possíveis.
Veja a seguir os valores que podem ser usados no campo TOS:
Valor Descrição
0x08 Minimizar atraso
0x04 Maximizar rendimento
0x02 Maximizar confiabilidade
0x01 Minimizar custo monetário
0x00 Serviço normal
Veja a seguir os valores que podem ser usados no campo TOS:
Valor Descrição
0x08 Minimizar atraso
0x04 Maximizar rendimento
0x02 Maximizar confiabilidade
0x01 Minimizar custo monetário
0x00 Serviço normal
segunda-feira, 18 de julho de 2011
MOS - Mean Opinion Score
What is Mean Opinion Score?
In voice and video communication, quality usually dictates whether the experience is a good or bad one. Besides the qualitative description we hear, like 'quite good' or 'very bad', there is a numerical method of expressing voice and video quality. It is called Mean Opinion Score (MOS). MOS gives a numerical indication of the perceived quality of the media received after being transmitted and eventually compressed using codecs.
MOS is expressed in one number, from 1 to 5, 1 being the worst and 5 the best. MOS is quite subjective, as it is based figures that result from what is perceived by people during tests. However, there are software applications that measure MOS on networks, as we see below.
The Mean Opinion Score Values
Taken in whole numbers, the numbers are quite easy to grade.
5 - Perfect. Like face-to-face conversation or radio reception.
4 - Fair. Imperfections can be perceived, but sound still clear. This is (supposedly) the range for cell phones.
3 - Annoying.
2 - Very annoying. Nearly impossible to communicate.
1 - Impossible to communicate
The values do not need to be whole numbers. Certain thresholds and limits are often expressed in decimal values from this MOS spectrum. For instance, a value of 4.0 to 4.5 is referred to as toll-quality and causes complete satisfaction. This is the normal value of PSTN and many VoIP services aim at it, often with success. Values dropping below 3.5 are termed unacceptable by many users.
How Are MOS Tests Conducted?
A certain number of people are sat and are made to hear some audio. Each one of them gives a rating from within 1 to 5. Then an artihmetic mean (average) is calculated, giving the Mean Opinion Score. When conducting MOS test, there are certain phrases that are recommended to be used by the ITU-T. They are:
You will have to be very quiet.
There was nothing to be seen.
They worshipped wooden idols.
I want a minute with the inspector.
Did he need any money?
Factors Affecting Mean Opinion Score
MOS can simply be used to compare between VoIP services and providers. But more importantly, they are used to assess the work of codecs, which compress audio and video to save on bandwidth utilization but with a certain amount of drop in quality. MOS tests are then made for codecs in a certain environment.
There are however certain other factors that affect the quality of audio and video transferred, as mentioned in that article. These factors are not supposed to be accounted for in MOS values, so when determining the MOS for a certain codec, service or network, it is important that all the other factors are favorable to the maximum for a good quality, for MOS values are assumed to be obtained under ideal conditions.
Software Automated Mean Opinion Score Tests
Since the manual/human MOS tests are quite subjective and less than productive in many ways, there are nowadays a number of software tools that carry out automated MOS testing in a VoIP deployment. Although they lack the human touch, the good thing with these tests is that they take into account all the network dependency conditions that could influence voice quality. Some examples are AppareNet Voice, Brix VoIP Measurement Suite, NetAlly, PsyVoIP and VQmon/EP.
Text from voip.about.com, all rights to the author.
In voice and video communication, quality usually dictates whether the experience is a good or bad one. Besides the qualitative description we hear, like 'quite good' or 'very bad', there is a numerical method of expressing voice and video quality. It is called Mean Opinion Score (MOS). MOS gives a numerical indication of the perceived quality of the media received after being transmitted and eventually compressed using codecs.
MOS is expressed in one number, from 1 to 5, 1 being the worst and 5 the best. MOS is quite subjective, as it is based figures that result from what is perceived by people during tests. However, there are software applications that measure MOS on networks, as we see below.
The Mean Opinion Score Values
Taken in whole numbers, the numbers are quite easy to grade.
5 - Perfect. Like face-to-face conversation or radio reception.
4 - Fair. Imperfections can be perceived, but sound still clear. This is (supposedly) the range for cell phones.
3 - Annoying.
2 - Very annoying. Nearly impossible to communicate.
1 - Impossible to communicate
The values do not need to be whole numbers. Certain thresholds and limits are often expressed in decimal values from this MOS spectrum. For instance, a value of 4.0 to 4.5 is referred to as toll-quality and causes complete satisfaction. This is the normal value of PSTN and many VoIP services aim at it, often with success. Values dropping below 3.5 are termed unacceptable by many users.
How Are MOS Tests Conducted?
A certain number of people are sat and are made to hear some audio. Each one of them gives a rating from within 1 to 5. Then an artihmetic mean (average) is calculated, giving the Mean Opinion Score. When conducting MOS test, there are certain phrases that are recommended to be used by the ITU-T. They are:
You will have to be very quiet.
There was nothing to be seen.
They worshipped wooden idols.
I want a minute with the inspector.
Did he need any money?
Factors Affecting Mean Opinion Score
MOS can simply be used to compare between VoIP services and providers. But more importantly, they are used to assess the work of codecs, which compress audio and video to save on bandwidth utilization but with a certain amount of drop in quality. MOS tests are then made for codecs in a certain environment.
There are however certain other factors that affect the quality of audio and video transferred, as mentioned in that article. These factors are not supposed to be accounted for in MOS values, so when determining the MOS for a certain codec, service or network, it is important that all the other factors are favorable to the maximum for a good quality, for MOS values are assumed to be obtained under ideal conditions.
Software Automated Mean Opinion Score Tests
Since the manual/human MOS tests are quite subjective and less than productive in many ways, there are nowadays a number of software tools that carry out automated MOS testing in a VoIP deployment. Although they lack the human touch, the good thing with these tests is that they take into account all the network dependency conditions that could influence voice quality. Some examples are AppareNet Voice, Brix VoIP Measurement Suite, NetAlly, PsyVoIP and VQmon/EP.
Text from voip.about.com, all rights to the author.
quarta-feira, 27 de abril de 2011
List Of SIP response codes
SIP responses are the codes used by Session Initiation Protocol for communication. They complement the SIP Requests, which are used to initiate action such as a phone conversation. Note that the Reason Phrases of the responses listed below are only the recommended examples, and can be replaced with local equivalents without affecting the protocol.
Contents
* 1 1xx—Informational Responses
* 2 2xx—Successful Responses
* 3 3xx—Redirection Responses
* 4 4xx—Client Failure Responses
* 5 5xx—Server Failure Responses
* 6 6xx—Global Failure Responses
* 7 External links
1xx—Informational Responses
* 100 Trying
extended search being performed may take a significant time so a forking proxy must send a 100 Trying response
* 180 Ringing
* 181 Call Is Being Forwarded
* 182 Queued
* 183 Session Progress
2xx—Successful Responses
* 200 OK
* 202 accepted: It Indicates that the request has been understood but actually can't be processed
3xx—Redirection Responses
* 300 Multiple Choices
* 301 Moved Permanently
* 302 Moved Temporarily
* 305 Use Proxy
* 380 Alternative Service
4xx—Client Failure Responses
* 400 Bad Request
* 401 Unauthorized (Used only by registrars or user agents. Proxies should use proxy authorization 407)
* 402 Payment Required (Reserved for future use)
* 403 Forbidden
* 404 Not Found (User not found)
* 405 Method Not Allowed
* 406 Not Acceptable
* 407 Proxy Authentication Required
* 408 Request Timeout (Couldn't find the user in time)
* 409 Conflict
* 410 Gone (The user existed once, but is not available here any more.)
* 412 Conditional Request Failed
* 413 Request Entity Too Large
* 414 Request-URI Too Long
* 415 Unsupported Media Type
* 416 Unsupported URI Scheme
* 417 Unknown Resource-Priority
* 420 Bad Extension (Bad SIP Protocol Extension used, not understood by the server)
* 421 Extension Required
* 422 Session Interval Too Small
* 423 Interval Too Brief
* 424 Bad Location Information
* 428 Use Identity Header
* 429 Provide Referrer Identity
* 433 Anonymity Disallowed
* 436 Bad Identity-Info
* 437 Unsupported Certificate
* 438 Invalid Identity Header
* 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
* 491 Request Pending
* 493 Undecipherable (Could not decrypt S/MIME body part)
* 494 Security Agreement Required
5xx—Server Failure Responses
* 500 Server Internal Error
* 501 Not Implemented: The SIP request method is not implemented here
* 502 Bad Gateway
* 503 Service Unavailable
* 504 Server Time-out
* 505 Version Not Supported: The server does not support this version of the SIP protocol
* 513 Message Too Large
* 580 Precondition Failure
6xx—Global Failure Responses
* 600 Busy Everywhere
* 603 Decline
* 604 Does Not Exist Anywhere
* 606 Not Acceptable
From Wikipedia, the free encyclopedia
Contents
* 1 1xx—Informational Responses
* 2 2xx—Successful Responses
* 3 3xx—Redirection Responses
* 4 4xx—Client Failure Responses
* 5 5xx—Server Failure Responses
* 6 6xx—Global Failure Responses
* 7 External links
1xx—Informational Responses
* 100 Trying
extended search being performed may take a significant time so a forking proxy must send a 100 Trying response
* 180 Ringing
* 181 Call Is Being Forwarded
* 182 Queued
* 183 Session Progress
2xx—Successful Responses
* 200 OK
* 202 accepted: It Indicates that the request has been understood but actually can't be processed
3xx—Redirection Responses
* 300 Multiple Choices
* 301 Moved Permanently
* 302 Moved Temporarily
* 305 Use Proxy
* 380 Alternative Service
4xx—Client Failure Responses
* 400 Bad Request
* 401 Unauthorized (Used only by registrars or user agents. Proxies should use proxy authorization 407)
* 402 Payment Required (Reserved for future use)
* 403 Forbidden
* 404 Not Found (User not found)
* 405 Method Not Allowed
* 406 Not Acceptable
* 407 Proxy Authentication Required
* 408 Request Timeout (Couldn't find the user in time)
* 409 Conflict
* 410 Gone (The user existed once, but is not available here any more.)
* 412 Conditional Request Failed
* 413 Request Entity Too Large
* 414 Request-URI Too Long
* 415 Unsupported Media Type
* 416 Unsupported URI Scheme
* 417 Unknown Resource-Priority
* 420 Bad Extension (Bad SIP Protocol Extension used, not understood by the server)
* 421 Extension Required
* 422 Session Interval Too Small
* 423 Interval Too Brief
* 424 Bad Location Information
* 428 Use Identity Header
* 429 Provide Referrer Identity
* 433 Anonymity Disallowed
* 436 Bad Identity-Info
* 437 Unsupported Certificate
* 438 Invalid Identity Header
* 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
* 491 Request Pending
* 493 Undecipherable (Could not decrypt S/MIME body part)
* 494 Security Agreement Required
5xx—Server Failure Responses
* 500 Server Internal Error
* 501 Not Implemented: The SIP request method is not implemented here
* 502 Bad Gateway
* 503 Service Unavailable
* 504 Server Time-out
* 505 Version Not Supported: The server does not support this version of the SIP protocol
* 513 Message Too Large
* 580 Precondition Failure
6xx—Global Failure Responses
* 600 Busy Everywhere
* 603 Decline
* 604 Does Not Exist Anywhere
* 606 Not Acceptable
From Wikipedia, the free encyclopedia
quinta-feira, 17 de março de 2011
Assinar:
Postagens (Atom)