The patent's inventors are Arauz-Rosado, Jesus-Javier (
This patent was filed on
From the background information supplied by the inventors, news correspondents obtained the following quote: "The following abbreviations are herewith defined, at least some of which are referred to within the ensuing description of the prior art and the present invention. 3GPP Third Generation Partnership Project AS Application Server CSCF Call Session Control Function DNS Domain Name System HSS Home Subscriber Server IAM Initial Address Message IBCF Interworking Border Control Function I-CSCF Interrogating CSCF IMS IP Multimedia Subsystem IP Internet Protocol MGCF Media Gateway Control Function MMS Multimedia Messaging Service POTS Plain Old Telephone Service PSTN Public Switched Telephone Network PUI Public User Identity RFC Request For Comments RTP Real-Time Transport Protocol S-CSCF Serving CSCF SIP Session Initiation Protocol SLF Subscription Locator Function TCP Transmission Control Protocol UA User Agent UE User Equipment URI Uniform Resource Identifier UTM URI Translation Module
"An IMS network is an IP-based network that enables User Agents (UAs) of an IMS network, as well as User Equipments (UEs) of other legacy networks, to establish multi-media sessions to other UAs so they can exchange any kind of real-time information (e.g. voice, video) or non-real-time information (e.g. messages, pictures). In its current state, the IMS network uses a SIP protocol to establish the multi-media sessions and a transport protocol like e.g. RTP to carry the payload of the multi-media sessions.
"In the IMS network, the information is routed on a multi-media session that was established with the target user by using an URI that identifies that user and by using a set of well-defined routing rules that must be followed by all of the elements within the IMS network. This set of rules is defined for 3GPP-compliant IMS networks in 3GPP TS 24.229 V.5.14.0 (
"There are two types of URIs that can be used to identify a particular target user when establishing a multi-media session: (1) SIP URIs; and (2) tel URIs. A SIP URI has a format that is defined in RFC3261 which is entitled 'SIP: Session Initiation Protocol'
"While, the format of a tel URI is defined in RFC3966 which is entitled 'The tel URI for Telephone Numbers' (the contents of which are incorporated by reference herein). Examples of tel URIs are: tel:+1-234-567-89 tel:2997;phone-context=+3491339
"In addition, there is a way to express a SIP URI with an embedded tel URI which is discussed in RFC3261. For instance, the exemplary tel-URIs could be embedded within SIP URIs as follows: sip:+firstname.lastname@example.org;user=phone sip:2997;email@example.com;user=phone
"A section of the set of routing rules mentioned above is devoted to routing calls between two different network operators. Specifically, when routing a call between two network operators a SIP URI or SIP URI/embedded tel URI must be used to identify the target user for the call. FIG. 1 (PRIOR ART) is a signal flow diagram used to help describe a first routing process, namely the inter-operator process of using a SIP URI/embedded tel URI to route a call from a UA.sub.1 located in an originating network 102 to a UA.sub.2 located in a terminating/destination network 104. The steps are as follows (reference is made to 3GPP TS 24.229 for more details): 1-3. The originating S-CSCF.sub.1 receives a SIP request (e.g., INIVITE tel: +123) from UA.sub.1 (step 1). The S-CSCF.sub.1 takes a Request-URI from the received session-initiating INVITE request and if the Request-URI contains a tel URI then S-CSCF.sub.1 queries an ENUM.sub.1 service (step 2). The ENUM.sub.1 changes the tel URI into a SIP URI/embedded tel URI (e.g., sip: +firstname.lastname@example.org;user=phone) and sends it to the S-CSCF.sub.1 (step 3). The S-CSCF.sub.1 replaces the original Request-URI in the SIP request with the SIP URI/embedded tel URI obtained from the query to form a new SIP request (e.g., INVITE sip: +email@example.com;user=phone). 4. The originating S-CSCF.sub.1 takes the domain part (e.g., op.com) of the new Request-URI and forwards the new INVITE SIP request to the address identified by that domain (if the domain is an IPv4 or IPv6 address the INVITE can be forwarded to that address straight away, otherwise a DNS needs to be queried using the domain part to obtain a destination IP address, which corresponds to either an IBCF or an I-CSCF.sub.2 in the terminating network 104). In this example, the S-CSCF.sub.1 forwards the new SIP request (e.g., INVITE sip: +firstname.lastname@example.org;user=phone) directly to the I-CSCF.sub.2 (step 4). 5-6. The I-CSCF.sub.2 is the first CSCF contacted for the terminating call and has the role of locating the S-CSCF.sub.2 that is serving the UA.sub.2 to which the call is targeted. To locate the S-CSCF.sub.2 that serves UA.sub.2, the I-CSCF.sub.2 may need to use two network databases: (1) the SLF.sub.2; and (2) the HSS.sub.2. The SLF.sub.2 is a database location function that finds the specific HSS.sub.2 instance which holds the UA.sub.2's subscriber data (including which S-CSCF.sub.2 is currently serving them), and is used when there are multiple HSSs instances in the terminating network 104. In this example, the I-CSCF.sub.2 uses the Request URI in the SIP request as a public user identity to send a query (e.g., Dx-Location-Query PUI=sip: +email@example.com;user=phone) to the SLF.sub.2 (step 5). Then, the SLF.sub.2 sends a response (e.g., Dx-Location-Query_Rsp Server-Name=HSS.sub.2) which indicates the HSS.sub.2 back to the I-CSCF.sub.2 (step 6). In the event there is a unique HSS in the network, then the SLF.sub.2 and steps 5-6 may be omitted. 7-8. The I-CSCF.sub.2 uses the Request URI in the SIP request as a public user identity to send a query (e.g., Cx-Location-Query PUI=sip: +firstname.lastname@example.org;user=phone) to the HSS.sub.2 (step 7). Then, the HSS.sub.2 sends a response (e.g., Cx-Location-Query_Rsp Server-Name=S-CSCF2.sub.2) which indicates the S-CSCF.sub.2 back to the I-CSCF.sub.2 (step 8). 9-10. Once the I-CSCF.sub.2 has located the S-CSCF.sub.2 it routes the call (e.g., INVITE sip: +email@example.com;user=phone) to that S-CSCF.sub.2 (step 9). The terminating S-CSCF.sub.2 then uses its internal location table to route the INVITE request to the contact address registered by the target user UA.sub.2 (in the example above this contact address is B-UE@op.com) (step 10). If there is no contact address registered, but the target user UA.sub.2 has activated some service which has an unregistered state, then the S-CSCF.sub.2 forwards the SIP request to the AS indicated by the service information stored within the S-CSCF.sub.2.
"Referring to FIG. 2 (PRIOR ART), there is a signal flow diagram which is used to help describe a second routing process, namely the routing process that takes place when a call does not come from a peer S-CSCF.sub.1 in a remote network 102 as discussed above but instead when it comes from a MGCF.sub.1. This particular second routing process occurs when a user UE.sub.3 is located in a PSTN 202 and initiates a call with a tel URI towards the UA.sub.2 which is located in the IMS terminating network 104. The steps for this particular routing process are as follows (reference is made to 3GPP TS 24.229 for more details): 1a. The MGCF.sub.1 has a PSTN signaling interface that receives an IAM sent from UE.sub.3 (step 1a). The MGCF.sub.1 uses the IAM to obtain the target user's E.164 number and generate an INVITE SIP request that includes a Request-URI field which has either a tel URI (containing the E.164 number) or a SIP URI (with embedded E.164 number). 2a. In this particular example, the INVITE SIP request includes a tel URI (e.g., tel:+123) (compare this step 2a to step 4 in FIG. 1). The MGCF.sub.1 forwards the INVITE SIP request (e.g., INVITE tel:+123) to the I-CSCF.sub.2 which is located in the terminating network 104 (step 2a). 3a-8a. The steps 3a-8a are similar to steps 5-10 from the previous routing procedure shown in FIG. 1 except that a tel URI (e.g., tel:+123) is used in some of the signals rather than the SIP URI (e.g., sip:+firstname.lastname@example.org;user=phone).
"Unfortunately, the routing procedures described above presents some problems:
"Accordingly, there has been and is a need to address these shortcomings and other shortcomings associated with the prior art. These needs and other needs are satisfied by the present invention."
Supplementing the background information on this patent, VerticalNews reporters also obtained the inventors' summary information for this patent: "The present invention proposes a specific handling of tel URIs in an IMS terminating network so as to enable routing of calls using telephone numbers (and not SIP URIs with embedded telephone numbers) as identifiers of the target users of those calls. Specifically, the present invention introduces a conversion module which is located within the IMS terminating network and is capable of converting SIP URIs with embedded telephone numbers into equivalent tel URIs which are then used by a terminating I-CSCF and S-CSCF to query the SLF and/or HSS so that they can to route the calls to the target users.
"In one scenario, the conversion module can convert a SIP URI/embedded with a telephone number into an equivalent tel URI by: (1) extracting a target user part from the SIP URI/embedded with the telephone number; and (2) pre-pending the target user part with a string 'tel:' to generate the equivalent tel URI. In another scenario, the conversion module can convert a SIP URI/embedded with a telephone number into an equivalent tel URI by: (1) extracting a first set of digits, namely a phone context descriptor (the phone context descriptor can be either a domain name or a global number prefix), located after the 'phone-context' argument in the SIP URI/embedded with the telephone number; (2) extracting a second set of digits located after a 'sip:' argument in the SIP URI/embedded with the telephone number and before the 'phone-context' argument; and (3) pre-pending a string 'tel:' before the first set of digits after which the second set of digits are inserted to generate the equivalent tel URI. In yet another scenario, the conversion module can convert a SIP URI/embedded with a telephone number into an equivalent tel URI by: (1) extracting a first set of digits, namely a phone context descriptor, located after the 'phone-context' argument; (2) extracting a second set of digits which are located after the 'sip:' but before the 'phone-context' argument; (3) using the first set of digits (phone context descriptor/global network prefix) as key to a pre-configured table of substitution rules to find a set of substitution rules; (4) applying these substitution rules to the second set of digits to produce a third set of digits, and (5) pre-pending a string 'tel:' before the third set of digits to generate the equivalent tel URI.
"Moreover, the present invention includes an I-CSCF that has receiver for receiving a SIP Request and a processor for determining if the SIP Request has a request URI that includes a SIP URI/embedded telephone number. In one scenario, the processor determines that the SIP request has a SIP URI/embedded telephone number if there is a 'user=phone' argument in the request URI. If the SIP request has a SIP URI/embedded telephone number, then the I-CSCF has a query device that forwards the request URI towards a conversion module (which generates a corresponding tel URI from the SIP URI/embedded telephone number) and then receives the corresponding tel URI from the conversion module. Thereafter, the processor removes the SIP URI/embedded telephone number and inserts the received tel URI in the request URI of the SIP request to form a revised SIP request. Lastly, the I-CSCF has a sender that submits the revised SIP request including the request URI with the corresponding tel URI towards a S-CSCF.
"In addition, the present invention includes an S-CSCF that has receiver for receiving a SIP Request and a processor for determining if the SIP Request has a request URI that includes a SIP URI/embedded telephone number. In one scenario, the processor determines that the SIP request has a SIP URI/embedded telephone number if there is a 'user=phone' argument in the request URI. If the SIP request has a SIP URI/embedded telephone number, then the S-CSCF has a query device that forwards the request URI towards a conversion module (which generates a corresponding tel URI from the SIP URI/embedded telephone number) and then receives the corresponding tel URI from the conversion module. Thereafter, the processor removes the SIP URI/embedded telephone number and inserts the received tel URI in the request URI of the SIP request to form a revised SIP request. Lastly, the S-CSCF has a sender that submits the revised SIP request including the request URI with the corresponding tel URI towards a terminating network.
"An advantage of the present invention is that since the I-CSCF and S-CSCF can route calls using the equivalent tel URIs then the SLF and/or HSS only need to maintain tel URIs of the target users and not maintain both the tel URIs and the SIP URI/embedded tel URIs of the target users. Another advantage of the present invention is that the conversion module can obtain the originally dialed telephone numbers of the target users which might have been stripped-off from the SIP request by a S-CSCF in the originating network and this is desirable since the terminating network may need the originating telephone numbers to support telephone number based services or legacy services like e.g. MMS."
For the URL and additional information on this patent, see: Arauz-Rosado, Jesus-Javier; Alriksson, Fredrik. IMS Call Routing Using tel-URIs. U.S. Patent Number 8619794, filed
Keywords for this news article include: Telecommunications, Telefonaktiebolaget LM Ericsson.
Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC
Most Popular Stories
- Obama Administration Releases Proposal to Regulate For-Profit Colleges
- Apple, HP, Intel May Take a Hit from Slowdown in Smartphone Sales Growth
- Elizabeth Vargas' Husband Marc Cohn Addresses Rumors
- Keurig Adds Peet's coffee, Alters Starbucks deal
- Motley Crue's Nikki Sixx Marries Model Courtney Bingham
- U.S. to Relinquish Gov't Control Over Internet
- FDIC Files Lawsuit on Behalf of Banks Allegedly Hurt by Libor Scandal
- Chinese e-Commerce Giant Alibaba Gears for IPO in U.S.
- Some California Cities Seeking Water Independence
- Quiznos Files for Chapter 11