IP Telephony ETS: IP Telephony Requirements for Emergency Telecommunication Service (ETS)
What IP telephony must do so that emergency calls are marked and treated as such
Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, DOI 10.17487/RFC3690, February 2004, <https://www.rfc-editor.org/info/rfc3690>.
@misc{rfc3690,
series = {Request for Comments},
number = 3690,
howpublished = {RFC 3690},
publisher = {RFC Editor},
doi = {10.17487/RFC3690},
url = {https://www.rfc-editor.org/info/rfc3690},
author = {K. Carlberg and R. Atkinson},
title = {{IP Telephony Requirements for Emergency Telecommunication Service (ETS)}},
pagetotal = 7,
year = 2004,
month = feb,
} RFC text
Contents
Network Working Group K. Carlberg
Request for Comments: 3690 UCL
Category: Informational R. Atkinson
Extreme Networks
February 2004
IP Telephony Requirements for
Emergency Telecommunication Service (ETS)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document presents a list of requirements in support of Emergency
Telecommunications Service (ETS) within the context of IP telephony.
It is an extension to the general requirements presented in RFC 3689.
Solutions to these requirements are not presented in this document.
1. Introduction
Effective telecommunications capabilities can be imperative to
facilitate immediate recovery operations for serious disaster events,
such as, hurricanes, floods, earthquakes, and terrorist attacks.
Disasters can happen unexpectedly, at any time or place. Quick
response for recovery operations requires immediate access to any
public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet
access via online terminals, IP telephones, and wireless Personal
Digital Assistants (PDAs). The commercial telecommunications
infrastructure is rapidly evolving to Internet-based technology.
Therefore, the Internet community needs to consider how it can best
support emergency management and recovery operations.
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 [1].
1.1. Problem
Standards have been developed by other standards bodies concerning
emergency communications. As discussed in [3], some of these
standards, such as T1.631 [5], define specific indicators or labels
for emergency communications in Signaling System 7 (SS7) networks.
Certain requirements must be defined in order to achieve peering
across hybrid networks (networks that communicate between IP and
other types of networks, such as that realized by the Public Switched
Telephone Network) in order to achieve an interworking of services.
2. Scope
[3] has defined a set of general system requirements to support
Emergency Telecommunications Service (ETS). This document defines an
additional set of system requirements to achieve support for ETS
within the specific context of IP telephony (note that this document
views IP telephony within the context of an end-to-end application
layer service). Solutions to requirements are not defined. The
document does not specify protocol enhancements or specifications.
Note that [4], Requirements for Resource Priority Mechanisms for the
Session Initiation Protocol (SIP), is an RFC that shares some overlap
with this document. However, [4] only applies to SIP and is not
meant to be applied to a more general perspective of IP telephony as
it relates to ETS.
2.1. Out of Scope
An item that is not in scope of this document is mandating acceptance
and support of the requirements presented in this document. The IETF
does not mandate requirements or capabilities to independent networks
that comprise the Internet. As an example, Internet Service
Providers (ISP) may choose not to operate any telephony-related
gateways or services. The IETF cannot and does not mandate that an
ISP deploy either telephony-related gateways or telephony-related
services. There is an expectation that business contracts, for
example Service Level Agreements (SLA), will be used to satisfy those
following requirements that apply to service providers. Absence of
an SLA implies best effort service is provided.
It is assumed that some ISPs will choose to offer ETS services and
that other carriers will choose not to offer ETS services. These
requirements do not apply to ISPs that have chosen not to offer ETS
services.
3. IP Telephony Requirements
The requirements in this section relate only to Telephony Signaling
as used in Internet-based telephony services. They are an extension
to the general requirements specified in [3]. The following
requirements explicitly do not relate to IP-layer mechanisms, such as
Differentiated Services or Integrated Services.
1) Telephony signaling applications used with Internet-based
telephony MUST be able to carry labels.
2) The ability to carry labels MUST be extensible to support various
types and numbers of labels. A single binary value will not be
sufficient given the various labeling standards in existence
today.
3) Telephony signaling labels SHOULD have a mapping with the various
emergency related labels/markings used in other telephony based
networks, such as the Public Switched Telephone Network (PSTN).
This ensures that a telephone call placed over a hybrid
infrastructure (traditional PSTN over some portion(s) of the path,
Internet telephony over some other portion(s) of the path) can
carry the labels end-to-end with appropriate translation at
PSTN/Internet boundaries. Absence of a mapping means that the
signaling reverts to a default service (presumably one attributed
to the general public).
4) Application layer IP telephony capabilities MUST NOT preclude the
ability to do application layer accounting.
Accounting is a useful feature in support of billing and tracking
down abuse of service. If specific solutions or protocols in
support of ETS require accounting, then this will be articulated
in future document(s).
5) Application layer mechanisms in gateways and stateful proxies that
are specifically in place to recognize ETS type labels MUST be
able to support "best available" service (this will probably be
realized as better than best effort). These labels MAY exist in
the application layer headers of data (i.e., bearer) traffic or
signaling traffic used for call completion.
The support for best available service SHOULD focus on probability
of forwarding packets. Probability MAY reach 100% depending on
the local policy associated with the label. Local policy MUST
also be used to determine if better than best effort is to be
applied to a specific label (or related set of labels).
Additional comments on this topic are presented below in item 2 of
section 4.
The above paragraphs MUST be taken in their entirety. The ability
to support best available service does not mean that the
application layer mechanism is expected to be activated. Further,
we do not define the means by which best available service is
realized. Application layer mechanisms that do not recognize ETS
type labels are not subject to this requirement.
4. Issues
This section presents issues that arise in considering solutions for
the telephony requirements that have been defined for ETS. This
section does not specify solutions, nor is it to be confused with
requirements. Subsequent documents that articulate a more specific
set of requirements for a particular service may make a statement
about the following issues.
1) Alternate paths
Experience with The Government Emergency Telecommunications
Service (GETS) over the PSTN has shown the utility of alternate
paths to a destination to help facilitate emergency-related
communications. From the perspective of the Internet, this
utility may be difficult to achieve and have a more limited
benefit. Unlike the PSTN, which creates a fixed path during call
setup phase, the Internet uses dynamic routing for IP packets.
This dynamic routing capability automatically causes IP packets to
travel the best current path. The Internet network infrastructure
does not have the concept of a "call" or the concept of "call
setup", though IP telephony applications might have application
layer awareness of calls or the call setup concept.
2) Application of Best Available Service
In item 5 of section 3 above, we discuss the requirement of
supporting best available service. We note that in this document,
the scope of that support is constrained to the application layer
and flows that traverse that layer. This may involve direct
support for the flow containing the ETS type label, or may involve
indirect support (e.g., ETS labels in signaling messages that
cause an effect on corresponding data or bearer flows).
It is critical to understand that how the support for best
available service can be realized is outside the scope of this
document. In addition, the perceived effectiveness of a given
approach or implementation is also outside the scope of this
document.
5. Security
Only authorized users or operators SHOULD be able to create non-
ordinary Labels (i.e., labels that may alter the default best effort
service). Labels SHOULD be associated with mechanisms to provide
strong end-to-end integrity during their transmission through the
telephony systems. Finally, in cases where labels are expected to be
acted upon by operators, these operators SHOULD have the capability
of authenticating the label on a received message or transmission in
order to prevent theft of service and reduce risk of denial of
service (e.g., by unauthorized users consuming any limited
resources).
Security is also discussed in the general requirements of [3], which
applies to section 3 above.
6. References
6.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[3] Carlberg, K. and R. Atkinson, "General System Requirements for
Emergency Telecommunications Service", RFC 3689, February 2004.
[4] Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487, February
2003.
[5] ANSI, "Signaling System No. 7(SS7): High Probability of
Completion (HPC) Network Capability", ANSI T1.631, 1993.
7. Authors' Addresses
Ken Carlberg
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
EMail: k.carlberg@cs.ucl.ac.uk
Ran Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA
95051 USA
EMail: rja@extremenetworks.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1Why Emergency Service Needs Its Own Requirements
Effective telecommunications capabilities can be imperative for immediate recovery operations after serious disaster events such as hurricanes, floods, earthquakes and terrorist attacks. Disasters happen unexpectedly, at any time or place, and a quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. Those capabilities include the conventional telephone, cellular phones, and Internet access through online terminals, IP telephones and wireless Personal Digital Assistants. Because the commercial telecommunications infrastructure is rapidly moving to Internet-based technology, the Internet community needs to consider how it can best support emergency management and recovery operations.
Other standards bodies have worked on emergency communications. Some of those standards, such as T1.631, define specific indicators or labels for emergency communications in Signalling System 7 networks. Requirements have to be defined so that peering works across hybrid networks, networks that communicate between IP and other types of network such as the Public Switched Telephone Network, and so that the services interwork.
In the telephone network an emergency call is marked, and the marking is what makes the call get through and get treated properly. When a call travels over both networks, that marking has to survive the boundary, and the requirements for that are what this document lists.
§2Scope and What Is Left Out
RFC 3689 has defined a set of general system requirements to support Emergency Telecommunications Service. This document defines an additional set of system requirements for the specific context of IP telephony, viewing IP telephony as an end-to-end application layer service. Solutions to the requirements are not defined, and the document does not specify protocol enhancements or specifications.
The document notes that RFC 3487, Requirements for Resource Priority Mechanisms for the Session Initiation Protocol, shares some overlap with it, but that RFC 3487 applies only to SIP and is not meant to be applied to the more general question of IP telephony as it relates to emergency service.
One item is deliberately out of scope: mandating acceptance and support of these requirements. The IETF does not mandate requirements or capabilities on the independent networks that make up the Internet. An internet service provider may choose not to operate any telephony-related gateways or services, and the IETF cannot require one to deploy either. The expectation is that business contracts, for example service level agreements, will satisfy the requirements that apply to service providers, and that the absence of such an agreement implies best effort service. It is assumed that some providers will offer emergency service and others will not, and these requirements do not apply to those that have chosen not to offer it.
The document is a list of requirements, not a design. It is also explicit that nobody is forced to offer emergency calling over IP: a provider that does not offer it is not breaking any rule here.
§3The Five IP Telephony Requirements
The requirements relate only to telephony signalling as used in Internet-based telephony services, and they extend the general requirements of RFC 3689. They explicitly do not relate to IP layer mechanisms such as Differentiated Services or Integrated Services.
- Telephony signalling applications used with Internet-based telephony MUST be able to carry labels.
- The ability to carry labels MUST be extensible to support various types and numbers of labels. A single binary value will not be sufficient, given the various labelling standards in existence today.
- Telephony signalling labels SHOULD have a mapping with the emergency related labels and markings used in other telephony based networks, such as the Public Switched Telephone Network. This ensures that a call placed over a hybrid infrastructure, traditional PSTN over part of the path and Internet telephony over another part, can carry the labels end to end with translation at the boundaries. Absence of a mapping means the signalling reverts to a default service, presumably one attributed to the general public.
- Application layer IP telephony capabilities MUST NOT preclude the ability to do application layer accounting. Accounting is a useful feature in support of billing and tracking down abuse of service.
- Application layer mechanisms in gateways and stateful proxies that are specifically in place to recognise emergency type labels MUST be able to support best available service, which will probably be realized as better than best effort. These labels MAY exist in the application layer headers of data, that is bearer, traffic or in signalling traffic used for call completion. The support for best available service SHOULD focus on the probability of forwarding packets, which MAY reach 100 percent depending on the local policy associated with the label, and local policy MUST also be used to determine whether better than best effort is applied to a specific label or related set of labels.
The document is careful about how the fifth requirement is read. The paragraphs must be taken in their entirety. The ability to support best available service does not mean that the application layer mechanism is expected to be activated, the means by which best available service is realized are not defined, and application layer mechanisms that do not recognise emergency type labels are not subject to the requirement at all.
Five things are required of the signalling side of IP telephony: it must carry a label, the label must be able to hold many different things, it should correspond to the emergency markings used elsewhere, it must not stop the network from keeping billing records, and the equipment that recognises emergency labels must be able to treat those calls better than ordinary ones.
- Carry labelsTelephony signalling applications used with Internet-based telephony must be able to carry labels.
- Make labels extensibleThe ability to carry labels must be extensible to support various types and numbers of labels, since a single binary value will not be sufficient.
- Map to other networksLabels should have a mapping with the emergency labels used in other telephony networks, so a call over a hybrid path keeps them end to end.
- Keep accounting possibleApplication layer capabilities must not preclude application layer accounting, which supports billing and tracking down abuse of service.
- Support best available serviceMechanisms that recognise emergency labels must be able to support best available service, with local policy deciding whether it applies.
§4Issues: Alternate Paths and Best Available Service
The issues section raises matters that arise when looking for solutions to the requirements, and it is not to be confused with requirements.
On alternate paths, experience with the Government Emergency Telecommunications Service over the PSTN has shown the utility of alternate paths to a destination for emergency communications. From the point of view of the Internet, this utility may be harder to achieve and more limited. Unlike the PSTN, which creates a fixed path during call setup, the Internet uses dynamic routing for IP packets, which automatically sends packets along the best current path. The Internet network infrastructure has no concept of a call or of call setup, although IP telephony applications may have application layer awareness of calls.
On the application of best available service, the scope of support is constrained to the application layer and the flows that traverse it. This may involve direct support for the flow carrying the emergency label, or indirect support, for example emergency labels in signalling messages that cause an effect on the corresponding data or bearer flows. How the support is realized, and how effective a given approach or implementation turns out to be, are both outside the scope of the document.
Two problems are left open. The telephone network can set up a second route to the emergency centre, and the Internet cannot easily do that. And the document says how much better than ordinary service an emergency call should get, without saying how to arrange it.
§5Security
Only authorised users or operators SHOULD be able to create non-ordinary labels, that is, labels that may alter the default best effort service. Labels SHOULD be associated with mechanisms that provide strong end-to-end integrity during their transmission through the telephony systems. Where labels are expected to be acted upon by operators, those operators SHOULD have the capability of authenticating the label on a received message or transmission, in order to prevent theft of service and to reduce the risk of denial of service, for example by unauthorised users consuming limited resources.
Security is also discussed in the general requirements of RFC 3689, which apply to the requirements in section 3.
Because a label can buy a call better treatment, only authorised people should be able to create one, the label should be protected against alteration while it travels, and the operator should be able to check who created it.