Auxiliary event packages

A method includes registering with a proxy for an auxiliary event-package, wherein the auxiliary event-package is provided by a plurality of auxiliary event-package servers. The method may further include subscribing to the auxiliary event-package through the proxy. The proxy forwards the subscription to the plurality of auxiliary event-package servers. The method may include receiving an initial notify from one of the auxiliary event-package servers and identifying the one of the auxiliary event-package servers as a primary handle for the auxiliary event-package. In addition, the method may include identifying others of the plurality of auxiliary event-package servers as secondary handles for the auxiliary event-package.

BACKGROUND INFORMATION

Many network providers are migrating to communication networks that employ session control protocols, such as Session Initiation Protocol (SIP). SIP is a session signaling protocol for creating, modifying, and terminating sessions at the application layer. SIP may create, modify, and terminate sessions (e.g., telephone calls, instant messaging conferences) among participants of the session. Proxies are typically employed to handle session signaling on behalf of devices in the SIP oriented network. The proxy may handle session signaling for many (e.g., thousands or millions) devices.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description is exemplary and explanatory only and is not restrictive of the invention, as claimed.

An event-package is a service on a network for which a device may subscribe and receive notifications of events. Event-packages in SIP oriented networks are implemented in a published and subscribed based architectural pattern (“pub/sub model”). In other words, the SIP event-package may be a hub of a particular feature set, such as presence, which is distributed to subscribers. SIP event-packages are often tightly integrated with a SIP soft-switch, which may be clustered and load balanced.

Embodiments disclosed herein relate to devices, methods, and systems for implementing a SIP client centric server-affinity that allows failover and load balancing of a SIP oriented network. In some instances, SIP event-packages are auxiliary to the soft-switch in SIP oriented networks and may be unknown to the SIP soft-switch, SIP gateway or proxy, and/or added as a third party to the soft-switch (i.e., customer premises equipment, cloud services, etc.). The presence of these auxiliary event-packages in the SIP oriented networks increases the difficulty of load-balancing the SIP oriented networks. The difficulty of load-balancing may be further increased when the auxiliary event-packages serve a plurality of soft-switches, gateways or proxies. Consistent with the embodiments described herein, SIP oriented networks may be implemented with either SIP user agent centric server-affinity or user device centric server-affinity that enables failover, load balancing, and/or reconnection across the SIP oriented network.

FIG. 1Ais a diagram of an exemplary network100in which systems and/or methods described herein may be implemented. As illustrated, network100may include an application server104, a plurality of proxies106(individually, “proxy106-x”), a plurality of auxiliary event-packages servers (AEPSs)108a-108n, and numerous user devices112(individually, “user device112-x”) coupled to a network102. Components of network100may be interconnected via wired and/or wireless connections. The configuration of components of network100illustrated inFIG. 1Ais for illustrative purposes only. Other configurations may be implemented. Therefore, network100may include additional, fewer and/or different components than those depicted inFIG. 1A. Also, in some instances, one or more of the components of network100may perform one or more functions described as being performed by another one or more of the components of network100.

Network100may comprise a SIP oriented network100, such as: an all Internet Protocol (IP) network using SIP proxies106; an IP Multimedia Subsystem (IMS) network using SIP proxies106; and/or a Long Term Evolution (LTE) network with Voice over LTE using SIP proxies106. SIP is a request/response protocol used for signaling in, for example, voice over IP networks. In addition to SIP proxies106, network100may include SIP soft-switches, and SIP gateways (not shown) that facilitate signaling in a SIP oriented network100.

In SIP, the peer-to-peer relationship between two devices is known as a “dialog.” The dialog provides the context to facilitate exchange of messages between devices (including, for example, user devices112and AEPSs108a-108n) in network100. Messages exchanged between devices can be, for example, either a request or associated responses to the request. A request and its responses may be referred to as a “transaction.” The devices in network100may communicate using a connection oriented protocol, such as transmission control protocol (TCP) and/or a connectionless communication protocol, such as user datagram protocol (UDP) or IP. A dialog may include one or more transactions. In network100, for example, user device112-1may subscribe to an event-package provided by AEPSs108a-108n. The subscription may be established using one of proxies106and a session control protocol, such as SIP, as described below.

