On 11/01/2010 05:24 PM, Vic Jolin wrote:
That's interesting, can you tell me more about that draft?
Hello
I have attached the draft.
There are 2 setups for using end-to-end OPTIONS ping
1. In Dialog... if one of the endpoints is a B2BUA, it can send at
specific interval in-dialog OPTIONS ping (OPTIONS request, increasing
cseq) to the other endpoint. Most well-behaved UAS will respond with a
481 if the dialog not longer exists as per RFC 3261 .
"The response to an OPTIONS is
constructed using the standard rules for a SIP response as discussed
in Section 8.2.6. The response code chosen MUST be the same that
would have been chosen had the request been an INVITE.
"
Other error conditions are on a 408 , 404 etc (as any in-dialog request
is not guaranteed to succeed).
This is already used some production environments.
2. Out of dialog. A proxy keeps sending OPTIONS request (no dialog
involved here) to one of the UA as long as one of these 2 conditions exist:
a. the dialog has not ended via a method specific mean (BYE for INVITE etc)
b. a 408 (or other error codes) was received when generating a BYE.
These where the big two points of the draft.
Marius
On Mon, Nov 1, 2010 at 11:18 PM, marius zbihlei
<marius.zbih...@1and1.ro <mailto:marius.zbih...@1and1.ro>> wrote:
On 11/01/2010 05:13 PM, Vic Jolin wrote:
Hi,
Just want to ask what is the best way to check if calls are
still active especially when we are not handling media?
Thanks
Hello
There is SST (Sip Session Timers RFC 4028), which is implemented
in the SST module, but at least 1 UA must know the extension. Also
I have been working on a IETF draft to use end-to-end OPTIONS
ping to determine the operational status of a UA.(it works well
with B2BUA, relatively well with stateful proxies). If you are
interested I can talk more about the draft and how I propose using
OPTIONS requests for this.(no changes on UAs are necessary)
Marius.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Network Working Group M. Zbihlei
Internet-Draft 1and1 Internet AG
Expires: February 2, 2011 August 2010
Draft-mzbihlei-end-to-end-OPTIONS-ping-01
Abstract
For VoIP providers, a common problem is related with finding the
state of a dialog in certain error conditions that are caused by
network problems, User Agent(UA) crashes etc. This document
describes a procedure for using the Session Initiation Protocol (SIP)
OPTIONS method in order to allow a SIP entity to discover the status
of a UA and decide the state of the dialog.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 2, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zbihlei Expires February 2, 2011 [Page 1]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
1. Introduction
Given the multitude of parties involved in a SIP Call, a common
problem for providers is determining the status of the caller/callee
during a dialog. There are methods for making SIP enabled networks
robust and efficient by providing redundancy at hardware or service
level, but this is not the case for most UAs. Hardware problems,
software crashes, power failures are factors in the way a UA behaves,
affecting billing, QoS etc. These problems have a far greater impact
in the case the error condition happens in-dialog, in most cases the
dialog state on the proxy being affected (BYEs are not sent,
responded etc).
Zbihlei Expires February 2, 2011 [Page 2]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119
[refs.RFC2119]
Zbihlei Expires February 2, 2011 [Page 3]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
3. Required Support
Transmission of the OPTIONS message between any two entities is
optional. The SIP specification requires that all user agents
support the OPTIONS message. To comply with procedures described in
this document, all SIP entities, including SIP user agents and proxy
servers, MUST support the OPTIONS message when received either
outside or inside of a dialog in accordance with this memo.
Zbihlei Expires February 2, 2011 [Page 4]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
4. Problem Statement
It is often necessary(for billing purposes) to query the status of a
User Agent. This can be done by an endpoint of the dialog (an User
Agent or a B2BUA), or by a entity like a stateful proxy(that is, to
servers that maintain the state of calls and dialogs established
through them) found in the path of the communication.
This memo proposes the use of OPTIONS (called an OPTIONS ping) to
determine the operational status of an UA and provides a mechanism to
decide if a session has ended without receiving a BYE (or other
request specific mechanism of ending sessions).
This memo does not replace the use of OPTIONS as describe in RFC 3261
[refs.RFC3261], but does further expand on use of OPTIONS to discover
the status of a UA, as per RFC 3261 Section 11.2. This memo does no
impose any new requirements on the underlying transport protocol.
Zbihlei Expires February 2, 2011 [Page 5]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
5. Procedure for Using OPTIONS to Query for Operational Status
This memo relies on the fact that each SIP entity must respond to a
OPTIONS request. To adhere to this specification, an entity present
MUST also transmit OPTIONS messages as described below.
The Section 5.1 and Section 5.2 sections will describe two methods of
using OPTIONS ping available to SIP entities to determine the status
of a UA.
5.1. Using Out-of-Dialog (OOD) OPTIONS requests
5.1.1. Overview
A stateful proxy or a B2BUA that keeps track of SIP dialogs (as
defined in RFC 3261 Section 12), wants to have the capability to
decide at any time the state of a session. In normal usage, session
are ended by sending a method specific request, most of the times a
BYE request(only method as per RFC 3261).
In an error case that affects a UA, like hardware or software
failure, network errors, power failures, a BYE might never be
generated, and thus the dialog is accounted by the proxy for a longer
time than necessary, resulting in incorrect billing, resource
exhaustion and other possible problems.
When initiating a session(by receiving a 2xx for an INVITE request),
a SIP entity adhering to this memo will query the UA periodically
regarding its status. This is done by generating, at a certain
interval, an OPTIONS requests and waiting for a suitable answer. For
a proxy to be able to send the OPTIONS request, it MUST be stateful
and MUST perform record-routing(so it keeps itself in the path of the
sequential dialog requests).
5.1.2. Generating and Transmitting OPTIONS requests
The OPTIONS requests are generated after a session is established.
The proxy keeps generating OPTIONS requests on a specific interval,
until one the following conditions is true:
o the session has ended through normal means (e.g. A BYE was
received)
o a OPTIONS request is not answered in a timely manner, or a status
code indicating an error has been received (described below)
The OPTIONS request is generated accordingly to RFC 3261 and has the
following particularities:
Zbihlei Expires February 2, 2011 [Page 6]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
o it MUST not have a To-tag (this is an OOD request)
o it SHOULD not have any Accept:, Require:, or Supported: header
fields.
5.1.3. Handling of response status codes
As per RFC 3261 section 12.2, an OPTIONS response code MUST be the
same that would have been chosen had the request been an INVITE.
Response status codes that mark error conditions:
o 404(User not Found), 408(Timeout), 410(Gone), 416(Unsupported URI
Scheme), 485(Ambiguous), 502(Bad Gateway), 604(Does not exist
anywhere)
Response status codes that mark normal conditions:
o 200, 486(Busy Here), other status codes that do not mark error
conditions.
5.1.4. Proxy behavior
When a response to an generated OPTIONS request has a status that
marks an error as described in Section 5.1.3, the proxy MAY remove
associated call state, and MAY free any resources associated with the
call.
5.1.5. Deployment Model
A Home Proxy is defined as a proxy serving as the terminal point for
routing an address-of-record. Intermediate proxies are defined as
proxies in the routing path that are not Home proxies. It is useful
to set up OOD OPTIONS ping on the Home Proxy for a specific user.
This will ensure that only one Proxy handles the OPTIONS ping
transmission for the User Agent.
The Proxy will use the same method for sending OPTIONS ping to the
User Agent as taken when routing the original request. The method
can be either directly, as that proxy knows the Address Of Record
binding and can send it to the specific SIP URI(Contact), or by means
of RFC 3327 [refs.RFC3227] which specifies a Path that all requests
for that specific user must take. This will ensure that the OPTIONS
request will follow the same routing path downstream as the request
which created the dialog. Any error code, as described in
Section 5.1.3, received during the OPTIONS request processing will
mean that the dialog state might not be consistent.
Zbihlei Expires February 2, 2011 [Page 7]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
5.2. Using In-Dialog OPTIONS requests
5.2.1. Overview
As per RFC 3261 Section 11.2 "The response to an OPTIONS is
constructed using the standard rules for a SIP response as discussed
in Section 8.2.6. The response code chosen MUST be the same that
would have been chosen had the request been an INVITE.". This means,
that a in-dialog OPTIONS request generated bye the one of the UAs,
SHOULD be answered with a 481 (Call does not exit) if the other UA
has no state indicating the dialog is still valid.(the same as a re-
INVITE in a dialog that does not exist).
For simplicity's sake, this section of the memo will only consider
OPTIONS request generated by the UA that initiated the dialog(this
might be a B2BUA)
5.2.2. Generating and Transmitting OPTIONS requests
The OPTIONS requests are generated when a dialog is established. The
UAC keeps generating OPTIONS requests on a specific interval, until
one the following conditions is true: * the dialog has ended through
normal means (e.g. A BYE was received) * a OPTIONS request is not
answered in a timely manner, or a status code indicating an error has
been received (described below)
The OPTIONS request are sent in-dialog and they follow the rules
described in RFC 3261 Section 12.2.1.
5.2.3. Handling of response status codes
Response status codes that mark error conditions:
o 404(User not Found), 408(Timeout), 410(Gone), 416(Unsupported URI
Scheme), 485(Ambiguous), 502(Bad Gateway), 604(Does not exist
anywhere), 481(Call does not exit)
Response status codes that mark normal conditions:
o 200, 486(Busy Here), other status codes that do not mark error
conditions.
As opposed to out-of-dialog OPTIONS ping, there is one added error
code, namely 481.
If the OPTIONS ping transaction times out or generates an error
response as described above, then the UAC sends a BYE request as per
Section12.2.1.2 of RFC 3261 [2]. If the OPTIONS request does not
Zbihlei Expires February 2, 2011 [Page 8]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
generate a 2xx response, the UAC SHOULD follow the rules specific to
that response code and retry if possible. For example, if receiving
a 500 or a unknown 5xx reply which contains Retry-After header field
value, the server thinks the condition is temporary, and the request
can be retried after the indicated interval. If the response does
not contain a Retry-After header field value, the UA may decide to
retry after an specific interval.
5.2.4. UAC behavior
In concordance with RFC 3261, a 408 or a 481 received as an answer to
an OPTIONS ping will not cause the dialog to be closed on the UAC,
but instead a BYE MUST be sent (or a method specific request), thus
allowing downstream entities to update their session information.
5.2.5. Deployment models
The recommended usage for In-Dialog OPTIONS ping as described in this
draft is at a B2BUA/SBC level. These SIP entities, part of a SIP
enabled network, play to part of either UAC or UAS in SIP Dialogs.
Zbihlei Expires February 2, 2011 [Page 9]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
6. Frequency of Message Transmission
Any two entities that communicate with each other on a regular basis
MAY be configured to transmit an OPTIONS message from time to time as
provisioned by the network administrator. The frequency with which
an OPTIONS message is transmitted is outside the scope of this
document. Having said that, the frequency with which OPTIONS
messages are transmitted SHOULD NOT place an undue burden on SIP
entities.
The minimum value for the interval is the transaction time-out
interval (defined as 64*T1), as no new OPTIONS transaction should be
created before the previous one was either answered or timed-out.
Zbihlei Expires February 2, 2011 [Page 10]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
7. Security Considerations
All security considerations applicable to RFC 3261 apply to this RFC.
Since an OPTIONS message transmitted outside of a dialog might be
used to probe the network for active SIP user agents or proxy servers
in preparation for an attack, network administrators SHOULD consider
methods that would prevent the reception of OPTIONS messages from
hosts or networks that are not trusted.
Zbihlei Expires February 2, 2011 [Page 11]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
8. IANA Considerations
Zbihlei Expires February 2, 2011 [Page 12]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
9. Acknowledgments
Zbihlei Expires February 2, 2011 [Page 13]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
10. References
[refs.RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[refs.RFC3261]
Rosenberg, R., "SIP: Session Initiation Protocol",
June 2002.
[refs.RFC3227]
Willis, D., "Session Initiation Protocol (SIP) Extension
Header Field for Registering Non-Adjacent Contacts",
December 2002.
Zbihlei Expires February 2, 2011 [Page 14]
Internet-Draft End-to-end SIP OPTIONS Ping August 2010
Author's Address
Marius Zbihlei
1and1 Internet AG
Zbihlei Expires February 2, 2011 [Page 15]
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
