Internet Draft James Yu Document: NeuStar, Inc. Expires: July 2, 2003 January 3, 2003 Using SIP to Support NP and Freephone Service Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (2001). All Rights Reserved. ABSTRACT This document describes how Session Initiation Protocol (SIP) [2] can be used to retrieve information related to NP, freephone service and/or other information, and how the retrieved routing information is used in call processing and SIP signaling. [Page 1] Using SIP to support NP and Freephone Service January 3, 2002 1. Introduction Number portability (NP)[5] allows the telephone subscribers to keep their telephone numbers when they change service provider, move to a new location, or change the subscribed services. The NP implementations in many countries presently support service provider portability for geographic numbers and non-geographical numbers. One special type of non-geographical numbers is the freephone numbers. Freephone service allows the called party to pay for the calls by using special numbering blocks (e.g., 800, 888 and 877 number blocks under country code 1). The freephone service provider for a particular freephone number is the one that can translate a freephone number typically to a Plain Old Telephone Service (POTS) number. Some countries support service provider portability for geographic numbers and/or non-geographical numbers by using centralized administrative process to manage the number porting and databases to host the routing information for a region or whole country. In those countries, information is retrieved from the NP databases to identify the routing number (e.g., Location Routing Number in the U.S.) associated with the terminating Public Switched Telephone Network (PSTN) switch for a geographical number, and from the freephone databases to identify the Carrier Identification Code (CIC) associated with the freephone service provider that serves the freephone number. When a CIC is retrieved from the freephone database for a freephone number, it is used by the PSTN to route the call to the network associated with the freephone service provider where the freephone number is translated again. In the U.S. it is possible to retrieve a POTS number in addition to the CIC at the first freephone number translation. This document describes how Session Initiation Protocol (SIP) can be used to retrieve the routing information from the NP and freephone databases described above and how the retrieved information is used in SIP call processing and signaling. 2. Abbreviations ABNF Augmented Backus-Naur Form CIC Carrier Identification Code (also cic) DNS Domain Name System IETF Internet Engineering Task Force IP Internet Protocol ISUP Integrated Services Digital Network User Part LDAP Light-weighted Data Access Protocol M3UA Message Transfer Part Level 3 User Adaptation MF Multi-Frequency NP Number Portability NPDB Number Portability Database [Page 2] Using SIP to support NP and Freephone Service January 3, 2002 npdi NPDB dip indicator POTS Plain Old Telephone Service PSTN Public Switched Telephone Network RFC Request For Comments rn Routing Number SCP Service Control Point SCTP Stream Control Transmission Protocol SG Signaling Gateway SIP Session Initiation Protocol sigtran Signaling Transport SIP-T SIP for Telephony SS7 Signaling System No. 7 SUA Signaling Connection Control Part User Adaptation TCAP Transaction Capabilities Application Part TRIP Telephony Routing Information Protocol URI Uniform Resource Identifier URL Uniform Resource Locators 3. tel URL and the Proposed Extensions [3] defines the ๔tel๖ Uniform Resource Locator (URL) scheme that describes a connection to a terminal that handles normal voice telephone calls, a voice mailbox or another voice messaging system or a service that can be operated using DTMF tones. [4] proposes the following three extensions to the "tel" URL for supporting NP and freephone service: - "rn," which stands for "Routing Number," carries the routing number used for call routing. This proposed extension can be used to carry any routing information that is different from the directory number even when NP is not involved. - "npdi," which stands for "NP Database (NPDB) Dip Indicator," indicates whether NPDB dip has been performed. - "cic," which stands for "Carrier Identification Code," identifies the freephone service provider/carrier associated with the freephone number in question. If a country uses the CIC codes to identify service providers/carriers that are not limited to the freephone service providers/carriers, this proposed extension can also be used to identify those service providers/carriers even when freephone service is not involved. 4. Accessing NP and freephone Information in the IP Domain The NP or freephone information is typically stored in the Service Control Points (SCPs) in the Public Switched Telephone Network (PSTN). There are several ways for an Internet Protocol (IP) node to access the information in the SCPs. [Page 3] Using SIP to support NP and Freephone Service January 3, 2002 - Connect with Signaling System Number 7 (SS7) network and support the same application layer messages to retrieve the information via SS7 networks. - Support the same application layer messages but use IETF sigtran protocols in the lower layers (e.g., Message Transfer Part Level 3 User Adaptation (M3UA) or Signaling Connection Control Part User Adaptation (SUA) with Stream Control Transmission Protocol (SCTP)) over IP through a Signaling Gateway (SG), which converts from the sigtran protocols to the SS7 network protocols, to access the SCPs in the PSTN. - Some SCPs in the PSTN can support IP-based interface, or Some IP servers in the IP domain can download the NP or freephone information to support NP or freephone service. The latter has one more advantage - URLs that are specific to the IP domain are allowed in addition to the information currently available in the freephone SCPs. Protocols that can be used to access the information may include: * TCAP over sigtran protocols (e.g., M3UA or SUA over SCTP) or other proprietary protocols * SIP * Domain Name System (DNS) * Lightweight Directory Access Protocol (LDAP) The focus of this document is on the SIP-based interface for accessing the NP and/or freephone information. The term "IP Server" is used to refer to the IP node that hosts the NP and/or freephone information, and the term "IP Client" is used to refer to the IP node that generates the SIP INVITE message for getting the NP or freephone information. IP Client can be a SIP proxy server, a SIP user agent (e.g., a PSTN gateway) or a SIP location server. Since SIP protocol does not cover the procedures at a SIP location server, IP Client in this document excludes that case. IP Client must have a trust relationship with IP Server to access the NP and/or freephone information. Freephone information in today's PSTN SCPs may include one geographical number in addition to the CIC. Since the access of the freephone information discussed in this document is via IP-based interface, it is assumed that one or more than one URLs can be retrieved from IP Server and some of those URLs may not contain a telephone number at all (e.g., a sip URL with the format of sip:user@host where user part does not contain a telephone number). It is assumed that whenever those URLs are retrieved, they SHALL NOT contain any of the "cic," "rn" and/or "npdi" parameter in the user part, if exists, of the URL. How those additional URLs are provisioned into IP Servers and whether and how some or all of the freephone information (e.g., the geographical number aspect) is synchronized with that in the PSTN SCPs are outside the scope of this document. [Page 4] Using SIP to support NP and Freephone Service January 3, 2002 5. Using SIP to Retrieve NP or Freephone Information This section describes how IP Client can retrieve NP or freephone information from IP Server that acts as a SIP redirect server. If IP Client simply uses SIP as a database query/response mechanism, it has the option to keep the information carried in the SIP INVITE message minimum to reduce the message size. Assume that "+1-202-533-1234," a geographical number, has been ported, and the routing number associated with it is "+1-202-544- 0000." Another geographical number, "+1-202-544-6789," is not ported. A freephone number,"+1-800-123-4567," is served by a carrier with a CIC of "+1-6789." This freephone number can be mapped to "+1-202-533-1234." IP Server has a host name of 'aaa.bbb.biz,' and IP Client has a host name of 'xxx.yyy.biz.' IP Client needs to be capable of detecting triggers so that it can halt the call processing, retrieve NP and/or freephone information, and resume the call processing using the additional routing information, if available, from IP Server. Only partial SIP INVITE messages and response messages are shown in Section 5 and Section 6 to reduce the document size. The scenarios described in the two sections also server as the examples how SIP can be used to retrieve NP, freephone and other types of information. 5.1 Retrieving NP Information IP Client sends a SIP INVITE message to IP Server. The Request-URI of the INVITE message contains either a tel or sip URL as shown below. tel:+1-202-533-1234 or sip:+1-202-533-1234@aaa.bbb.biz;user=phone "aaa.bbb.biz" identifies IP Server. The host part can be "xxx.yyy.biz" if IP Server allows that IP Client's host name be used in the sip URL of the Request-URI and the SIP INVITE message is addressed directly to IP Server. IP Server, acting as a SIP redirect server, retrieves the routing number, "+1-202-544-0000," associated with the geographical number, "+1-202-533-1234," and return a "302 Moved" response that contains a Contact Header with either a tel URL or sip URL as shown below. tel:+1-202-533-1234;rn=+1-202-544-0000;npdi or [Page 5] Using SIP to support NP and Freephone Service January 3, 2002 sip:+1-202-533-1234;rn=+1-202-544-0000;npdi @xxx.yyy.biz;user=phone IP Client then uses the routing number in "rn" to determine how to route the call. If the geographical number is not ported, IP Server returns a "302 Moved" response that contains a Contact Header with either a tel URL or sip URL as shown below. tel:+1-202-544-6789;npdi or sip:+1-202-544-6789;npdi@xxx.yyy.biz;user=phone Please note that the centralized NP databases only contain routing numbers for telephone numbers that are ported out of the donor switch or network. See [5] for the definition for the donor switch. If IP Server does not have information on a telephone number, it treats it as a non-ported telephone number. So IP Sever always includes the "npdi" if the telephone number is not ported. That telephone number may be an unassigned telephone number. In that case, the call will fail and the caller may hear the network announcement that the telephone number is unassigned. IP Client then uses the POTS number, "+1-202-544-6789," which is equivalent to a "routing number" now, to determine how to route the call. 5.2 Retrieving Freephone Information IP Client sends a SIP INVITE message to IP Server. The Request-URI of the INVITE message contains either a tel or sip URL as shown below. tel:+1-800-123-4567 or sip:+1-800-123-4567@aaa.bbb.biz;user=phone IP Server, acting as a SIP redirect server, retrieves the CIC information, "+1-6789," associated with the freephone number, "+1- 800-123-4567," and returns a "302 Moved" response that contains a Contact Header with either a tel URL or sip URL as shown below. tel:+1-800-123-4567;cic=+1-6789 or sip:+1-800-123-4567;cic=+1-6789@xxx.yyy.biz;user=phone [Page 6] Using SIP to support NP and Freephone Service January 3, 2002 If both the CIC and POTS number are available from the freephone database, the tel or sip URL returned in the Contact Header would be tel:+1-202-533-1234;cic=+1-6789 or sip:+1-202-533-1234;cic=+1-6789@xxx.yyy.biz;user=phone IP Client then uses the CIC information in "cic" in both cases to determine how to route the call. Please note that the freephone number is not returned. It may be in the TO header or can be carried in another header. The latter is for further study. 6. Enhanced Services At IP Server IP Server can provide additional services to IP Client. This section briefly described three enhanced services. IP Server, acting as a SIP proxy server or a SIP redirector, can support additional services in addition to those enhanced services described below. They are outside the scope of this document. 6.1 Terminating PSTN Gateway or IP Server Information In this example, IP Server has both NP information and terminating PSTN gateway or IP server information. It is possible that IP Server determines the next-hop IP nodes instead of the terminating PSTN gateway or IP server. This document only describes the terminating PSTN gateway and/or IP server to simplify the discussion. IP Client sends a SIP INVITE message to IP Server. The Request-URI of the INVITE message contains either a tel or sip URL as shown below. tel:+1-202-533-1234 or sip:+1-202-533-1234@aaa.bbb.biz;user=phone IP Server, acting as a SIP redirect server, retrieves the routing number, "+1-202-544-0000," associated with the POTS number, "+1-202- 533-1234," determines that the next hop server should be "gw1.mmm.nnn.biz" based on the routing number, and returns a "302 Moved" response that contains a Contact Header with a sip URL as shown below. sip:+1-202-533-1234;rn=+1-202-544-0000;npdi @gw1.mmm.nnn.biz;user=phone [Page 7] Using SIP to support NP and Freephone Service January 3, 2002 Please note that "gw1.mmm.nnn.biz" instead "xxx.yyy.biz" appears in the host part of the sip URL. That host name "gw1.mmm.nnn.biz" tells IP Client to route the call to the host "gw1.mmm.nnn.biz." This means that even if "cic" or "rn" appears in the user part of sip URL, it would not be used for routing decision when the host part contain a host name that is not IP Client itself. Please also note that tel URL is not returned in the response because it does not have a host part or another extension to carry the information. If multiple terminating PSTN gateways and/or IP servers can be used to terminate the call, multiple sip URLs corresponding to those PSTN gateways and/or IP servers are returned in one or several Contact Headers. If there are difference preferences in choosing those PSTN gateways or IP servers, the "q" parameter of the Contact Header is used to indicate the preference value. How those preference values are assigned is outside the scope of this document. 6.2 Combined NP and Freephone Information In this example, IP Server has both NP and freephone information, and the freephone information includes the POTS number and the CIC. IP Client sends a SIP INVITE message to IP Server. The Request-URI of the INVITE message contains either a tel or sip URL as shown below. tel:+1-800-123-4567 or sip:+1-800-123-4567@aaa.bbb.biz;user=phone IP Server, acting as a SIP redirect server, retrieves the CIC information, "+1-6789," and POTS number, "+1-202-533-1234," associated with the freephone number, "+1-800-123-4567," and the routing number, "+1-202-544-0000," associated with the POTS number, "+1-202-533-1234," and returns a "302 Moved" response that contains a Contact Header with either a tel URL or sip URL as shown below. tel:+1-202-533-1234;rn=+1-202-544-0000;npdi;cic=+1-6789 or sip:+1-202-533-1234;rn=+1-202-544-0000;npdi;cic=+1-6789 @xxx.yyy.biz;user=phone IP Client then uses the CIC information in "cic" to determine how to route the call. IP Server can support freephone plus the terminating PSTN gateway or IP server information. In that case, IP Client's host name in the sip URL as shown in Section 5.2 is replaced by one associated with a terminating PSTN gateway or IP server. If IP sever supports NP, [Page 8] Using SIP to support NP and Freephone Service January 3, 2002 freephone plus the terminating PSTN gateway or IP server information, IP Client's host name in the sip URL as shown in Section 6.2 is replaced by one associated with a terminating PSTN gateway and/or IP server. Again, if multiple PSTN gateways and/or IP servers can terminate the call, multiple sip URLs with the host part carrying information corresponding to those PSTN gateways and/or IP servers are returned in one or several Contact Headers. IP Server can use different host names for IP Client to request specific service or a set of services. For example, IP Client can use a particular host name to request for NP information for a geographical number and another one for the freephone information for a freephone number. This scheme is outside the scope of this document. 6.3 IP Server Acting As A SIP Proxy Server IP Server also can act as a SIP proxy server instead of a SIP redirect server. In that case, instead of returning the information to IP Client, IP server forwards the SIP INVITE message to the next- hop IP node using the information available from NP and/or freephone database and/or about the terminating PSTN gateways and/or IP servers. If more than one "next-hop IP nodes" can be used, such as in the case of multiple PSTN gateways and/or IP servers, IP Sever can do forking if it supports that function. 7. Processing Guidelines This section discusses the call processing procedures at the SIP proxy servers and SIP user agents that either act as IP Server or IP Client or receive incoming SIP INVITES messages that contain information such as "cic," "rn" and/or "npdi." The SIP user agents described below are the PSTN gateways instead of end user devices such as the SIP phones. 7.1 Processing Guidelines for SIP Proxy Servers or User Agents This section describes the general guidelines for SIP proxy servers or SIP user agents whether they perform IP Client functions or not. They are called "IP Node" below. IP Node MUST have triggers so that it can determine whether to act as IP Client to retrieve NP, freephone and/or other types of routing information when it processes a call with a telephone number during call processing. How to set the triggers and determine when trigger conditions are met during the call processing are outside the scope of this document. No matter what, IP Node SHALL never be triggered to launch a NP query when "npdi " is present or a freephone query when "cic" is present. [Page 9] Using SIP to support NP and Freephone Service January 3, 2002 IP Node SHALL also never be triggered to launch two queries in a row for the same telephone number and same service if the second query is resulted from the processing of a "302 Moved" response to a previous query from IP Server. For example, if the first query is for a freephone number "+1-800-123-4567" and IP Server does not have any information on that number, IP Server returns a "302 Moved" response with the same freephone number but without any additional routing information (e.g., "cic," "rn" and/or a geographical telephone number). IP Client SHALL never be triggered to send another SIP INVTE message for the routing information of the same freephone number. This is to prevent a loop before the caller or any upstream IP node or PSTN switch releases the call. The procedures starts when IP Node receives an incoming SIP INVITE message either directly from another SIP node (e.g., IP Node is a SIP proxy server) or indirectly through the interworking with the PSTN signaling (e.g., IP Node is a PSTN gateway). For the latter case, IP Node SHALL follow the mapping between the SIP and Integrated Services Digital Network User Part (ISUP) or Multi- Frequency (MF) signaling as defined in the "SIP for Telephony (SIP- T)" document [6]. A. If the host part of the URL in the Request-URI field points to another IP Node, IP Node should determine call routing based on that host part of the URL by following the existing procedures. B. If the host part of the URL points to this IP Node and the user part does not contain a telephone number, IP Node SHALL follow the existing procedures to terminate the call to a registered IP device. C. If the host part of the URL points to this IP Node and the user part contains a telephone number but without "cic," "rn" or "npdi" information, or the URL is a tel URL but without "cic," "rn" or "npdi" information: 1. If IP Node is not to perform IP Client functions, it SHALL follow the existing procedures to determine call routing based on the telephone number. This includes the case when IP Node is a PSTN gateway that needs to perform interworking between SIP and PSTN signaling to terminate the call into the PSTN. 2. If IP Node is to perform IP Client functions a. If the trigger conditions are met when processing the telephone number, IP Node MUST halt the call processing and branch to Step A in Section 7.2. b. If the trigger conditions are not met when processing the telephone number, IP Node SHALL follow the existing procedures to determine call routing based on the telephone number. [Page 10] Using SIP to support NP and Freephone Service January 3, 2002 D. If the host part of the URL points to this IP Node and the user part contains a telephone number with "cic," "rn" or "npdi" information, or the URL is a tel URL with "cic," "rn" or "npdi" information: 1. If "cic" and "rn" in addition to a telephone number are present, "cic" MUST be used for determining the call routing. a. In the U.S. a "cic" value of "+1-0110" indicates "local, translated number provided." In that case IP Node SHALL ignore the "cic" and branch to Step D-2. b. If "cic" identifies another network, IP Node SHALL determine call routing based on "cic." This includes the case when IP Node is a PSTN gateway that needs to perform interworking between SIP and PSTN signaling to terminate the call into the PSTN. c. If "cic" identifies the network where IP Node is in - If there is routing data provisioned for that "cic" (e.g., route to other IP Nodes in that network), IP Node SHALL determine call routing based on the provisioned routing data. - If there is no data provisioned for that "cic" at IP Node, IP Node SHALL remove the "cic" and branch to Step D-2. d. IP Node must have default procedures in handling any situation not described above (e.g., unknown "cic" value). One example is that IP Node can remove "cic" and branch to Step D-2. 2. If "rn" and a telephone number are present but without "cic," "rn" MUST be used for determining call routing. a. If "rn" identifies another network or another IP Node in the same network, IP Node SHALL determine call routing based on "rn." This includes the case when IP Node is a PSTN gateway that needs to perform interworking between SIP and PSTN signaling to terminate the call into the PSTN. b. If "rn" identifies the network where IP Node is in but does not identify a particular IP node in that network: - If there is routing data provisioned for that "rn" (e.g., route to other IP Nodes in that network), IP Node SHALL determine call routing based on the provisioned routing data. - If there is no routing data provisioned for that "rn," IP Node SHALL remove the "rn" and branch to Step C-1. [Page 11] Using SIP to support NP and Freephone Service January 3, 2002 c. If "rn" identifies this IP Node, IP Node SHALL remove "rn" and branch to Step C-1. d. IP Node must have default procedures in handling any situation not described above (e.g., unknown "rn" value). One example is that IP Node can remove "rn" and branch to Step C-1. 3. If a telephone number and "npdi" are present but without "cic" and "rn," IP Node SHALL treat the telephone number as a routing number and use it to determine call routing. This includes the case when IP Node is a PSTN gateway that needs to perform interworking between SIP and PSTN signaling to terminate the call into the PSTN. 7.2 Processing Guidelines for IP Client IP Client MUST be upgraded to use SIP-based interface to retrieve routing information from IP Server based on the guidelines below. It is assumed that IP Client has been triggered to launch a query to IP Server. If the telephone number is a local or national telephone number, IP Client MUST convert that telephone number to an international telephone number by adding the appropriate leading digits (e.g., area code and/or country code plus the leading "+") unless IP Server allows a local or national number in the SIP INVITE messages. IP Client MAY have an indication whether IP Server acts as a SIP proxy server or a SIP redirect server so that it can react to the responses received from IP Server properly. If multiple IP Servers can provide the same service, how IP Client selects an IP Server is outside the scope of this document. A. IP Client MUST convert the tel URL to a sip URL if IP Client MSUT use a specific domain name or IP address in the host part of the Request-URI field to invoke particular services at a particular IP Server. The conversion is done by copying everything after "tel:" to the user part of the sip URL and by adding "@" and the host part plus other URI parameters such as "user=phone." A valid telephone number without "cic," "rn" or "npdi" MUST appear in the Request-URI field. IP Client sends a SIP INVITE message to IP Server and waiting for a response to the INVITE message. B. If IP Client decides to cancel the INVITE message at any time before timing out for receiving an informational or a final response to the INVITE message, it SHALL follow the existing procedures to cancel the INVITE message (e.g., send a SIP CANCEL message to IP Server). IP Client MUST have default procedures in [Page 12] Using SIP to support NP and Freephone Service January 3, 2002 handling the call since additional routing information is not retrieved from IP Server. C. If IP Client receives any informational response before receiving a final response to the INVITE message, it SHALL follow the existing procedures in handling the informational response. D. If IP Client times out for receiving a final response to the INVITE message, it MUST have default procedures in handling the call since additional routing information is not retrieved from IP Server. For example, it may try another IP Server, forwards a SIP INVITE message to another IP Client that can do the query, routes the call based on the original telephone number, or drops the call, etc. How exactly IP Client continues the call processing is outside the scope of this document. E. When IP Client receives a final response to the INVITE message, it SHALL follow the procedures below in handling the response. 1. A "200 OK" response is received. This indicates that IP Server, acting as a SIP proxy server, has successfully setup the call to the terminating SIP user agent. IP Client MSUT follow the existing procedures in handling this response. 2. A "302 Moved" response containing one or more Contact Headers is received. IP Client MUST return a SIP ACK message and retrieve the URLs with the associated "q" values, if available, that are usable for call processing (e.g., sip and tel URLs for a voice call). IP Client SHALL NOT relay the "302 Moved" response upstream if IP Server acts as a SIP redirect server. It MAY relay the "302 Moved" response upstream if IP Server acts as a SIP proxy server. a. If IP Client cannot use any of the URLs for call routing (e.g., no sip, tel or h323 URL), IP Client MUST have default procedures in handling this situation. For example, it can use the original telephone number to determine call routing or release the call. b. If only one URL can be used for call routing: - If the URL contains the same telephone number but without additional routing information (e.g., IP Server has no routing information for this telephone number), IP Client MUST have default procedures in handling this situation. - If the URL contains additional routing information (e.g., "cic," "rn" and/or "npdi," IP Client SHALL follow the procedures defined in Section 7.1 to determine how to use the information in the URL for call routing. c. When multiple usable URLs are available for call routing IP Client SHOULD be able to randomly select one if they all have the same preference value, or randomization is weighted [Page 13] Using SIP to support NP and Freephone Service January 3, 2002 according to the ratio of the Preference values if not all the preference values are the same. The exact scheme of selecting one URL from the set of URLs is outside the scope of this document. If IP Client supports forking it can use the URLs and send out multiple INVITE messages in parallel. IP Server MUST follow the existing forking procedures. 3. A "400 Invalid Telephone Number" response is received. IP Client SHOULD log the error and alert the operation personnel so as to check why an invalid telephone number is sent in the INVITE message. 4. A "5xx" response is received. IP Client MAY try other IP Servers if they are available. If no other IP Servers can be used for retrieving routing information for the telephone number, IP Client MUST have default procedures in handling this situation. If a Retry-After Header is in the response, IP Client SHOULD follow the information in the Retry-After Header to send future INVITE messages to that particular IP Server. 5. For all other types of responses, IP Client SHALL follow the existing procedures in handling those responses. 7.3 Processing Guidelines for IP Server This section describes IP Server's behavior in handling the SIP INVITE messages from IP Client. Since IP Server is a special SIP node used for supporting NP, freephone and other enhanced services, this section focuses on the information to be returned in the response. It is assumed that IP Server knows its role, a SIP proxy server or a SIP redirector server, and the requested services when responding to a SIP INVITE message from a particular IP Client. How IP Server accomplishes those is outside the scope of this document. IP Server SHALL follow the guidelines below. The guidelines apply to IP Server acting as either a SIP proxy server or a SIP redirect server unless they are specifically specified for a particular type of IP Server. A. If the received INVITE message contains errors (e.g., missing mandatory headers), IP Server SHALL follow the existing procedures by returning an appropriate final response. The following procedures apply to the cases where the INVITE message can be processed. B. IP Server MAY return a "100 Trying" response in response to the received SIP INVITE message. C. If IP Server cannot support the requested services due to internal problem (e.g., database failure), it MAY send a "503 Service Unavailable" response to IP Client and closes the session. IP [Page 14] Using SIP to support NP and Freephone Service January 3, 2002 Sever MAY include a Retry-After Header to instruct when IP Client can send in the service requests again. IP Server SHALL follow the existing procedures in handling general types of errors that are not specific to IP Server function described in this document. D. IP Server SHALL determine the requested services based on the requesting IP Client's customer profile, or the domain name or IP address in the host part of the URL in the Request-URI field. How IP Server identifies a particular IP Client and how a specific domain name or IP address is used to indicate requested service types are outside the scope of this document. E. If the telephone number in the INVITE message is invalid (e.g., +1 plus nine more digits), IP Server SHALL return a "400 Invalid Telephone Number" response to IP Client and closes the session. F. If no additional routing information can be available for the telephone number in the SIP INVITE message, IP Server SHALL return a "302 Moved" response that contains a Contact Header with a URL that carries the same telephone number but without the additional routing information (e.g., "cic," "rn" and/or "npdi, or a host name or IP address that is different from that of IP Client). IP Server then closes the session. G. IP Server retrieves the routing information associated with the telephone number based on the requested services. IP Server SHALL prepare a URL or a set of URLs to be returned in a "302 Moved" response when IP Server acts as a SIP redirect server or in the outbound SIP INVITE message(s) when IP Server acts as a SIP proxy server. 1. If a geographical telephone number and "npdi" are to be included in the URL (e.g., the geographical telephone number is not ported): a. For a tel URL, the geographical telephone number appears after "tel:" followed by "npdi" (e.g., tel:+1-202-533- 1234;npdi). b. For a sip URL, the same information after "tel:" in G-1-a appears in the user part of the sip URL and IP Client's host name or IP address appears in the host part of the sip URL followed by ";user=phone" (e.g., sip:+1-202-533-1234;rn=+1- 202-544-0000;npdi@xxx.yyy.biz;user=phone). 2. If a geographical telephone number, a routing number and "npdi" are to be included in the URL (e.g., the geographical telephone number is ported): a. For a tel URL, the geographical telephone number appears after "tel:" followed by ";rn=" and the routing number [Page 15] Using SIP to support NP and Freephone Service January 3, 2002 information and by "npdi" (e.g., tel:+1-202-533-1234;rn=+1- 202-544-0000;npdi). b. For a sip URL, the same information after "tel:" in G-2-a appears in the user part of the sip URL and IP Client's host name or IP address appears in the host part of the sip URL followed by ";user=phone" (e.g., sip:+1-202-533-1234;rn=+1- 202-544-0000;npdi@xxx.yyy.biz;user=phone). 3. If a freephone number and a CIC are to be included in the URL (e.g., the freephone number is mapped to a CIC but without a geographical telephone number): a. For a tel URL, the freephone number appears after "tel:" followed by ";cic=" and the CIC information (e.g., tel:+1- 800-123-4567;cic=+1-6789). b. For a sip URL, the same information after "tel:" in G-3-a appears in the user part of the sip URL and IP Client's host name or IP address appears in the host part of the sip URL followed by ";user=phone" (e.g., sip:+1-800-123-4567;cic=+1- 6789@xxx.yyy.biz;user=phone). 4. If a geographical telephone number and a CIC are to be included in the URL (e.g., the freephone number is mapped to a CIC and a geographical telephone number): a. For a tel URL, the geographical telephone number appears after "tel:" followed by ";cic=" and the CIC information (e.g., tel:+1-202-533-1234;cic=+1-6789). b. For a sip URL, the same information after "tel:" in G-4-a appears in the user part of the sip URL and IP Client's host name or IP address appears in the host part of the sip URL followed by ";user=phone" (e.g., sip:+1-202-533-1234;cic=+1- 6789@xxx.yyy.biz;user=phone). 5. If terminating PSTN gateway and/or IP server information are available and are to be included in the URL: a. If a prepared URL is a tel URL, IP Server SHALL convert the tel URL to a sip URL for each terminating PSTN gateway or IP server by appending "@" followed by the host name or IP address of the terminating PSTN gateway or IP server. For example, if there are three terminating PSTN gateways, one tel URL will be turned into three sip URLs. If preference values associated with those terminating PSTN gateways and/or IP servers are available, IP Server, acting as a SIP redirect server, SHALL append "q=" followed by the preference value after the host part of the sip URL. If IP Server acts as a SIP proxy server, IP Server will follow the internal algorithm in using the preference values of those [Page 16] Using SIP to support NP and Freephone Service January 3, 2002 URLs to select a URL for an outbound SIP INVITE message unless forking is supported. b. If a prepared URL is a sip URL, IP Server SHALL replace the host name or IP address in the host part of the sip URL for each terminating PSTN gateway or IP server by the host name or IP address of the terminating PSTN gateway or IP server. Again, if preference values associated with those terminating PSTN gateways and/or IP servers are available, IP Server, acting as a SIP redirect server, SHALL append "q=" followed by the preference value after the host part of the sip URL. If IP Server acts as a SIP proxy server, IP Server will follow the internal algorithm in using the preference values of those URLs to select a URL for an outbound SIP INVITE message unless forking is supported. H. Now IP Server has one or a set of URLs. 1. If IP Server acts as a SIP redirect server, it SHALL return a "302 Moved" response with the URL(s) contained in one or more than one Contact Headers to IP Client. It SHALL follow the existing procedures to re-transmit the same response until it receives an ACK message or times out for receiving an ACK message. 2. If IP Server acts as a SIP proxy server: a. If only one URL is available and no additional routing information is available, IP Server SHALL return a "302 Moved" response to IP Client unless some default procedures where IP Server sends a SIP INVITE message out to the next- hop IP node based on the original telephone number are provisioned. b. If several URLs are available, IP Server SHOULD be able to randomly select one if they all have the same preference value, or randomization is weighted according to the ratio of the Preference values if not all the preference values are the same. The exact scheme of selecting one URL from the set of URLs is outside the scope of this document. If IP Client supports forking it can use the URLs and send out multiple INVITE messages in parallel. IP Server MUST follow the existing forking procedures. 8. Security Considerations The access to the NP and/or freephone data at IP Server is likely to be via dedicated lines, virtual private network and other types of secure connection arrangements. IP Server or a front-end server will block all unauthorized accesses. [Page 17] Using SIP to support NP and Freephone Service January 3, 2002 9. IANA Considerations There is nothing to register with IANA. 10. Conclusion The intention of this document is to describe how SIP can be used to retrieve NP, freephone and/or other types of routing information and how SIP proxy servers and SIP user agents determine call routing based on the additional routing information available from the services supported by IP Server. The specific procedures that are to achieve the above are considered a special way of implementing SIP protocol. NORMATIVE REFERENCES [1] S. Bradner, RFC2026, "The Internet Standards Process -- Revision 3," October 1996. [2] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation Protocol," June 2002. [6] G. Camarillo, et al., RFC3398, " Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping," December 2002. INFORMATIVE REFERENCES [3] H. Schulzrinne and A. Vaha-Sipila, "The tel URI for Telephone Calls," draft-antti-rfc2806bis-07.txt, December 5, 2002. [4] J. Yu, " Extensions to the "tel" URL to Support Number Portability and Freephone Service," draft-yu-tel-url-07.txt, January 3, 2003. [5] M. Foster, T. McGarry and J. Yu, "Number Portability in the GSTN: An Overview," draft-ietf-enum-e164-gstn-np-05.txt, June 24, 2002. Authors' Address James Yu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 U.S.A. Phone: +1-571-434-5572 Email: james.yu@neustar.biz [Page 18] Using SIP to support NP and Freephone Service January 3, 2002 Full Copyright Statement "Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. [Page 19]