User devices112may include mobile telephones, personal digital assistants (PDAs), laptop computers, desktop computers, tablet computers, or another type of computation or communication device. User devices112may connect to network102via wired, wireless, and/or optical connections. User devices112may include a transceiver (not shown) to transmit and receive SIP messages. User devices112may include user agents114that implement SIP according to the Internet Engineering Task Force (IETF) document Request For Comments (RFC) 2543 and document RFC 3261. User agents114may be implemented for a single address of record (AOR) that corresponds to a single user. The AOR includes a user name and a domain with which the AOR is associated. There may be multiple instances of a single AOR. For example, an end user may log in to a messaging application on multiple user devices112including a mobile phone, personal computer, and PDA. Corresponding user agents114in this instance are all registered to a single AOR. User agents114may register and subscribe for SIP services in network100through proxies106.

Each of proxies106may include a device that facilitates the establishment, definition, and termination of sessions, such as telephone calls, on behalf of other devices in network100(e.g., user devices112). Proxies106may be aggregated to form a SIP proxy farm that is associated with a particular SIP domain. Network100may include a load balancer (not shown inFIG. 1) for the SIP proxy farm. Proxies106may route requests to user device's112locations, authenticate and authorize user devices112for services provided through proxies106, implement call-routing policies, and provide features to user devices112. The services and features provided through proxies106may include event-packages, which are services on network100for which the devices112can subscribe and receive notifications. SIP event-packages may be provided through an integrated SIP soft-switch or alternately, through AEPSs108a-108n, for instance as described in RFC 3265 (SIP specific event notification) and RFC 3903 (SIP extension for event state publication).

Each of AEPSs108a-108nmay provide auxiliary event-packages to subscribing user devices112on network100through proxies106. AEPSs108a-108nmay comprise hardware, software or a combination of hardware and software that hosts auxiliary event-packages and provides the auxiliary event-packages to authorized and/or authenticated devices using a network protocol. Each of AEPSs108a-108nmay host a same auxiliary event-package. These auxiliary event-packages may be unknown to the SIP soft-switch and SIP gateway. The auxiliary event-packages provide access to extenuating or ancillary actions to a published event, such as contingent access to a database or other predetermined action. According to one implementation, a particular soft-switch may have a particular set of extensions defined by an event-package that is integrated with the soft-switch. An auxiliary event-package may be implemented in network100to extend features of user agent114and user device112with features that are not included in the event-package for the soft-switch. The auxiliary event-package may be specific to a particular network100and may not be supported by a CPE (customer premises equipment) vendor or manufacturer of a particular user device112. AEPSs108a-108nmay support applications and functionality that is specific to and provided by the telecommunications service provider that maintains network100.

AEPSs108a-108nmay distribute particular feature sets, such as presence to subscribing user devices112or user agents114. For example, a user agent114in network100may update a presence status by publishing information regarding presence of the device. In this instance, the auxiliary event-package is a third party event-package to a SIP soft-switch. However, AEPSs108a-108nmay not be tightly integrated with the SIP soft-switch and issues may arise with regards to load balancing network100.

Application server104may support access side protocols in network100including SIP, media gateway control protocol (MGCP) and network-based call signaling (NCS). Application server104may include a database of user and group profiles as well as service and subscription data. According to one implementation, application server104and adapters110a-110nof AEPSs108a-108ncomprise a SIP publisher client cluster. Application server104may publish SIP messages to AEPSs108a-108n. Adapters110a-110nmay be collocated and communicate with AEPSs108a-108n. Adapters110a-110nmay receive a published SIP message from application server104and transform the published SIP message, for example, into a notification message input to AEPSs108a-108n(designated as notify in the SIP protocol). AEPSs108a-108nmay output the notification message to subscribing user devices112or user agents114through proxies106. The published SIP message may be distributed via network102to subscribers of that auxiliary event-package, as described below.

Network102may include a wired or wireless network. Network102may include a wireless public land mobile network (PLMN) (e.g., a cellular network). The PLMN may include a Code Division Multiple Access (CDMA) 2000 PLMN, a Global System for Mobile Communications (GSM) PLMN, an LTE PLMN and/or other type of PLMN. In addition to a wireless network, network102may include one or more other networks of various types, such as, for example, a telecommunications network (e.g., a Public Switched Telephone Network (PSTN)), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an intranet, the Internet, and/or a cable network (e.g., an optical cable network). Network102may also include a wireless satellite network.

