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]