DESCRIPTION SYSTEMS, METHODS, AND COMPUTER PROGRAM PRODUCTS FOR PROVIDING SERVICE INTERACTION AND MEDIATION IN A COMMUNICATIONS NETWORK PRIORITY CLAIM Tile application claims the benefit of U.S. Provisional Patent Application Serial No. 60/925,612, filed April 20,2007, U.S. Provisional Patent Application Serial No. 60/991,260^ filed November 30, 2007, and U.S. Provisional Patent 10 Application Serial No. 60/992,384, filed Decembers, 2007; the disclosures of which are incorporated herein by reference in their entireties. TECHNICAL FIELD The subject matter described herein relates to providing services in 15 mixed-protocol telecommunications networks. More particularly, the subject matter described herein relates to systems, methods, and computer program products for providing service interaction and mediation in a communications network. 20 BACKGROUND Service interaction in a communications network refers to the process of managing the interaction between network entities that request network services, referred to as sen/ice clients, and network entities that provide those network services, referred to as application servers. Service clients may 25 request a sen/ice from an application server by issuing messages commonly referred to as service requests, service trigger messages, or service queries. Application sen/ers may respond to such requests by issuing messages commonly referred to as service request responses, service responses, or simply responses. 30 Service mediation in a communications network refers to conversion of service-related messages from one message protocol into another message protocol. Service mediation may also entail determining whether a requesting client or communications service subscriber is authorized to access network applications / services, and subsequently enforcing such access authorization -1- rules. Service mediation becomes necessary as formerly distinct networks are merged, requiring network elements to communicate in each other's protocol, and as protocols themselves are improved and modified to the point that newer versions of a protocol are no longer backwards-compatible with older versions 5 of the same protocol. One example of networks that are created from the merger of previously distinct and often incompatible networks are telecommunications networks. Modern telecommunications networks may be an amalgam of land-line telephone networks, mobile telephone networks, and data networks. Each 10 formerly separate piece of a now-consolidated network may have its own services, which the other pieces of the network would like to use. One example service Is prepaid calling, in which a subscriber purchases in advance an amount of network usage. A prepaid subscriber might purchase a certain number of minutes of call time, and once the subscriber has used all 15 of the purchased minutes, the subscriber's access to the network may be barred unless and until more minutes are purchased. Thus, whenever a prepaid subscriber attempts to use the network, a query may be made to determine whether the subscriber's prepaid account has a balance sufficient to allow the subscriber to proceed. For example, when a prepaid subscriber tries 20 to make a call, the subscriber connects to the telecommunications network through a mobile switching center (MSC) if the subscriber is a using a mobile phone, and through a service switching point (SSP) if the subscriber is using a land line. An MSC/SSP is hereinafter generically referred to as a switching point (SP). An SP typically queries a service control point (SCP) that maintains 25 a prepaid database (I.e., a "prepaid SCP") to determine whether a mobile subscriber's prepaid account balance is sufficient to allow the call to proceed. The query to a prepaid SCP is one possible step in a sequence of steps that the cell phone, the SP, and various SCPs perform in the process of connecting to a network and setting up a call. This process may be defined by 30 a basic call state model (BCSM) in which the process is described In terms of transitions in a call state diagram, where each call state may represent a change of status, such as "dialing", "ringing", "connected", "disconnected", etc. -2- The SP may track and maintain the state information for each call that it processes, based on the BCSM used by the SP. A BCSM may Include some point in the state machine where control of the call may be permanently or temporarily transferred to another entity. Such 5 a point in the state machine is called a detection point. Detection points are based on the specific call model applicable to the protocol being used by the SP. The SP may generate a service trigger message in response to a triggering event in detection point. One example of a service trigger message is an IDP message. The service trigger message typically contains parameters, 10 such as a service key, that identify which sen/ice is being requested. For example, in the prepaid subscriber example above, when the subscriber attempts to place a call, the subscriber's cell phone sends the called party telephone number to an SP. In an example BCSM, a detection point may when the SP successfully receives the called party number. In response to the 15 detection point, the SP may send a service trigger message, such as an IDP message, to a prepaid SCP to query the prepaid account balance for the calling party, the called party, or both. The service trigger message may include a sen/ice key that identifies the sen/ice desired. In this example, the sen/ice desired is a query to a prepaid database. The prepaid SCP may perfomn a 20 prepaid account balance query and then return control of the call to the SP along with an indication of whether or not the prepaid subscriber(s) had a sufficient account balance to allow the call to proceed. Thus, by issuing the service trigger message the SP may temporarily pass control of the call to the prepaid SCP and regain control from the prepaid SCP upon receipt of a sen/ice 25 response message. One problem associated with conventional telecommunications networks is one of interoperability. As telecommunications signaling networks have evolved, so too have the protocols, and a merged communications network may use protocols ranging from system signaling #7 (SS7) protocol to 30 SIGTRAN, which can be thought of as SS7 over Internet protocol (IP), to session initiation protocol (SIP), and others. Within the SS7 protocol family, there are multiple variants, such as intelligent network (IN), advanced intelligent network (AIN), wireless intelligent network (WIN), and customized applications for mobile networks enhanced logic (CAMEL). Thus, different application sen/ers may use different protocols. Similarly, a client requesting the services may use protocols different from the protocol used by the application server. For example, an operator may have a prepaid SCP running IN protocol, but 5 may want to access the same prepaid SCP from a new CAMEL-based SP; or, the operator may want to offer a new service, that is only available on a SIP application server (SAS); to service clients that only support IN and CAMEL. Many other examples may be contemplated by those knowledgeable in the art. Because the individual pieces of the merged network may use separate 10 protocols, they may not interoperate well, or at all. One proposed solution to the problem of Interoperability is to modify the service clients so that they support all protocols required by the various application servers. Another proposed solution is to modify the application servers so that they support all protocols required by the various service clients. 15 Both proposed solutions can be very expensive, due to the number of entities on the network that may need to be modified. In addition, protocol mediation can involve more than mere message format conversion, and may require maintenance of separaite data structures, state machines, and the like, adding complexity to the call state models. Furthermore, putting additional complexity 20 into either the service clients or the application servers may potentially tie a communications network to one client or server vendor, reducing that vendor's incentive to provide flexible solutions and/or competitive pricing. Another problem that limits interoperability of various components of a telecommunications network is that current implementations of service clients 25 and applications servers Support very limited service interaction. In particular, current implementations of MSCs and SSPs do not have the ability to generate multiple service request messages in response to a single detection point. This inability can prevent a telecommunications sen/ice provider from providing complex service packages that require interaction among multiple application 30 servers. For example, where a prepaid subscriber wants to connect using a virtual private network (VPN), the SP may need to issue two separate sen/ice request messages, one to the prepaid SCP to determine whether the subscriber has a sufficient balance to proceed, and another to a VPN SCP to -4- handle setting up the VPN. Thus, unless the SP can issue multiple service requests in response to a single sen/ice trigger, such as an IDP, the telecommunications service provider cannot offer a service package that allows a subscriber to be both a prepaid subscriber and a VPN subscriber. 5 One proposed solution to the inability to generate multiple service request messages from a single service trigger Is to add this functionality to either the service client or the application server. As in the case of service mediation above, this proposed solution can be very expensive due to the number of network entities that must be upgraded, and may require that the 10 basic call state model used by the SP, for example, to become enormously more complex, and thus harder to maintain. Yet another proposed solution to the problem of interoperability is found in the 3''' Generation Partnership Project (3GPP) specification TS 23.002, ETSI TS 123 002 V7.1.0 (2006-03). This document describes a service capability 15 interaction manager (SCIM), which is an application which performs service interaction and mediation. The SCIM is designed to operate as an intermediary between entities that request sen/ices and entities that provide services. The SCIM is designed to appear as an application server to the service client, and as a service client to the application server. For example, a SCIM may present 20 itself to an MSC as a CAMEL-speaking SCP, and to an SSP as an IN-speaking SCP. Similarly, the SCIM may present itself to the SCP as either an IN-speaking or CAMEL-speaking network element, depending on the capabilities of the SCP. In addition, the SCIM allows CAMEL or IN based entities that request services to communicate with IMS entities that provide services that 25 use the SIP protocol, such as SIP Application Servers (SAS). However, current implementations of the 3GPP SCIM do not issue multiple service requests because they are unable to process the multiple responses to the service requests and take appropriate action. The process of accepting multiple input messages (the responses to the service requests) and 30 generating typically a single output message (a response representing the collective responses to the service requests) is referred to as "aggregation". Since each service control network client may either accept or reject their respective requests for sen/ice, a SGIM that issues multiple requests in -5- response to a single service trigger message must also be able to resolve conflicting responses to determine whether or not the call proceeds anyway. Current implementations of the 3GPP SCIM do not issue multiple service requests in response to a single service trigger, and do not aggregate. 5 Thus, a significant limitation of both conventional SPs and current implementations of the 3GPP SCIM is that, due to an inability to aggregate, they can effectively generate only a single service request message for any given service trigger, which is typically a detection point. This limits the network operator's ability to offer a "service package" to the subscriber if the service 10 package requires multiple service requests to be issued in response to a single service trigger. For example, this limitation currently prevents a subscriber from being both a prepaid subscriber and a VPN subscriber. Accordingly, there exists a need to manage service interactions and provide service mediation between a network entity that requests network 15 services and a plurality of network entities that provide network services. Specifically, there exists a need for systems, methods, and computer program products for providing enhanced service interaction and mediation in a communications network. 20 SUMMARY According to one aspect, the subject matter described herein includes a system for providing service interaction and mediation in a communications network. The system Includes a communications interface for receiving a ciient-to-SCIM message from a service client; and a sen/ice capability 25 interaction manager (SCIM) module for providing service interaction between the service client and multiple application servers providing different types of services. Providing the service interaction includes receiving, from the communications interface, the ciient-to-SCIM sen/ice interaction message, and, in response to receiving the ciient-to-SCIM message, generating multiple SCIM- 30 to-server messages and sending the SCIM-to-server messages to multiple application servers. Providing the service interaction also includes receiving multiple server-to-SCIM service interaction messages from at least some of the application servers that received the SCIM-to-server messages, and, in response to receiving the server-to-SCIM messages, generating a SCIM-to- -6- ■ client message containing an aggregation of at least a portion of data from at least some of the server-to-SCIM messages, and sending the SCIM-to-client message containing the aggregation to the service client via the communications interface. 5 According to another aspect, the subject matter described herein includes a system for providing rules-based service Interaction and mediation in a communications network. The system includes a service interaction and mediation rules database for storing sen/Ice Interaction and mediation rules for providing service interaction and mediation, and a service capability interaction 10 manager (SCIM) module for providing, using service Interaction and mediation rules stored in the service Interaction and mediation rules database, service interaction and mediation between a sen/Ice client and a plurality of application servers providing different types of services. The service capability Interaction manager module is configured to receive at least one incoming service 15 Interaction message; identify, using a component of one of the incoming messages, a sen/ice interaction and mediation rule; generate, using the identified rule, at least one outgoing service interaction message; and send the at least one outgoing message. According to yet another aspect, the subject matter described herein 20 includes a system for providing service interaction and mediation in a communications network. The system includes a communications interface for receiving a sen^lce interaction message including infomiation Identifying a subscriber, and a sen/Ice capability Interaction manager (SCIM) module for providing service interaction and mediation between a service client and a 25 plurality of network entities. Providing the service interaction includes identifying an event, occurring at the service client and associated with the identified subscriber, for which notification is desired; identifying at least one of the plurality of network entities for receiving notification of the identified event; maintaining mappings between the identified network entitles and the Identified 30 event; and sending, to the service client, a request to send notification of the identified event to the SCIM module. According to yet another aspect, the subject matter described herein includes a service capability interaction manager (SCIM) having an extendable . ■ -7- arcfiitecture. Tlie SCIM includes a database for storing system configuration information and element protocol configuration information; a service interaction rules module for storing service interaction and mediation rules; a service mediation and aggregation logic module for providing service mediation and 5 aggregation in a communications network based on stored service interaction and mediation rules and stored system configuration information; a communications interface for receiving, from a plurality of network entities, service interaction messages including information identifying a subscriber; and a plurality of protocol handlers for performing protocol mediation and 10 conversion between a first protocol used by the service mediation and aggregation logic and a second protocol used by one of the plurality of network entities, based on stored element protocol configuration information. According to yet another aspect, the subject matter described herein includes a method for providing service interaction and mediation in a 15 communications network. The method includes receiving, at a service capability interaction manager (SCIM) module for performing service interaction and mediation between a service client and multiple application servers providing different services, a client to a client-to-SCIM service interaction message from a service client, and, in response to receiving the client-to-SCIM 20 message, generating multiple SCI M-to-server messages and sending the SCIM-to-server messages to multiple application servers. The method also includes receiving multiple server-to-SCIM service interaction messages from at least some of the application servers that received the SCIM-to-server messages, and, in response to receiving the server-to-SCIM messages, 25 generating a SCIM-to-client message containing an aggregation of at least a portion of data from at least some of the server-to-SCIM messages, and sending the SCIM-to-client message containing the aggregation to the service client. According to yet another aspect, the subject matter described herein 30 includes a method for providing rules-based sen/ice interaction and mediation in a communications network. As used herein, the term "rule" refers to a description of the response of an entity to particular stimuli, and the term "rules-based" refers to behavior that is determined at least in part by the operation of -8- one or more rules. The method includes receiving, at a service capability interaction manager (SCIM) module for performing service interaction and mediation between a service client and a plurality of application servers providing different services, at least one incoming service interaction message; 5 using a component of one of the incoming messages to identify a service interaction and mediation rule in a service interaction and mediation rules database that is operatively associated with the service capability interaction manager module and is for storing service interaction and mediation rules for performing service interaction and mediation; and using the identified rule to 10 generate and send at least one outgoing message. According to yet another aspect, the subject matter described herein includes a method for providing service interaction and mediation in a communications network. The method includes, at a service capability interaction manager (SCIM) module for performing service interaction and 15 mediation between a service client and a plurality of network entities: receiving a service interaction rnessage including information identifying a subscriber; identifying an event, occurring at the service client and associated with the identified subscriber, for which notification is desired; identifying at least one of the plurality of network entities for receiving notification of the identified event; 20 maintaining mappings between the identified network entities and the identified event; and sending, to the service client, a request to send notifications of the identified event to the SCIM module. The subject matter described herein for systems, methods, and computer program products for providing sen/ice Interaction and mediation in a 25 communications network may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms "function" or "module" as used herein refer to hardware, software, and/or firmware for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a computer readable medium 30 having stored thereon computer executable instructions that when executed by the processor of a computer perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include disk memory devices, chip memory -9- devices, programmable logic devices, and application specific integrated circuits. In addition, a computer program product that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms. 5 BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings of which: Figure 1 is a block diagram illustrating an exemplary system for providing 10 service interaction and mediation in a communications network in accordance with an embodiment of the subject matter described herein; Figure 2 is a flow chart illustrating an exemplary process for providing service interaction and mediation in a communication network in accordance with an embodiment of the subject matter described herein; 15 Figure 3 is a flow chart illustrating an exemplary process for managing message subscription and notification in a communications network in accordance with an embodiment of the subject matter described herein; Figure 4 is a block diagram illustrating an exemplary system for providing rules-based service interaction and mediation in a communications network in 20 accordance with another embodiment of the subject matter described herein; Figure 5 is a flow chart illustrating an exemplary process for providing rules-based service interaction and mediation in a communications network in accordance with an embodiment of the subject matter described herein; Figure 6 is a flow chart illustrating the operation of an exemplary system 25 for providing rules-based sen/ice interaction and mediation in a communications network in accordance with an embodiment of the subject matter described herein; Figure 7 is signaling message flow diagram illustrating in more detail exemplary messages communicated between a service client network entity 30 and two application servers in accordance with an embodiment of the subject matter described herein, showing examples of multiple message issue and aggregation from both directions; Figure 8 is signaling message flow diagram illustrating in more detail exemplary messages communicated between a service client network entity -10- and two application servers In accordance with an embodiment of the subject matter described herein; Figure 9A is a block diagram illustrating an exemplary system for providing service interaction and mediation in a communications network in 5 accordance with another embodiment of the subject matter described herein; Figure 9B is a block diagram illustrating an exemplary system for providing service interaction and mediation in a communications network in accordance with another embodiment of the subject matter described herein; Figure 10 is a block diagram illustrating an exemplary system for 10 providing service interaction and mediation in a communications network in accordance with another embodiment of the subject matter described herein; Figure 11 is a block diagram illustrating an exemplary system for providing service interaction and mediation in a communications network in accordance with another embodiment of the subject matter described herein; 15 and Figure 12 is a flow chart illustrating an exemplary process for providing service interaction and mediation in a communication network in accordance with another embodiment of the subject matter described herein. 20 DETAILED DESCRIPTION In accordance with the subject matter disclosed herein, systems, methods, and computer program products for providing service interaction and mediation in a communications network are provided. The subject matter described herein enables pre-IMS network elements to access SIP-enabled 25 services, allows GSM elements to access IP services, and allows IMS/CSCF to access GAMEL/IN services. In one embodiment, multiple service request messages may be generated from a single service trigger, and multiple service response messages may be aggregated into a single response message. A single 30 service trigger may be translated into or used to trigger the generation of multiple additional service triggers, which enables multiple feature invocation' and interaction involving any number of communications protocols including SiP, CAMEL, and IN protocols. ■11- In another embodiment, sen/ice interaction and mediation may be based on service interaction and mediation rules, which may be stored in a service interaction and mediation rules database. Figure 1 is a block diagram illustrating an exemplary system for providing 5 sen/ice interaction and mediation in a communications network in accordance with an embodiment of the subject matter described herein. In one embodiment, system 100 may include an enhanced service capability interaction manager ESCIM102 for providing service interaction and mediation, including receiving a service trigger message from a client, 10 generating multiple service request messages, and aggregating the associated responses. A sen^ice request message may include a service trigger message (e.g., initial detection point message), a service query message, or other message containing information associated with a communications service subscriber. ESCIM 102 may include a sen/ice capability interaction manager 15 module (SCI M module 104) for providing service interaction between a service client 106 and multiple application servers providing different types of services. SCIM module 104 may communicate with service client 106 via a first communications interface, such as a service control function (SCF 108), for receiving client-to-SCIM messages and for sending SCIM-to-client messages. 20 In one embodiment, SCF 108 may perform protocol conversion between a protocol used by service client 106 and a different protocol, such as an internal protocol used by SCIM module 104 and/or a protocol used by an application server. For example, SCIM module 104 may use a SIP protocol for all internal operations, while a message from service client 106, such as an initial detection 25 point (IDP) message, may use a non-SIP protocol, such as an IN protocol. In this case, SCF 108 nlay convert a client-to-SCIM message from IN protocol to SIP protocol before passing the message to SCIM module 104 for internal processing. Similarly, SCF 108 may convert a SClM-to-client message from SIP protocol to IN protocol before sending the message to sen/ice client 106. 30 SCIM module 104 may communicate with application sen/ers via a second communications interface, such as a sen/ice switching point (SSF110), for receiving server-to-SClM messages and for sending SCIM-to-sen/er messages. In one embodiment, SSF 110 may perform protocol conversion -12- between a protocol used by an application server, such as PPSCP 112 or RTSCP 114, and a different protocol, such as an internal protocol used by SCIM module 104 and/or a protocol used by service client 106. For example, SCIM module 104 may use an AIN protocol internally, while PPSCP 112 may 5 use a CAMEL protocol, in which case SSF110 may convert a server-to-SCIM message from CAMEL protocol to an internal protocol (e.g., AIN) before passing the message to SCIM module 104. Similarly, SSF 110 may convert a SCIM-to-server message from AIN protocol to CAMEL protocol before sending the message to the application server. 10 In one embodiment, service client 106 may be a mobile switching center (MSC), a service switching point (SSP), or other network entity that may request network services. The application servers may include system control points (SCPs), session initiation protocol (SIP) application servers (SAS), simple object application protocol (SOAP) servers, or other network entity that 15 may provide network services. For example, system 1(M) may include a prepaid SCP (PPSCP 112) for managing prepaid subscriber accounts, a ringback tones SCP (RTSCP 114) for providing ringback tones whereby a calling party hears the called party's custom music or message instead of the default sound sent to a calling party to indicate that the called party's phone is ringing, and a SIP 20 application server (SAS 116) for providing SIP-based services. SCIM module 104 may perform service interaction. In one embodiment, SCIM module 104 receives a client-to-SCIM service interaction message, and, in response to receiving the client-to-SCIM message, generates multiple SCIM-to-server messages and sends the SCIM-to-server messages to multiple 25 application servers. SCIM module 104 may receive multiple server-to-SCIM service interaction messages from at least some of the multiple application servers that received the SCIM-to-server messages, and, in response to receiving the server-to-SCIM messages, generate a SCIM-to-client message containing an aggregation of at least a portion of data from at least some of the 30 server-to-SCIM messages, and send the SCIM-to-client message containing the aggregation to the service client via the communications interface. -13- Figure 2 is a flow chart illustrating an exemplary process for providing sen/ice interaction and mediation in a communication network in accordance with an embodiment of the subject matter described herein. At block 200, a client-to-SCIM service interaction message is received 5 from service client 106. For example, ESCIM 102 may receive an initial detection point (IDP) message in AIN protocol from a service switching point (SSP), or an IDP message in CAty/IEL protocol from a MSC. In one embodiment, a communications interface, such as service control function SCF 108, may perform a mediation function to convert the incoming 10 message to an internal protocol. For example. ESCIi\^ 102 may use a SIP protocol internally, in which case SCF 108 may convert the incoming AIN or CAMEL protocol message to a SIP protocol before passing the converted message to SCIM module 104. Alternatively, the protocol conversion may be performed by SCIM module 104. 15 At block 202, in response to receiving the client-to-SCIM message, multiple SCIM-to-server messages may be generated and sent to at least some of the application servers. For example, SCIM module 104 generate and send two SCIM-to-server messages: a prepaid query to PPSCP 112 to determine whether a prepaid calling and/or called party has a sufficient prepaid account 20 balance, and a ringback tones service request to RTSCP 114, requesting that the called party's custom ringback tone be sent to the calling party while the calling party waits for the called party to complete the connection. In one embodiment, a component within ESCIM 102, such as SSF 110, may perform a mediation function to convert the SCIM-to-server messages 25 from either a protocol used by service client 106 or an internal protocol used by SCIM module 104 to a protocol used by an application server. For example, if ESCIM 102 uses a SIP protocol internally, PPSCP 112 uses an IN protocol, and RTSCP 114 uses a CAMEL protocol, SCIM module 104 may generate the prepaid query and ringback tones service requests in SIP protocol and pass the 30 service requests to SSF 110. SSF 110 may then convert the messages into IN protocol and CAMEL protocol, respectively, before sending the queries to their respective destinations. Alternatively, another component within ESCIM 102, such as SCIM module 104, may perform the protocol conversion. -14- At block 204, multiple server-to-SCIM messages may be received from at least some of the application sen/ers that received the SCIM-to-server messages. For example, as the application servere receive their representative messages from ESCIM102, they may send response messages to ESCIM102 5 in reply. PPSCP 112 and RTSCP 114 may each generate a response to their respective queries, and their responses may be received by ESCIM 102. In one embodiment, a component within ESCIM 102, such as SSF110, may convert the sen/er-to-SCIM messages from their external protocols to the internal protocol used by ESCIM 102 before passing the server-to-SCIM 10 message to SCIM module 104. For example, SSF 110 may convert the prepaid query response received from PPSCP 112 from an IN protocol into an internal SIP protocol, and convert the ringback tones sen/ice request response received from RTSCP 114 from a CAMEL protocol into an internal SIP protocol, before forwarding the converted message to SCIM module 104. Alternatively, another 15 component within ESCIM 102, such as SCIM module 104, may perform the protocol conversion. At block 206, in response to receiving the server-to-SCIM messages, a SCIM-to-client message may be generated, containing an aggregation of at least a portion of data from at least some of the server-to-SCIM messages, and 20 sent to the service client. For example, both PPSCP 112 and RTSCP 114 may respond to their respective queries and service requests with a "service denied" message, in which case SCIM module 104 may aggregate the multiple responses into a single "service denied" message and send a message containing the aggregated response to sen/ice client 106. In this manner, 25 service client 106 will receive only a single response to its single IDP. Similarly, SCIM module 104 may aggregate multiple "sen/ice allowed" messages into a single "service allowed" message, which it will send to sen/ice client 106. SCIM module 104 may receive conflicting messages, which must be resolved. For example, SCIM module 104 may receive a "service allowed" 30 message from PPSCP 112 (e.g., indicating that the prepaid subscribers have sufficient funds to allow access to the network) and a "sen/ice denied" message from RTSCP 114 (e.g., indicating that the called party is not configured to send a custom ringback tone to the calling party). In this scenario, SCIM module 104 -15- may determine that the call should continue without a custom ringback tone, in which case SCIM module 104 may generate and send a single "connect" message to service client 106 to indicate that the call should continue. On the other hand, if RTSCP 114 returns a "service allowed" message (e.g., the called 5 party has a custom ringback tone that is to be played to the calling party while the calling party is waiting for the called party to answer the phone), but PPSCP 112 returns a "sen/ice denied" message (e.g., the calling party is a prepaid subscriber with an insufficient prepaid account balance), SCIM module 104 may generate and send a single "don't connect" message to service client 106 to 10 indicate that access to the network was denied. According to another embodiment of the present invention, SCIM function 104 is adapted to provide intelligent "error" handling logic in the course of applying sen/ice interaction and sen/ice orchestration rules. For instance, using the previous example, SCIM function 104 receives a single service trigger 15 message from service client 106. In response to receiving the sen/ice trigger message, SCIM function 104 first generates a SCIM-to-server message that is fonwarded to PPSCP 112. If PPSCP 112 responds to SCIM function 104 with an "error" indication, then SCIM function 104 does not generate a second SCIM-to-server message towards RTSCP 114. Instead, SCIM function 104 20 generates a single "don't connect" message to service client 106 to indicate that access to the network was denied. In yet another example of intelligent error handling, if SCIM function 104 first generates a SCIM-to-server message that is fonwarded to PPSCP 112 and does not receive a response from PPSCP 112 (e.g., PPSCP 112 is unavailable / failed), then SCIM function 104 does not 25 generate a second SCIM-to-server message towards RTSCP 114. Instead, SCIM function 104 generates a single "don't connect" message to service client 106 to indicate that access to the network was denied. In this manner, service nodes such as SCPs and SIP applications servers may be shielded from unnecessary queries. 30 In addition to managing requests that issue from service client 106 and aggregating the responses from the application senders, SCIM module 104 must also manage the reverse scenario - where requests are issued from multiple application servers and responses to those requests come from service -16- client 106. Unlike the examples presented above, where SCIM module 104 may broadcast a request and aggregate the responses, In the foilowing examples, SCIM module 104 may aggregate the requests and broadcast the responses. For example, an application server may request to be notified 5 whenever a specified event occurs at service client 106. One example of this manner of operation is a publish and subscribe (pub/sub) system. In the context of a service switching point, such functionality is typically implemented through the use of service triggers which may be statically armed through provisioning or dynamically armed by an SCP/ application server. Referring to 10 Figure 1, in one embodiment, system 100 may contain a subscription database 208 for maintaining publication and subscription information. Figure 3 is a flow chart illustrating an exemplary process for managing message subscription and notification in a communications networi<: in accordance with an embodiment of the subject matter described herein. 15 At block 300, multiple requests to be notified of specified events are received from multiple application servers. For example, multiple SCPs or application servers may generate and send to the SCIM function multiple requests to arm the same service trigger at an SSP. The multiple requests are aggregated into a single notification request message, which is sent to a 20 service client. For example, after an initial IDP is sent from sen/ice client 106 through SCIM module 104 to multiple applications servers, one or more application servers may issue requests to subscribe to notification of certain events ttiat may occur on the service client 106. In this example, SCIM module 104 may receive a report basic call state model (RRB) request, RRB(E1, E2), 25 from PPSCP 112, asking to be notified of the (xjcurrence of event "El" or event "E2". SCIM module 104 may receive another RRB request, RRB(E1 ,E3), from RTSCP114, asking to be notified of the occurrence of event "El" or event "E3". In one embodiment, SCIM module 104 may aggregate the separate RRB requests into a single RRB request, RRB(E1 ,E2,E3), asking to be notified of the 30 occurrence of either event "El", "£2", or "E3", and send the aggregated single request to service client 106. Thus, from the perspective of service client 106, ESCIM102 looks like a single application server that is asking for notification whenever specified -17- events occur. When any or the specified events do occur, service client 106 may issue a notification message to ESCIM 102. ESCIM 102 has the responsibility to make sure that the subscribed application servers receive proper notice of the pertinent events. 5 At block 302, mappings between the application servers and the specified events are maintained. In one embodiment, SCIM module 104 may use subscription database 208 to store and maintain lists of which applications servers should be notified for which events. In one embodiment, for each message received by SCIM module 104, 10 such as subscription requests and notification requests, the service type associated with the request is determined. Example sen/ice types include notification or publish/subscribe services, charging services, and the like. An application server that is associated with the determined service type is subscribed to receive notification of events associated with that service type. 15 For example, upon receipt of an RRB(EI) request from PPSCP 112, SCIM module 104 may create a list of application servers that should be notified of the occurrence of event El, if such a list does not already exist, and add PPSCP 112 to thaf list. Upon receipt of an RRB(E1,E2) request from RTSCP114, for example, SCIM module 104 may add RTSCP114 to the list of 20 application servers that should be notified if event E1 occurs, create a list of application servers that should be notified if event E2 occurs, and add RTSCP 114 to that list. At block 304, a notification of an event is received. The mappings are used to identify which application servers are subscribed to receive notification 25 of the event, and the identified application servers are notified of the event. For example, service client 106 may issue a client-to-SCIM message notifying ESCIM 102 of the occurrence of charging event E2. The client-to-SCIM message is processed by SCIM module 104, which may identify which of the application servers should receive notification and send notification to the 30 identified application servers. In one embodiment, SCIM module 104 may query subscription database 208 using the event or service type to identify which list or lists of servers should receive notification messages, and send notification messages to each -18- application server included in the identified list or lists. For example. If event E2 occurs, service client 106 may issue a first event report BCSM (ERB) message, ERB(E2), to ESCIM 102. SCIM module 104 may determine that it is being notified of the occurrence of event E2, retrieve the list of application servers to 5 be notified if event E2 occurs, and send notification messages to each application server on the retrieved list. In this example, SCIM module 104 which may determine that only RTSCP114 is subscribed to receive notification of event E2, in which case ESCIM 102 may notify RTSCP 114 of the occurrence of event E2 by publishing the ERB(E2) message (e.g., fon/varding a 10 copy of the ERB(E2) message) to RTSCP 114. Continuing the example above, if event El occurs, service client 106 may issue a second (ERB) message, ERB(EI), to SCIM module 104. When SCIM module 104 receives the ERB(EI) message, it may determine that both PPSCP 112 and RTSCP 114 are subscribed to receive notification of event El. 15 In one embodiment, SCIM module 104 may determine which application servers are subscribed by checking its list of E1 subscribers. SCIM module 104 may forward the ERB(EI) message or othenwise issue an event notification message to both PPSCP 112 and RTSCP 114. In yet another example, SCIM module 104 may receive an apply 20 charging (ACH) message from one or more application servers, such as from PPSCP 112 and RTSCP 114. SCIM module 104 may aggregate the multiple messages into a single ACH message, which is then sent to service client 106. SCIM module 104 may maintain charging service subscription information, such as a list identifying PPSCP 112 and RTSCP 114 as application servers 25 that should be notified in the event of receipt of an apply charging report (ACR) message from service client 106. If SCIM module 104 later receives an ACR message from service client 106, SCIM module 104 may publish the ACR message to those application servers identified as being subscribed to receive these messages. For example, SCIM module 104 may, based on its 30 subscription information, send separate ACR messages to each of PPSCP 112 and RTSCP 114. ■19- The service mediation and protocol conversion functions described in sections above may be performed in concert with the publication and subscription functions. Figure 4 is a bloGl< diagram illustrating an exemplary system for providing 5 rules-based service interaction and mediation in a communications network in accordance with another embodiment of the subject matter described herein. In one embodiment, system 400 may include an enhanced service capability interaction manager ESCIM 402 for providing service interaction and mediation. ESCIM 402 may include a sen/ice capability interaction manager module 10 (SCIM module 404), which uses sen/ice interaction and mediation rules stored in a service interaction and mediation rules database 406 to provide service interaction and mediation between service client 106 and a plurality of application servers providing different types of services. Conceptually, a rule defines how a module or entity responds in a 15 particular situation and/or to particular stimuli. Example rules in a rules-based SCIM might include: "If an IDP is received from an MSC or SSP, check to see if the calling party Is a prepaid subscriber, and, if so, send a query to a prepaid SCP asking if the subscriber's prepaid account balance is sufficient to be allowed access"; and "If the prepaid SCP sends a message indicating that 20 subscriber X does not have a sufficient prepaid account balance, terminate subscriber X's cair\ A script is a combination or sequence of rules. A script may be used to define more complicated interactions, including interactions that require maintenance of state information, such as stateful transactions. A script may define a sequence of messages, such as queries and responses, that 25 should be exchanged between the SCIM module 404 and one or more application servers. For example, a script may define the interoperability of multiple CAMEiyiN-based products that utilize the same CAMEUIN trigger. Scripts may be comprised of literal and abstract terms and logical operators that are easily interpreted and understood by a human operator. A human 30 operator may compose a SCIM rule by assembling terms and logical operators so as to define a service interaction rule. It will be appreciated that the exemplary rules referred to below are plain English language equivalents, and -20- that a SCIM rule may assume a variety of forms depending upon the set of literal and abstract terms used in a particular SCIM system. A script may define rules that operate in series. For example, a script may include a first rule, "If a prepaid subscriber has an insufficient balance, 5 send a text message to the subscriber asking for permission to replenish his prepaid minutes by billing his credit card", and a second rule, "If permission is received from a prepaid subscriber to replenish his prepaid minutes, send a electronic funds transaction request to the subscriber's credit card company, requesting a transfer of funds from his credit card to purchase additional 10 prepaid minutes". According to one embodiment, user configurable SCIM rules are maintained in a table-driven environment. Consequently, SCIM rules defining how interactions among multiple services are to be handled may be quickly and easily configured on a per-service basis (i.e., same behavior for all subscribers of a service), on a subscriber-by-subscriber basis, or a combination 15 of both. In one embodiment, a script may be associated with a combination of services available to a particular subscriber, such as a mediation service package, a calling plan, and the like. For example, a first subscriber's account or calling plan may be a prepaid account with custom ringback tones, while a 20 second subscriber's account may be a non-prepaid account with VPN service. In one embodiment, SCIM module 404 may select a service interaction and mediation language script based on a subscriber's calling plan, where the script defines the combination of services, such as prepaid, ringback tone, and VPN service, that is available to that subscriber. SCIM module 404 may then 25 execute the selected service interaction and mediation language script. In one example, SCIM module 404 may determine the calling party is a prepaid subscriber and the called party is a ringback tones subscriber, and therefore two services, prepaid and ringback tones, must be requested in response to the IDP message. Based on the results of this service key / 30 subscriber ID analysis, SCIM module 404 may select a service interaction and mediation script from rules database 406 that is designed for the "prepaid calling party + ringback tones" subscriber. SCIM module 404 may then execute the selected script. The script being executed by SCIM module 404 may direct -21- SCiiyi module 404 to send multiple messages related to the first IDP message; in this example, SCII\^ module 404 may send a prepaid service request message to PPSCP112 in order to determine whether the calling subscriber has a sufficient prepaid account balance to be allowed access to the network, 5 and SCiM module 404 may also send a ringback tones request message to RTSCP114 requesting the called party's custom ringback tone. in another example, during key and subscriber analysis of the original IDP message, SCIM module 404 may determine that the called party also is a prepaid subscriber. In that case, a different service interaction and mediation 10 script, one which is designed for the "prepaid calling party+prepaid called party + ringback tones", may be selected from rules database 406, in which case the script may issue a second prepaid query to RTSCP 114 in order to determine whether the called subscriber has a sufficient prepaid account balance. A script may define njles that operate in parallel. For example, a script 15 may Include a first rule, "If an IDP trigger is received for a call from a prepaid caller, query the prepaid database to confirm that the calling party has a sufficient prepaid account balance to allow access to the network", and a second rule, "If an IDP trigger is received for a call to a prepaid caller, query the prepaid database to confirm that the called party has a sufficient prepaid 20 account balance to allow receipt of the call". In this example, a single IDP message could trigger the operation of both rules, which could operate independently of each other. This is one example of a rules-based implementation of an entity, such as a SCIM, that can issue multiple SCIM-to-server service requests in response to a single cllent-to-SCIM service trigger. 25 As seen from the example Immediately above, a SCIM may receive distinct responses from the two prepaid queries, which it may need to reconcile. How and when to reconcile multiple responses may also be defined by a rule. For example, a rules-based SCIM may include a rule such as "If a prepaid calling party has a sufficient account balance and a prepaid called party does 30 not have a sufficient account balance, allow the call anyway If the prepaid called party is a premium subscriber (e.g., one who is not charged for incoming calls), but deny the call If the prepaid called party is a standard subscriber (e.g., one who is charged for incoming calls)." This Is one example of a rules-based -22- implementation of an entity, such as a SCIM, that can aggregate multiple server-to-SCIM response messages into a single SCIM-to-client response message. Thus, there may be a rule (and associated response) for every 5 combination of inputs. For example, there may be a rule for responding to an I DP from an MSC, a rule for responding to an IDP from an SSP, a rule for responding to a CONNECT from a prepaid SCP, a rule for responding to a CONNECT from a ringtones SCP, and so on. Rules may be written in a hierarchical or modular fashion, such that 10 common functions, such as a query to a prepaid database to determine whether a subscriber has a sufficient account balance, may be invoked by other functions. For example, the multi-instruction rule above might be written as "If an IDP is received from a prepaid subscriber that is calling another prepaid subscriber, invoke function CheckPrePaidBalance("CallingParty"), and also 15 invoke function CheckPrePaidBalance("CalledParty")." In another example, there may be a single rule for responding to all IDPs, and sub-rules which are invoked depending on whether the IDP came from an MSC or an SSP. In one embodiment, rules may access tables and variables. Using variables allows great flexibility and a significant reduction in code size. For 20 example, use of variables, tables, and parameters allows the creation of templates to cover a family of similar interactions, thus obviating the need to create a separate rule for every possible condition. Variables can be used for flow control conditions, such as if..then..else, while, and until. For example, a rule library may include a script or set of rules for managing call initiation and 25 setup, another script or set of rules for managing service requests made during the call, another script or set of rules for managing call termination, yet another script or set of rules for managing billing, and so on. From the examples listed above* it can be seen that rules can define functional aspects of an entity, and that by changing the rules, the operation of the entity may be subtly or 30 fundamentally changed. A rules-based entity may be contain a set of default rules that can be overridden or extended as needed. By providing a default set of rules, rules-based entities may be deployed and become operable with a -23- minimum of configuration necessary, while at the same time having the flexibility to be configured to meet particular needs. In one embodiment, rules database 406 may be a table. In alternative embodiments, rules database 406 may be a full-fledged database, a data 5 structure, a memory, or other construct for storing data. In one embodiment, service client 106 may be a mobile switching center (IVISC), a service switching point (SSP), or other network entity that may request network services. The application servers may include system control points (SCPs), session initiation protocol (SIP) application servers (SAS), or 10 other network entity that may provide network services. For example, system 40O may include a prepaid SCP (PPSCP 112) and a ringback tones SCP (RTSCP 114) as described above, and also a virtual private network SCP (VPNSCP408). In one embodiment, a portion of ESCIM 402, such as SCIM module 104, 15 may perform protocol conversion between a protocol used by service client 106 and a different protocol, such as an internal protocol used by ESCIM 402 itself or one of its components and/or a protocol used by an application server. For example, ESCIM 102 may use a SIP protocol for all internal operations. In such embodiments, incoming messages, such as from service client 106 or an 20 applications server, may be converted into a SIP protocol message by SCIM module 404. Similarly, SCIM module 104 may convert outgoing messages from an internal protocol into a different, external protocol. For example, SCIM module 104 may convert an outgoing message from SIP protocol into another protocol, such as IN or CAMEL, before the message is sent to an application 25 server. Alternatively, another component within ESCIM 402 may perform the protocol conversion before passing the message. Protocol conversion includes conversion or harmonization of messages among different versions or phases of the same protocol (e.g., CAMEL phase 1, CAMEL phase 2, etc.). In one embodiment, the service interaction and mediation rules stored in 30 rules database 406 may define the sequence of operations that may be performed during particular service interactions. For example, a rule may define how ESCIM 402 should respond particular incoming messages, including sending multiple messages in response to service triggers and / -24- aggregating multiple messages into a single message; a rule may define how ESCIM 402 should treat particular subscribers; a rule may define how ESCIM 102 should communicate with particular network entities, etc. In one embodiment, SCIM module 404 may use a component of an 5 incoming message to identify a service interaction and mediation rule to apply. For example, a client-to-SCII^ message, such as an IDP, may include a service l 1 Proces«JDP Table 1, below, Is a possible internal table representation: 35 Type Sequence Parameter Operator Value Next IDP 1 ServlceKey IsEqualTo 1 Then IDP 2 Script SetTo Process^lDP End Table 1 - Table Representation of a Rule An example script, representing a call flow, is shown below In simplified form. The script shown below is an example implementation of the script "ProcessJDP" referred to in the bottom row of Table 1, above. For simplicity. -26- the script is represented in the form of procedural code rather than in a possible internal table representation. This example script is provided as an explanation of the subject matter and not as a limitation. Other content, forms, formats, and syntaxes are within the scope of the subject matter herein. // Name of the script = "ProcessJDP". // Name of the state machine. Entry point for state "START'. Triggerl : receiving an IDP from a client SSP; IDP contents stored in data structure "IDPr. Send an IDP to application server "ASr, with parameter PI from the original IDP, a new parameter PX, while setting the sen^ice key to a new value, "SK2". Store this IDP in data structure "IDP2". Start a timeout timer for an IDP Transition to new state "STATE1", save contents of IDP1 for later use. End of response to triggerl. End of state "STARr 01 ProcessJDP{ // 02 03 EP-IDP: // 04 05 START{ // 06 @IN(SSP, IDP=IDP1){ // 07 // 08 // 09 0UT(AS1,IDPvlDP2, // 10 1DP1.P1,PX, // 11 SK=SK2); // 12 // 13 // 14 // 15 START_TIME0UT(IDP1); // 16 WAIT(STATE1,IDP1); // 17 // 18 } // 19 } // 20 21 STATE1{ // 22 ©IDPI.TIIVIEOUT { // 23 // 24 7/No action // 25 // 26 // 27 // 28 // 29 •■}.:., // 30 31 @IN(AS1,RRBsRRB1, // 32 CUE=CUE1){ // 33 // 34 // 35 OUT (AS2, IDP, IDP3, // 36 IDP2, SK=SK3V, // 37 // 38 // 39 // 40 WAIT(STATE2, IDP1, // 41 RRB1,CUE1); // 42 // 43 ■■■■'■},• // 44 Entry point for state "STATEI". Triggerl : no response from application server within timeout period set for IDP1. Is action needed? Client that requested sen/ice typically keeps track of this. Alternatively, the script may instruct SCIM to send another IDP to another application sen/er. End of response to triggerl. Trigger2: receiving an RRB and CUE from sen/er AS1, storing RRB and CUE parameters into data structures "RRBI" and "CUE!", respectively. Send an IDP to application sen/er "AS2", with same parameters as IDP2, but with a new sen/ice key value, "SK3". Store this IDP in data structure "iDP3". Transition to new state "STATE2", save contents of IDP1, RRB1, and CUE1 for later use. End of response to trlgger2. -27- 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 R1 @!N(AS1,RELaREL1){ 0UT(SSP,REL1); } DEFAULT{ } ■■}:;:;■' II II II II II II II II II II Trigger3 : Receiving a "REL" (release) from AS1. The REL parameters are stored in data structure "REL1". Fwd the REL message to the SSP. End of response to triggers. Default processing as specified by the user. Useful for processing fall-through conditions for aggregation or multiple-Issue rules. End of state "STATE 1". STATE2{ @ IDP2T1ME0UT { // no action II II II II II Entry point for state "STATE2" Triggerl : no response from application sen/er within timeout period set for IDP2. Is action needed? End of response to triggerl. 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 @ IN (AS2, RRB=RRB2, C0N=C0N1){ OUT (SSP, RRB2, C0N1); EXIT (EP-IDP); } II II II II II II II Trigger2 -.receiving an RRB and CON from sender AS2, storing RRB and CON parameters into data structures "RRB2" and "C0N1", respectively. Fwd the RRB and CON to the SSP. Exit the state machine "EP-IDP". End of response to trigger2. @ IN (AS2, RED { //... } II II II Trigger3: Other possible responses from AS2, such as a "REL" (release), should be handled, also. DEFAULT{ II... ) ) II II II II II Default processing as specified by the user. Useful for processing fall-through conditions for aggregation or multiple-issue rules. End of state "STATE2". ] II End of script "Process_IDP". As can be seen in the example script above, in one embodiment, a script may have a name, such as "Process_IDP", and may define the operation of a state machine, named "EP-IDP". The script may define the states in the state 5 machine, such as "START", "STATE1", "STATE2", etc. At each state, the state machine may wait for the occurrence of triggering events, or triggers. For example, execution of script "Process_IDP", above, activates state machine "EP-IDP" and initializes the state machine to the START state. The state machine will continue to remain in the START state until an IDP is received 10 from an SSP (line 06of the script). In response to receipt of the IDP, the rules-based SCIM will issue its own IDP message to application server AS1 (line 09). This second IDP will include parameter PI from the first IDP, will contain a new ■ -28- parameter, PX, and will ovenwrlte the service key parameter, SK, with a new value to be sent to ASI. The SCIM will then start a timeout timer (line 15) to limit how long the SCIM will wait for a response from ASI before moving on to the next step of the process or even abandoning the process entirely. State 5 machine EP-IDP then moves to the next state, STATE1, making sure to store any state information necessary (line 16). This example script illustrates several capabilities of a rules-based entity. First, a script, or a rule in a script, can execute other scripts or rules. For example, lines 15 and 16 may be calls to subroutines or functions named 10 "START_TIMEOUT()" and "WAITO", respectively. Control flow may retum from function or subroutine call, as in the case of the WAITQ function, or not, as in the case of the EXIT() function. Second, a script or rule can manipulate local and/or global variables, arrays, and data structures. For example, in line 06, a data structure named "IDP1" is created to hold all or part of the incoming IDP 15 message, and in line 10, a part of that structure - message parameter "PI" from the original IDP message - Is read via a reference to "IDP1.P1" and copied into outgoing message IDP2. Third, multiple states may be defined for the state machine (e.g., lines 05,21, and 56), and each state may respond to multiple distinct events or triggers (e.g., lines 22, 31, 45, and 50 for state 20 "STATE1"). In one embodiment, rules database 406 may contain aggregation rules for determining how to combine or consolidate multiple messages into a single message and how to resolve conflicts between multiple, possibly contradictory, responses. For example, rules database 406 may include aggregation rules 25 that may direct SCIM module 404 to aggregate multiple server-to-SCIM messages, such as event notification requests, into a single SCIM-to-client message, and which may direct or assist SCIM module 404 In creating an aggregated message. An aggregation rule may include conflict resolution rules to resolve and aggregate incompatible responses, such as in the examples 30 above, where one application server returns a "service allowed" message while another application server returns a "service denied" message. Table 2, below, lists some example aggregation rules: -29- Message Rule RRB Combine & Fonward CUE Drop if CON response present CON (Nortel Specific) Fonward ACH Fonward REL Foward (Default rules based behavior) Table 2 - Sample Aggregation Rules Table 2 can be more easily understood in the context of some background information. A request report BCSM event (RRB) message is a 5 message, sent by an application server to a client, requesting that the client notify the application server of the occurrence of a particular event or events. For example, an RRB may request notification of a transition from one state to another state in the BCSM, the receipt of a particular type of message by the client, or the satisfaction of a specific set of conditions by the client. It is not 10 uncommon that multiple application servers may be interested In the same event or condition at the client. For example, in general, all application servers actively providing a service during the life of a call want to be notified when the call Is terminated, so that server resources may be released for use by another subscriber or process. However, there is no need to issue the same RRB 15 message multiple times to the client every time another application server joins into (e.g., provides services tor) a call. As can be seen from Table 2, above, the rule for RRB messages is "combine and fonward", indicating that although multiple application servers may issue RRB requests to the client, the SCIM will aggregate the multiple RRB requests into a single RRB request, which the 20 SCIM fonwards to the client. In one embodiment, rules database 406 may contain rules for issuing multiple outgoing (e.g., SCIM-to-server) messages in response to receiving a single incoming (e.g., client-to-SCIM) message, such as a service request trigger; these rules are hereinafter referred to as "multiple-issue" rules. In 25 general, a rule may be implicit or explicit. An implicit rule may operate to send messages to entities implicitly requesting message delivery. An explicit rule may operate to messages to entities explicitly requesting message delivery. For example, explicit rules may apply where a requesting entity expects a response to its query, while implicit rules may apply where a requesting entity 30 seeks notification of an event that may or may not occur. The classification of -30- rules generally and multiple-issue rules in particular as implicit or explicit is for conceptual illustration only, and is not a limitation of the contents or scope of the subject matter described herein. An example of operation of an implicit rule is the scenario in which an 5 application server sends to a switching point an establish temporary connect (ETC) message or other message to which the application server expects a response. An implicit rule could be "Responses to an ETC message should be forwarded to the entity that issued the ETC message." An example of an implicit multi-issue rule Is the scenario in which one or more application servers 10 send apply charging (ACH) messages to client. An implicit multi-issue rule could be "Apply charging report (ACR) messages should be fonwarded to any entity that issued an ACH message." An example of operation of an explicit multi-issue rule is the scenario where one or more application servers each send a request report BCSM event 15 (RRB) message to a client. An explicit multi-issue rule could be "Any event report BCSM (ERB) message received from a client should be fonwarded to all entities that sent RRB messages to that client." The ERB rule is explicit because each RRB message is a request that expects a timely response. In contrast, the ACR mle is implicit because an ACH is not a request that expects 20 a timely response, but merely a request for notification should a particular event occur. There is no guarantee that the event will ever occur. In one embodiment, rules database 406 may include rules for sen/ice mediation. For example, a message sent to one application sen/er may use a different protocol from a message sent to another application server. 25 Commonly used protocols include CAMEL, IN and in variants, such as AIN and WIN, SIP, and other protocols. For example, if PPSCP 112 is a CAMEL-capable device, and RTSCP114 is a non-CAMEL-capable device, such as an IN or AIN device, a component within ESCIM102 is responsible for converting the service request message issued by SCIM module 404 from the internal 30 protocol used by SCIMmodule 404 into a CAMEL protocol If the message is for PPSCP 112 or an AIN protocol If the message is for RTSCP 114. In one embodiment, rules database 406 may include a set of error handling rules, so that only the expected (e.g., error-free) operation need be -31- programmed explicitly. In one embodiment, rules database 406 may contain a set of default rules that define the default operation of the device, and which may be overridden. The use of default rules may allow for even simpler configuration, since only the non-standard expected operation need be 5 programmed explicitly. Default rules for multiple-issue and aggregation would be particularly useful to aid the configuration of the device to support these capabilities. One characteristic of a rules-based function that distinguishes it from a non-rules-based function is that the rules are distinct constructs from the 10 processing engine or other entity that reads and processes the rules. Typically, the rules may change, but the engine used to process the rules does not change. This is in contrast to hard-coded functions, i.e., hardware or hard¬wired logic, which are difficult or impossible to modify once deployed. This is also in contrast to software functions that are compiled to a binary image and 15 executed, in which even a minor change to a function requires a recompile. For example, software functions written as procedural code typically require a new function or subroutine to be written to support a new feature, while software written in an object oriented fashion require either the creation of a new object type or modification of existing objects to support the new feature. In both 20 cases, a non-rule-based engine requires modification to support the new subroutine, object class, etc. Even if the functions are written in an interpreted language, the program - including the new functions, subroutines, or objects -must be reinstalled. In contrast, a rules-based entity can be upgraded to support new functions and features by merely adding a new rule to the rules 25 table or database. It is not necessary to modify the rules interpretation engine. Furthermore, a rules-based entity, such as a SCIM, may be easier to customize. For example, a rules-based SGIM's ruleset may be tuned to support the combination of sen/ers that it connects to, the combination of functions that it must support in the network, and even the brand of servers that 30 it must communicate with. A rules-based entity may be easier to upgrade to new standards as standards change. -32- Figure 5 is a flow chart illustrating an exemplary process for providing rules-based service interaction and mediation in a communications network in accordance with an embodiment of the subject matter described herein. At block 500, at least one Incoming service interaction message is 5 received at a service capability interaction manager (SCIM) module for performing service Interaction and mediation between a service client and a plurality of application servers providing different services. At block 502, a component of one of the incoming messages is used to identify a service interaction and mediation rule contained in a service 10 interaction and mediation rules database operatively associated with the service capability interaction manager module and for storing service interaction and mediation rules for performing service interaction and mediation, such as rules database 406. In one embodiment, rules database 406 may be co-located with SCIM module 404. In alternative embodiments, rules database 15 406 may not be co-located with SCIM module 404 but accessed remotely by SCIM module 404. In one embodiment, SCIM module 404 may use a service key parameter and a subscriber identifier to determine which services are appropriate for a particular subscriber, which SCIM module 404 may then use in combination 20 with the service key parameter to determine what service request messages should be issued to which application servers, and to choose the appropriate rule or script for that case. For example, ESCIM102 may receive from service client 106 a message containing a service key parameter identifying the message as an IDP message, as well as subscriber information Identifying the 25 called and calling parties. SCIM module 404 may determine, based on the calling party's subscriber identifier, that the calling party is a prepaid subscriber. In this case, SCIM module 404 may determine that for an IDP, a query to PPSCP112 is required to determine whether the calling party has a sufficient prepaid account balance, and choose the rule or script that includes this query 30 step. On the other hand, if prepaid subscribers may receive unlimited text messages, for example, SCIM module 404 may determine that for a text message being sent to a prepaid subscriber, no query to PPSCP 112 is necessary, and choose the rule or script that does not include this query step. -33- At block 504, the identified rule Is used to generate and send at least one outgoing service interaction message. In one embodiment, rules database 406 may include service interaction rules that may direct SCIM module 404 to issue multiple SCIM-to-server messages, such as service request messages, in 5 response to a client-to-SCIM message, such as a service request message or service trigger. Similarly, a rule may direct SGIM module 404 to issue multiple event notification messages to application servers in response to receiving an event notification message from the client. Example actions defined by a rule could include sending the same message to multiple application servers, 10 sending unique messages to each of multiple application servers, sending multiple messages to one application server, sending multiple messages to multiple application servers, and so on. The multiple messages may be sent serially, such as in a query/response environment, where SCIM module 404 may wait for the 15 response to a first queiy before sending a second query, or the multiple messages may be sent in parallel, where SCIM module 404 may issue queries to multiple application servers without waiting for a response to the first query before sending the second query. In one embodiment, rules for sen/ice interaction, aggregation, mediation, 20 and so on, may be included in the service interaction and mediation scripts stored in rules database 406. In an alternative embodiment, the different types of rules may be segregated from each other. For example, service interaction and mediation scripts may call aggregation functions or make reference to aggregation rules stored in a separate aggregation rules table; interaction and 25 aggregation rules miay invoke mediation rules prior to sending outgoing messages; etc. Figure 6 is a flow chart illustrating in more detail the operation of an exemplary system for providing rules-based sen/ice interaction and mediation in a communications network in accordance with an embodiment of the subject 30 matter described herein. * At block 600, a message is received at a rules-based ESCIM 402. The trigger message is of a type recognized by ESCIM 402 as being a trigger message. At block 602, SCIM module 404 may access internal and/or external -34- databases in order to collect information about the subscriber associated with the message, such as the calling party, the called party, etc. The information collected may be used to populate variables to be used by the state machines. At block 604, the service key parameter from the incoming message is 5 analyzed to determine which script to select for execution. At block 606, the identified script is selected, retrieved if necessary, and executed. An instance of a state machine may be created, and the initialization code of the state machine may be executed. At block 608, after the initialization code of the state machine has completed, the state machine waits until the arrival of 10 another message. At block 610, a second message associated with the same call as the first message, is received at ESCIM 402. At block 612, if the script includes a rule for the type of message received, that rule will be executed by SCIM module 404; if not, SCIM module 404 may execute default rules, stored in rules 15 database 406, for the type of message received. At block 614, SCIM module 404 may retrieve and execute additional rules, such as aggregation and/or multi-issue rules, as applicable. At block 616, SCIM module 404 determines if the script has completed; if not, control returns to block 608 to wait for the next incoming message. Otherwise, the process ends, the state machine 20 terminates, and the resources associated with the call, including variables, are freed. Figure 7 is signaling message flow diagram illustrating in more detail exemplary messages communicated between a service client network entity and two application servers in accordance with an embodiment of the subject 25 matter described herein, showing examples of multiple message issue and aggregation from both directions. In this figure, service client 106, a service switching point, and two application sen/ers, PPSCP 112 and VPNSCP 408, communicate via service interaction and mediation node ESCIM 402. This process will now be described with reference to Figures 1 and 4. 30 Message 700 is an initial detection point (IDP) message that is sent from service client 106 to ESCIM 402. This message includes a service key parameter, SKI. Upon receipt of Message 700, SCIM module 404 extracts the service key from the incoming message, uses the service key to determine -35- which service interaction and mediation script to execute, and retrieves the appropriate script from rules database 406. In this embodiment, execution of the service interaction and mediation language script may include interaction between two application servers, PPSCP 112 and VPNSCP 408, and the 5 service client entity that issued the IDP, service client 106. This interaction is described in more detail below. Message 702 is an iDP message Issued by ESCIM 402 to PPSCP 112, according to the service interaction and mediation script that controls this service interaction and mediation session. IDP message 702 includes a sen/ice 10 lalance. The RRB(E1,E2) parameter is a subscription 15 request asking that PPSCP 112 be notified should either event El or event E2 occur. For example, event E1 may represent the caller hanging up the phone, and event E2 may represent the called party answering the call. SCIM module 404 may subscribe PPSCP 112 to receive notification of events E1 and E2 in a manner described above. 20 At block 806, ESCIM 402 may maintain an association between a subscriber or call associated with the subscriber, one or more events, and one or more application servers. For example, ESCIM 402 may create an entry in call state database 410 to record that PPSCP 112 has requested notification of events E1 and E2 with respect to the call that triggered IDP message 800 or a 25 subscriber associated with that call. ESCIM 402 may determine whether or not service client 106 has already been configured to Issue such notifications, e.g., whether ESCIM 402 is subscribed to receive such notifications, and if not, attempt to configure service client 106 to send the desired notifications. In the example illustrated in Figures, ESCIM 402 determines that it has not yet made 30 any subscription requests to service client 106, in which case ESCIM 402 sends message 808 to service client 106 requesting notification events El and E2. In one embodiment, ESCIM may request notification of these events only as they pertain to a particular subscriber or call, or ESCIM may request -40- notification of these events regardless of the subscriber, only for certain classes of subscribers, and so on. Message 810 isan IDP message issued by ESCIM 402 to VPNSCP 408, according to the service Interaction and mediation script. IDP message 810 5 includes a service key parameter, SK4, from which VPNSCP 408 can determine that a virtual private network connection is being requested. Message 812 Is a message Issued from VPNSCP 408 to ESCIM 402 in response to service request message 810. In this example, message 812 includes the parameter RRB(E2), which is a subscription request asking that 10 VPNSCP 408 be notified of the occurrence of event E2. At block 814, ESCIM 402 determines whether or not service client 106 is configured to send notification of event E2. For example, ESCIM 402 may perform a lookup using call state database 410 and determine that service client 106 is already configured to send notification of events El and E2 to 15 ESCIM 402, in which case ESCIM 402 determines that it is not necessary to send another RRB(E2) request to service client 106. In this manner, ESCIM 402 aggregates multiple RRBs, i.e., messages 804 and 812, into a single message 808, by suppressing subsequent redundant messages from ESCIM 402 to service client 106. 20 Figure 9A is a block diagram Illustrating an exemplary system for providing service Interaction and mediation in a communications network in accordance with another embodiment of the subject matter described herein. In one embodiment, system 900 includes an ESCIM 102 and service client 106 as described in reference to Figure 1, as well as multiple application servers for 25 providing various functions. In the embodiment Illustrated In Figure 9A, CNAM 902 performs caller name (CNAM) lool