In instances in which SIP event-packages are auxiliary to the SIP soft-switch and/or unknown to the SIP soft-switch, SIP gateway or proxy, the presence of these auxiliary event-packages in SIP oriented network100increases the difficulty of load-balancing SIP oriented network100. Signal diagrams described below demonstrate implementations of a SIP client-centric server-affinity process that allows fail-over and load-balancing of a SIP oriented network100.

FIGS. 1B and 1Cillustrate signal diagrams150and190, respectively, of exemplary dialogs implementing a SIP client centric server-affinity that allows failover and load balancing of a SIP oriented network100. As illustrated, signal diagrams150and190may include transactions between user agents114(user agent114-1and user agent114-2), a load balancer (LB)152, proxies106, AEPSs108a-108n, and application server104. The transactions illustrated inFIGS. 1B and 1Care for illustrative purposes only. Other transactions may be implemented. Therefore, signal diagrams150and190may include additional, fewer and/or different components and/or transactions than those depicted inFIGS. 1B and 1C. Also, in some instances, one or more of the components of signal diagrams150and190may perform one or more transactions described as being performed by another one or more of the components of signal diagrams150and190.

Referring toFIG. 1B, signal diagram150illustrates dialog implementing load balancing and failover of an auxiliary event-package. User agent114-1may register154with proxy106, in this instance proxy106-1. LB152may be used in this instance to route an initial connection between user agent114-1and proxies106. For example, user agent114-1may make a registration request that LB152may subsequently redirect to one of the proxies106based on LB's152determination of an appropriate proxy106(in this instance proxy106-1) that achieves load balancing requirements of network100. The load balancing performed by LB152occurs at a separate level of network100than load balancing performed with AEPSs108a-108n, described below. User agent114-1may achieve additional load balancing requirements of network100by directing publications and notifications to and from the auxiliary event package to particular AEPSs108.

User agent114-1may subscribe156to an auxiliary event-package located in a SIP domain maintained by proxy106-1. The auxiliary event-package may be provided through AEPSs108a-108n. AEPSs108a-108nmay have registered with proxy106-1prior to user agent114-1registering154with proxy106-1. Proxy106-1may fork182(as defined in RFC 3261) the subscription156(subscribe156-1, subscribe156-2) to all registered AEPSs108a-108nthat maintain that auxiliary event-package (in this instance AEPS108aand AEPS108b). For example, proxy106may fork182the subscription156by forwarding the single subscription156to multiple endpoints, which in this case corresponds to each of the plurality of AEPSs108a-108n.

AEPSs108a-108nmay respond with a normal accept (designated as a 200 series message in SIP protocol) and an initial notify158(notify158-1and notify158-2from AEPS108aand AEPS108b, respectively). User agent114-1may receive an accept notification (not shown) and initial notify158for all instances of the auxiliary event-package in the SIP domain of proxy106-1. The first (initial) notify158received by user agent114-1(i.e., the first initial notify158of initial notifies158corresponding to each of AEPSs108a-108n) is acknowledged and the sending AEPS108(in this instance AEPS108a) becomes the primary handle (e.g., primary server and/or primary device that handles the auxiliary event-package for user agent114-1) or the primary subscription. The remaining responses are designated and processed as secondary handle(s) (e.g., secondary server(s) and/or secondary device(s) that handles the auxiliary event-package for user agent114-1). User agent114-1may acknowledge the notification (not shown) and at or near that time a new session160becomes active (new session160-1and new session160-2for AEPS108aand AEPS108b, respectively). AEPS108aand AEPS108bmay both consider the subscription to the auxiliary event-package as active at that instant.

Load balancing of AEPSs108a-108nin network100occurs where user agent114-1selects one of AEPSs108a-108nas the primary handle. Subsequent to selection of the primary handle, the selected AEPSs108becomes the primary handle that user agent114-1communicates with to execute transactions regarding the auxiliary event package. The AEPSs108that responds first becomes the primary handle. Those of AEPSs108a-108nthat are busy/unavailable may respond at a later time than AEPSs108a-108nthat have comparatively lower workloads. Therefore, AEPSs108a-108nmay be load balanced according to response times, which may be based on workload of AEPSs108a-108n.

