WO2012130344A1

WO2012130344A1 - Method for importing identities from internet services to a telecommunication network

Info

Publication number: WO2012130344A1
Application number: PCT/EP2011/070221
Authority: WO
Inventors: Daniel VELASCO BENITO; Andres POZO MUÑOZ; Sonsoles FERNANDEZ VILLARUBIA
Original assignee: Telefonica SA
Current assignee: Telefonica SA
Priority date: 2011-03-25
Filing date: 2011-11-16
Publication date: 2012-10-04
Anticipated expiration: 2013-09-25

Abstract

Present invention refers to a method for importing a second identity of a user from an internet service to a telecommunication network where the user is registered with a main identity. The method comprises: sending a request to the telecommunication network to associate the second user identity to the main identity; notifying the internet service about the request of the user; the user verifying through the internet service that he is the owner of said second identity; and finally associating the second identity of the user to the main identity of the user, as an alias, in a server of the telecommunication network.

Description

METHOD FOR IMPORTING IDENTITIES FROM INTERNET SERVICES TO A TELECOMMUNICATION NETWORK

D E S C R I P T I O N

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to the identification of users in telecommunication networks and more specifically to the import of identities from internet services to next generation networks.

BACKGROUND OF THE INVENTION

Traditional telcos are evolving their legacy core networks to NGNs (Next Generation Networks) based on the all-IP approach. This shift can be described as the use of IP and Internet related protocols for both, communications signalling and media transport (voice, video, instant messaging, etc.) not only in telco's core network but also in access ones. That evolution is telco's response to the Internet technologies push, in order to import their functional improvements and cost reduction derived benefits of the Internet environment to the traditional telco networks and services. However, there are scenarios in Internet-world services such as user identification and generalized routing (for email, blog, IM, etc.) which have not been covered or exploited in telco's domains and more precisely within their NGNs.

NGN networks include a control layer based on the IMS (IP Multimedia Subsystem) standard defined by 3GPP project. This standard was initially intended for mobile networks only but later on it was generalized for other access network technologies (fixed, WLAN, etc) but always within the telco scene. IMS is the telecommunications industry effort to deliver telecom-grade quality multimedia services across fixed and mobile access networks. It is the only open standard aimed to deliver common IP- based services to every access technology telco users.

IMS technology is based on SIP (Session Initiation Protocol, an IP based control protocol) for session negotiation between call parties, through a set of core network entities (CSCFs, Call Session Control Function) which enable routing, authentication, security, policy and charging of the sessions. CSCFs will also provide information to underlying IP transport network about how call media traffic is to be transported. But IMS is more than just a protocol. It is a network architecture for the convergence of speech and data networks, and it is based on a wide range of protocols. IMS is a system designed to provide robust multimedia services over diverse access technologies.

Among the main characteristics the IMS technology provides to a telecommunication network, these can be emphasized:

• End-to-end QoS session oriented multimedia services for the users

• Access technology agnostic network

• Reinforcement of different technology networks convergence

• Charging facilities for multimedia sessions

• Standard based: makes easier different telecommunication networks interoperability

• Authentication, Authorization and Accounting

• CAPEX/OPEX costs savings.

• Open interfaces:3^rd party services

• Legacy networks interconnection

A general principle in IMS conception was to define it as a network infrastructure which relied on Internet derived protocols such as SIP and RTP. However, over the years these protocols have showed limited adoption across the Internet. So, the main nexus between NGNs and Internet continues to be the underlying IP technology. Aside from that, they use different service protocols and procedures for identification, authentication, interconnection, charging, etc. In this landscape, Web 2.0 and NGN continue to be fragmented worlds from the end users' services perspective.

IMS basic operation, e.g. call session establishment, can be summarized as the following. First of all, calling user will dial the called destination ID, which could be codified in form of a SIP or Tel URI. Examples of this could be sip:john@domain.com or tel:+34666999666. URI (Uniform Resource Identification) is a generic concept which defines the structure and requirements of the different possible URI schemes.

A URIs is a string of characters used to identify a name or a resource and the mentioned URI specification provides some common syntactic conventions, for uniform semantic interpretation across different types of URIs. URI specification provides a simple and extensible means for identifying resources: in the common IMS procedures, using the dialled ID, calling party User Equipment (UE) will generate an invitation request (INVITE SIP method). This request will be sent to the IMS entry node, the P-CSCF. This P-CSCF will route the call to the S-CSCF in which calling user is registered to. In case called party is codified as Tel URI, calling S-CSCF will use DNS ENUM procedures to translate Tel URI into a routable SIP URI that identify the called destination IMS network. All this process is depicted in Figure 1.

