Internet DRAFT - draft-polk-ecrit-lost-server-uri
draft-polk-ecrit-lost-server-uri
Network Working Group James Polk
Internet-Draft Cisco Systems
Expires: December 19th, 2006 June 19th, 2006
Learning the Initial Location-to-Service Translation (LoST)
Uniform Resource Identifier (URI) During Session Initiation
Protocol (SIP) Registration
draft-polk-ecrit-lost-server-uri-00
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 December 19th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A Location-to-Service Translation protocol (LoST) Server is used to
resolve or map a given location with an appropriate Public Safety
Answering Point (PSAP) Uniform Resource Identifier (URI) for that
location. This query is conceivably performed on two occasions:
prior to making an emergency call, and during an emergency call.
This document specifies a new Session Initiation Protocol (SIP)
header, returned in a SIP Registration transaction, indicating to a
SIP user agent the appropriate LoST Server's URI to send this query
to.
Polk Expires December, 2006 [Page 1]
Internet-Draft Learning the Backup LoST URI in SIP June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . 3
2. Basic Overview of Learning LoST Server URI . . . . . . . . . 3
3. New LoST-Server-URI Header in SIP . . . . . . . . . . . . . . 4
4. New LoST-Server-URI Option-Tag . . . . . . . . . . . . . . . 4
5. Rules of the LoST Server URI Extension in SIP . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1 Normative References . . . . . . . . . . . . . . . . . . 6
9.2 Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . 7
1. Introduction
The Location-to-Service Translation (LoST) protocol [ID-LOST] is the
resolution protocol tasked with determining the appropriate PSAP
SIP(S)-URI from a given location value representing where a phone is
located. A SIP user agent (UA) can learn the URI of a LoST server
to query through one or more of a least three ways:
o Through manual configuration
o During boot time through a device configuration protocol such as
DHCP (or LLDP-MED)
o During SIP Registration
It is envisioned that a Voice Service Provider (VSP) will want or be
required, perhaps by law, to control the actions taken when one of
its (SIP) registered phones places an emergency call. Of the three
choices listed, only the third choice: during SIP/device
Registration involves the VSP; therefore this is the focus of this
document.
This document specifies a new SIP header to allow a SIP user agent
to learn the appropriate LoST Server URI for resolving where to send
a LoST Query seeking an appropriate Public Safety Answering Point
(PSAP) SIP(S)-URI. This header is used during the SIP Registration
transaction, defined in [RFC3261].
It is conceivable that this extension could be applied to/utilized
in a SUBSCRIBE/NOTIFY pair of transactions, but that is not detailed
here.
Polk Expires December, 2006 [Page 2]
Internet-Draft Learning the Backup LoST URI in SIP June 2006
1.1 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 [RFC2119].
2. Basic Overview of Learning LoST Server URI
As scoped in [ID-ECRIT-FW], once a SIP device boots, communicates
with a configuration server to learn its IP address, default
gateway, and other aspects to communicate, including learning its
location, likely from [RFC3825] or [ID-CIVIC], this device will
register with a Voice Service Provider. This last part is a SIP
REGISTER transaction. SIP REGISTER is RECOMMENDED to be transmitted
using TLS for confidentiality and integrity in [RFC3261]. Location
can be conveyed by-reference, meaning in a URI in a header of a SIP
message, or by-value, meaning the location itself is contained
within the SIP message in the form of a Presence Information Date
Format - Location Object (PIDF-LO) as defined in [RFC4119]. SIP
location conveyance is specified in [ID-SIP-LOC]. That document
specifies how a location can be included in a SIP REGISTER message.
That function is necessary for this extension. In order for a UA
to learn a LoST URI to query for a PSAP SIP(S)-URI, the UA will
follow this basic message flow:
UA Alice SIP Registrar
| [M1] REGISTER (w/ Location) |
|---------------------------------------->|
| [M2] Response (w/LoST Server URI) |
|<----------------------------------------|
| |
Figure 1. Learning a LoST Server URI Through SIP Registration
In message [M1], the SIP REGISTER message, Alice would include a new
LoST-Server-URI option tag in either a Supported or Require header,
and include her location by-reference in a Location header, or
by-value in a PIDF-LO message body (part).
The VSP's Registrar server would receive this request message.
During processing this message, the Registrar would understand that
Alice either wants or requires a LoST Server URI be returned in a
successful response back. Having Alice's location is a MUST. The
200 OK response message would contain a LoST-Server-URI header with
the URI of the LoST server to be queried by Alice to learn her PSAP
SIP(S)-URI.
This SIP(S)-URI is meant to be used as a backup URI to the
appropriate PSAP for Alice's given location at registration time.
Polk Expires December, 2006 [Page 3]
Internet-Draft Learning the Backup LoST URI in SIP June 2006
[ID-LOST] and [ID-ECRIT-FW] specify how this PSAP URI is a fallback,
to be used if the active mapping of a location to a PSAP-URI fails
during the emergency call.
More than one URI MAY be included in this new header. Each is to be
considered equal in importance. Two URIs pointing at the same LoST
server defeats the purpose of a UA being able to contact a secondary
server if one is unreachable, for whatever reason.
3. New LoST-Server-URI Header in SIP
The new "LoST-Server-URI" header has the following BNF syntax:
LoST-Server-URI = "LoST-Server-URI" HCOLON (LostServerURI
*(COMMA LostServerURI))
LostServerURI = SIP-URI / SIPS-URI / absoluteURI
SIP-URI and SIPS-URI are defined in RFC 3261 [RFC3261].
The following table extends the values in Table 2&3 of RFC3261
[RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
LoST-Server-URI r r - - - - o - -
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
LoST-Server-URI r r - - - - - - -
The LoST-Server-URI header MAY be read by a proxy in transit if
present in a REGISTER request message. A proxy MUST NOT add the
LoST-Server-URI header in transit if one is not present.
More than one LoST-Server-URI header or header value MAY be in a
message. Each is to be considered of equal importance, and MUST NOT
be pointing at the same server. This creates multi-server
redundancy in case one LoST server is unreachable, the secondary URI
does not attempt to contact that same (unreachable) server.
4. New LoST-Server-URI Option-Tag
This extension creates a new option tag: lost-server-uri.
This option tag is to be used in SIP headers such as Supported,
Require and Unsupported.
This option tag MUST NOT be used in the Proxy-Require header, as the
purpose of this extension is orthogonal to the operation of a SIP
Proxy, therefore a UAC should not assume any Proxy understands this
Polk Expires December, 2006 [Page 4]
Internet-Draft Learning the Backup LoST URI in SIP June 2006
extension in order for the extension to work properly.
5. Rules of the LoST Server URI Extension in SIP
The following are the rules of operation for this SIP extension for
emergency calling:
- A SIP REGISTER request message with a Supported header containing
the lost-server-uri option tag means a UAC wants to learn its LoST
Server URI during SIP registration, or registration refresh. The
presence of this header MUST NOT prevent SIP registration from
continuing if this Registrar does not support this extension.
- A SIP REGISTER request message with a Require header containing
the lost-server-uri option tag means a UAC needs to learn its LoST
Server URI during SIP registration, or registration refresh. The
presence of this header MUST prevent SIP registration from
continuing if this Registrar does not support this extension. In
this case, if this extension is not understood by the Registrar
server, a 420 (Bad Extension) is the appropriate response message,
containing an Unsupported header with a lost-server-uri option
tag.
- The UAC's Location MUST be by-value or by-reference in the
REGISTER message to invoke this extension. If location is not in
the message, a 424 (Bad Location Information) response is the
appropriate response. This response SHOULD include both the
lost-server-uri and location option tags in a Supported header to
indicate to the UAC the Registrar can comply with this
extension/feature if provided the appropriate information.
- If a Registrar supports this extension, and receives a REGISTER
request message containing lost-server-uri and location option
tags in a Supported header, and detects location by-value or
by-reference, the Registrar SHOULD include a LoST-Server-URI
header with an appropriate URI as a header value in the 200 OK
response message.
- More than one LostServerURI header value MAY be in the
"LoST-Server-URI" header, with no preferential ordering assigned
if more than one value is present in this new header. Each
additional header value SHOULD be considered another contact point
for a mapping.
- Each LoST URI in this message MUST point at unique LoST servers,
enabling redundant servers to be included in a response message.
6. IANA Considerations
This document adds one new SIP Header and one new option tag to the
Polk Expires December, 2006 [Page 5]
Internet-Draft Learning the Backup LoST URI in SIP June 2006
sip-parameters section of the IANA registry.
6.1 LoST-Server-URI Header Registry
The SIP "LoST-Server-URI" header is created by this document, with
its definition in Section 3 of this document, and rules in Section
5.
6.2 lost-server-uri Option Tag Registry
The SIP option tag "lost-server-uri" is created by this document,
with the definition in Section 4 of this document, and rules in
Section 5.
7. Security Considerations
This extension is a backup or fallback mechanism to learning and
including a URI of a PSAP in an emergency call. The primary means
of learning this URI is during call processing in a special Proxy
Server called an Emergency Services Routing Proxy (ESRP). If this
ESRP, which queries the LoST Server for a PSAP SIP(S)-URI fails, the
back-up URI, enabled by this extension is used. This failure should
be an highly unlikely event. Therefore it is not foreseen that this
has many advantages of corrupting. The SIP REGISTER transaction
should use TLS already, thus this extension is protected for
confidentiality and integrity already through normal operation
within SIP.
This extension should add no new security concerns to SIP.
8. Acknowledgements
Your name here.... or, if you contribute a fair amount of text, you
can become a co-author
9. References
9.1 Normative References
[ID-LoST] T. Hardie, H. Schulzrinne, A. Newton, H. Tschofenig, "LoST:
A Location-to-Service Translation Protocol",
draft-hardie-ecrit-lost-00.txt, "work in progress", February
2006
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Polk Expires December, 2006 [Page 6]
Internet-Draft Learning the Backup LoST URI in SIP June 2006
Requirement Levels", RFC 2119, March 1997
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-
sip-location-conveyance-03.txt, "work in progress", June
2006
9.2 Informative References
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
progress", January 2006
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Fax: none
Email: jmpolk@cisco.com
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
Polk Expires December, 2006 [Page 7]
Internet-Draft Learning the Backup LoST URI in SIP June 2006
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 provided by the IETF
Administrative Support Activity (IASA).
Polk Expires December, 2006 [Page 8]
