Patent Application
20120166652
The Internet Protocol (IP) Multimedia Subsystem is a standardized set of specifications that describe a Next Generation Network (NGN) with a generic architecture for Internet Protocol (IP)-based telephony and multimedia services. Third Generation Partnership Project (3GPP) and Third Generation Partnership Project 2 (3GPP2) enable and support the evolution of mobile networks beyond second-generation (2G) mobile systems such as Global System for Mobile Communications (GSM) and cdma2000. IP Multimedia Subsystem (IMS) uses Session Initiation Protocol (SIP) to control multimedia communication sessions.
The IMS uses Public User Identities (IMPUs) to identify users and route SIP signaling. 3GPP Release 6 onwards, IMS allows users to register the same IMPU from a number of IMS devices. Registrations are differentiated based on the private identity (IMPI) and public identity (IMPU). In IMS, an IMPU is a SIP Uniform Resource Identifier (URI), Tel Uniform Resource Identifier (URI), or Globally Routable User Agent URI (GRUU). All can be used to reach resources when using SIP. A SIP URI identifies a communication resource: it is used to initiate and maintain a SIP session with the resource (e.g. an user, a device, or a service). Its format is similar to an email address (i.e. sip:user@domain although other extensions may be used. User part may be a phone number. The full syntax of SIP URI is defined as sip:user@host:port;uri-parameters?headers where user is the identifier of a particular resource, host a Fully-Qualified Domain Name, followed by optional parameters).
A tel URI contain phone numbers either local numbers (i.e. telephony numbers which are unique only within a certain geographical area or a certain part of the telephone network) or global numbers (i.e. phone numbers which are unambiguous worldwide; they include the leader character “+” followed by the country code and the national numbers). Examples of tel URI include tel:+1-201-555-0123 (a global number assigned in the United States), tel:7042;phone-context=example.com: (a local phone number valid with the “context example.com”). The Globally Routable User Agent URI (GRUU) is a URI that reaches a particular UA instance (an IMS device), but is reachable by any host on the Internet. A GRUU can be either temporary (when created in each IMS registration request to keep user's public identity hidden) or public (when it is a unique combination of a Public User Identity and an instance of the IMS device). Examples of GRUUs include pub-gruu uri=“sip:user@example.com;gr=hha9s8d-999a” (a public GRUU) and temp-gruu uri=“sip: 8ffkas08af7fasklzi9@example.com;gr” first-cseq=“54301”.
Some of the benefits of IMS core networks include, for example, support for simultaneous calling, call hunt, VoIP, and multimedia services based on standardized interfaces and reusable components, etc. Simultaneous calling is described in 3GPP specifications (e.g., 3GPP TS 23.228, 3GPP TS 24.228, and 3GPP TS 24.229) when all called parties share the same IMPU that has been registered on a same SIP server (registrar server i.e. a SIP server that accepts and processes SIP REGISTER requests. The SIP registrar provides a location service which registers IP addresses to SIP URIs) in a same network. That is, standard systems support simultaneous calling only when all subscriber devices share a same identity (i.e., the called party IMPU) and all IMPUs are registered to the same Serving Call Session Control Function (S-CSCF) in the same IMS network. This feature is also called parallel SIP forking. Forking is the ability to split or “fork” an incoming call so that several SIP clients (telephony devices) sharing the same IMPU can ring at once. The first location to answer takes the call.
Call hunt, also called sequential forking, is a service wherein devices that share a same IMPU are called one by one. That is, if the call is not answered on a first device within a time limit, ringing is terminated on the first device and the call is transferred to a second device (the second device rings). If the timer (time limit) expires, the second device stops ringing and a third device rings, and so on, until the call is forwarded to a last device if not previously answered.
In the Figures, the left-most digit of a component reference number identifies the particular Figure in which the component first appears.
Overview
The systems and methods for simultaneous and sequential SIP forking described herein provide simultaneous and sequential forking support to multiple IMS subscribers by establishing multiple SIP session dialogs from a single SIP request in the IMS domain. In contrast to conventional parallel and sequential SIP forking (collectively “SIP forking”) techniques that require all subscriber devices to share a same IMPU to participate, for example, in simultaneous and sequential SIP session establishment, the systems and methods described herein provide SIP forking to any public identities, including parties that do not share a same IMPU (regardless of where they are registered and as assigned to resources) without contribution from the recipients or the originator. That is, parties participating in a SIP forking event may have different IMPUs. In one embodiment, one or more of the IMPUs are regular phone numbers. Additionally, the described systems and methods allow multiple parties (with a same IMPU or with different IMPUs) to be registered on different S-CSCFs. In one implementation, the systems and methods for simultaneous and sequential SIP session establishment allow registration of parties with different telephony operators (networks) including PSTN or circuit-switched networks.
To these ends, the systems and methods for simultaneous and sequential call routing include an application server to implement SIP forking based on a call profile. A user can define his/her user profile: for example, which IMPUs are used for simultaneous or sequential SIP session when someone initiates a SIP session. The user may include other criteria such as time of day or calling party number(s). Users define on which devices they want to answer as part of the user profile. Some of the devices may even be registered on other networks. A user profile may be rule-based (e.g., based on time of day). Using the systems and methods, a user can update their user profile at any time. In one implementation, the user profile is stored in a call profile store. In another implementation, the user profile is stored in a database such as the Home Subscriber Server (HSS) or in an XML Document Management Server (XDMS).
These and other aspects of the systems and methods for simultaneous and sequential SIP session establishment are now described in greater detail.
An Exemplary System
The Interrogating-Call Session Control Function (I-CSCF) is the point of contact for IMS users in their home network. The I-CSCF 208 facilitates all connections for that IMS user. Among other operations, the I-CSCF 208 provides the name of the next hop (either an application server such as application server 212 or S-CSCF 210), and routes incoming requests to an assigned S-CSCF or application server depending on the information retrieved from the HSS 214. HSS 214 is a user database that provides information pertaining, for example, to subscriber profiles, authentication and authorization of user(s), and may provide information about a subscriber's location and IP information.
S-CSCF 210 is a SIP server that handles SIP registrations, performs session control, and provides routing services to forward SIP messages to appropriate application server(s) such as application server 212 or other nodes (e.g., to continue a session in the IMS domain or to a Breakout Gateway Control Function or BGCF (not shown) to breakout in a circuit-switched domain). S-CSCF also interfaces with the HSS 214 to download user profiles.
Other components in IMS network 204 may include, for example, one or more known components that are not shown in
Network 204 can also be a SIP network composed of one or several SIP servers. The SIP server receiving SIP requests such as INVITE shall query the user profile before processing SIP requests.
IMS Device Registration
IMS devices register to their respective S-CSCF assigned in their home network. IMS devices register with their home IMS network using known techniques such as those as defined by 3GPP TS 23.228, 3GPP TS 24.228, and 3GPP TS 24.229. In this particular implementation, IMS network 204 is the home network for one or more of IMS device(s) 202. In another implementation, the home network for one or more other ones of IMS devices 202, for example, may be IMS network 218. IMS devices 202 can register directly on an IMS network (e.g., networks 204) using Internet Protocol (IP) and SIP user agents. Network 218 can be an IMS network, an IP network (e.g. supporting SIP) or Circuit-Switched network (in that gateways such as MGCF and BGCF are required to translate protocols between IMS and circuit-switched networks as defined by 3GPP—not described in this submission), or an IP network. In one implementation, fixed access (e.g., Digital Subscriber Line (DSL), cable modems, Ethernet), mobile access (e.g., W-CDMA, CDMA2000, GSM, and GPRS), and wireless access (e.g., WLAN, WiMAX) are all supported. Other phone systems like plain old telephone service (POTS—the old analog telephones), H.323, and non IMS-compatible VoIP systems, are supported through gateways.
A user of an IMS device 202 defines a user profile 220 to indicate, for example, which IMPUs are to be used for simultaneous and/or sequential SIP forking by IMS network 204 when someone initiates a SIP session to the user. To define/create the user profile 220, a user indicates the particular IMS devices 202 to answer responsive to simultaneous or sequential SIP forking as part of the user profile. In one implementation, one or more of the IMS devices identified in the user profile 220 for SIP forking services is/are registered to a communication network different from the home network 204. For example, one or more of the IMS devices 202 specified in user profile 220 may be registered in network 218 or another network. The user profile 210 may be rule-based (e.g., based on time of day, and/or based on other criteria). In one implementation, user profile 220 is stored on XDMS 216. In another addition, user profile 220 is stored on a different database (e.g., HSS 214, and/or so on).
TABLE 1 shows an exemplary user profile 220 defined in Extensible Markup Language (XML).
Referring to TABLE 1, exemplary user profile 220 specifies characteristics for ringing (simultaneous or sequential SIP session), as illustrated by the data between tags “<ringing>” and “</ringing>.” More particularly, the information between tags “<type>” and “</type>” particularly specifies the type of ringing to be performed (simultaneous or sequential SIP session type ringing). Information between tags “<criteria>” and “</criteria>” indicate any rules-based criteria to be evaluated for conditions associated with SIP sessions. In this particular example, such criteria include the particular day(s) and time(s) of day (i.e., start and end times for each day). These illustrated criteria are examples only and this and/or other criterion and criteria may be specified. The information between tags “<impu>” and “</impu>” indicate each respective IMPU(s) that is/are to participate in establishing SIP session of the described systems and methods. The illustrated tags are examples only, and other tags and information within the described SIP session contexts may be specified in a user's call profile 220.
In one implementation, a user interacts with a user interface served by application server 212 to define user profile 220 for storage by the application server in a database. In another implementation, the user interfaces with a third-party Web server 224 via the Internet 226 to generate the user profile 220 from a series of served web pages 228. That profile can be stored into e.g. the XDMS 216. In this scenario, the IMS device 202 is used to upload the user profile to application server 212 for storage and subsequent access in the IMS network.
The systems and methods of environment 200 for simultaneous and sequential SIP forking provide simultaneous and/or sequential SIP sessions established for any public entities for IMS-originated calls and IMS-terminated calls. In a scenario of an IMS-originated call, an IMS device 202 associated with User A communicates a SIP INVITE (requesting a session with User B) to S-CSCF 210 (the originated S-CSCF). Responsive to receiving the SIP INVITE message, and based on the corresponding user's (“User A”) initial Filter Criteria (iFC), the SIP INVITE (INVITE 222) is routed to the application server 212. The iFC is a collection of conditions for service invocation with application server(s) responsible for execution of the associated service logic. In this implementation, the iFCs, as subsets of the User Profile, are already downloaded from the HSS 214 during assignment procedure and are stored locally at the S-CSCF 210.
Responsive to receiving the SIP INVITE 222 from S-CSCF 210, application server 212 fetches user profile 220 from XDMS 216 (or another database) for User B (the B party). Based on the user profile 220, application server 212 either forwards INVITE 222 to S-CSCF 210 or establishes several legs (SIP forking) as illustrated in INVITE block 224. Application server 212 remains in the signaling path so that if the SIP session is answered on one of the devices 202, the SIP sessions is terminated for the other legs. Application server 212 sends these INVITE messages to S-CSCF 210 over the IMS Session Control (ISC) reference point between S-CSCF 210 and application server 212. As shown in message block 226, S-CSCF 210 routes respective ones of the received INVITE messages 224.
An Exemplary Procedure
Operations of block 404 receive a message (e.g., a SIP INVITE) to establish a SIP session between first and second IMS subscribers. Operations of block 406, responsive to receiving the message to establish the SIP session implement, based on characteristics specified in the user profile, call routing to respective ones of multiple devices associated with the target second IMS subscriber. Significantly, the operations of block 406 to implement SIP forking (simultaneous or sequential SIP establishment) are completely independent of whether or not respective ones of multiple SIP-enabled devices associated with the target IMS subscriber share a same public identity. Additionally, these operations are completely independent of whether or not the public identities are registered with a same SIP proxy server. Moreover, these operations are completely independent of whether or not the devices in corresponding public identities are registered in a same communication network.
In view of the above, the systems and methods described herein in reference to
Although the systems and methods for call forking have been described in language specific to structural features and/or methodological operations or actions, it is understood that the implementations defined in the appended claims are not necessarily limited to the specific features or actions described. Rather, the specific features and operations of routing data are disclosed as exemplary forms of implementing the claimed subject matter.