User agent114-1may maintain subscriptions to each of the other AEPSs108a-108n. The other AEPSs108a-108nare identified as secondary handles. User agent114-1may refresh subscriptions periodically according to an expired header field or expired header tag, received for instance in a SIP message such as notify158, before an expiration timer terminates the subscription. User agent114-1communicates with the primary handle (AEPS108a) for subsequent transactions. Additionally, user agent114-1may keep the subscription active for the secondary handle(s). From that point forward, user agent114-1may publish to the primary handle (AEPS108a), and may expect notifications from both the primary handle and secondary handle(s).

User agent114-1may publish164via proxy106-1and direct the publish request to the primary handle (AEPS108a). User agent114-1may direct any response in a pub/sub architectural pattern to a particular instance of an AOR. For instance, user agent114-1may direct the response to a location subscription to a particular user agent114. Application server104may receive a publish164message and perform a call action in response. Application server104may subsequently issue a call update166through adapter110B that initiates a notify168that is directed to a particular instance of an AOR, which in this case corresponds to user agent114-1.

According to a further implementation, the primary handle (AEPS108a) may become unavailable for providing the auxiliary event-package. For example, the hosting server for AEPS108amay become unavailable. User agent114-1requires the primary handle (in this instance AEPS108a) to be available only at instances in which user agent114-1is to perform a specific action, for example, to output another publication (publish164). Proxy106-1may receive information regarding the unavailable status of AEPS108a. For instance, proxy106-1may determine the unavailable status of AEPS108abased on either discovering the unavailable status or based on failure of a refresh rebind process for AEPS108a. In response to publish164from user agent114-1, proxy106-1may provide notification that the primary handle is unavailable176. Proxy106-1may provide notification by either sending a client status code message (i.e., a 480 SIP message) or a server error status code message (i.e., a 503 SIP message) based on the particular implementation of proxy106-1.

Upon receipt of the notification that the primary handle is unavailable176, user agent114-1may select a secondary handle as a new primary handle (AEPS108b) and release the now former primary handle (AEPS108a). User agent114-1may attempt to maintain a subscription state for the former primary handle. User agent114-1may attempt to reestablish a connection to the former primary handle (AEPS108a) at a predetermined refresh rate. User agent114-1may publish164(republish to primary172) to the new primary handle (AEPS108b).

According to another implementation, all AEPSs108a-108nmay receive a publication or option from user agent114-1indicating to the plurality of AEPSs108a-108nan identity of the primary handle from the plurality of AEPSs108a-108nand which of the plurality of AEPSs108a-108nare secondary handle(s). User agent114-1may limit notifications and publications to and from the auxiliary event-package to the primary handle. If the primary handle becomes unavailable (e.g., maintenance period or network failure, etc.), user agent114-1may receive a SIP480/Unavailable message from proxy106that maintains that auxiliary event-package instance. At that instant, user agent114-1may change a server-affinity to one of the available secondary handles (each in turn) optionally sending a notification or option request indicating that change to AEPS108b(i.e., a change from secondary to primary affinity). All subsequent notifications and publications will then be re-directed from, and to, that auxiliary event-package instance, AEPS108b. Once the previously unavailable auxiliary event-package instance (i.e., AEPS108a) becomes available again, the next client subscription refresh may be forked182, and establish AEPS108a(again, via the accept and initial notify158) as a secondary handle in user agent114-1.

The foregoing implementation may be applied to either a stateful or stateless auxiliary event-package, allow multiple subscriptions per AOR (i.e., AOR instances) and establish server-affinity (i.e., affinity to a particular AEPS108) at the time of subscription, and re-establish server-affinity on upon receiving SIP480/Unavailable message, and on upon refresh re-subscribe. A stateless auxiliary event-package treats each request as an independent transaction. A stateful auxiliary event-package has a current state that may be dependent on past states and/or transactions. The implementation may utilize current standards for SIP communication between a proxy and an event-package, and may enable a developer or network administrator to load balance without regard to the soft-switch, gateway or proxy vendor, or the network environment in which the soft-switch is placed.

Turning now toFIG. 1C, signal diagram190illustrates an exemplary dialog implementing a new subscription to an existing SIP session with an auxiliary event-package in network100. As illustrated, transactions in signal diagram190may follow transactions or be performed concurrently with transactions illustrated in signal diagram150.

