Abstract:
A method, telecommunications node, and User Equipment (UE) are provided for transmitting a user identifier such as a Uniform Resource Locator (URL) in a presence document of a user, and for using that URL for handling communications. When an a first user, e.g. an IMS user communicates with a second user, e.g. an IMPS user, oftentimes the first user only knows the Mobile Station International Subscriber Directory Number (MSISDN) of the second user, and not also his URL. The invention allows for the transmissions of the second user&#39;s URL inside a presence document relative to that second user. The first user subscribes to presence information relative to the second user, and receives a presence document that includes, along the second user&#39;s presence information, also the second user&#39;s URL. Then, the first user uses the URL for handling communications with the second user, including initiating outgoing communications, or handling incoming communications from the second user.

Description:
TECHNICAL FIELD  
       [0001]    The present invention relates to the area of telecommunications, and in particular to the area of communications addressing. 
       BACKGROUND  
       [0002]    Mobile Instant Messaging (IM) based on Presence is expected to become more and more widespread in the years to come. The Open Mobile Alliance (OMA) provides a standard set of specifications, called Instant Messaging and Presence Services (IMPS) that telecom operators can use to host IMPS services for mobile terminals. The Wireless Village consortium developed the first cut of the specifications. After Wireless Village was merged with OMA, its specifications became the OMA IMPS 1.0 specifications. IMPS is widely deployed but not necessarily marketed. Interworking between several operators&#39; IMPS platforms is being performed under the GSM Association (GSMA) initiative that encourages interworking and deployment of IM. Vanilla terminals (i.e simpler phones) often have IMPS clients. On Nokia terminals, the chat client is accessed via the “My Presence” menu. On Sony Ericsson terminals, it&#39;s called “My Friends”, while on Motorola terminals it&#39;s called “IM”. 
         [0003]    OMA also provides technical specifications using the Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) extensions to provide IMS based presence services, such as—for example—defined by OMA Presence SIMPLE V1.0.1, and IM services such as—for example—defined by OMA SIMPLE IM V1.0. On the other side, presence and messaging services based on the IP Multimedia Subsystem (IMS) are seen as a longer term solution and, for now, many systems only implement IMPS as defined by the OMA specifications. Thus, many operators interested in providing mobile IM based on Presence are deploying IMPS solutions. 
         [0004]    Then again, some telecom manufacturers offer only IMS-based Presence and Instant Messaging (IMS-M) products, enhanced with an inter-working solution between IMS-M (based on SIP/SIMPLE) and IMPS. This inter-working capability is deemed important for systems to be able to inter-communicate. However, it has not been completely standardized yet and, as a result, there is currently no smooth interoperability between IMS-M and IMPS. 
         [0005]    In order to facilitate such interoperability, the GSMA issued a draft guideline specification, called “DRAFT SIP SIMPLE Interconnect Technical Implementation Document for Personal IM”, document number IPIAG Gen Doc 005 — 06r1, dated 18 Oct. 2006, (all of which is hereby included by reference), which describes the technical implementation details and call flows for interconnecting IM communities across operators. The specification dictates that different operators with different IM solutions should use SIP/SIMPLE protocols to communicate across a Network-to-Network Interface (NNI). In particular, the GSMA specifications (as e.g. shown in section 4.1) include the sequence of messages between the operator&#39;s inter-working gateways when a user in one system adds a contact to his/her terminal&#39;s contact book (also called address book or contact list), when the contact belongs to a user in the other system. This is also aligned with the OMA specifications (currently in initial draft version). Such addition of a user in a terminal contact book may serve subsequently for initiating communications from that terminal with a given user from the other network. 
         [0006]    Typically, for both IMS and IMPS systems, IM users are identified with a user identity in the form of a Uniform Resource Locator (URI), alike “UserPart@domainPart”, such as for example John.Doe@OperatorX.com. However, it is also known and possible to identify a user by the telephone number of his mobile terminal (the Mobile Station International Subscriber Directory Number, or MSISDN). As a result, in both IMS and IMPS networks, a user may have two identities (including when they use their mobile terminals to access the IM service). 
         [0007]    According to the GSMA specification, when the user&#39;s MSISDN is used to contact a user from another network for the purpose of, for example Presence or IM, in the process of verifying the user, the other network is required to return the user identifier (user ID, e.g. the Uniform Resource Locator, or URL) associated with the MSISDN, and all subsequent signalling related to that user is required to use the user&#39;s URL, thus requiring the network to remember the association between the originally signalled MSISDN and the subsequently used URL. This is specified in section 4.1.1.1 of the GSMA specification mentioned above and also in section 5.7 of OMA specification called “IMPS SIP/SIMPLE Interworking Function Requirements”, Draft Version 1.0, dated 14 Aug. 2007, document number OMA-RD-IMPS_SIP_SIMPLE-V1 — 0-20070814-D, all of which is hereby included by reference. 
         [0008]    Reference is now made to  FIG. 1  (Prior Art) that shows an example of the interworking problem existing between an exemplary system  102  for IMS-M (IMS-M system) and a system  104  for IMPS (IMPS system). Shown in  FIG. 1  is a highly simplified view of a global network  100  comprising the IMS-based system  102  providing IMS-M services (not all of which is shown for simplicity purposes) connected to the IMPS system  104  (not all of which is shown for simplicity purposes) providing IMPS services via an NNI  101 . The IMS-M system  102  may comprise a radio access network composed of base stations and base station controllers, and a core network including various nodes, routers, and switches such as for example Call State Control Functions (CSCFs) that provide session control for subscribers accessing services within the IMS. In essence, the CSCFs may be SIP Servers having the responsibility for interacting with network databases such as the Home Subscriber Server (HSS) for mobility, and with the Access, Authorization and Accounting (AAA) servers for authorisations and security. Another example of IMS nodes are the Session Border Gateway (SBG), a device or application that governs the manner in which calls or sessions, are initiated, conducted and terminated in the network, and the HSS that includes subscriber data related to services and charging. A Presence and Group Management (PGM) is also be present in order to provide presence services, as it is known in the art. The IMPS network  104 , on its side, comprises one or more IMPS server and a plurality of IMPS clients (the UEs). 
         [0009]    In the network  100 , two exemplary users are identified as follows:
       An IMS user, User A  103 , in Operator A&#39;s IMS-M network  102  (providing IMS-based IM services) has the following identities:
           sip:UserA@OperatorA.com (describing the user&#39;s SIP URL)   MSISDN, +1-514-555-3333 (describing the user&#39;s MSISDN)   
           An IMPS user, User B  105 , in Operator B&#39;s IM network  104  (providing IMPS services) has the following identities:
           wv:UserB@OperatorB.com (describing the user&#39;s Wireless Village URL)   MSISDN, +1-514-555-7777 (describing the user&#39;s MSISDN)   
               
 
         [0016]    The User A  103  in the IMS-M system  102  may know User B  105  of the IMPS system  108  only by User B&#39;s MSISDN, and may want to initiate presence-based IM with User B using that MSISDN. The sequence of SIP requests over the NNI  101 , when User A wants to add User B as a contact in his contact book, using User B&#39;s MSISDN (complying with both GSMA specification and OMA specification) and then sending an IM to user B (using his MSISDN) at a later time is as follows: 
         [0017]    When the user A  103  adds user B  105 &#39;s MSISDN in his contact list and wants to perform IM based on the presence information of user B (e.g. to send an IM message to user B when his presence information shows him, e.g., as being active and connected), user A  103  first acts to i) (optionally) add user B identity to his contact list and ii) to subscribe for user B  105 &#39;s presence information, action  118 . For this purpose, user A  103 , once he/she added user B  105  MSISDN to his/her contact list (action not specifically shown in  FIG. 1 ) issues a SIP SUBSCRIBE message  120  destined to the MSISDN  119  of user B. The operator A&#39;s Interworking Gateway (IWGW)  106  receives the presence subscription  120  that contains the user B  105 &#39;s MSISDN  119  and relays it to the operator B&#39;s IWGW  108  over the network-to-network (NNI) interface  101 . However, the IWGW  108  rejects, in action  121 , the subscription for presence information because it uses the MSISNDN  119 , rather then the user B&#39;s URL expected by the IWGW  108 . However, the IWGW  108  is capable to map the user B&#39;s MSISDN received in action  120  to the user B&#39;s URL that is known to network  104 . As a consequence, in action  122  the operator B&#39;s IWGW  108  sends back a SIP 301 message that returns to the originator the user B&#39;s URL  123  to be used for such presence subscriptions, in line it the above-mentioned specifications. In action  124 , the IWGW  106  rather uses the newly received URL  123  of user B  103  in order to subscribe to presence information related to that user. Proper reception of the message  124  is confirmed via the SIP 200 OK message  126  by the IWGW  108  and, in action  128 , the IWGW  108  responds to the subscription for presence information by sending a SIP NOTIFY message including the presence status information of user B  103 . Once the gateway  106  further relays to the user A  103  the presence status information of user B  105  (that sequence is not shown in  FIG. 1  for simplicity purposes), a messaging sequence  138  can take place where the user A  103  can communicate, for example instant messages to user B, as he now knows the presence status of user B  105  (such as for example being available for instant messaging). Message  140  is an exemplary SIP MESSAGE message via which the user A communicates instant messages with user B. 
         [0018]    Currently, there are no specifications that dictate how, in this example, Operator A&#39;s IMS network  102  would maintain the mapping between User B&#39;s MSISDN  119  that is originally known to User A  103 , and the user B&#39;s URL  123 , which is returned from User B&#39;s network  104  in action  122 . It is indirectly expected (as hinted by section 5.7 of OMA&#39;s technical specification) that User A terminal&#39;s contact list would maintain the mapping, i.e. would have the capability to store both the User B&#39;s MSISDN  119  and the User B&#39;s URL  123 . Consequently, User A&#39;s IMS client would be expected to access (and possibly store) a contact list with the mapping, and use User B&#39;s URL  123  for IM (alike the action  138 ) and presence subscriptions. 
         [0019]    However, this is not possible for many terminals in today&#39;s market. Many terminals, PDAs, and mobile phones that host IMS clients use address books as starting points for initiating communications, including IM, and many such devices have address books that do not have the capability of storing IM user identifiers (URLs) as a contact. This is partially due to the fact that, historically, mobile communications were held using the MSISDN only, so many current terminals&#39; address books were only designed to store the users&#39; MSISDNs, and not the more recent URLs identifiers. Thus, such devices cannot store the mapping between the MSISDNs and the User IDs, for given users, and consequently will always initiate IM using the MSISDNs. This renders impossible proper IM communications alike the one described in action  138 . 
         [0020]    Although there is no solution as the one proposed by the present invention, the international publication number WO2005/022863A1 bears some relation with the field of the present invention. This publication teaches a method for managing presence services in a communication system making use of heterogeneous protocols. Each communication subsystem supports a presence service that operates according to different presence protocols, such as for example using wireless village specifications or SIP based specifications. According to the publication, interoperability between the different presences services is obtained by converting a presence message generated at an originating subsystem from the local protocol to another protocol. Presence messages including, for example, presence documents are converted from one protocol to another based on predefined schemes. However, the teaching of this publication is limited to a simple protocol to protocol conversion of presence related messages and stops short of teaching or suggesting the present invention. 
         [0021]    The international publication WO2004/030434 also bears some relation with the field of the presence invention. This international publication teaches a mapping functionality between a Wireless Village server and a presence messaging and group server of an IMS system, in order to permit interoperability between Wireless Village and IMS clients for IMPS services. This is destined for operators who have deployed both IMS and Wireless Village services. However, the teaching of this publication is also limited to a conversion from one given protocol to another given protocol with the purpose of enabling instant message services based on presence between heterogeneous networks and, as such, this publication also stops short of teaching or suggesting the present invention. 
       SUMMARY  
       [0022]    Accordingly, it should be rightly appreciated that in order to overcome the deficiencies and the short comings of the existing solutions, it would be advantageous to have a solution that allows the use of mobile terminals and other types of devices which contact book cannot contain both the MSISDN identifier and another user ID (e.g. the contacts URL) to handle communications with another party. The present invention provides such a method and solution. 
         [0023]    In one aspect, the present invention is a method of communication between first and second user terminals the method starting with the receiving of a presence document comprising presence information related to the first user terminal. The method then allows for the insertion in the presence document of a URL of the first user terminal, and for the sending of the presence document comprising the URL of the first user terminal to the second user terminal, whereby the second user terminal uses the URL of the first user terminal obtained from the presence document to subsequently handle communications with the first user terminal. 
         [0024]    In another aspect, the present invention is a method of communication between first and second user terminals, the method starting with the sending of a subscription request message for presence information related to the first user terminal, the subscription request message being addressed to an MSISDN of the first user terminal. Responsive to the subscription request message, a presence document is received comprising presence information related to the first user terminal, the presence document further comprising a URL of the first user terminal. The URL of the first user terminal obtained from the presence document of the first user terminal is then uses to handle a communication with the first user terminal. 
         [0025]    In yet another aspect, the present invention is a computer-operated telecommunication node comprising a communication module receiving a presence document comprising presence information related to a first user terminal. The node further comprises a service logic module inserting in the presence document a URL of the first user terminal. The communication module sends the presence document comprising the URL of the first user terminal to a second user terminal, whereby the second user terminal uses the URL of the first user terminal obtained from the presence document to subsequently handle communications with the first user terminal. 
         [0026]    In yet another aspect, the invention is a User Equipment (UE) comprising a communication module sending a subscription request message for presence information related to another UE, the subscription request message being addressed to an MSISDN of the other UE, the communication module, responsive to the subscription request message, receiving a presence document comprising presence information related to the other UE, the presence document further comprising a Uniform Resource Locator (URL) of the other UE. The presence module then stores the presence document received from the communication module, and the communication module further uses the URL of the other UE obtained from the presence document to handle communications with the other UE. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0027]    For a more detailed understanding of the invention, for further objects and advantages thereof, reference can now be made to the following description, taken in conjunction with the accompanying drawings, in which: 
           [0028]      FIG. 1  (Prior Art) is a simplified high-level nodal operation and signal flow diagram of a prior art implementation of IM services; 
           [0029]      FIG. 2  is a nodal operation and signal flow diagram of an exemplary IM implementation according to the preferred embodiment of the present invention; 
           [0030]      FIG. 3  is a high-level node diagram of an exemplary telecommunications node (e.g. gateway, Call State Control Function, User Equipment) according to the preferred embodiment of the present invention; and 
           [0031]      FIG. 4  is a high-level node diagram of an exemplary user equipment according to the preferred embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION  
       [0032]    The innovative teachings of the present invention will be described with particular reference to various exemplary embodiments. However, it should be understood that this class of embodiments provides only a few examples of the many advantageous uses of the innovative teachings of the invention. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed aspects of the present invention. Moreover, some statements may apply to some inventive features but not to others. In the drawings, like or similar elements are designated with identical reference numerals throughout the several views. 
         [0033]    Accordingly, in order to solve the aforementioned deficiencies of the prior art, the present invention proposes a new method in a telecommunications node that allows the use of legacy User Equipments (UEs) which contact book cannot store the mapping between an MSISDN identifier and a URL identifier of a given user for instant messaging and other types of communications that require the us of the URL. According to a preferred embodiment of the invention, the user&#39;s URL is not stored as usual with newer devices in the address book of that given device, but rather propagated and stored in a presence document that the user receives. According to the invention, the mapping between the originally known MSISDN and URL of a given user is communicated as part of the IMPS users presence information, and as a consequence, even in cases when the presence subscription of an IMS user to an IMPS user is initiated using the IMPS user&#39;s MSISDN, the presence document returned to the IMS user related to the IMPS user&#39;s presence information includes, along the presence status of the IMPS user, also the IMPS user&#39;s URL identifier which can then be used to establish subsequent communications (e.g. IM communications). 
         [0034]    According to the invention, an interworking gateway of an IMS network may introduce the URL information into the presence document that is being propagated to the requesting IMS user. Upon receipt of the presence document of the IMPS user by the IMS user, the later stores the presence document that includes the URL and subsequently accesses the URL from the presence document in order to establish communications, such as for example instant messaging communications, with the IMPS user, as the presence document (possibly updated from time to time or as requested) is persistently stored in the IMS device for the entire duration of the presence subscription. Thus, presence-based communications, such as for example instant messaging based on presence, can be always initiated as long a presence document of the user is found. For example, the presence subscription of an IMS user to presence information associated with an IMPS user may be initiated soon after the IMS user registers into the IMS network, and may be maintained until the IMS deregisters from the IMS network. In such a circumstance, the presence document containing the URL of the IMPS user is stored by the IMS user so that he can initiate communications using the URL of the IMPS user at any moment. 
         [0035]    The present invention may be, for example, useful for legacy devices such as for example mobile stations, user equipments, PDAs, and other type of mobile terminals that include legacy address books that can only store for example the MSISDN of users, and not, for example the users&#39; URLs. The present invention can also be useful for other types of devices where it is deemed more convenient, for various reasons, to use the URL stored in the presence document associated with a given user in order to initiate communications. 
         [0036]    Reference is now made to  FIG. 2 , which shows a simplified nodal operation and signal flow diagram of an exemplary telecommunication system  200  implementing the preferred embodiment of the invention. First, a User Equipment (UE) A  202  is to communicate with another user&#39;s UE B  204 . The UE  202  is an IMS user and is part of an IMS network A  201  that comprises, for example a Call State Control Function (CSCF)  205  for handling control plane communications on behalf of UE A  202 , a (Domain Name Server (DNS) entity  206  capable of resolving addressing of various messages exchanged in the network  201  and an IMPS gateway  208  responsible for communications between the IMS network A  201  and network B  203 . On the other side, the IMPS network B  203  comprises a UE B  204  which, for the purpose of the presence example, is an IMPS UE. Furthermore, the IMPS network  203  comprises a core network part  210  which contains the appropriate telecommunications nodes and functions for supporting communication for UE B  204  (it is to be understood that other UEs may also be present in both networks  201  and  203  although not shown for simplicity purposes). 
         [0037]    Reference is now further made jointly to  FIG. 3  that shows a high-level node diagram of an exemplary telecommunications node  300  (e.g. gateway, Call State Control Function, User Equipment) according to the preferred embodiment of the present invention, which may comprise, for example, the IMPS gateway  208  shown in  FIG. 2 . The telecommunications node  300  may include a communication module  304  such as for example an IMS communication module  304  capable of handling IMS based communications (SIP-based communications) with external networks and nodes. The communication module  304  may comprise a SIP communications module  302  for handling SIP-based communications with, for example, the network A  201  and with the IMPS network B  203 . Furthermore, the telecommunication node  300  may comprise a service logic module  306 , in communication with IMS module  304  and also connected to a data storage  308 , which detailed functioning is yet to be described. The data storage module may include a memory (RAM), a disk, or preferably a cache. 
         [0038]    Reference now further jointly made to  FIG. 4 , which shows the IMS UE A  202  and its exemplary internal structure. The UE A  202  may comprise an address book  410  ( also called sometimes a contact book or contact list) for storing information related to contacts such as for example, telephone numbers, names, addresses and the likes. The UE  202  may further include an IMS client  405  responsible for supporting IMS-based communications on behalf of the UE, with external networks. The IMS client  405  may include a SIP client module  402  capable of supporting incoming and outgoing SIP based communications with other nodes and networks. Finally, the UE A  202  may further include a presence module  404  that handles and possibly stores presence information sent and received by the UE A  202 . The presence module  404  includes presence documents  406 , and  408  that comprise presence information related to various other UEs. Such presence documents may be, in some implementations, stored either in the presence module  404  or partly or totally, in the address book  410  as they may relate to particular contacts stored in the address book  410 . 
         [0039]    With reference being now made jointly to  FIGS. 2 ,  3 , and  4 , the IMS UE A  202  desires to subscribe to presence information related to the IMPS UE B  204 . In order to obtain such presence information related to the UE B  204  and then to initiate a communication such as for example an IM communication with UE B  204  based on its present status, the UE A  202  first subscribes to the presence information. For this purpose, the UE A  202  issues a SIP SUBSCRIBE message  220  which comprises the MSISDN  222  of the UE B  204 . The SIP SUBSCRIBE message  220  also comprises a field  224  that indicates the SIP URL of the originator, i.e. of the UE A  202 . The message  220  is sent to the CSCF A  205  which resolves its DNS address and obtains, in action  226 , the address  228  of the IMPS gateway  208  that is to be contacted in order to relay the SIP SUBSCRIBE message  220  to the IMPS network B  203  (which serves the intended recipient of the message  220 , which is the UE B  204 ). Thus, once the CSCF A  205  obtains the address of the IMPS gateway  208  in action  226 , it relays the SIP SUBSCRIBE message  220  to the gateway  208 . Receipt of the message is confirmed by the SIP module  302  of the gateway  208  to the UE A  202  using a SIP 200 OK message  225 . The SIP module  302  of the IMPS gateway  208  further relays the SIP SUBSCRIBE message  220  to the IMPS network  203  using the same recipient identifier, i.e. the MSISDN  222  of the UE B  204 . Because the IMPS network  203  expects SIP subscription messages to be addressed to SIP URLs, and not to MSISDN identifiers as it is the case herein, the network  203  responds, in action  230 , to the SIP SUBSCRIBE message  220  with a SIP 301 message that indicates the subscription  220  was not accepted and that also returns the URL  232  of the user B  204  as known to the network  203 . For this purpose, the network  203  can perform a mapping determination between the MSISDN  222  and the user B&#39;s URL  232  subsequent to action  220 , i.e. to determine the user B  204  URL  232  based on the user B  204  MSISDN  222  received in action  220 . In action  231 , the SIP module  302  of the IMPS gateway  208  receives the SIP URL identifier  232  of the UE B  204 , and the service logic module  306  instructs its storage in the data storage module  308 . Such storage may be done temporarily, for the duration of the SUBSCRIBE session started in action  220 , in order to allow the yet-to-be-described addition of that URL  232  into the user B&#39;s presence document. The SIP module  302  further issues a new SIP SUBSCRIBE message  234  that this time properly identifies the user B  204  using his URL identifier  232 . Proper receipt of the SIP SUBSCRIBE message  234  is confirmed by the network  203  using a SIP 200 OK message  236 . The presence information  238  subscribed to is returned by the network  210  to the IMPS gateway  208  in action  240 . The SIP NOTIFY message  240  may comprise a presence document containing the presence information  238 , for example in the form of a presence tuple. Such presence information  238  may comprise the presence status of the UE B  204  as it is known to the network  203 , for example user B  204  is present, or user B is not present, or user B is active, or user B is active for IM communications but not for voice chat, etc. The SIP module  302  of the gateway  208  receives the presence document  238  and in action  242 , the service logic module  306  instructs the insertion of the URL  232  of the user B  204 , obtained in previous action  231 , in the presence document  238  related to the user B  204 . For example, the presence document associated to the IMPS user B  204  identified with the MSISDN  222  “+1-514-555-7777” may have the following format, wherein the user B  204  URL  232  is inserted at line  13  of the document: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 1   &lt;?xml version=“1.0” encoding=“UTF-8”?&gt; 
               
               
                   
                    &lt;presence xmlns=“urn:ietf:params:xml:ns:pidf” 
               
               
                   
                    xmlns:pdm=“urn:ietf:params:xml:ns:pidf:data-mode1“ 
               
               
                   
                       xmlns:op=“urn:oma:xml:prs:pidf:oma-pres” 
               
               
                   
                 5       entity=“tel:+15145557777”&gt; 
               
               
                   
                     &lt;tuple id=“a1232”&gt; 
               
               
                   
                      &lt;status&gt;&lt;basic&gt;open&lt;/basic&gt;&lt;/status&gt; 
               
               
                   
                      &lt;op:service-description&gt; 
               
               
                   
                       &lt;op:service-id&gt;org.openmobilealliance:IM-pager 
               
               
                   
                 10 mode&lt;/op:service-id&gt; 
               
               
                   
                       &lt;op:version&gt;1.0&lt;/op:version&gt; 
               
               
                   
                      &lt;/op:service-description&gt; 
               
               
                   
                      &lt;contact&gt;sip:UserB@OperatorB.com&lt;/contact&gt; 
               
               
                   
                     &lt;/tuple 
               
               
                   
                 15  &lt;pdm:person id=“p1”&gt; 
               
               
                   
                      &lt;op:overriding-willingness&gt; 
               
               
                   
                       &lt;op:basic&gt;open&lt;/op:basic&gt; 
               
               
                   
                      &lt;/op:overriding-willingness&gt; 
               
               
                   
                     &lt;pdm:note&gt;I&#39;m at the office&lt;/pdm:note&gt; 
               
               
                   
                    &lt;/pdm:person&gt; 
               
               
                   
                   &lt;/presence&gt; 
               
               
                   
                   
               
             
          
         
       
     
         [0040]    In action  244 , the SIP module  302  of the gateway  208  confirms proper receipt of the presence document  238  using a SIP 200 OK message sent back to the network  210 . Further, in action  240 ′, the SIP module  302  of the gateway  208  relays a new SIP NOTIFY message to the UE A  202 , which contains the presence document  238 ′ related to the UE B  204 , as modified in the action  242  to include the UE B  204  URL identifier  232 . The UE A  202  receives the SIP NOTIFY message  240 ′ via its own SIP client  402 , and in action  250  stores the presence document  238 ′ related to the UE B  204  which also include the UE Bs URL  232 , in the presence module  404 . 
         [0041]    With reference being made mainly to  FIG. 4 , the SIP client  402  of the UE A  202  may receive the SIP NOTIFY message  240 ′ and save the presence document  238 ′ in the presence module  404 . The SIP client  402  may further confirm the proper receipt of the SIP NOTIFY message  240 ′ using a SIP 200 OK message  252  sent back to the IMPS gateway  208 . 
         [0042]    Now that the UE A  202  has stored the presence document  238 ′ of the UE B  204 , including not only the presence information of the UE B  204  but also the UE B&#39;s URL identifier  232 , the UE A  202  can use the URL identifier  232  for multiple purposes. For example, the UE A  202  may initiate subsequent communications with UE B  204  using the UE B&#39;s URL identifier  232 , instead of the UE B&#39;s already known MSISDN  222 . For example, it is assumed in the present exemplary scenario that the UE A  202  desires to initiate an IM communication with the UE B  204 . For this purpose, in action  255 , the SIP client  402  of the UE A  202  extracts from the presence document  238 ′ associated with the UE B  204  the UE B&#39;s URL  232 , and creates a SIP MESSAGE message  260  intended for the UE B  204  and destined to the URL  232 . The message is sent to the gateway  208 , action  260 , which relays it further to the network  210  and finally to the UE B  204 . Proper receipt of this IM communication using the SIP MESSAGE message is confirmed using a SIP 200 OK message  264  sent back from the UE B  204  up to the UE A  202  via the gateway  208 . 
         [0043]    It is to be understood, that although the present exemplary scenario is described with reference to an instant message communication, such as exemplified in actions  260  and  262 , other types of communications can also be established using the UE B URL obtained by the UE A  202  from the presence document  238 ′ stored therein. Such communications can include, for example voice communications, email messages, voice chats, whiteboard sharing, etc. 
         [0044]    According to yet another aspect of the present invention, the URL  232  of the UE B  204  stored in the presence document by the UE A  202  can also be used for handling incoming communications by the UE A  202 . For example, in action  270 , the UE A  202  itself may receive a new incoming communication from the UE B  204 . Such a communication may be an IM based on a SIP MESSAGE message, or other type of communication such as for example a SIP INVITE requesting the start of a new voice communication, etc. The communication  270  can be addressed to the UE A  202  and may comprise the originator information related to the user B  204  in the form of the user B URL  232 . When receiving the communication  270 , the SIP client  402  of the user A  202  may act first to extract the user B URL  232  from the incoming message  270 . Noticing that the address book  430  of the UE A  202  contains no reference to such URL  232  (because for example the address book is not configured to store also the URL, in addition to the MSISDN of a user), the SIP client may obtain the presence document  238 ′ associated to the user B&#39;s URL  232  from the presence module  404  (or alternatively from the address book  410  if stored therein), action  280 . The URL  232  is found in the presence document  238 ′ of the User B  204  and then the UE A&#39;s SIP client  402  can use the URL information from the presence document  238 ′ to map in action  282  the user B URL  232  to the MSISDN  222  of the user B  204 . Now provided with the MSISDN  222  information related to the user B  204 , the UE A  202  can handle the incoming communication  270  based on the MSISDN  222  information, action  284 . Such handling can include, for example, displaying the caller identifier name, which can be obtained from the address book  410  based on the MSISDN  222  stored therein, or other types of specific handling of the communication  270  based on the MSISDN  222  (such as for example, call divert, call forwarding, busy tone, etc.) 
         [0045]    Therefore, with the present invention, it becomes possible to persistently store information regarding the URLs of contacts in a UE even when the native address book of a given UE is not configured to support such storing. The invention proposes to provide such UEs with presence documents related to contacts that also include the contacts&#39; URL information so that when such presence document are stored by a certain UE, the URL information can be used either for initiating subsequent communications using the stored URL, or for handling incoming communications identified as originating from those URLs. 
         [0046]    Therefore, it becomes apparent, that according to the present invention there is provided advantageous methods and telecommunications node for transmitting a presence document, such as for example a presence tuple, that contains not only the MSISDN of a given user but also his/her URL identifier, so that to enable the use of that URL identifier for subsequent communications with that user, or for properly handling incoming communications. 
         [0047]    Based upon the foregoing, it should now be apparent to those of ordinary skills in the art that the present invention provides an advantageous solution. Although the system and method of the present invention have been described with particular reference to certain type of messages and nodes, it should be realized upon reference hereto that the innovative teachings contained herein are not necessarily limited thereto and may be implemented advantageously in various manners. For example, the UE  202  and the telecommunications node  300 / 208  may be implemented along with their described components (from  FIGS. 3 and 4 ) using software modules, hardware modules, or any combination of computer-operated software modules and hardware modules. Typically but not necessarily, those nodes may be computer-operated terminals or nodes running an operating system that enables the use of various hardware and/or software modules with instructions for performing the described actions. It is believed that the operation and construction of the present invention will be apparent from the foregoing description. While the method and system shown and described have been characterized as being preferred, it will be readily apparent that various changes and modifications could be made therein without departing from the scope of the invention as defined by the claims set forth hereinbelow. Although several preferred embodiments of the method and system of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.