One document matched: draft-polk-ecrit-mapping-during-registration-00.txt
ECRIT Working Group James Polk
Internet-Draft Cisco Systems
Expires: Aug 27th, 2006 Feb 27th, 2006
ECRIT Mapping During Session Initiation Protocol Registration
draft-polk-ecrit-mapping-during-registration-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 August 27th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses four different Layer-7 options to solve the
problem of getting the appropriate Public Safety Answering Point
(PSAP) Session Initiation Protocol (SIP) Uniform Resource Identifier
(URI) into an emergency calling capable device prior to it's user
calling for help.
Polk Expires August 27th, 2006 [Page 1]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . 3
2. Options for Layer-7 Mapping Prior to Emergency Call . . . . . 3
3. Requirements on Transaction to Learn PSAP-URI at Layer-7 . . 4
4. Basic Assumptions About Location . . . . . . . . . . . . . . 5
5. Transaction Overview . . . . . . . . . . . . . . . . . . . . 6
6. Option #1 - SIP REGISTER with a PSAP-URI Request Header . . . 6
6.1 New PSAP-URI Header in SIP . . . . . . . . . . . . . . . 6
6.2 Usage of PSAP-URI Header Field . . . . . . . . . . . . . 7
6.3 PSAP-URI Option Tag . . . . . . . . . . . . . . . . . . . 7
6.4 SIP Element Rules . . . . . . . . . . . . . . . . . . . . 7
7. Option #2 - SIP REGISTER with a new event package . . . . . . 10
8. Option #3 - UA Performs a HTTP Query to a Remote Server . . . 11
9. Option #4 - SIP SUBSCRIBE With a New Event Packet . . . . . . 11
10. Examples of All Four Options . . . . . . . . . . . . . . . . 11
10.1 Example of PSAP-URI Header Transaction . . . . . . . . . 11
10.2 Example of SIP REGISTER Event Package Transaction . . . . 12
10.3 Example of HTTP Transaction . . . . . . . . . . . . . . . 13
10.4 Example of SIP SUBSCRIBE Event Package Transaction . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1 Normative References . . . . . . . . . . . . . . . . . . 13
14.2 Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 15
1. Introduction
ECRIT Requirements [ID-ECRIT-REQS] are defining how a emergency
capable device requests a binding of a given location in the form of
a Presence Information Data Format Location Object (PIDF-LO)
[RFC4119] to a SIP(S)-URI of the appropriate PSAP for that location.
[ID-SOS] defines how a voice call can be identified as an emergency
cell set-up message within SIP.
The prevalent model most are working towards is that a user of a SIP
user agent (UA) enters a designated (locally, perhaps by law)
dialstring into the entry point of said UA, which recognizes this as
a locally significant emergency dialstring. Both [ID-DHC-DIAL] and
[ID-ECRIT-DIAL] provide means that this can be learned from the UA's
location at different layers of the network during boot-up time, as
well as the UA likely being configured with an appropriate 'home'
dialstring the user will have learned from society. For example, in
North America the dialstring would be '9-1-1', and it is '9-9-9' in
the United Kingdom.
Polk Expires August 27th, 2006 [Page 2]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
Once the caller enters the appropriate dialstring, the UA sends a
specially formed SIP INVITE message with a Request-URI of
"urn:service:sos" and includes the location of the UA. Within the
network, a SIP server, called an Emergency Services Proxy Server
(ESRP) will be the first to understand the concept of emergency
calling, and provide a unique routing action with this message. The
ESRP will query a remote server with the ECRIT Mapping protocol, yet
to be defined, but scoped in [ID-ECRIT-REQS]. This is ECRIT mapping
protocol will return the appropriate PSAP SIP(S)-URI to be placed
into this emergency message for routing to the PSAP.
A few have questioned if this is the best time to rely on this
Location-to-PSAP routing decision. What if the mapping function
fails, what happens to the INVITE message?
[ID-DHC-URI] defines how a user agent can learn the appropriate
PSAP-URI well before the emergency call is placed by the user. Some
want the mapping function to have the freshest information. This is
ideal, with no doubt. But there are always failures in systems,
this document discusses one alternative time in which a UA can learn
its PSAP-URI.
For the purposes of clarity, throughout this document the acronyms
PSAP SIP(S)-URI and PSAP-URI mean the same thing. The intention is
addressing the SIP INVITE with a Request-URI or a (loose) Route
header that is destined for the network local to the appropriate
PSAP.
[ID-MAPPING] provides several scenarios in which this location-to-
PSAP-URI mapping can occur, and the ideal situation is that the
mapping can occur in all the scenarios and not conflict. This is to
show that mapping should be done before an emergency call takes
place, as well as during the emergency call. The former transaction
provides a fallback mapping result that can be used at any time
there is a failure in the primary ECRIT mapping function during the
call, without having to send an error back to the UA. The UA may
not know what to do with an error of this kind.
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. Options for Layer-7 Mapping Prior to Emergency Call
There are four options discussed in this document for how a PSAP-URI
can be obtained by a SIP user agent during, or soon after device
Polk Expires August 27th, 2006 [Page 3]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
registration:
Option #1 - SIP REGISTER with a header in the request
Option #2 - SIP REGISTER with a new event package
Option #3 - UA performs a HTTP Query to a remote server
Option #4 - SIP SUBSCRIBE with a new event packet
The advantages of placing this function in a SIP REGISTER message is
that in travels with the device configuration. Meaning the UA would
learn of this information at boot time, with appropriate indicators
to tell the UA when the Registrar can and cannot perform this task.
Using a new event package creates more flexibility in what
information can be provided lateral to the PSAP-URI, for example:
- a service-identifier type of PSAP-URI
- indicating if this is the primary or secondary URI PSAP target
The type of PSAP-URI is important in those countries that today have
more than one emergency dialstring; [ID-SOS] provides a list of
service-id types. For example, in Switzerland, the dialstring
'116'is used to contact the police, and '117' is used to contact the
fire department. This capability is not available throughout the
world, but it is important were it is available now; and may spread
to other parts.
The ability to download a primary and secondary PSAP-URI means there
is a fallback with this fallback idea. Given that in times of an
emergency, preloading however many fallback routes is never a bad
idea. But there will likely always be a primary coverage PSAP in
any case, and this should be identifiable.
Constructing a request and response for a PSAP-URI is not really
that hard, and neither is adding a cursory second piece of
information to that URI, but there may be some security risks that
some may not want to take on a open public network in transit to an
emergency services network. Choosing one of the two ways in a SIP
REGISTER Request is open for discussion.
Creating this capability in HTTP should be fairly straight forward,
but there have been some issues raised lately that not all HTTP
implementations are created equal, and this would force HTTP onto
every UA that wanted this capability, which may not be the case, and
may not be desired.
Here we talk about an HTTP server being any server running HTTP, and
not a necessarily (any or all) traditional Web-server(s).
Polk Expires August 27th, 2006 [Page 4]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
It is possible that the same, or a similar, event package could be
used in a SIP SUBSCRIBE message as is suggested above for a REGISTER
message.
3. Requirements on Transaction to Learn PSAP-URI at Layer-7
The following are the requirements necessary for a UA to learn its
PSAP-URI during a Layer-7 transaction:
Req#1 - A (SIP or HTTP) user agent MUST be able to indicate it
requires an PSAP-URI during a transaction with a remote
entity (i.e. a SIP Registrar or HTTP server).
Req#2 - A (SIP or HTTP) user agent SHOULD be able to indicate it
requires a secondary PSAP-URI during a transaction with a
remote entity (i.e. SIP Registrar or HTTP a server).
Req#3 - A user agent MUST its location in a PIDF-LO by-reference or
by-value in the request for a PSAP-URI. By-value is
RECOMMENDED as a dereference transaction can also fail.
Req#4 - A (SIP or HTTP) user agent SHOULD be able to indicate which
service-id type of PSAP-URI it is seeking during a
transaction with a remote entity (i.e. only police or only
fire).
Req#5 - A (SIP or HTTP) user agent SHOULD be able to indicate more
than one service-id type of PSAP-URI it is seeking during a
transaction with a remote entity (i.e. to a general request,
respond with all that apply in that location/country).
Req#6 - A server node (SIP Registrar Server or server running HTTP)
MUST recognize a request for a PSAP-URI from
a UA, understand to look for the UA's location within the
message, then perform an ECRIT Mapping function (query) to
learn the appropriate URI for that location.
Req#7 - A server node (SIP Registrar or HTTP Server) MUST be able to
respond with one or more PSAP-URI's for that location,
including indicating the service-id type of URI each is in
the response of a transaction with the user agent.
Req#8 - A user agent MUST be able to request and update existing
information at any time the device can contact the server.
4. Basic Assumptions About Location
One basic assumption has to be made here: the UA knows its location,
either by-value or by-reference. Without this knowledge, any
request for the appropriate PSAP-URI would not yield a valid answer,
Polk Expires August 27th, 2006 [Page 5]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
because there is such a list to choose from. This document does not
discuss how the UA was sent, retrieved or knows its location; just
that it has to know where it is, at least at a country level, in
order to expect a server to plausibly be able to answer this request
for information.
5. Transaction Overview
Here is the basic message flow of this transaction, regardless of
which of the four options are chosen:
Here Alice is registering to a (SIP or HTTP) server.
Alice SIP or HTTP Server
[M1] Request
------------------------>
[M2] Response
<------------------------
From a "where in the request is the request indication for the
PSAP-URI"? It does not matter from a messaging point of view. The
request indication could be in a Header or a new event package
message body. The event package could be different for what goes in
a SIP REGISTER and SUBSCRIBE Request, the transaction looks the
same. It also looks similar to an HTTP transaction, even it the
message body is different.
The key facet of the request is two-fold:
- That the message contains location by-value or by-reference, and
- That the message requests what it seeks
This message MAY be at device boot time in each of these messages,
or it MAY be after device boot time with any of these messages.
6. Option #1 - SIP REGISTER with a PSAP-URI Request Header
6.1 New PSAP-URI Header in SIP
Communicating the primary or secondary PSAP-URI in a request or
response can be accomplished with a new header. The PSAP-URI header
would have the following syntax (The "token-nodot" production is
copied from [RFC3265]):
PSAP-URI = "PSAP-URI " HCOLON PSAP-URI-value *(COMMA
PSAP-URI-value)
PSAP-URI-value = (absoluteURI / option-tag)
option-tag = string
Polk Expires August 27th, 2006 [Page 6]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
service-id = string
NOTE: we aren't sure this BNF is correct. The goal is to get this
Result as a Request:
PSAP-URI: <psap-uri; service-id=primary>,
<psap-uri; service-id=secondary>,
<psap-uri; service-id=police>,
<psap-uri; service-id=fire>
And this result in a Response:
PSAP-URI: <sip:psap1.colleyville.tarrant.tx.us.sos.arpa;
service-id=primary>
6.2 Usage of PSAP-URI Header Field
The following table extends the values in Tables 2&3 of RFC 3261
[RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
PSAP-URI Rr - - - - o o -
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
PSAP-URI Rr o o o o - o -
This header is opaque to proxy servers. It has optional usage in
the REG [RFC3261], OPT [RFC3261], SUB/NOT [RFC3265], UPD [RFC3311],
INF [RFC2976] and MSG [RC3428].
6.3 PSAP-URI Option Tag
This document creates a new option tag "psap-uri" to be used in
Requires, Supported and Unsupported headers in SIP between compliant
SIP elements of this extension. At this time, the authors do not
see any need for this option tag to be placed in the Proxy-Requires
header, as this extension should be opaque to proxies and merely
propagated by B2BUAs. This option tag will be IANA registered.
6.4 SIP Element Rules
Here are the behaviors of the relevant SIP elements within this
operation. This SIP extension is opaque to SIP Proxies, SHOULD be
copied unchanged from receiving request to transmitted request by
B2BUAs and SBCs.
Polk Expires August 27th, 2006 [Page 7]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
6.4.1 UAC Behavior with PSAP-URI Header Option
A UAC wanting an appropriate PSAP-URI be returned during
registration process will do the following:
- The UAC SHOULD include psap-uri Option-tag in a Requires header,
but MAY include option-tag in Supported header to prevent initial
420 if Registrar doesn't understand this extension.
- The UAC MUST include location in the REGISTER Request message,
by-value is RECOMMENDED, but MAY send location by-reference in
Location header [ID-SIP-LOC].
- The UAC SHOULD include a Location header in the request, with a
cid indication of where location is in the message body, even if
there is only one message body part.
- If the UAC has its location by-reference URI, it MUST include this
in the Location header of the REGISTER request, unless location
by-value is included. Both MUST NOT be included in the same
message.
- A UAC requesting an PSAP-URI MUST expect to receive a server
identifier in the response.
- The UAC SHOULD use S/MIME to protect the PIDF-LO for e2e
confidentiality.
- The UAC MUST use TLS or IPSec for hop-by-hop confidentiality.
- A UAC MAY request this PSAP-URI with every REGISTER Request,
include a refresh, to ensure it has the freshest information.
- There may be more than one valid PSAP-URI for where
the UAC is at the moment. The UAC MUST be prepared to receive
more than one URI in the PSAP-URI header.
6.4.2 Server Behavior with Emergency-Dialstring Header Option
A Registrar server understanding the concept of PSAP-URI will do the
following:
- The Registrar MUST understand Emergency-Dialstring header and
emergency-dialstring option-tag in a Supported or Requires header.
- If the Registrar does not understand the psap-uri option-tag in a
Requires header, the Registrar MUST reject the message with a 420
(Bad Extension) Response, including the psap-uri option-tag in an
Unsupported header.
- A Registrar MUST respond to an OPTIONS request with psap-uri
Polk Expires August 27th, 2006 [Page 8]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
option-tag in a Supported header with the psap-uri option-tag in
an Unsupported header.
- Having understood the request to perform an ECRIT Mapping Query
for a PSAP-URI, the Registrar MUST look for location within the
Request message to determine where the UAC is geographically, or
contact another server, perhaps using another protocol, that can
do this operation.
- The Registrar MUST look for the Location header in the Request
message to indicate a location by-reference URI, or a cid value of
where the location message body part is in the overall message
body [ID-SIP-LOC].
- The Registrar MUST understand location by-reference, per
[ID-SIP-LOC] and fetch the PIDF-LO from remote server to
include the location of the UAC in the ECRIT Mapping Query.
- The Registrar MUST understand the content-type
application/pidf+xml to properly parse the PIDF-LO fetched or from
the by-value message body.
- The Registrar MUST understand all both parts of the PSAP-URI
Header (i.e. also the service-ID part).
- A request for an PSAP-URI MUST include a service identifier in the
response, with the default value being 'primary'.
- If more than one PSAP-URI is used or appropriate within the UAC's
current location, more than one URI MUST be returned in the
PSAP-URI header, separated by a ',' (comma), with each URI
partnered with the respective service identifier
- The Registrar MUST use TLS for hop-by-hop Confidentiality of these
Transactions; IPSec usage is optional.
- The Registrar MUST adhere to the location retention and
distribution rules set in the PIDF-LO [RFC4119].
6.4.3 Error Conditions with Emergency-Dialstring Header Option
6.4.3.1 UAC Error Conditions
A user agent client, having included an PSAP-URI in a request
message, receives an error response, will do the following:
- If the UAC receives a 420 (Bad Extension), if it placed the
psap-uri option tag in a Requires header, it SHOULD resend the
REGISTER request, but place the psap-uri option tag in a Supported
header.
Polk Expires August 27th, 2006 [Page 9]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
- If the UAC sent a REGISTER with an psap-uri option tag in a
Requires header, and receives a 503 (Service Unavailable) from the
Registrar with an psap-uri option tag in a Supported header, it
knows the Registrar understood the request, but could not complete
URI request. The UAC SHOULD retry registration with the psap-uri
option tag in a Supported header.
- If the UAC receives a 415 (Unsupported Media type) from a
Registrar to the content-type application/pidf+xml, the UAC SHOULD
NOT attempt to send a PIDF-LO again to the Registrar, meaning the
UAC cannot ask for its PSAP-URI from that SIP element.
6.4.3.2 Registrar Error Conditions to Header
A Registrar server understanding the concept of PSAP-URIs will do
the following:
- If the Registrar does not understand the psap-uri option tag in a
Requires header, the proper response is a 420 (Bad Extension),
including psap-uri
- If the Registrar does not understand the psap-uri option tag in a
Supported header, the proper response is to convey a lack of
support for the option tag by including this in the Unsupported
header in the response message
- If the Registrar does not understand the content-type
application/pidf+xml, the proper error response is a 415
(Unsupported Media type)
- an Unsupported header MUST be in the 415, which includes this
option tag
- If a Registrar server understands the concept of PSAP-URIs, and
receives a request for an PSAP-URI from a UAC during registration
in a Requires header, but for whatever reason cannot complete this
part of the transaction, the server MUST return a 503 (Service
Unavailable) response to the UAC. The Registrar MUST include the
psap-uri option tag in a Supported header to indicate this part of
the request was understood, but could not be performed at this
time.
7. Option #2 - SIP REGISTER with a new event package
The creation of a new SIP REGISTER event package to request and
respond with a psap-uri and service identifier in a request or
response can be accomplished ...
This section to be completed soon
Polk Expires August 27th, 2006 [Page 10]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
[The authors did not have time prior to the submission cut-off to
complete additional options to these requirements. We are sorry!]
8. Option #3 - UA Performs a HTTP Query to a Remote Server
The creation of a new HTTP Query to request and respond with a
psap-uri and service identifier in a request or response can be
accomplished ...
This section to be completed soon
[The authors did not have time prior to the submission cut-off to
complete additional options to these requirements. We are sorry!]
9. Option #4 - SIP SUBSCRIBE With a New Event Packet
The creation of a new SIP SUBSCRIBE event package to request and
respond with a psap-uri and service identifier in a request or
response can be accomplished ...
This section to be completed soon
[The authors did not have time prior to the submission cut-off to
complete additional options to these requirements. We are sorry!]
10. Examples of All Four Options
This section illustrates only one of the four options at this time.
As soon as the event packages are completed in XML, they will be
incorporated into the text here. However, if any of these options
are not considered appropriate by the community, they will be
dropped like a burning pan you didn't realize was hot before you
picked it up.
Thank you for your patience...
10.1 Example of PSAP-URI Header Transaction
Here is Alice's modified registration transaction.
Alice Registrar Server
[M1] REGISTER (with PIDF-LO, and Requires
plus PSAP-URI header)
------------------------>
[M2] 200 OK (with PSAP-URI header)
<------------------------
Polk Expires August 27th, 2006 [Page 11]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
The following message are *not* well-formed.
[Message 1 - REGISTER from Alice to Registrar Server]
REGISTER registrar-server@example.com SIP/2.0
Via: Alice
To: Alice
From Alice
PSAP-URI: <psap-uri; service-id=primary>
Requires: psap-uri
Location: cid <foo>
Call-ID: 1
Content-type: application/pidf+xml
Content-Length: ...
cid <foo>
[PIDF-LO message body (not shown)]
[Message 2 - 200 OK from Registrar Server to Alice]
SIP/2.0 200 OK
Via: Alice
To: Alice
From Alice
PSAP-URI: <sip:psap1.colleyville.tarrant.tx.us.sos.arpa;
service-id=primary>
Supported: psap-uri
Call-ID: 1
Content-Length: 0
Location is sent to the Registrar in the form of the [RFC 4119]
PIDF-LO message body in the above example. The Registrar is the
destination UAS of this message, so it can read all that is in the
message, even if encrypted. The Registrar will generate a ECRIT
Mapping Query to learn the PSAP-URI for this location (which is
include in the Query). The (hopefully) positive results of the
query will be sent to the UA in the 200 OK SIP response. At this
point, Alice's UA has a PSAP-URI, which she may refresh at any time,
to place (conceivably) in a (loose) Route header of the INVITE
request message that is generated if and when Alice calls for
emergency help. The exact placement of this URI in the INVITE has
not reach consensus in the community, but this is the likely target
header for it.
10.2 Example of SIP REGISTER Event Package Transaction
To be completed...
Polk Expires August 27th, 2006 [Page 12]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
10.3 Example of HTTP Transaction
To be completed...
10.4 Example of SIP SUBSCRIBE Event Package Transaction
To be completed...
11. IANA Considerations
This document will make IANA Registrations when one or more of the
four options to these requirements has been decided upon.
12. Security Considerations
A concern with this extension (in its current form) is making sure
the header field is not changed in transit between the Registrar
server and the UAC, as this could start a chain of events to occur
that will have a SIP INVITE fallback to the a bad PSAP-URI if the
ESRP Mapping function failed. Therefore, message integrity is
necessary. Normal SIP mechanisms, such as using TLS or IPSec for
message transmissions, should suffice.
Message body confidentiality needs to be used to protect the PIDF-LO
message body to adhere to location information retention and
distribution rules. Normal SIP mechanisms, such as using TLS or
IPSec for message transmissions, as well as S/MIME encryption of the
message body, should suffice.
13. Acknowledgements
Your name here
14. References
14.1 Normative References
[ID-ECRIT-REQS] H. Schulzrinne, R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-04.txt, "work in progress",
January 2006
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005
[ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-00, "work in
progress", January 2006
Polk Expires August 27th, 2006 [Page 13]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
[ID-DHC-DIAL] J. Polk, "A Dynamic Host Configuration Protocol Option
for the Locally Significant Emergency Calling Dialstring",
draft-polk-dhc-emergency-dialstring-option-00, "work in
progress", February 2006
[ID-ECRIT-DIAL] J. Polk, " Using the Session Initiation Protocol
REGISTER Method To Obtain an Emergency Dialstring",
draft-polk-ecrit-emergency-dialstring-00, "work in
progress", February 2006
[ID-DHC-URI] J. Polk, "A Dynamic Host Configuration Protocol Option
for Requesting and Receiving Uniform Resource Identifiers",
draft-polk-dhc-uri-02.txt, "work in progress", October 2005
[ID-MAPPING] J. Polk, " Analyzing ECRIT Mapping of a Location to an
Emergency URI for Emergency Calling",
draft-polk-ecrit-mapping-events-00.txt, "work in progress",
February 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-
sip-location-conveyance-01.txt, "work in progress", June
2005
14.2 Informative References
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002
[RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging" , RFC 3428, December 2002
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
Polk Expires August 27th, 2006 [Page 14]
Internet-Draft ECRIT Fallback Mapping at Layer-7 Feb 2006
USA
Phone: +1-817-271-3552
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
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.
Polk Expires August 27th, 2006 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 06:57:33 |