Enhanced telephony application server session management

A solution for an enhanced telephony application server session management is described herein. A TAS may fork an incoming invite for packet switched connectivity to all user devices of a same user account registered for parallel forking. When receiving a SIP client failure response from one of the user device, TAS will determine whether a SIP 18X provisional response is received prior to the client failure response from the same user device. If such a provisional response is not received prior to the client failure response, TAS will not terminate the invite forking.

BACKGROUND

The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an architectural framework for delivering IP multimedia services. IMS uses Internet Engineering Task Force (IETF) protocols for transactions and the managements thereof, predominantly the Session Initiation Protocol (SIP). In IMS architectures, a Serving Call Session Control Function (S-CSCF) server and an Application Server, which in a case of telephony services, is also referred to as Telephony Application Server (TAS), are critical functions in controlling packet switched connectivity for a service(s) session, e.g., a voice call session.

DETAILED DESCRIPTION

The systems, devices, and techniques described herein are directed to providing an enhanced telephony application server session management solution.FIG. 1illustrates an example operation environment100. Example client user agent/device110may be linked to server user agents of SIP, here, for example, server UAs120a,120band120cunder a same user account120, through IMS130via SIP message exchanges. Note that in IMS, a user device may function both as a client and as a server depending whether it initiates an invite (client) or receives and responds to an invite (server). IMS130is illustrated as including an S-CSCF132and an TAS134, although other components of an IMS architecture are also included.

The association of multiple user agents/devices120a,120band120cthrough the same user account120may include the scenarios of: (A), a single telephone number shared by multiple devices with multiple SIM cards, and/or (B), multiple devices with multiple native numbers linked via a same account with a same virtual number (i.e., native/ virtual lines). In both scenarios A and B, the user account120may show to client UA110with a same dial-in number. Other scenarios of multiple user devices associated together under a same user account are also possible and included in the disclosure. For example, circuit switched UA120cmay have a voice call forwarding association with a packet switched UA120abased on a SIM card of packet switched UA120a. Further, a user account120may include a combination of multiple scenarios of device association, e.g., scenario A and scenario B above may co-exist within a user account120.

When receiving a voice call invite from client UA110for user account120, TAS134may apply the call forking logic to relay the invite to each of multiple user devices of user account120, which are registered for parallel forking. Note that TAS134may apply both parallel forking and sequential forking for the associated server UAs under various registration scenarios. For illustrative example, it is assumed that user account120provides that packet switched UA120aand tablet UA120bare registered for parallel forking and for sequential forking prior to circuit switched UA120cregistered for sequential forking later.

FIG. 2illustrates an example message exchange scenario for the parallel forking, where TAS134forks the incoming call invite to each of the UA devices120a,120band other UA(s) registered for ringing in parallel. Under traditional approaches, if one of the server UA instance, e.g.,120aor120b, rejects the incoming call, TAS134will send SIP CANCEL to all the UA instances of parallel forking where it has sent SIP INVITE to stop ringing.

However, user devices/agents registered for parallel forking may include various combination of capacities and registration status (i.e., configurations) for various services of connectivity. Some user devices, e.g., tablet UA120b, may be configured for a network connectivity other than a packet switched based voice call connectivity, and may include no packet switched voice call connectivity configuration, and thus may respond to an SIP invite differently than a packet switched UA, e.g.,120a. For example, there can be user agents/devices that support data over LTE network and support register on circuit switched (CS) domain only for the purpose of receiving incoming messages for a brief period of time. For such a user device, e.g., tablet UA120b, upon receiving incoming voice call invite/request from TAS134, the paging will fail resulting in a user busy error that translates to SIP code 486 response. Traditionally, such code 486 response will result in SIP CANCEL message be sent to other user devices, e.g., UA120a, which are still in the process of setting up a voice call session.