For the translation of the Tel URI into the destination IMS network, the Calling S- CSCF entity will query the DNS ENUM facilities for NAPTR (Name Authority PoinTeR) records for that domain. First of all, the DNS ENUM client in the S-CSCF will transform the Tel URI dialled by the user into the corresponding domain name to query to.

Continuing with the call session establishment, Calling S-CSCF is responsible for identifying the called party network and re-send the INVITE to the corresponding destination network l-CSCF. I-CSCF will forward the INVITE message to the S- CSCF in which the called party is registered to and, successively, calling S-CSCF will route the invitation to the called party through its P-CSCF. An example of session establishment flow in the IMS using Tel URIs is presented in Figure 1 .

The routing procedure in showed in Figure 1 has the following steps:

1 . The user tries to set up a call to a Tel URI. The IMS client he is using composes a SIP INVITE to the request URI the user dialed, for example: tel:+447700900123.

The INVITE message is sent to the P-CSCF entity of the calling user.

2. The P-CSCF entity will route the SIP signaling to the S-CSCF entity the user is registered to. The S-CSCF entity, after evaluating the iFCs for the calling user, will begin with the routing session procedure in IMS. DNS Enum translation procedure will be executed here to obtain a routable SIP URI (e.g. sip:+447700900123@mnc010.mcc234.3gppnetwork.org), from which l-CSCF info can be extracted from. Details of DNS Enum were presented before in this section.

Once the calling user's S-CSCF entity has the IP address of the I- CSCF entity of the called user, it will forward the INVITE message with the first SIP routable URI the first DNS ENUM query returned as the request URI.

The l-CSCF receives the INVITE message with the routable URI, and will rebuild the Tel URI (destination number is still included in the user part of the routable URI). Once it has the Tel URI, it will query the HSS entity to know the S-CSCF entity the called user is registered into. Once known, it will forward the INVITE message to the S-CSCF.

The S-CSCF entity will route the INVITE message to the called user's P-CSCF.

Finally P-CSCF will deliver the session signaling to the called user's terminal.

It has to be stated here that 3GPP has started an Study Item about the concept of IMS Network-Independent Public User Identities. 3GPP study is focused on enabling IMS user identities in which the domain part is not the typical telecommunication network domain name (@telecommunicationnetwork.com) but a different one, and even users of the same domain could be subscribed to different NGN telecommunication networks. 3GPP explicitly considers that the SIP URI domain of IMS identities could be built from the company domain name for corporate users or even provided by a third party (in case of residential users or corporate users when the company wants to reuse user IDs from other services, like email). However, 3GPP remains constrained to user@domain ID patterns, missing the concept that, by definition, any internet ID is unique by itself. This constrain comes from 3GPP defines new SIP URIs with the imported domain rather than using the imported ID itself as an URI. NGN control layer, based on IMS, defines that users can only be identified by a kind of URI, called SIP URIs. . These SIP URIs are the only type of identification for the users considered in the IMS standard. These URIs can be built from traditional phone numbers (in a standardized way defined by 3GPP) or follow the Internet convention user@domain format. URIs based on telephone numbers are called Tel URIs. More details regarding the standardized method to build Tel URIs can be found at Figure 1 .

So far, with the existing solutions telecommunication networks are working with, a NGN user could have 2 typical NGN/IMS identities:

• TEL URI: 'tel:+34666999666', which represents the user by means of his phone number (E.164).

• SIP URI: 'sip:john@domain.com", representing the user in the classical SIP URI scheme.

Additionally, it is possible to represent the user by means of his E.164 number through a SIP URI: "sip: +34666999666@domain.com;user=phone"

So far, telecommunication network companies represent their NGN users with these 2 types of identities: SIP and Tel URIs. Additionally, some other URIs could be added by the user to this set as user alias of his main identity. However, all of them have to be based on other phone numbers the user may have or additional SIP

URIs which belong to the same telecommunication network domain.

On the other hand, with the massive adoption by the public of all kind of Internet services and the development of the called Web 2.0 paradigm people identify more and more their physical person with their identities in these user-centric services (skype, twitter, email, etc.). Furthermore, some of these Internet services are capturing part of the user's communication habits, which reinforce the identification of the people with their IDs in those new services.