As shown inFIG. 1C, user agent114-2initializes in network100and registers154with proxy106-2. User agent114-2may comprise a second instance of an AOR associated with user agent114-1. User agent114-2may subscribe156to an auxiliary event-package via proxy106-2of the proxy cluster. The auxiliary event-package may be hosted by AEPSs108a-108n.

Proxy106-2sends a subscription request (subscribe156) to AEPS108b. Subscribe156may reuse a session192that has been previously established by an instance of an AOR, such as a session established by user agent114-1in signal diagram150. Note that network100may include a subscription layer and a session layer. User agent114-2may have a same session as user agent114-1at the session layer of network100and a new active subscription at the subscription layer of network100. For instance, with reference back toFIG. 1B, subscribe156may reuse session160-2at AEPS108bthat was established by user agent114-1. Multiple instances of an AOR may have parallel use of a single session, for instance initiating a telephone call on one user device112-1and participating in the telephone call on another user device112-2.

User agent114-2may receive an initial notify158from AEPS108b. AEPS108bbecomes the primary handle for user agent114-2. According to this implementation, a single AOR or user may have two user agents114(user agent114-1and user agent114-2). For example, a user may sign in to a presence application on multiple devices, such as a PDA and a mobile phone. Application server104may respond with a call update170to adapter110bthat is sent as a notify164to AEPS108b. There are two subscriptions to the auxiliary event-package at AEPS108bin this instance. AEPS108bmay fork182the notify164(e.g., send notify164-1to user agent114-1, notify164-2to user agent114-2) to both subscribing user agents114via proxies106(proxy106-1, proxy106-2) corresponding to each user agent114. In this manner, an end user may reuse an existing session of the auxiliary event package at an AEPS108for additional user agents114and corresponding user devices112.

Devices in network100may each include one or more computing modules.FIG. 2is a block diagram of exemplary components of a computing module200. Computing module200may include a bus210, processing logic220, an input device230, an output device240, a communication interface250, and a memory260. Computing module200may include other components (not shown) that aid in receiving, transmitting, and/or processing data. Moreover, other configurations of components in computing module200are possible.

Bus210may include a path that permits communication among the components of computing module200. Processing logic220may include any type of processor or microprocessor (or families of processors or microprocessors) that interprets and executes instructions. In other embodiments, processing logic220may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a multi-core processor, a reduced-instruction set code (RISC) processor, etc.

Input device230may allow a user to input information into computing module200. Input device230may include a keyboard, a mouse, a pen, a microphone, a remote control, an audio capture device, an image and/or video capture device, a touch-screen display, etc. Some user devices112, such as home phone may include a keypad for entering telephone numbers when calling a party. Other user devices, such as a mobile phone, may include a keypad or a touch screen for entering numbers for calling a party. On the other hand, SIP proxies106may be managed remotely and may not include input device230. In other words, some devices may be “headless” and may not include a keyboard, for example.

Output device240may output information to the user. Output device240may include a display, a printer, a speaker, etc. For example, user devices112may include a liquid-crystal display (LCD) for displaying information to the user, such as the name and/or number of a calling party. Headless devices, such as proxy106, may be managed remotely and may not include output device240.

Input device230and output device240may allow a user to activate and interact with a particular service or application, such as telephone application to call a party. Input device230and output device240may allow a user to receive and view a menu of options and select from the menu options. The menu may allow the user to select various functions or services associated with applications executed by computing module200.

Communication interface250may include a transceiver that enables computing module200to communicate with other devices or systems. Communication interface250may include a transmitter that converts baseband signals to radio frequency (RF) signals or a receiver that converts RF signals to baseband signals. Communication interface250may be coupled to an antenna for transmitting and receiving RF signals. Communication interface250may include a network interface card, e.g., Ethernet card, for wired communications or a wireless network interface (e.g., a WiFi) card for wireless communications. Communication interface250may also include, for example, a universal serial bus (USB) port for communications over a cable, a Bluetooth™ wireless interface, a radio-frequency identification (RFID) interface, a near-field communications (NFC) wireless interface, etc.