Under the enhanced solution(s) of this disclosure, in the scenario of parallel forking, if TAS134receives a SIP code 4XX client failure response from a user device of parallel invite forking, TAS134may check whether a SIP code 18X provisional response, e.g., a code 180 (Ringing) response, has already been received from the same user device prior to the SIP 4XX client failure response. In a case that a SIP 18X provisional response has not been received prior to the client failure response from the same user device, TAS134may continue normally with other user devices for which it has sent the SIP INVITE to allow a possibility of voice call setup on other available user devices.

As shown inFIG. 2, TAS134forks an invite/request for packet switched connectivity of voice call to packet switched UA120aand tablet UA120bwhich include no packet switched voice call connectivity configuration, along with other UA(s). Packet switched UA120areturns a SIP 18X provisional response, e.g., a SIP code 180 (Ringing) response. Then a SIP code 486 (Callee Busy) response is returned from tablet UA120b. Determining that there is no provisional response received from tablet UA120bprior to the code 486 response, TAS may continue the invite forking session with packet switched UA120aand the other UA(s) and cancel the invite only with tablet UA120b. Then a SIP code 486 response, for example, is received from packet switched UA120a. Determining that a provisional response180has been received from packet switched UA120abefore the code 486 response, TAS134may terminate the invite with all the remaining server UAs120aand other UA(s), and, for example, apply Call forwarding, if it is included in the service subscription.

2. Example Devices

FIG. 3illustrates a system diagram showing aspects of an illustrative example application server300. Application server300may be used to implement TAS134and/or S-CSCF132and/or other components of IMS130ofFIG. 1. As shown inFIG. 3, application server300may include a memory (memories)310containing computer executable instructions which, when executed by a processing unit, configures the processing unit to implement an invite forking system320. Invite forking system320may include a request receiving unit322, a request relaying unit324, a response receiving unit326and a transaction management unit328. Transaction management unit328may further include a determination unit330and a control unit332.

Application server300may further include a processing unit(s) (“PU”)340, an interfacing unit350, an RF unit360and other components370.

It should be appreciated that units of application server300may reside on a single computing device, e.g., a server device, or in multiple computing devices in a distributed computing environment/system, and all are included in the disclosure. Further details of a computing device or a distributed computing environment is not required to understand the disclosure and do not limit the scope of the disclosure.

FIG. 4shows an example user device400. Example user device400may implement a packet switched UA120aofFIG. 1. User device400may include a memory (memories)410containing computer executable instructions which, when executed by a processing unit, configures the processing unit to implement an association unit412, a server UA request receiving unit414, a provisional response unit416and an invite processing unit418. User device400may also include a processing unit(s) (“PU”)420, an interfacing unit(s)430, an RF unit(s)440and other components450. In an example, user device400is configured to be compliant with and registered under Session Initiation Protocol (SIP).

Referring toFIGS. 3-4together, in operation, request receiving unit322of invite forking system320may be configured/operable to receive an invite (request), e.g., from client UA110, for a packet switched connectivity for a voice call to an associated user account, e.g., user account120, that includes multiple user devices/agents, e.g.,120a,120band120c, associated with one another.

For example, user device400may be used to implement packet switched UA120aof user account120. Association unit412of user device400may be configured/operable to function together with a server of a service provider to associate user device400(as UA120a) with another user device having no packet switched voice call connectivity configuration, e.g., tablet UA120band/or circuit switched UA120cofFIG. 1, under the same user account120.

Request relaying unit324may be configured/operable to relay the invite/request to each of the multiple user devices, e.g., server UAs120a,120b, and120c. The relaying of the invite to the multiple user devices may be performed sequentially or may be performed in parallel, e.g., substantially simultaneously, or may include a combination of both. The relayed invite may be a Session Initiation Protocol (SIP) invite message.

Server UA request receiving unit414may be configured/operable to receive the SIP invite from application server300. The receiving may be under any approach(es) provided by the SIP specifications/provisions, and all are included in the disclosure.