Traditionally, telcos have focused on exporting their identity assets instead of taking advantage of existing user's identities in other domains in their networks/services.

The user identity solution NGN telecommunication networks are working with does not allow users from adding, to their alias group in NGN, other widely-used Internet identifiers such as their email address, skype IDs, blog URI, or any other Internet service. Therefore, a unique solution for managing the multiple identities that a user has in the Internet must be provided for supporting the convergence of Web 2.0 and NGN networks. SUMMARY OF THE INVENTION

The present invention serves to solve the aforesaid problem by providing a method for

importing a second identity of a first user from an internet service to a telecommunication network where the first user is registered with a first identity, called main identity, the method comprises the steps of:

the first user sending a request to the telecommunication network to associate the second identity of the first user to the main identity; the telecommunication network notifying the internet service about the request of the first user to authenticate him;

the internet service authenticating the first user's ownership of the second identity;

the internet service notifying the telecommunication network that the authentication of previous step have been positive;

- the telecommunication network associating the second identity of the first user to the main identity of the first user, as an alias, in a server of the telecommunication network, called authoritative server.

The invention may also comprise the next steps: a second user sending a message to the telecommunication network requesting to establish a communication with the first user through the alias;

the authoritative server of the first user answering the request of the second user sending back to the second user the address of the user, as the alias is associated with the main identity registered in the telecommunication network;

establishing a communication between the second user and the user. Another aspect of the invention refers to codifying the alias into a compatible format with Internet Protocol, the structure of said format is as follows:

Was.lnternetService:Userldentification wherein:

"was" is a fixed identificator for these type of identifications, it is followed by a

"InternetService" is a string that specifies the service from the Internet where the user identification belongs;

"Userldentification" is a string that specifies the identity of the user in the internet service;

The invention also refers to a computer program comprising program code means adapted to perform the steps of the method, when said program is run on a general purpose processor, a digital signal processor, a FPGA, an ASIC, a micro-processor, a micro-controller, or any other form of programmable hardware.

Present invention gives the user the possibility of using any Internet ID in a telecommunication network as a result of the procedure defined. The only condition needed in the invention is that the ID is unique and belongs to the user. A normalization process is defined to transform the Internet ID into a valid format to be used in telecommunication network during session establishment.

Additionally, in this invention is the user, and not the internet service provider, who delegates to use its Internet ID to telecommunication network. Thus, the role of the user is changed, giving to him more control over his own identities.

With the solution proposed in this invention, telecommunication network companies can take advantage of these Internet services and bring them closer to the Next Generation Networks. Saving in computing times and a better use of telecommunication networks resources are also advantages, as the invention allows sharing resources among telecommunication networks. The above features and advantages do not limit the present invention, and those skilled in the art will recognize additional features and advantages upon reading the following detailed description and upon viewing the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

To complete the description that is being made and with the object of assisting in a better understanding of the characteristics of the invention, in accordance with a preferred example of practical embodiment thereof, accompanying said description as an integral part thereof, is a set of drawings wherein, by way of illustration and not restrictively, the following has been represented:

Figure 1 depicts a common session routing procedure in prior art.

Figure 2 depicts a general scheme of the process for associating an internet identity to a telecommunication network.

Figure 3 depicts a sequence of steps involved in a call establishment of a use case of preferred embodiment.

DETAILED DESCRIPTION OF THE INVENTION

The present invention enhance NGN/IMS control layer operation to enable CSCF entities to handle Web 2.0 user IDs, such as email addresses, twitter ID, Skype ID, blog URL, Blackberry ID, etc. which the user has imported to NGN network. Thus, those Internet imported identities could be used to route NGN requests and thanks to that, NGN services will be able to be offered as additional communication services with a unified user experience.

This procedure is referred as New Generation Identity Portability, where the user is allowed to carry with him, not only a phone number, but any other Internet ID he would like to receive incoming NGN requests to.

In particular, it specifies a couple of DDDS applications in order to enable the access to NGN services through Internet identities. These DDDS applications are called Operator and Interconnection WAS DNS (Web 2.0 Alias DNS) which both constitute the WAS DNS Infrastructure.

Also, this invention includes a new URI scheme to represent imported Web 2.0 identities as valid URIs.

