Patent Application
20110194554
The IP Multimedia Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia services. IMS was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP) as a part of the vision for evolving mobile networks beyond the GSM standards. The original formulation of IMS (3GPP R5) represented an approach to delivering Internet services over the data service which was added to GSM, i.e., General Packet Radio Service (GPRS).
Basically, the IMS network allows for an integration or convergence of networks in order to facilitate the use of IP packets for wireless and landline services, such as telephony, fax, email, internet access, web services, Voice over IP (VoIP), instant messaging (IM), videoconferencing, Video on Demand (VoD), etc. The ideal for many network operators is to migrate, from a circuit switched network for example, to a full IMS centric network which offers all of their services.
Today's circuit switched networks typically provide a number of so-called supplementary services in addition to basic call services. Such supplementary services include features like call forwarding, caller ID, and call pick-up, among others. In order to transition from circuit switched networks to IMS networks, solutions are needed to support, in an IMS network, all of the various supplementary services to which users have been accustomed.
Of particular interest for the present application is the call pickup service. The call pickup service allows one user to answer a call that is physically ringing in another telephone, device or user terminal than the one which he or she is currently using, e.g., a device located in another part of a large office. In this way, someone can answer a nearby phone for a colleague without having to physically walk over to another workstation or the like. The device whose call is being picked up could, for example, either belong to the user that is answering the call or to a group of users that belong to a team or project. However there is currently no network-based solution which is available to provide call pickup service in IMS networks.
Accordingly, it would be desirable to provide methods, systems, devices and software which facilitate the provision of call pickup service in IMS networks.
According to an exemplary embodiment, a method for providing call pickup service in an IP Multimedia Subsystem (IMS) communication network includes receiving, at an IMS network node, a Globally Routable User Agent URI (GRUU) associated with one of a plurality of devices which is to be used to pick up a call that is in the process of being placed to another of the plurality of devices, determining, by the IMS network node, that the one of the plurality of devices is authorized to pick up the call based, at least in part, on the received GRUU, and transmitting, by the IMS network node, a message to establish the call with the one of the plurality of devices.
According to another exemplary embodiment, a IMS network node includes an interface configured to receive a message including a Globally Routable User Agent URI (GRUU) associated with one of a plurality of devices which is to be used to pick up a call that is in the process of being placed to another of the plurality of devices, and a processor configured to determine that the one of the plurality of devices is authorized to pick up the call based, at least in part, on the received GRUU, wherein the processor is further configured to control the interface to transmit a message to establish the call with the one of the plurality of devices.
According to another exemplary embodiment, a method for initiating call pickup service in an IP Multimedia Subsystem (IMS) capable end user device includes receiving an input indicating that a call is to be picked up by the IMS capable end user device, and transmitting a call pickup request signal including a Globally Routable User Agent URI (GRUU) associated with the IMS capable end user device toward a call pickup application server.
According to still another exemplary embodiment, an IP Multimedia Subsystem (IMS) capable end user device includes a processor configured to receive an input indicating that a call is to be picked up by the IMS capable end user device, and an interface configured to transmit, in response to the input, a call pickup request signal including a Globally Routable User Agent URI (GRUU) associated with the IMS capable end user device toward a call pickup application server.
The accompanying drawings illustrate exemplary embodiments, wherein:
The following detailed description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.
As mentioned above, network operators who are transitioning from, e.g., circuit-switched networks, to IMS networks will likely want to be able to offer some or all of the supplementary services which they are currently offering to their subscribers. An example of such a service offered by a network operator is the call pickup service. However, in the more recently introduced IMS networks there are no simple, well-defined solutions for implementing call pickup functionality in a multi-device environment.
Generally stated, exemplary embodiments of the present invention use the Globally Routable User Agent URI (GRUU) in an IMS network, among other things, to provide call pickup service in a multi-device environment. By using the Globally Routable UA URI (GRUU) addressing scheme, a description of which can be found at the following location in the RFC document 5627 (http://tools.ietf.org/html/rfc5627), an application server can be provided in a network, for example, to route calls or messages to any User Agent device by using a Uniform Resource Identifier (URI), which in this case would be the GRUU. The GRUU addressing scheme introduces the ability in the application server to know which user, and correspondingly which of his or her devices are registered (i.e., online), at any given time. Moreover, these exemplary embodiments also enable the application server to make decisions associated with the call pickup service, and act on those decisions, at the network level based on the GRUU information, as will be described in detail below. This enables the application server to implement various network policies, e.g., authorization/authentication, that may be desirable by the network operator in the provision of this service.
More specifically, exemplary embodiments of the present invention use the GRUU as a mechanism to control how call pickup, in a multi-device environment, can be handled in an IMS network by using an application server. For example, the GRUUs of a subscriber can be used to control how, and when, a call pickup is executed for the subscriber that has multiple registered devices and wants to answer incoming calls on any of his or her registered devices, in an IMS network. Generally, the GRUU as used in these exemplary embodiments describes a new way of reflecting the users Address of Record (AOR) for a given registered device. In addition, the GRUU can be represented in two ways from a security perspective: encrypted and non-encrypted.
Now, turning to
The P-CSCF 102 provides for authentication of the users, among other functions, in the IMS network 100. As seen in
Additionally, the S-CSCF 108 can provide the service of assigning and translating the GRUUs for use by the registered devices. This GRUU assignment and translation service can be conducted, for example, as specified in draft-ietf-sip-gruu-15 (October 2007): “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)” and draft-ietf-sipping-gruu-reg-event-09 (July 2007):“Registration Event Package Extension for Session Initiation Protocol (SIP0 Globally Routable User Agent URIs (GRUUs)”, the disclosures of which are incorporated here by reference. Each assigned GRUU represents an association between a public user identity (ID) and an instance ID provided by a registering device. The assigned GRUU is used to address a particular device that possesses the instance ID and registers with the public user identity. The GRUU can also denote a contact address registered with the public user identity when the contact address has a “+sip.instance” header field parameter containing the GRUU instance ID, for example.
IMS systems typically employ, as identifiers, IP addresses, which are physical identities tied to individual devices and which may undergo various translations throughout the system so as to not necessarily be readily available to the end user, and user identities, which are logical identities that are not directly tied to any particular device. The GRUUs thus provide a connection between each physical device and the logical identity of the corresponding user(s), which identifiers are implemented as URIs which route to a specific user agent instance and can, therefore, be used according to these exemplary embodiments to support call pickup services in conjunction with a scenario wherein multiple devices are related to a particular user or group of users and wherein it is desirable to enable an end user device to directly contact an application server to execute a call pickup in a manner which is controllable and verifiable by the network. A purely illustrative example of such a GRUU which is associated with a user agent (which is in turn associated with a particular end user device) is:
sip:bob@vertigo.com;gruu;opaque=user:id:XXXXXXXXXXXX
The S-CSCF 108 issues GRUUs as part of the registration process, and also reports GRUUs as part of the notifications for subscriptions to the “reg” event package, for example. The S-CSCF 108 generally issues GRUUs in pairs—a public GRUU (or permanent GRUU) and a temporary GRUU. In case of implicit registration, the S-CSCF 108 assigns a unique public GRUU and a unique temporary GRUU for each public user identity. A more detailed discussion of registration involving GRUUs in the context of these exemplary embodiments is provided below with respect to
As shown in
Regardless of where it is located, the functionality associated with MM-AS 110 provides overall network management of the call pick-up service according to these exemplary embodiments based, at least in part, on certain information which it collects via a third party registration process. For example, the multimedia AS 110 can request a third-party registration of users from the S-CSCF 108 for all the subscribed users in the IMS network 100. The S-CSCF 108 will thus, after a successful registration by a user or user device, send a third-party SIP REGISTER message to the MM-AS 110 with the following information: the To-header which contains a non-barred public user identity belonging to the service profile, and, for an initial registration, the registration expiration interval value. This information can be stored and used by the multimedia AS 110 to, for example, track the users and enforce security associated with the provision of the call pickup service.
A detailed, yet purely exemplary, signaling embodiment by way of which an MM AS 110 provides call pickup service associated with a caller's device 112 and callee devices 104 and 106, will now be described with respect to
The signaling process shown in
According to some exemplary embodiments, when the MM AS 110 is provided in the IMS network 100 as a separate node, e.g., relative to the S-CSCF 108, the MM AS 110 will receive all incoming calls for processing. Note that the dotted lines in
The MM AS 110 operates as a routing B2B user agent for the callee and, thus, performs a number of operations upon receipt of a call from the S-CSCF 108. For example, upon receipt of the request 202, the MM AS 110 is triggered and creates and stores a call context which contains call state information including, for example, identification of the caller and callee, and the status of the call (e.g., ringing/alerting, call established, call terminated, etc.). The MM AS 110 can also execute terminating services associated with the incoming call, including but not limited to the call pickup service of interest herein. The MMAS 110 may also create a new call leg for the incoming call. Those skilled in the art will appreciate that the foregoing operations associated with the MM AS 110 are exemplary and that more or fewer operations can be performed by this node.
Upon completion of its tasks associated with new call handling, the MM AS 110 then returns a SIP INVITE message 204 including this information back to the S-CSCF 108. A purely illustrative example of a SIP INVITE message 204 is provided in Table 2 below.
The S-CSCF 108 selects an initial device within the call pickup group to attempt to establish the call, e.g. device 104, based upon, for example, the feature tag that the S-CSCF 108 receives in SIP INVITE message 204 and then sends a SIP INVITE 206 toward the selected device 104 to alert the callee of the incoming call from caller device 112. More specifically, during the registration phase, each device (or device's user agent) specifies the communication services that they are capable of processing by using the feature tag (e.g. IMS Communication Service Identifiers (ICSI), Open Mobile Alliance (OMA) messaging, etc.). This information is stored in the S-CSCF 108 by, for example, a registrar function, which information is then used to select the initial device for establishing the call. At this point, the device 104 will begin ringing or otherwise indicating the presence of an incoming call.
However, as shown in
Once the MM AS 110 receives the HTTP POST 208, it will authenticate the user (callee) 106 using, for example, the X-UI parameters in message 208 such as P-Asserted-Identity, Group, GRUU, etc. MM AS 110 can also check to see if the GRUU(s) in the HTTP POST message 208 belong to the user based on the information which the MM AS 110 stores as part of the registration process described below. Then, the MM AS 110 will determine whether the user requesting the call transfer actually has an ongoing alerting call. Assuming, for this example, that these determinations are all positive, the MM AS 110 can then determine whether the call has already been answered.
Assuming also for this example that the call has not yet been answered at device 104 (which case is illustrated in
As mentioned above, a significant feature of providing call pickup service in an IMS network using GRUUs is the capability for the network node which is controlling the service management, e.g., MM AS 110, to authenticate the request by a callee device to pickup the call prior to establishing the call toward that callee device. Part of this capability is provided by performing third party registration toward the MM AS 110, an example of which will now be described with respect to
More specifically, the S-CSCF 108, when receiving a registration request 306, 308, 310 from a User Agent or UE that includes an instance id, shall allocate a GRUU set. If the User Agent or UE indicates support of GRUU in the REGISTER request, then the S-CSCF 108 returns the permanent and temporary GRUU set (P-GRUU+T-GRUU) in the registration response and associates that GRUU set with the registered contact information for that UE. As long as the instance id provided in the register request is the same, the resulting P-GRUU in the GRUU set will always be the same for a given public user identity. The T-GRUU will be different from those returned during previous re-registrations. All T-GRUUs that are allocated continue to remain valid until that UE Instance ID and Public User Identity pair are deregistered. If there are implicitly registered public user identities, the S-CSCF 108 generates a GRUU set for each implicitly registered public user identity and includes the corresponding GRUU set with the notification of each implicitly registered public user identity
In addition to assigning and providing the GRUUs to the user agents/end user devices, exemplary embodiments also provide these identifiers to the MM AS 110 which requests a third party registration from the S-CSCF 108. Thus, as shown in
The exemplary embodiments described above relate to methods and systems for providing a call pickup service to user equipment in IMS networks which involves the cooperation of several nodes in the system, including (at least in some embodiments) the end user devices 104, 106, 112, the S-CSCF 108, and the MM AS 110. Such nodes can, at a high level, be architected in a manner which is generally represented by communications node 600 shown in
Alternatively, in the context of an IMS network node, e.g., MM AS 110 or S-CSCF 108, the processor 602 can run an application 610 which handles call pickup services, including a trigger for performing the afore-describe routing B2B agent steps described above when it receives a SIP INVITE associated with a new call. In such a case memory 604 and/or secondary storage device 606 will contain a database or other data structure which been designed to capture the GRUU information, and other information, which the MM AS 110 receives as part of the third party registration process and which the node 600 then uses to authenticate requests for call pickup as described above.
A network centric approach (as opposed to using a terminal centric approach, for example) through the use of a call pickup application server in the network is described in the foregoing exemplary embodiments in order to control the way calls are picked up in a multi-device environment. However, the present invention is not restricted to such an implementation and, for example, a terminal centric approach may be implemented instead. On the other hand, some advantages of using a network centric approach for services such as the call pickup service, include the capability for a network operator to easily control the way its subscribers can be reached, through a centralized application server which is programmable. Also, since the services are implemented in the operator's network, an end-user can define a personal profile that describes which devices he or she has and how or when he or she wants to be reached on these devices. The network operator can define this profile on the user's behalf and charge for this service on a monthly or even package level, for example.
Furthermore, the use of GRUUs for carrying registration information into the call pickup application, and thereby enabling the application server to decide to which device and when to redirect call requests, offers a security mechanism by encrypting the URI for each device before it is propagated, if required. As a result, the network operator can be assured that its offered services are secure. In addition to redirecting and authenticating calls, application server can also introduce intelligence to the call sequence flows when, for example, the callee issues an HTTP POST that requests a call pickup. For example, suppose that the MM AS 110 receives an HTTP POST from a device that only supports voice content, but the caller that issued the call is requesting to communicate via video. In this situation, the MM AS 110 will know the device characteristics of the callee's device and can attempt to negotiate with the callee, e.g., the MM AS can offer the option to either downgrade the call to a voice call or simply reject the call.
Various modifications and other embodiments of the disclosed invention will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
This application is related to, and claims priority from, U.S. Provisional Patent Application Ser. No. 61/303,151, filed on Feb. 10, 2010, and entitled “Systems and Methods for Implementing Call Pickup Using GRUU in an IMS Network”, the disclosure of which is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61303151 | Feb 2010 | US |