Memory260may store, among other things, information and instructions (e.g., applications264and operating system262) and data (e.g., application data266) for use by processing logic220. Memory260may include a random access memory (RAM) or another type of dynamic storage device, a read-only memory (ROM) device or another type of static storage device, and/or some other type of magnetic or optical recording medium and its corresponding drive (e.g., a hard disk drive).

Operating system262may include software instructions for managing hardware and software resources of computing module200. For example, operating system262may include Linux, Windows, OS X, OpenSolaris, Unix, etc. In instances in which user device112is a mobile phone, for example, operating system262may include MeeGo, Android, WebOS, iOS, Symbian, etc. Applications264and application data266may provide network services or include applications, depending on the device in which the particular computing module200is implemented.

In an exemplary implementation, computing module200may perform the operations described herein in response to processing logic220executing software instructions contained in a computer-readable medium, such as memory260. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into memory260from another computer-readable medium (e.g., a hard disk drive (HDD), SSD, etc.), or from another device via communication interface250. Alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to implement processes consistent with the implementations described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

FIG. 3is a block diagram of exemplary components of user device112. User devices112may each include a transceiver306and a user agent114, which may further include message generation logic304. The components of device112-xare shown for ease of understanding and simplicity. Device112-xmay include more, fewer, or a different arrangement of components.

User agent114may use a protocol (e.g., SIP) to establish, define, and terminate sessions with other devices. A session may include a lasting connection between two devices that may carry a stream of packets from one device to the other and/or vice versa. User agent114may perform the functions of a user agent client (UAC) and/or a user agent server (UAS). A UAC is a logical entity that creates a new request, and then uses client transaction state logic to send the request. The role of UAC may last for the duration of that transaction. In other words, if device112-xinitiates a request, user agent114acts as a UAC for the duration of that transaction. On the other hand, a UAS is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. The role of UAS may last for the duration of that transaction. In other words, if device112-xresponds to a request, user agent114acts as a UAS for the duration of that transaction.

Transceiver306may receive and transmit SIP messages included in a SIP dialog. SIP dialog may be identified by a combination of the Call-ID, From tag and To tag. A SIP transaction is identified by the branch parameter of the Via header and the Method name in the CSeq field. These fields can be used to construct respective dialog ID and transaction ID identifiers.

FIG. 4Ais a flowchart of an exemplary process400for implementing load balancing and failover of an auxiliary event-package in network100, etc. The data flows associated with process400are described in conjunction with signal flow150inFIG. 1B. Process400may execute in a user agent114and/or user device112(e.g., mobile phone, personal computer). It should be apparent that the process discussed below with respect toFIG. 4Arepresents a generalized illustration and that other elements may be added or existing elements may be removed, modified or rearranged without departing from the scope of process400. AlthoughFIG. 4Ais described with respect to a user agent114-1, processes described inFIG. 4Amay also be applied with respect to user devices112.

At block402, user agent114-1may register154with proxy106. For example, user agent114-1may send a registration request to a load balancer (e.g., load balancer152) in network100that redirects the registration request to a particular proxy106in a SIP proxy farm. Proxy106may register user agent114-1. Proxy106may previously have registered a plurality of auxiliary event-package servers, AEPSs108a-108n, that host an auxiliary event-package. The auxiliary event-package may be unknown to the SIP soft-switch and SIP gateway, and may extend functionality of user devices112on network100. The auxiliary package may extend a feature set of user device112. For instance, the auxiliary event-package may comprise a location service that publishes a location of user agent114to subscribers of the location service.

At block404, user agent114-1may subscribe156to the auxiliary event-package through proxy106. For example, user agent114-1may subscribe156to a location event-package that may include a third party event-package to network100. Proxy106may fork182the subscription request156to AEPSs108a-108n, which host instances of the auxiliary event-package. According to an implementation, proxy106forks182the subscribe156(sends subscribe156-1, subscribe156-2) to all instances of AEPSs108a-108n.

At block406, an initial notify is received from each of AEPSs108a-108nby user agent114-1and selected as a primary handle for the auxiliary event-package. Each of AEPSs108a-108nmay send an initial notify in response to receiving subscribe156messages received from user agent114-1. Each AEPS108may process respective subscribes156received and send initial notifies158based on workload. For example, an AEPS108that has a comparatively heavy workload may be slower in responding than an AEPS108with a comparatively light workload. User agent114-1may identify a primary handle based on respective times that initial notifies158are received from each of AEPSs108a-108n. According to an implementation, user agent114-1identifies the sender of a first initial notify158(illustrated as notify158-1inFIG. 1B) that user agent114-1receives as a primary handle for the auxiliary event-package for user agent114-1and may establish server-affinity at that time to the primary handle. Subsequent to identifying the primary handle, user agent114-1communicates with the particular AEPSs108that serves as the primary handle to access features of the auxiliary event-package.