These Internet imported identities are not complete IMS user identities in the NGN domain (users are not able to 'register' directly this identities in the IMS domain), but any user can use these identities to set up any kind of communication session with the referred user. The IMS infrastructure is able, by means of the WAS DNS applications, to translate the WAS identity into one of the user's identity in the NGN domain.

Thus, the telco provides their users, some facility to manage the importation of the Internet identities he owns into the NGN domain. A federation procedure is established between the NGN and the owner of the internet service, in order to provide the user a method to demonstrate that he is the legitimate owner of that service identity. This federation facility is based on existing procedures used by internet services to delegate authentication in third parties, in this case, internet services that own the imported ID. Once the user has decided that wants to be reachable in the NGN domain with some internet imported ID, he requests the inclusion of this WAS identity as a WAS DNS alias of his main identity in the NGN domain. Once the federation process is completed, and the user has demonstrated that he is the owner of that service identity, the NGN is able to configure the alias relation in his Operator and Interconnection WAS DNS server. From that time on, any user is able to contact the main user identity through the aliased WAS identity.

In case user decides to become a client for other NGN, he is able to de-federate the internet ID from the previous NGN and federate it in the new one.

When a NGN users establishes a session to a URI corresponding to the WAS identity of another user, the S-CSCF entity of the calling user queries the WAS DNS infrastructure of the telecommunication network, in order to translate this URI into a routable one in the NGN domain. If the called user does not belong to that NGN, it queries a higher hierarchy Interconnection WAS DNS infrastructure (containing entry reference records of all the WAS identities managed by all the NGN) in order to determine the NGN domain that serves the contacted user.

In order to support these user's WAS Identities translations into NGN routable SIP URIs, telecommunication network companies have to deploy in their NGN networks these couple of entities. These WAS DNS applications are not available in the internet domain, but only in the NGN domains and their interconnection.

The entities to de deployed are:

• Operator WAS DNS application: it allows a NGN to translate destination user's WAS Identities (Web 2.0 alias) with a globally routable SIP URI. This application is queried only from the NGN entities, and it only contains the WAS Identities belonging to that telecommunication network's users (it does not contain WAS identities from users of other NGN).

• Interconnection WAS DNS application: it allows a NGN or IPX provider to determine the NGN domain for destination user's WAS Identity and route the request to that domain. Thus, normalized DNS entries will be defined for the aliases, imported from Web2.0. The SIP URI record retrieved from DNS is used to progress the call towards the entry point of the destination domain.

