Network Working Group F. Miller
Internet-Draft Cornfed Systems, LLC
Expires: August 5, 2006 February 2006
The SIP PING Method
draft-fwmiller-ping-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) has the potential for long
periods of time to elapse when no signaling traffic is sent between a
User Agent Client (UAC) and a User Agent Server (UAS). There are
situations when it is advantageous to have some signaling traffic
flow periodically between these endpoints or to have a quick,
lightweight check whether a UAS is alive. The PING method is
proposed that can be used for these purposes.
Miller Expires August 5, 2006 [Page 1]
Internet-Draft ping February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. PING Method . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Header Field Support for PING Method . . . . . . . . . . . 4
2.2. Response to the PING Method . . . . . . . . . . . . . . . 6
2.3. Message Body Inclusion . . . . . . . . . . . . . . . . . . 6
2.4. User Agent Behavior . . . . . . . . . . . . . . . . . . . 6
2.5. Behavior of SIP Proxy and Redirect Servers . . . . . . . . 7
2.5.1. Proxy Server . . . . . . . . . . . . . . . . . . . . . 7
2.5.2. Forking Proxy Server . . . . . . . . . . . . . . . . . 7
2.5.3. Redirection Server . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Miller Expires August 5, 2006 [Page 2]
Internet-Draft ping February 2006
1. Introduction
Two SIP entities pass signaling traffic between them as required to
support SIP-based services. There can be long periods of time either
when session is established or when no session exists when no traffic
is flowing between the endpoints. There are situations where some
signaling traffic should be sent between the UAC and UAS. For
example, if one of the endpoints is behind a Network Address
Translation (NAT), signaling traffic may be needed to keep the NAT
port bindings alive. The PING method is intended to confirm that the
endpoints are alive and verify that a signaling path is still valid.
Miller Expires August 5, 2006 [Page 3]
Internet-Draft ping February 2006
2. PING Method
The PING method is used to determine if a UAS is alive and to
validate a signaling path. The PING method is not used to change the
state of SIP calls, nor does it change the state of sessions
initiated by SIP. Rather, it provides an indication to both ends of
a session that signaling messages can still flow between them.
A PING request may be sent at any time. PINGs may be sent
periodically to serve as a heartbeat. A UAC MUST NOT have more than
one outstanding PING transaction in existence at any time with a
specific UAS.
The only interval specified in this standard is that subsequent PING
requests MUST be sent with at least a minimum of 500 milliseconds
between them.
A PING request is routed the same way any other request is routed.
This can be either direct signaling between the UAC and UAS or a
signaling path involving SIP servers that potentially add themselves
to the Record-Route headers.
PING requests are sent unreliably. This means that a UAC sends a
single PING request to an UAS, and waits for a response. If no
response arrives before the expiration interval, the transaction is
terminated and the UAC is notified that not response was received.
It is up to the UAC to decide whether another PING is sent. If it
is, the new PING request represents a new PING transaction.
2.1. Header Field Support for PING Method
The PING request does not carry any information other than the intent
to check for the liveness of the UAS and the signaling path validity.
As such, only a few headers are used in both the PING request and its
associated response.
Header Where PING
------ ----- ----
Accept - -
Accept-Encoding - -
Accept-Language - -
Alert-Info - -
Allow - -
Authentication-Info - -
Authorization - -
Call-ID R m
Call-ID 200 m
Call-Info - -
Miller Expires August 5, 2006 [Page 4]
Internet-Draft ping February 2006
Contact - -
Content-Disposition - -
Content-Encoding - -
Content-Language - -
Content-Length R t
Content-Type - -
CSeq R m
CSeq 200 m
Date - -
Error-Info - -
Expires - -
From R m
From 200 m
In-Reply-To - -
Max-Forwards R m
Max-Forwards 200 m
Min-Expires - -
MIME-Version - -
Organization - -
Priority - -
Proxy-Authenticate - -
Proxy-Authorization - -
Proxy-Require - -
Record-Route R o
Record-Route 200 o
Reply-To - -
Require - -
Retry-After - -
Route R c
Route 200 c
Server - -
Subject - -
Supported - -
Timestamp - -
To R m
To 200 m
Unsupported - -
User-Agent R o
User-Agent 200 o
Via R m
Via 200 m
Warning - -
WWW-Authenticate - -
If a Content-Length field is included in the PING request, it MUST be
set to zero (0).
The intent is to provide as simple a message as possible to allow for
Miller Expires August 5, 2006 [Page 5]
Internet-Draft ping February 2006
implementations (particularly for servers) to optimize PING message
processing.
2.2. Response to the PING Method
A UAC formats a PING request as desired and sends it to the UAS. The
request is sent using the same routing rules by which an OPTIONS non-
INVITE transaction would be sent. The request is sent unreliably,
i.e. it is not retransmitted. The UAC waits 5 seconds for a
response. If a response is received or the UAC times out waiting for
a response, the PING transaction is considered terminated and the UAC
is notified of the outcome.
UAC UAS
| |
| PING |
|--------->|
| |
| 200 OK |
|<---------|
| |
There is only one defined response to a PING messages. This means
that a UAS that receives, recognizes, and supports the PING method
MUST only send one possible response back to the UAC.
The defined response is a 200 OK response. A UAS that supports
reception of the PING method MUST respond immediately with a 200 OK
message when it receives a PING request.
If a UAS that does not support the PING method receives a PING
request, it will generate other responses, e.g. a 501 Not Implemented
per [1]. A UAC SHOULD accept any response other than a 1xx
provisional response or a 3xx redirection. If a response other than
a 1xx or a 3xx is received, the UAC SHOULD assume that the UAS does
not recognize or support the PING method but the UAC SHOULD accept
the response as if it were a 200 OK response. A UAC receiving a 1xx
or 3xx response SHOULD drop the response as if it were never
received.
2.3. Message Body Inclusion
A PING request MUST NOT contain a message body.
2.4. User Agent Behavior
Unless otherwise stated, the protocol rules for the PING request
governing the usage of tags, Route, and Record-Route, retransmission
Miller Expires August 5, 2006 [Page 6]
Internet-Draft ping February 2006
and reliability, CSeq incrementing and message formatting follow
those in [1] as defined for the OPTIONS request.
A PING request MAY NOT be canceled.
2.5. Behavior of SIP Proxy and Redirect Servers
2.5.1. Proxy Server
Unless stated otherwise, the protocol rules for the PING request at a
proxy are identical to those for a OPTIONS request as specified in
[1].
2.5.2. Forking Proxy Server
Unless stated otherwise, the protocol rules for the PING request at a
proxy are identical to those for a OPTIONS request as specified in
[1].
2.5.3. Redirection Server
Unless stated otherwise, the protocol rules for the PING request at a
proxy are identical to those for a OPTIONS request as specified in
[1].
Miller Expires August 5, 2006 [Page 7]
Internet-Draft ping February 2006
3. Security Considerations
The only security consideration is that of a Denial of Service (DoS).
A "PING Storm" DoS attack can be launched at a UAS if PING requests
are sent at closer intervals than 500 milliseconds. Even 500
milliseconds can be considered tight. It is RECOMMENDED that PING
request intervals be at least several seconds if possible.
4. References
[1] 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.
Miller Expires August 5, 2006 [Page 8]
Internet-Draft ping February 2006
Author's Address
Frank W. Miller
Cornfed Systems, LLC
103 Overhill Road
Baltimore, MD 21210
US
Phone: +1 410 404 8790
Email: fwmiller@cornfed.com
URI: http://www.cornfed.com/
Miller Expires August 5, 2006 [Page 9]
Internet-Draft ping February 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Miller Expires August 5, 2006 [Page 10]