At block408, user agent114-1may identify other AEPSs108a-108nas secondary handles based upon additional initial notifies158received from other AEPSs108a-108n. According to an implementation, user agent114-1may identify other AEPSs108a-108nthat sent initial notifies that are received later than a first initial notify158as secondary handles. User agent114-1maintains active subscriptions to the auxiliary event-package for the secondary handles.

At block410, user agent114-1may communicate with primary handle to execute the auxiliary event-package. For example, user agent114-1may publish to the primary handle and receive notifies168in response to call actions184and ensuing call updates166from an application server104in network100.

According to an implementation, at block412, user agent114-1may determine whether the primary handle is available. In instances in which the primary handle is available, user agent114-1continues to execute transactions with the auxiliary event package using the primary handle.

At block414, in response to a determination at block412that the primary handle is unavailable, user agent114-1may identify one of the secondary handles as a new primary handle. For example, user agent114-1may receive a SIP480/Unavailable message indicating that the primary handle (a particular AEPS108) is unavailable from proxy106. Subsequent to identifying the new primary handle, user agent114-1communicates with the particular AEPSs108that serves as the primary handle to access features of the auxiliary event-package (Block410). Additionally, user agent114-1may reestablish a connection to the former primary handle once the former primary handle becomes available. The former primary handle is then identified as a secondary handle.

FIG. 4Bis a flowchart of an exemplary process450for implementing a new subscription to an existing SIP session with an auxiliary event-package in network100. The data flows associated with process400are described in conjunction with signal flow190inFIG. 1C. Process450may execute in a user agent114and/or user device112(e.g., mobile phone, personal computer). It should be apparent that the process discussed below with respect toFIG. 4Brepresents a generalized illustration and that other elements may be added or existing elements may be removed, modified or rearranged without departing from the scope of process450. AlthoughFIG. 4Bis described with respect to a user agent114-2, processes described inFIG. 4Bmay also be applied with respect to user devices112. Although, process450is described as executing in network100subsequent to process400and may use existing sessions and information determined in process400, it should be understood that process450may be implemented independently (e.g., concurrently, before, after) of process400.

User agent114-2may register with proxy106(block452). For example, user agent114-2may send a registration request to a load balancer (e.g., load balancer152) in network100that redirects the registration request to proxy106. Proxy106may register user agent114-2.

At block454, user agent114-2may subscribe156to the auxiliary event-package through proxy106. Proxy106may redirect a subscription request (subscribe156) to an existing session160for the auxiliary event-package at an AEPS108.

At block456, user agent114-2may receive an initial notify158from AEPS108. User agent114-2thereby reuses session192that was initiated by user agent114-1.

According to an implementation, at block458, application server104may issue a call update170to AEPS108through an adapter110. For instance, application server104may issue the call update170, which is converted to a notify164by proxy106. Proxy106forks182the notification (notify164-1, notify164-2) to all subscribing user agents114for the auxiliary event-package.

The foregoing description provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while series of signal flows have been described with respect toFIGS. 1B and 1Cand series of acts have been described with regard to the flowcharts ofFIGS. 4A and 4B, the order of the signals flows and acts may differ in other implementations. Further, non-dependent signal flows and acts may be performed in parallel.

Although embodiments described herein in the context of SIP and an Internet Protocol (IP)-based network, in other implementations equivalent or analogous communication protocols (e.g., International Telecommunication Union (ITU) H.323) and/or types of transport networks (e.g., asynchronous transfer mode (ATM), frame relay, etc.) may be used. Both the ITU H.323 standard and the IETF's SIP standard are examples of protocols that may be used for establishing a communications session among terminals, such as devices112, connected to a network. Further, a combination of such protocols may be applied in various parts of the overall system.

Embodiments, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement the exemplary embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that one would be able to design software and control hardware to implement the embodiments based on the description herein.