This interconnection WAS DNS entities are structured in a hierarchy with a strict delegation model, similar to the one used by DNS ENUM. There is only one WAS DNS server authoritative over a WAS Identity. If a query is performed against a server that is not the authoritative one to that WAS DNS record, the server will get the response asking some higher WAS DNS server in the hierarchy. In the event that a URI for a Web 2.0 alias is identified to belong to other service provider (based on the result of the query to Operator WAS") it will be managed by the telecommunication network transit function or the IPX provider's interconnection.

The present invention may be summarized in three points: 1- Definition of a generic URI schema

Definition of a generic URI schema, in accordance with the standardized URI schema, to allow the representation of these Internet aliases over URIs. Specification of the associated schemes and protocols to access the most used Web 2.0 alias (e.g. Facebook ID, twitter username, Blog's URL, etc.).

WAS URI is the URI that user devices translates the internet ID to, in order to place it in the NGN destination of the session Some new URI scheme and subschemes are defined to support the indication of

Web 2.0 aliases as origin or destination public user identities in NGN. The solution described in this invention does not limit the type of internet IDs to be used as alias of the NGN identity of the user. It just defines an initial set of them and a general procedure for these aliases construction.

The structure of the Web 2.0 alias IDs (WAS URIs) follow the following URI structure:

was.lnternetService:Userldentification

_ J <scheme name>:<hierarchical part>

The scheme name for Web 2.0 IDs URIs is composed of:

• was fixed identificator for these type of URIs. It is followed by a · InternetService string that specifies the Web 2.0 service the URI is about.

•

The hierarchical part of the WAS URI is the user's identification in the internet service.

For example, a WAS URI for the identity of user JhonDoe in twitter service

(@johndoe) would be:

I was.twittenjohndoe In this example, "twitter" is the chosen InternetService part in the scheme name for Twitter.com service. The hierarchical part of the URI is johndoe, as the username for the user in twitter is @johndoe.

This general procedure for WAS URI construction should be defined for every new type of identity to be used in this model. Some examples are provided in the following table, although the model, with the general WAS URI schema explained before, is extensible to any internet service ID.

The Internet environment user's identities will behave as aliases of the main identity (SIP URI) of the user in the NGN Domain. As these identities belong to the user themselves, the telecommunication network must provide some facility for the user to manage their aliases.

On the other hand, it has to be ensured that the user who claims the use of the

Internet identity in the NGN infrastructure is the authentic owner of that identity. NGNs have to establish some federation procedure for the user in order to let him prove their own the identity. This procedure is different depending on the type of identity the user wants to use in NGN domain.

A general scenario of this federation procedure is depicted in Figure 2. The general steps for the federation process: 1 1 . The process begins when the user wants to use one of his Internet identities to be contacted in his NGN subscription with his Telco.

To enable the user of these internet aliases in his NGN domain, the NGN provides some facility for its users to be able to manage these identities in the NGN domain. Making use of this NGN User Identity management infrastructure, the user requests the new alias (corresponding to the new Internet Identity he wants to use) to be an additional NGN identity for his subscription.

12. Telco User identity management system, once it receives the user alias use request, begins with the verification process that the user identity is owned by the user that requested its use.

For this ownership verification, the user will get notified by Telco User Identity Management system that the use of that Internet service user identity as a NGN alias has been requested.

13. Some kind of notification is sent to the user through the Internet service whose identity the user want to alias into the NGN domain: Eg: a email, a skype or blackberry message. This message contains a method for the user to grant he is the appropriate user of that identity. User would grant the permission for the alias set up by some mean the telecommunication network sets in the notification sent to the user.

14. User authenticates himself to verify that he owns the Identity with the method the telecommunication network included in step 3's message.

15. Telco User Identity Management System receives the user's confirmation to set up the alias with the internet identity in the NGN domain. At this point the telecommunication network knows that his user is the owner of the internet identity and they have granted permissions for the alias.

16. The alias is set up in the Operator WAS DNS for internal queries from the telecommunication network.

17. The alias record is set up also in the Interconnection WAS DNS for queries inter - telecommunication networks in the IPX. From this moment on the user can be reached through this Internet identity alias into the NGN domain.

The same infrastructure and procedures are used in case the user wants to de- federate a previous imported Internet ID, e.g., in case of portability to another telecommunication network.

2- Operator WAS DNS Application.

Definition of a DDDS (Dynamic Delegation Discovery System) Application over DNS to translate these Internet aliases into globally routable SIP URIs, in the form of a private, Operator WAS DNS.

Operator WAS DNS entity takes user's Web 2.0 ID and replaces it with a SIP URI which belongs to the same user and is globally routable within the NGN domain. This is true in case the requested Internet ID has been federated in the telecommunication network in which the request is done. If it is federated in other telecommunication network, local Operator WAS DNS provides no answer.

Every telecommunication network owns its own internal Operator WAS DNS infrastructure.

Application Unique User's Web 2.0 identity as a valid URI, taking into account String the URI formats and schemes defined before.

First Well Known The URI to be queried will be replaced in the following way: Rule operatorwdns will be set as first level domain for the query.

The "was." Part of the URI will de discarded. Then the type of was URI as second level domain, and the other part of the URI (colon not considered).

So was.twittenjohndoe would be transformed into johndoe. twitter, operatorwdns for the query

Or was.email:johndoe@gmail.com would become johndoe.gmail.com. email. operatorwdns

Valid Database DNS Database.

Expected Output In case the user belongs to its NGN Domain, a SIP URI in that NGN domain. Otherwise, this operator WAS DNS will not provide a positive answer.

Rule Format for each Flags:

of the NAPTR only "U" is possible, since URIs are the only possible records output.

Services:

service-field = "W2U" 1 ^*(servicespec)

servicespec = "+" wasservice

wasservice = type (T(subtypespec) subtypespec = ":" subtype

type = 1 ^*32(ALPHA / DIGIT)

subtype = 1 ^*32(ALPHA / DIGIT)

Where the basic was service will be SIP, without subtypes.

3- Interconnection WAS DNS Application.

Definition of a DDDS Application over DNS to translate these Internet aliases into URIs which point at the destination domain, for the cases where the Web 2.0 service belongs to other service provider different from the NGN. This is the Interconnection WAS DNS.

It takes user Web 2.0 ID and replaces it with a URI which includes the domain of the NGN authoritative for that user. It differs in the Operator WAS DNS application since:

• It is aimed at resolving the Web 2.0 ID with the corresponding NGN domain, not with the associated user SIP URI.

• It is transparent to end-users.

• Contains data used for routing purposes which can only be accessed by those connected to the telecommunication network interconnection infrastructure (e.g. IPX).

Interconnection WAS DNS is shared resource among telecommunication networks, typically provided as a service by the interconnection provider. Application Unique User's Web 2.0 identity as a valid URI, taking into account String the URI formats and schemes defined before.

First Well Known The URI to be queried will be replaced in the following way: Rule interconnectionwdns will be set as first level domain for the query. The "was." Part of the URI will de discarded. Then the type of was URI as second level domain, and the other part of the URI (colon not considered).

So was.twitteqohndoe would be transformed into johndoe. twitter, interconnectionwdns for the query

Or was.email:johndoe@gmail.com would become johndoe. gmail.com. email. interconnectionwdns

Valid Database DNS Database.

Expected Output A SIP URI which is composed by:

- Sip as scheme

- The entry key without interconnectionwdns as username part.

- As domain, a sequence formed as: mnc<MNC>.mcc<MCC>.3gppnetwork.org

- User-parameter as "was-uri".

E.g., sip: johndoe. twitter @mnc12.mcc123.3gppnetwork.org;user=was-uri

Rule Format for Flags:

each of the NAPTR only "U" is possible, since URIs are the only possible records output.

Services:

service-field = "W2U" 1 ^*(servicespec) servicespec = "+" wasservice

wasservice = type 0^*(subtypespec)

subtypespec = ":" subtype

type = 1 ^*32(ALPHA / DIGIT)

subtype = 1 ^*32(ALPHA / DIGIT)

Where the basic service will be SIP, without subtypes. Use case

A call establishment of a use case is showed, in a detailed description.

WAS DNS infrastructure is showed interacting with NGN networks to route a call directed to a previously imported Internet ID.

A sequence of steps involved are represented in Figure 3 and explained below:

21 . A user makes a NGN request (e.g. a multimedia call) towards a destination user, using a Web alias such as his twitter ID (e.g. @williampt)

At this point, the IMS client in the calling user's terminal will generate a SIP INVITE message with the request URI from the ID the user dialed to, this is the WAS URI. Applying the rules presented before the WAS URI corresponding to twitter ID @ williampt will be:

was . twi tte r : wi 11 i am pt

22. The IMS core entity in the calling user's NGN domain (S-CSCF in NGN) will check the request URI of the INVITE sip message. It realizes that it is a WAS DNS URI (from the prefix was.twitter:) and it will try to resolve user's Web 2.0 ID into a routable SIP URI through the Operator WAS DNS application.

In this case the S-CSCF entity will query in the Operator WAS DNS the following domain to get a NAT PR entry for the DNS service "W2U".

williampt.twitter.operatorwdns

This domain name is built following the definition of Operator WAS DNS. It is supposed that the Operator WAS DNS entity will answer "Domain not found" as user owning this WAS DNS record does not belong to the calling user's NGN.

23. At this point, the IMS Core has to query the Interconnection WAS DNS in order to determine the IMS domain destination of the session.

The IMS Core queries the following domain to Interconnection WAS DNS to get a NAT PR entry for the DNS service "W2U":

williampt. twitter.interconnectionwdns This domain name is built following the definition of Interconnection WAS DNS. It is supposed that some NGN has imported this internet ID, so the answer of the Interconnection WAS DNS would be:

NAPTR 10 TOO "u" "W2U+sip" "!V$!sip:williampt.twitter

@mnc002. mcc234.3gppnetwork.org; user=was-uri"

This SIP URI will be set as new Request URI for the INVITE message sent to the called user's IMS domain. But some new queries will be performed to get the IP address where the INVITE message has to be sent. These queries are not specific of this invention but the regular ones for routing SIP URIs.

mnc002.mcc234.3gppnetwork.org domain is queried, and a record with "server" flag is got:

mnc002.mcc234.3gppnetwork.org. IN NAPTR 50 100 "SIP+D2U" _sip._udp.example.com.

The server _sip._udp.example.com server is queried, and the result is some SRV records:

_sip._udp.example.com. SRV 0 1 5060 sipserv1 .example.com.

_sip._udp.example.com. SRV 0 2 5060 sipserv2.example.com.

Finally sipserv1 .example.com server is queried and the IP address register is got:

sipservl .example.com. IN A 101 .1 .2.3

At this point, the calling user's S-CSCF will send the INVITE message to the IP it got in the previous DNS queries. The request URI will be the one get in the first WAS DNS query:

sip: williampt.twitter@mnc002.mcc234.3gppnetwork.org; user=was-uri

24. The l-CSCF entity in the called user's IMS domain will be the first entity to get the INVITE message.

25. The l-CSCF will check the "user" attribute in the request URI and in case it is set to 'was-uri', will get the original WAS URI the calling user dialed and will query it in its Operator WAS DNS. williampt.twitter.operatorwdns

NAPTR 10 100 "u" "W2U+sip" "!^A.^*$!sip:william@operator2.com!" . In this point, Operator WAS DNS provides an answer taking into account that Internet ID is supposed to be previously imported by destination NGN. From that answer, the 'native' NGN ID corresponding to the imported Internet ID will be:

sip:william@operator2.com

Once the l-CSCF has a 'native' IMS identity of the called user, it will check in the HSS for the S-CSCF entity the called user is registered to. The l-CSCF then changes the request URI to the sip URI WAS DNS answered the query, and forwards the INVITE to the called user's S-CSCF entity.

26. The l-CSCF will send the INVITE to the S-CSCF entity the called user is registered to. The S-CSCF makes the signaling reach to the called user's terminal.

27. Call is established between both parties. From this point, the treatment of the call in NGN will be the same that any other NGN session.

The variants from the previous flow could be:

a) In case Internet ID would be federated by a user of the calling user NGN, the answer to the request to Operator WAS DNS would be directly the SIP URI of the destination user, so no further request to Interconnection WAS DNS is needed.

b) In case Interned ID would not be federated by any NGN, the answer from Interconnection WAS DNS would be "Domain not found" and calling S-CSCF will reject the called with a corresponding '404 User not found' answer.

Claims

1. - A method for importing a second identity of a first user from an internet service to a telecommunication network where the first user is registered with a first identity, called main identity, the method comprises the steps of:

the telecommunication network associating the second identity of the first user to the main identity of the first user, as an alias, in a server of the telecommunication network, called authoritative server.

2. - The method according to claim 1 further comprising the next steps:

a second user sending a message to the telecommunication network requesting to establish a communication with the first user, identifying the first user by the alias;

the authoritative server of the first user answering the request of the second user obtaining the main identity associated to the alias, as the alias is associated with the main identity registered in the telecommunication network;

establishing a communication between the second user and the first user using the main identity.

3. - The method according to claim 2 wherein sending the message to request establishing a communication, further comprising codifying the alias into a compatible format with Internet Protocol, the structure of said format is as follows:

was.lnternetService:Userldentification wherein:

"InternetService" is a string that specifies the service from the Internet where the first user identification belongs;

"Userldentification" is a string that specifies the identity of the first user in the internet service;

4. - The method according claim to 3 wherein the message sent to request establishing a communication between the second user and the first user is a SIP INVITE message directed to first user alias.

5. - The method according to claims 4 wherein the SIP INVITE message directed to first user alias is detected by a node of the telecommunication network.

6. - The method according to claim 5 wherein, when detecting the SIP INVITE message directed to first user alias, further comprising:

- sending a query, requesting the main identity of the first user for establishing a communication, to the authoritative servers of the telecommunication network;

- if the query is answered by the authoritative server of the first user, obtaining the main identity of the first user and establishing the communication;

- if the query is not answered and the main identity is not obtained, sending a query to an interconnection authoritative server to obtain the telecommunication network which the first user belongs;

- once obtained the telecommunication network, the call is sent to that telecommunication network where the first user belongs.

- when the call reaches a destination user, telecommunication network, recovering the original first user alias, sending a query for establishing a communication to its authoritative servers and waiting the answer of the authoritative server of the first user for establishing the communication.

7. - The method of previous claims wherein the telecommunication network is a Next Generation Network.

8.- The method of previous claims wherein the second user identity is an internet service user ID.

9.- The method of previous claims wherein the first user and the second user belong to different telecommunication networks.

10.- A computer program comprising program code means adapted to perform the steps of the method according to any claims from 1 to 9 when said program is run on a general purpose processor, a digital signal processor, a FPGA, an ASIC, a micro-processor, a micro-controller, or any other form of programmable hardware.