Provisional response unit416may be configured/operable to return a provisional response to sever300. The provisional response may be a SIP code 18X response, e.g.,180(Ringing),181(Call Is Being Forwarded),182(Queued) and/or183(Session Progress).

Invite processing unit418may be configured/operable to continue processing the received SIP invite message despite/after an associated UA that has no packet switched voice call connectivity configuration, e.g., tablet UA120b, returning a client failure response, e.g., code 486 (Callee Busy) response, to server300. Any approaches may be used to implement the continued processing function(s), and all are included in the disclosure. For example, the continued processing may be based on that no request/invite cancelling and/or termination message is received from server300. In another example, the association between packet switched UA120aand tablet UA120b(which does not have packet switched voice call connectivity configuration) may provide that a client failure response from tablet UA120bdoes not stop the processing of the SIP invite message at packet switched UA120a.

Response receiving unit326may be configured/operable to receive a response from a server UA, e.g., server UAs120a.120band/or120c, including a client failure response. For example, a client failure response may be a code 486 response indicating Callee Busy on the specific UA.

Transaction management unit328may be configured/operable to manage the packet switched connectivity transaction based on SIP responses received by response receiving unit326. Specifically, determination unit330may be configured/operable to determine whether a provisional response is received from a user agent/device prior to a client failure response received from the same user agent/device.

Control unit332may be configure/operable to control the processing and/or status of the packet switched connectivity transaction based on a determination result of determination unit330. For example, if it is determined that a provisional response is not received from a user device prior to a client failure response received from the same user device, control unit332may cause to maintain the relaying/forking of the invite request to other ones of the multiple user devices in lieu of the received client failure response. If it is determined that a provisional response has been received from a user device prior to a client failure response received from the same user device, control unit332may cause to terminate the relaying of the invite with respect to all of the multiple user devices in a parallel forking, responsive to the received client failure response.

Further, transaction management unit328may be configured/operable to identify and record a user device as having no packet switched connectivity configuration for voice call service based on that the user device returns a client failure response without a prior provisional response.

3. Example Processes

Referring toFIGS. 1-3 and 5together, in example operation510, request receiving unit322of invite forking system320may receive an invite (request), e.g., from client user agent110, for a packet switched connectivity for a voice call to an associated user account, e.g., user account120, that includes multiple user devices/agents, e.g.,120a,120band120c, associated with one another.

In example operation520, request relaying unit324may relay the invite/request to each of the multiple user devices registered for parallel forking, e.g., server UAs120a,120b, and120c. The relaying of the invite to the multiple user devices may be performed sequentially or may be performed in parallel, or may include a combination of both. The relayed invite may be a Session Initiation Protocol (SIP) invite message. It should be appreciated that before the relaying, multiple procedures may be performed to comply with the SIP standard provisions, e.g., to authenticate client UA110. The relaying and/or relayed invite/request message may include different content and/or format than the invite/request received from client UA110.

In example operation530, response receiving unit326may receive a client failure response, e.g., a code 486 (Callee Busy) response, from a server UA, e.g., tablet UA120b.

In example operation540, determination unit330may determine whether a provisional response is received from tablet UA120bprior to the client failure response received from the same tablet UA120b.

If it is determined that a provisional response is not received from tablet UA120bprior to the code 486 (Callee Busy) response received from the same tablet UA120b, in example operation550, control unit332may cause to maintain the relaying of the invite request to other associated user devices, e.g., packet switched UA120aand/or circuit switched UA120c, of the multiple user devices of user account120in lieu of the received code 486 (Callee Busy) response from tablet UA120b.

If it is determined that a provisional response, e.g., a code 180 (Ringing) response has been received from a user device, e.g., packet switched UA120a, prior to a client failure response, e.g., code 486 (Callee Busy) response, received from the same UA120a, in example operation560, control unit332may cause to terminate the relaying of the invite with respect to all of the multiple user devices of user account120responsive to the received client failure response.