SIPPING J. Rosenberg Internet-Draft Cisco Systems Expires: April 19, 2007 October 16, 2006 An Architecture and Framework for the Usage of Telephone Numbers with the Session Initiation Protocol (SIP) draft-rosenberg-rai-phone-names-numbers-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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Session Initiation Protocol (SIP) is often used for the purposes of making and receiving Voice over IP (VoIP) calls, and in many of these cases one or both parties in the call is on the Public Switched Telephone Network (PSTN). For this reason, phone numbers are often used as part of SIP calls. Despite numerous small specifications describing usage of phone numbers for SIP, there remains a great deal of interoperability problems and feature loss. This document tries to address this by providing a general framework for the usage of Rosenberg Expires April 19, 2007 [Page 1] Internet-Draft Phone Practices October 2006 phone numbers and phone naming and numbering services with SIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Names, Numbers and Routes . . . . . . . . . . . . . . . . . . 4 3. Phone Number Processing . . . . . . . . . . . . . . . . . . . 6 3.1. Dial String Processing . . . . . . . . . . . . . . . . . . 8 3.2. Source Identity Selection . . . . . . . . . . . . . . . . 9 3.3. Name to Address Translation . . . . . . . . . . . . . . . 10 3.4. Route Determination . . . . . . . . . . . . . . . . . . . 12 4. Number Portability . . . . . . . . . . . . . . . . . . . . . . 13 5. Freephone Services . . . . . . . . . . . . . . . . . . . . . . 15 6. Short Code Services . . . . . . . . . . . . . . . . . . . . . 18 7. Carrier Selection . . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.1. URN Namespace . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Service URN Values . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Rosenberg Expires April 19, 2007 [Page 2] Internet-Draft Phone Practices October 2006 1. Introduction The Session Initiation Protocol (SIP) [1] is often used for the purposes of making and receiving Voice over IP (VoIP calls. Consequently, SIP calls often traverse gateways to the PSTN, and frequently end up carrying phone numbers in their messages. As a consequence of this frequent interworking, SIP endpoints end up being involved in traditional PSTN services. There are many aspects of this interworking which require specification. One broad class of problems are those of protocol conversion, between SIP and various SS7 signaling variants. Those are covered in specifications such as [11] and [12]. However, there is another aspect of this problem which merits consideration - the usage of legacy PSTN addressing concepts with SIP, and more specifically, the usage of phone numbers with SIP. This aspect of interworking has the unique property that, once the last PSTN switch is disconnected and all calls run over VoIP (and SIP of course), the usage of phone numbers within SIP is likely to persist. Numerous specifications have been developed to deal with the usage of phone numbers in SIP. RFC 4248 [3] defines a URI scheme for telephone numbers. Numerous extensions have been specified for it, including ones for number portability [15] and trunk groups [17]. The SIP URI can also contain telephone numbers in its user part. ENUM itself [13] is concerned primarily about mapping of phone numbers to Internet resources, and extensions to ENUM for handling PSTN naming and numbering services, such as number portability [18] and calling name [19], are under development. Despite this, the usage of phone numbers and phone numbering concepts with SIP remains a source of interoperability problems. Some of these relate to non-compliance with specifications, but others can be attributed to lack of specification. Some of the problems include: o Interoperability failures when a SIP UA (such as PSTN gateway) is expecting to see phone numbers with a tel URI, but instead they arrive in SIP URI form, and vice-a-versa. o Interoperability failures when a SIP UA is expecting and receives a SIP URI, but doesn't recognize the domain part is its own and thus rejects the request. o Interoperability failures when a SIP UA is expecting a tel URI or a SIP URI in various SIP header fields (To, From, Route, Request- URI, Contact) and receives a form it did not expect. Rosenberg Expires April 19, 2007 [Page 3] Internet-Draft Phone Practices October 2006 o Difficulty providing local number portability to users with SIP endpoints, and when it is provided, oftentimes with a confused transition period. o Interoperability failures when dial plans are used, and a phone emits a number that is not in a format understood by the proxy or UA. All of these problems are related to the usage of telephone numbers with SIP. Indeed, the root cause behind each of these problems is a misapplication of the concepts of names, numbers and routes when used in conjunction with phone numbers. This document tries to address this problem by defining a framework for usage of phone numbers within SIP. Section 2 defines the concepts of names, numbers and routes with VoIP and shows how they map to SIP concepts. Section 3 defines a sequence of translation functions which need to be undertaken in the processing of a call to any phone number. Using these concepts, Section 4 discusses local number portability and its usage within all IP networks and PSTN interoperability. Section 5 discusses freephone services. Section 6 discusses short code services. Section 7 discusses carrier selection. 2. Names, Numbers and Routes A central concept in this document is the distinction between a name, a number, and a route. The general definitions of these terms are: Name: An identifier which points to a resource by means of an opaque or structured reference that reveals nothing about the location of the resource. In the postal system, this would correspond to a person's name, i.e., "Jane Doe". Address: An identifier which points to a resource by indicating where it can be found. In the postal system, this would correspond to a person's street address, i.e., "500 Main Street, Anytown U.S.A". Route: A sequence of addresses, each of which points to a hop to be visited in order to deliver a message to a recipient. In the postal system, this would correspond to the set of post offices used to relay a letter towards the recipient. Based on these definitions, some important conclusions can be drawn about SIP identifiers: o A tel URI is a name. It lacks any information whatsoever about the location of the object. Indeed, a tel URI can be used to identify a SIP user, a webpage, or a line on a PSTN switch. Rosenberg Expires April 19, 2007 [Page 4] Internet-Draft Phone Practices October 2006 o A service URN [8] is a name. Like the tel URI, it lacks any information about the location of an object. Indeed, it is actually represented by a Universal Resource Name [4], which is the standardized way to represent a name. o A SIP URI is an address. The domain part of the SIP URI is the only mandatory portion of the SIP URI, and it identifies the namespace within which to interpret the user part, and through RFC 3263 [2], the place to go to find that resource. o The SIP Route header field is a route. The Route header field has one or more values, and each one contains an address (a SIP URI) of an intermediate service (a SIP proxy service) which is visited in the delivery of a request to the target recipient. Perhaps one of the biggest points of confusion in the usage of phone numbers with SIP is the difference between: 1. A tel URI with global number X 2. A SIP URI with global number X in the user part, with a user=phone parameter 3. A SIP URI with a global phone number X in the user part, with a user=IP parameter or no user parameter RFC 3261 is clear that user=phone is used when the user part is formatted as a phone number. However, this document argues that when used in a SIP URI there is an additional, deeper meaning. The domain part of the SIP URI serves two important purposes. First, it specifies the host to which the request should be delivered. However, this is secondary to its more important meaning - it is an identifier for the owner of the namespace from which the user part is selected. Consequently, when the user part is a global phone number, it is asserting ownership of that global phone number by that domain. Thus, the SIP URI form with user=phone MUST only be used when the entity constructing the URI has knowledge from an authoritative source that the domain in the URI is the owner of the phone number in the left hand side. Such knowledge comes from databases such as ENUM or PSTN-based local number portability tables, in additional to localized knowledge within the domain that knows definitively that it owns the number. For example, if the number +17325551000 is owned by example.com, the following URI would represent a SIP address indicating such: sip:+17325551000@example.com;user=phone Rosenberg Expires April 19, 2007 [Page 5] Internet-Draft Phone Practices October 2006 Lack of the user=phone parameter (or usage of a different user value) is used when the user part is merely a localized key interpreted in the context of the domain in the right hand side. The primary use case of this are for representing dial strings, as discussed below. Finally, a tel URI represents a name of a resource when the domain of ownership is not known or not within the IP network. These definitions permit further clarification on the operations performed on these identifiers: Translation: Translation is the process of converting a name to an address in order to deliver a request to a target. This translation requires the use of translation tables. ENUM serves as one such mechanism. Indeed, the principal purpose of ENUM is to serve as a translation from a name, in the form of a tel URI, to an address in the form of a SIP URI. The LoST protocol [20] also serves to translate from a name in the form of a service URN, to an address in the form of a SIP URI. Retargeting: Retargeting is the process of changing the name or address that identifies the target to a different name or address that identifies a different target. Routing: In SIP, routing is the process of determination of a route (which is a series of Route header fields) for delivering a request to the current name or address that identifies the target of the request. 3. Phone Number Processing With these definitions, the set of processing steps that need to be undertaken in the handling of a call to a phone number can be described. These steps are shown in Figure 2 Rosenberg Expires April 19, 2007 [Page 6] Internet-Draft Phone Practices October 2006 | | | Dial | String | V +------------------+ | | | Process |<------ Dial Plan | Dialed Digits | | |<------ Number Plan | | +------------------+ | | Target +--------------+ Name | | (tel or service URN) | | | V | +------------------+ | | | | | Name to | Translation | | Address |<------- Service | | Translation | (ENUM, LoST, etc.) | | | | +------------------+ | | | | Target +--------+ | Address | | (SIP URI) V V +------------------+ | | | Route | Routing Tables | Determination |<------- (DNS, TRIP, | | configured, etc) | | +------------------+ Figure 2 There are three steps in this process. The first is the collection of a dial string, and the conversion of that dial string (either in the UA or in a network service) to a target name. The target name is then converted, through a translation service, to a target address. In some cases, the target name cannot be translated, or it is known that translation has to take place elsewhere, in which case a route is determined to reach the target address or a translation service Rosenberg Expires April 19, 2007 [Page 7] Internet-Draft Phone Practices October 2006 for the target name. When combined with the loose route concepts of [9] (which are essential to this specification) this processing implies that the target name appears in the request URI, and that the process of translation and route determination both impact the Route header field. The subsections which follow explain each step in more detail. 3.1. Dial String Processing The first step is the collection of a dial string. For user interfaces where the user enters in the destination number as a sequence of digits, the dial string is the sequence entered by the device. Dial strings are not always used; for user interfaces (such as those on a PC or a wireless phone) where the user enters or selects an alias for the target, the phone itself would store and use the target name or address. Once the dial string is obtained, the next step is to convert the dial string into the target name (represented by a tel URI or service URN). This conversion is done based on two pieces of context. One is the dial plan, and the other is the number plan. The number plan specifies rules about how the number space is managed and allocated to users. An example of a numbering plans is the E.164 numbering plan. A dial plan is a set of rules about how numbers entered on the device map into the number plan. An example dial plan would specify that a user has to dial '9' in order to get an 'outside line', or dial '011' for an international number. The dial plan processing can occur either in the UA itself, or in a server in the network. When it occurs within the UA, there is never a need for a standardized representation of a dial string; it is merely an intermediate format within the host prior to producing the output - the target name. However, in some cases, the UAC does not have access to the dial plan or numbering plan, and cannot perform this function. In such cases, the UA would send the request to a service which can perform the conversion. In such a case, there is a need for representation of the dial string. Indeed, the request is effectively being targeted to a network service. This network service is addressed using the concepts in RFC 3087 [14], whereby the URI parameters identify the parameters of the service. Here, the service requires but one parameter - the dial string. The service extracts the dial string from the URI and performs a retargeting operation to the name or address of the target based on its knowledge of the dial string and number plan. For this reason, the dial string is represented as a SIP URI using the user=dialstring URI parameter Rosenberg Expires April 19, 2007 [Page 8] Internet-Draft Phone Practices October 2006 [10]. When a UA emits a request to a dial-string service, it MUST include the URI containing the dial string (and invoking the service) in the Request-URI. The domain part SHOULD be configured, and if not configured, SHOULD be equal to the domain part of the user's AOR. The URI MUST include a phone-context if one was configured with use for the dial plan service. The To header field will echo the resulting URI. This does mean that the recipient of the request can inspect the To header field and see that it was reached through a dial-string processed by a dial-string service. Since the dial- string service is fundamentally a retargeting operation, it MUST rewrite the Request-URI with the target name, and SHOULD include a History-Info [5] header field indicating that it retargeted. However, it is RECOMMENDED that the dial string processing function be done within a user agent. This avoids the "ugly To header field" problem described above, and eliminates the difficulty of binding a request to a dial plan within the network (which is what necessitates the phone context parameter). This also produces a consistent format for requests emitted from all UA, since "smart" UA will not even use dial strings, and instead emit requests directly addressed towards the target. Regardless of whether the dial string processing is done by the UA or in the network by a dial string service, the request that emerges from this service will have the target name (as a tel URI or service URN) in the Request-URI. This is not an address at this point, and therefore is NOT using the SIP URI format. For example, a request emitted by a UA performing the dial string processing would look like, in part: INVITE tel:+19735551000 SIP/2.0 To: tel:+19735551000 From: sip:joe@example.com Route: sip:edge.example.com 3.2. Source Identity Selection Prior to emitting the request (regardless of whether the UA performs the dial string processing), the UA will need to select an identity for placement in the From header field. This selection is important, since it will be signed by an identity service [6], and presented to the called party as a form of "caller ID". The selection is complicated for several reasons. First, the identity mechanisms of RFC 4474 only apply to SIP URI, not a tel URI. Secondly, the caller may have multiple identities, each of which may be applicable in Rosenberg Expires April 19, 2007 [Page 9] Internet-Draft Phone Practices October 2006 different contexts. For example, a user within an enterprise may have an identity within the local numbering plan (tel:5000;phone-context=example.com), a direct-dial number (tel:+19735555000) and a multiplicity of SIP AOR (sip:joe@example.com, sip:joe.smith@example.com). Ideally, the From header field would contain the internal number when calling within the enterprise, would contain the E.164 tel URI when calling a phone on the PSTN, and a SIP AOR when calling a SIP endpoint. Unfortunately, the caller does not know what the target will be. How then can it select the identity in the From header field? [[TODO: I don't have a good solution for this. The best I've been able to think of is to place a canonical identity in the From header field that gets signed, and place the remaining ones in Reply-To. This raises questions about the verification of Reply-To values, and still makes it hard to determine what to place in the From. More consideration of this is needed.]] 3.3. Name to Address Translation Once a target name has been identified, the next step is the translation of this name to an address. Typically this processing is done by a proxy server in the domain of the caller, but this need not be the case. The output of the translation service would be a SIP URI representing an AOR for the called party. It can also be a telephone number, representing a routing address for the user within the PSTN. [[OPEN ISSUE: Once again, it feels like a new URI scheme is needed here.]] There are two cases that can be considered. In the first case, proxy that is processing the request cannot perform the translation. This can happen for many reasons: 1. The proxy doesn't have access to any kind of translation services at all, and will instead have the translation service performed elsewhere. Elsewhere can include the PSTN itself, in which case the request is routed towards a PSTN gateway. 2. The proxy has access to a translation service, but has discovered that the name does not correspond to any entity on the IP network. Thus, the call needs to be routed towards the PSTN, since the name corresponds to an entity that resides there. This happens when an ENUM query returns no result, for example. [[OPEN ISSUE: Ideally, we'd have a separate way to identify a phone number which is an address rather than a name. The closest thing at this point is the ENUM dip indicator [16], but to me it feels like we need a new URI scheme of some sort, since the concept is really independent of the mechanism for resolution Rosenberg Expires April 19, 2007 [Page 10] Internet-Draft Phone Practices October 2006 (ENUM). Something like line: feels about right.]] 3. The proxy has partial translation services. In particular, it has definitive knowledge about the translation just for the set of numbers it is directly serving. For other numbers, it is not certain. Consequently, it would perform a name to address translation process if the name is one it serves (and it knows it still serves - see Section 4, and for others, route the request towards a translation service elsewhere. In the second case, the proxy performing the translation can do it. This can happen for several reasons: 1. The proxy has accessed a translation service, such as ENUM, which has successfully produces an address (in the form of a SIP URI) for that number. 2. The proxy has localized knowledge that it definitively owns that number, and consequently performs a localized translation to a SIP URI. In cases where the proxy cannot perform the translation, it determines a route for reaching a translation service. Oftentimes, this translation service is within the PSTN itself, in which case the route that is determined is a route to a PSTN gateway. As described in Section 3.4, this route will appear in the Route header field, and the target of the request remains a tel URI in the Request-URI: INVITE tel:+19735551000 SIP/2.0 To: tel:+19735551000 From: sip:joe@example.com Route: sip:gw23.example.com If, however, the translation does occur, this translation is NOT a retargeting. As defined in [9], a retargeting only occurs when the entity that is reached cannot identify itself with the identity prior to the translation. In this case, it would be able to, since the name is a valid identifier for the entity with that address. This means that the request emitted after the translation would look like: INVITE tel:+19735551000 SIP/2.0 To: tel:+19735551000 From: sip:joe@example.com Route: sip:+19735551000@example.org Note how the address appears as the topmost Route header field, and Rosenberg Expires April 19, 2007 [Page 11] Internet-Draft Phone Practices October 2006 the Request-URI remains as the target name. Had the translation service produced an address on the PSTN, the request would look like: INVITE tel:+19735551000 SIP/2.0 To: tel:+19735551000 From: sip:joe@example.com Route: tel:+19735559999 In this case, the number has been ported and the Route header field indicates the target address, which is a line on a switch in the PSTN, and thus identified by a tel URI [[OPEN ISSUE: ugh again.]]. 3.4. Route Determination The next step in the processing of the request is route determination. This process takes the target name and/or address, and from it, determines the sequence of additional services (proxies or gateways) that must be visited prior to reaching the target, each identifed by a SIP URI [[OPEN ISSUE: Need to consider non-SIP URI here; for example, specifying hops within the PSTN]]. In cases where no additional hops are to be visited, this process yields a null output. These routes, if present, MUST be pushed into the Route header field. If the target of the request is a name that is a tel URI, or if the target is an address within the PSTN, the route determination is called gateway routing, and typically involves the selection of an egress gateway. Gateway routing is determined through routing tables that are present on the proxy performing the gateway routing. These tables can be created dynamically from routing protocols like TRIP [7], or they can be manually configured. Typically, they are based on a "longest prefix match" operation on the target name, though need not be. Using the example of a translation service which produced a tel URI as an address, the routing process would select a PSTN gateway and push the result into the request. The result would look like: INVITE tel:+19735551000 SIP/2.0 To: tel:+19735551000 From: sip:joe@example.com Route: sip:gw334.example.com Route: tel:+19735559999 Which assumes that the result of the gateway selection was sip: gw334.example.com. Elements which perform gateway routing SHOULD be Rosenberg Expires April 19, 2007 [Page 12] Internet-Draft Phone Practices October 2006 capable of outputting any valid SIP URI, and NOT just a hostname or IP address. This allows a gateway to have differentiated processing associated with the request based on the value of the remainder of the URI (and typically the user part) of the Route header field. For example, if a gateway has different processing for inbound local vs. long distance calls, the previous hop could use a different value of the user part for each case. In essence, the service URI concepts of RFC 3087 [14] apply equally well to gateways, and indeed to proxies and other intermediary services. However, as intermediaries, the service treatment is specified in the URI in the Route header field. As described in RFC 3087, the value for the URI would not be standardized, but rather would be opaque to upstream elements and merely configured based on the features and configuration of the downstream elements. Another way to consider this is that the Route header field URI points to an index for the policies that are to be applied in the intermediary for processing of the request. Arguably, this makes the topmost Route header field value analagous to the concept of trunk groups in the PSTN, which serve this purpose as well (though they serve other purposes, such as capacity planning, which are not analagous to Route). Consequently, it is RECOMMENDED that gateways and other intermediaries use the user part of Route header fields as an index for request processing, as a form of "SIP trunks". Gateway and intermediary vendors SHOULD publish, as part of their product specification, valid values for the user parts and their associated meanings, when well-known values are used. Usage of the actual trunk group URI parameters for identifying such processing [17] is NOT RECOMMENDED, since it is specific to the PSTN concept of trunk groups, and not applicable to non-GW intermediaries like SIP proxies. However, the Route header field is applicable to all types of intermediary, including vanilla SIP proxies. [[OPEN ISSUE: This whole concept here seems a little out of place in a section on route determination, since its more general than that. Maybe move elsewhere?]] It is never necessary for the route to a PSTN gateway to contain the desired number in the user part; this number will always be present in either the next Route header field, or if there is none, the Request URI. Indeed, a URI of the form sip:number@gateway;user=phone MUST NOT be used. As defined above, the user=phone form implies name ownership, and the gateway itself does not own the telephone number. 4. Number Portability Rosenberg Expires April 19, 2007 [Page 13] Internet-Draft Phone Practices October 2006 Number portability (NP), also known as local number portability (LNP) is a concept in the PSTN whereby a user can take their existing phone number, and move it from one provider to another. This allows a user to have choice in their providers without having to change the number by which everyone knows them. Local number portability, at its core, is merely specifying that the translation of a name (the phone number) to an address (in the PSTN, a switch line identifier) can change. This concept is applicable even in a pure SIP network, as long as users can be identified by names and not addresses. If one presumes that phone numbers continue to exist as identifiers even after the PSTN has disappeared, LNP continues to be important. Indeed, the LNP service is applicable to other forms of names besides phone numbers. One can imagine names based on national identifiers (urn:ssn:123456789 for social security numbers in the United States) or human friendly names (urn:humannames:jonathan.rosenberg). Since LNP is just the ability to change the mapping of a name to address over time, it is readily addressed by the model in Section 3. The primary complication is how to synchronize the change across providers. If ENUM is used as the name to address translation service, and a DNS TTL of zero is used, instantaneous porting is possible. When a user requests a number port, the proxy serving the number currently would mark the user's account as "transitioning". This means that any localized configuration within the domain mapping that users name (in the form of a tel URI) to their address (their SIP URI with user=phone) is no longer definitive. This will require the proxy to perform the ENUM query, which returns the new address, which will have a domain part of a different provider. The request would then be properly sent to the new provider by placing the address in the Route header field. For example, if the number +19735551000 is ported from example.com to example.org, the example.com proxy would note that the number needs to be checked in the public databases, and once the databases are updated, the resulting request would look like: INVITE tel:+19735551000 SIP/2.0 To: tel:+19735551000 From: sip:joe@example.com Route: sip:+19735551000@example.org;user=phone Interestingly, this same model applies equally well to numbers that reside in the PSTN. A proxy performing a name to address translation would find that the number doesn't exist on the IP network or is not reachable through the IP network. This would happen because the name to address translation service yields no results. So, instead, the Rosenberg Expires April 19, 2007 [Page 14] Internet-Draft Phone Practices October 2006 proxy queries an alternative name to address service, one that returns PSTN addressing information. This can be an SS7 query from the proxy, if it has SS7 interfaces, or an IP-based query, such as the ENUM query suggested in [18]. The phone number that results from the query, represents an address, and would therefore appear in the topmost Route header field: INVITE tel:+19735551000 SIP/2.0 To: tel:+19735551000 From: sip:joe@example.com Route: tel:+19735559999 The subsequent route determination function would use the topmost Route header field and find an egress gateway that is ideal for reaching this number. [[OPEN ISSUE: This INVITE above takes a form different from the suggestion in [18], which would have the request URI containing the original number and the ported number in the np parameters. The author of this document proposes that doing so confounds names, addresses and routes. Concretely, it would result in a completely different format for pure SIP based LNP. As shown above, the mechanism here is unified an applicable even when the name that is being ported is not a phone number. It needs to be considered whether to change the format of the LNP records, or keep the format and change how the result is used.]] 5. Freephone Services In the PSTN, freephone numbers are numbers that are aliases to an actual number, but indicative of a special service towards that number - a free call. In the United States, these are represented by 800, 888 and other similar prefixes in place of an area code. Freephone numbers are just another form of name, and the translation of the freephone number to an actual number is just another form of name to address translation or name to name translation. Like number portability, the concept of many alias numbers for a user, each of which has different service implications, is applicable even in pure networks. Indeed, it is perfectly reasonable for a freephone number to resolve to a SIP URI that points to a SIP entity. This would allow a SIP UA to call a freephone number which routes entirely over the IP network. It is outside of the scope of this document as to how inter-carrier billing arrangements would be managed to meet the expectations associated with freephone numbers. This document is concerned only with the representation and usage of such numbers. Rosenberg Expires April 19, 2007 [Page 15] Internet-Draft Phone Practices October 2006 Considering for a moment the case of freephone specifically, there is some controversy as to whether the global tel URI form can even represent a name that is a freephone number. Freephone numbers in the U.S. are national numbers, only accessible from within the U.S.. Freephone numbers are also not considered part of the E.164 numbering plan. Despite this fact, many implementations have been using the global tel URI (and its SIP version) to represent freephone numbers. Other implementations use a local tel URI (tel:18005551212;phone-context=+1). Though the latter is a valid representation, it begs the question of how lookups would be processed. It introduced a new qualifier - phone-context. How would this map to ENUM, for example? An alternative is to define a new URN scheme for freephone numbers (urn:service:freephone:number). The dial plan would translate 8xx numbers (in the U.S. at least) to the appropriate URN scheme. [[OPEN ISSUE: Need to conclude on this and give some guidance]]. The translation service for the freephone name would ideally produce the address. However, in the PSTN today it actually produces one of two entries - either a carrier identified by a carrier code) or another number (which itself might have been ported) which represents an alternative name. Consequently, an IP-accessible translation service for freephone names could return a SIP address, a tel URI name, a carrier code, or a SIP URI representing a route to the provider that owns the number (which would be followed by a localized translation service within that domain). Currently, there is no URI format for representing a carrier code. There is a tel URI cic parameter, but nothing to represent a carrier code alone is isolation. Using the cic parameter confounds the name and the route used to get to its owner, and thus a separate URN seems more appropriate here. A carrier code is another form of name, and thus is ideally represented with a urn. Section 8.1 registers the cic URN scheme for this purpose. Considering each of these use cases, if a freephone translation service returns a SIP address, this is not a retargeting (indeed none of these are retargeting), and the resulting SIP request would look like (we assume the tel URI local form for freephone numbers: INVITE tel:8885551000;phone-context=+1 SIP/2.0 To: tel:8885551000;phone-context=+1 From: sip:joe@example.com Route: sip:+19735551000@example.org;user=phone In which case the request can be directly sent to the example.org domain. If the translation service returns a telephone number (a name): Rosenberg Expires April 19, 2007 [Page 16] Internet-Draft Phone Practices October 2006 INVITE tel:8885551000;phone-context=+1 SIP/2.0 To: tel:8885551000;phone-context=+1 From: sip:joe@example.com Route: tel:+19735551000 A subsequent name to address translation can be performed on this, and if that fails, route determination can then be run on the number in the Route header field to determine how to reach it, possibly through a gateway. It is very important to note that, once the request arrives at the gateway, both the original 8xx number and the translated number are available. Both are required to correctly populate the SS7 signaling. If the translation service returned a CIC code: INVITE tel:8885551000;phone-context=+1 SIP/2.0 To: tel:8885551000;phone-context=+1 From: sip:joe@example.com Route: urn:cic:87787 The route determination function would still run on the topmost Route header field. Since the URN is clearly labeled as a CIC, CIC- specific routing tables can be used to push the Route of a gateway. When this arrives at a gateway, the original 800 number and the desired CIC are known. This allows for proper trunk selection at the gateway. Note however that it does not require a gateway; nothing about the CIC URN suggests that it map to a PSTN connected resource. If a proxy has configured mappings of a CIC to a SIP URI, those can be used. If the translation service returns a domain (for example indicating that example.com owns the number), this would be done using a SIP URI pointing to the domain-local translation service. For example: INVITE tel:8885551000;phone-context=+1 SIP/2.0 To: tel:8885551000;phone-context=+1 From: sip:joe@example.com Route: sip:local8xx@example.org Where sip:local8xx@example.org is a URI service [14] which accesses the 8xx translation service stored just within the example.org domain (typically in a local database of some sort). Note that this form is identical to the case where the actual address is returned as a SIP URI above. Rosenberg Expires April 19, 2007 [Page 17] Internet-Draft Phone Practices October 2006 6. Short Code Services Another form of legacy PSTN services are short code services. These are services such as 311 (local emergency assistance in the U.S.), and 411 (directory services). Conceptually, these are very similar to freephone services. It is RECOMMENDED that short codes be detected as part of dial plan processing, and be mapped to service URN for each service. Section 8.2 defines a set of registrations for some of the existing short code services. The name to address translation service will then take the service URN and find a service to handle it. The means for such translation will be service specific. For ones based on location information, the LoST protocol SHOULD be used. For others, which are location invariant but localized, local configuration of a name to address translation SHOULD be used for IP connected services. If the service resides in the PSTN, route determination will be used instead. In such a case, the request will arrive at the PSTN gateway with a Request URI equal to the service URN, and a topmost Route identifying the gateway. [[OPEN ISSUE: Need to mention more about how to convert this into SS7]]. 7. Carrier Selection Another legacy service of the PSTN is carrier selection. This is a feature which allows users to pick their 'long distance carrier'. This selection can be pre-subscribed (meaning that it is part of the user's profile, and the user doesn't need to indicate it each time they make a call) or a carrier can be selected on a call-by-call basis using a code. In the United States, 101xxx is dialed to select a carrier. In many respects, this feature is very much legacy, and the entire notion of long distance will evaporate with pure VoIP. However, even in a pure VoIP/SIP world, it is very likely that there will be numerous providers focused solely on interconnect. Sometimes, those providers will be chosen entirely by the originating and termianting providers and not subject to user selection. However, one can imagine that other interconnect providers would provider services that are of benefit to the subscriber and thus be something a subscriber might wish to elect. For example, interconnect providers could provide specialized anonymization service (consider a SIP equivalent of the onion router), specialized logging and accounting services, specialized billing rates, and so on. These are sensible even in pure IP interconnect. Rosenberg Expires April 19, 2007 [Page 18] Internet-Draft Phone Practices October 2006 Based on the models described here, carrier selection is nothing more than user indication of a desired route. The route would be in the form of a SIP URI which identifies the service that the intermediate provider is to offer, and placed in the Route header field. Again, it is important to note that the route selection here is NOT just of an IP address, or even of a provider, it is of a service URI that identifies a service to be applied at an intermediary. The intermediary URI could take the form of a SIP URI, in which case it is the address of the intermediary service on the SIP network. It could be a tel URI, in which case it is the name of the service (not quite clear what this means). It could also be a carrier code using the cic URN format, implying that the request be routed to that carrier. In one model, where the user device has the legacy PSTN interface, the dial plan processing would detect that a 1010xxx was dialed, and insert the appropriate service URI into the topmost Route header field. Any outbound proxies or route sets would be pushed ontop of that. In another model, where the subscriber has a pre-subscribed interconnect provider, the same thing could happen - the pre- subscribed URI is placed into the request by the UA as the bottom- most Route header field values. Different URI could be used based on the fact that the provider was selected explicitly vs. via pre- subscription. [[OPEN ISSUE: There are many standardized values for the parameters of the intermediary service in the PSTN. [21] proposes tel URI parameters for each. This would imply standardized service URI formats for this; need to consider that further.]] 8. IANA Considerations This specification defines a new URN namespace for carrier codes, and defines several new service URN values. 8.1. URN Namespace TODO. 8.2. Service URN Values TODO. 9. Security Considerations Rosenberg Expires April 19, 2007 [Page 19] Internet-Draft Phone Practices October 2006 This specification makes extensive use of the loose routing concepts of [9]. The primary implication of this is that the Route header field becomes the source of explicit and important identifying information for the handling of a request. This introduces the possibility of attacks whereby users insert incorrect, malformed, or inaccurate Route header fields in order to accomplish a specific goal. Consequently, a SIP entity MUST verify that the topmost Route header field of a request it receives is one that is valid and authorized by use from the previous hop. The use of mutual TLS between servers is RECOMMENDED as a means for establishing identity to assist in such authorization. A proxy that receives a request with Route headers beyond itself from a client MUST authorize that this is a valid route for a user to request. [[TODO: Should give specific guidance for the use cases above where this can happen, such as carrier selection]] 10. Acknowledgements Many of the concepts in this document came out of discussions with many people over the years, including Paul Kyzivat, Tasvir Shah, and Jon Peterson. 11. References 11.1. Normative 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. [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [3] Hoffman, P., "The telnet URI Scheme", RFC 4248, October 2005. [4] Moats, R., "URN Syntax", RFC 2141, May 1997. [5] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [6] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. Rosenberg Expires April 19, 2007 [Page 20] Internet-Draft Phone Practices October 2006 [7] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002. [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-05 (work in progress), August 2006. [9] Rosenberg, J., "User Agent Loose Routing in the Session Initiation Protocol (SIP)", draft-rosenberg-sip-ua-loose-route-00 (work in progress), October 2006. [10] Rosen, B., "Dialstring parameter for the Session Initiation Protocol Uniform Resource Identifier", draft-rosen-iptel-dialstring-04 (work in progress), June 2006. 11.2. Informative References [11] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)", RFC 3578, August 2003. [12] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, "Interworking between the Session Initiation Protocol (SIP) and QSIG", BCP 117, RFC 4497, May 2006. [13] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [14] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001. [15] Yu, J., "NP Parameters for the "tel" URI", draft-ietf-iptel-tel-np-11 (work in progress), August 2006. [16] Stastny, R., "The ENUM Dip Indicator parameter for the "tel" URI", draft-ietf-iptel-tel-enumdi-05 (work in progress), June 2006. [17] Jennings, C. and V. Gurbani, "Representing trunk groups in tel/ sip Uniform Resource Identifiers (URIs)", draft-ietf-iptel-trunk-group-09 (work in progress), October 2006. [18] Livingood, J. and R. Shockey, "IANA Registration for an Enumservice Containing PSTN Signaling Information", Rosenberg Expires April 19, 2007 [Page 21] Internet-Draft Phone Practices October 2006 draft-ietf-enum-pstn-05 (work in progress), August 2006. [19] Shockey, R., "IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type 'application/cnam'", draft-ietf-enum-cnam-04 (work in progress), September 2006. [20] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-ietf-ecrit-lost-01 (work in progress), September 2006. [21] Yu, J., "DAI Parameter for the "tel" URI", draft-yu-tel-dai-00 (work in progress), October 2006. Rosenberg Expires April 19, 2007 [Page 22] Internet-Draft Phone Practices October 2006 Author's Address Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires April 19, 2007 [Page 23] Internet-Draft Phone Practices October 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. Rosenberg Expires April 19, 2007 [Page 24]