Internet DRAFT - draft-fwmiller-ping
draft-fwmiller-ping
Network Working Group F. Miller
Internet-Draft Cornfed Systems, LLC
Expires: November 16, 2006 May 15, 2006
The SIP PING Method
draft-fwmiller-ping-03
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 November 16, 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 may be necessary for some signaling traffic to
flow periodically between these endpoints or to have a quick,
lightweight check for whether a UAS is alive. The PING method is
proposed that can be used for these purposes.
Miller Expires November 16, 2006 [Page 1]
Internet-Draft ping May 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 November 16, 2006 [Page 2]
Internet-Draft ping May 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 during these long intervals between
the UAC and UAS. For example, if one of the endpoints is behind a
Network Address Translation (NAT), signaling traffic may be used 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 November 16, 2006 [Page 3]
Internet-Draft ping May 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. A UAC MUST space PING transactions with the same UAS
at least 500 milliseconds apart.
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. The sending of a PING request initiates
a nominal non-INVITE transaction as specified in Section 17.1.2 of
[1].
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 - -
Contact - -
Content-Disposition - -
Content-Encoding - -
Content-Language - -
Content-Length R t
Content-Type - -
CSeq R m
CSeq 200 m
Miller Expires November 16, 2006 [Page 4]
Internet-Draft ping May 2006
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
implementations (particularly for servers) to optimize PING message
processing.
Miller Expires November 16, 2006 [Page 5]
Internet-Draft ping May 2006
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 retransmission and routing rules by
which an OPTIONS non-INVITE transaction would be sent.
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
and reliability, CSeq incrementing and message formatting follow
those in [1] as defined for the OPTIONS request.
An implementation may want to optimize the processing of received
PING requests. One potential implementation optimization is to
recognize the PING method on the request line by scanning the first
four characters of a incoming request for the PING method name.
Miller Expires November 16, 2006 [Page 6]
Internet-Draft ping May 2006
Implementations may then initiate expedited processing of the request
in order to return a 200 OK response as quickly as possible. For
example, an implementation may simply copy the To, From, Via,
Call-ID, and CSeq headers from the request into the response.
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 November 16, 2006 [Page 7]
Internet-Draft ping May 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 November 16, 2006 [Page 8]
Internet-Draft ping May 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 November 16, 2006 [Page 9]
Internet-Draft ping May 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 November 16, 2006 [Page 10]
