HK1155014A - Enhanced call tracing - Google Patents

Description

Enhanced call tracing

Technical Field

The present invention relates generally to communications, and more particularly to call tracing.

Background

Session Initiation Protocol (SIP) is an open signaling Protocol for establishing various real-time communication sessions. Examples of the types of communication sessions that may be established using SIP include voice, video, and/or instant messaging. These communication sessions may be conducted on any type of communication device, such as a personal computer, laptop computer, personal digital assistant, and the like. One key feature of SIP is its ability to use the Address of Record (AOR) of the end user as a single unified public Address for all communications. Thus, in the world of SIP enhanced communications, a user's AOR becomes its single address that links the user to all communication devices associated with the user. With this AOR, the caller can contact any one of the User's communication devices, also known as User Agents (UAs), without knowing each unique device address or telephone number.

Call tracing in conventional communication systems is relatively easy because the messages transmitted during a communication are mostly related to the communication (e.g., are content-bearing messages). However, when SIP is used, many messages from a particular endpoint or IP address are not useful for the call. For example, SIP utilizes many messages that are not content-bearing messages and are therefore not necessarily required for call tracing purposes. Thus, there is currently no solution for intelligent call tracing in a SIP environment.

Conventional call tracing solutions apply a single filter for identifying calls of interest that are subject to a call tracing mechanism. The filter criteria typically include an initiator identifier and a target identifier. For example, the call tracing filter criteria may indicate that call tracing should occur for any call from IP address "a" to IP address "B" and from IP address "B" to IP address "a". A problem with using these conventional mechanisms in a SIP environment is that these simple filtering criteria may trigger call tracing of relatively unimportant or unwanted SIP messages, thereby unnecessarily tying up call tracing resources and call logging resources.

Disclosure of Invention

It is therefore an aspect of the present invention to provide an intelligent call tracing mechanism that is particularly well suited for use in a SIP environment. Embodiments of the present invention provide a multi-stage filter for communication session tracing. The initial filter criteria can be similar to prior art filter criteria in that it is caller and/or callee centric. For example, the initial filter criteria may indicate that communication session tracing should occur for calls from address "a" to address "B" or from domain "X" to domain "Y". When the first message is found to meet the initial filter criteria, the module analyzes the first message for certain types of call parameters or characteristics, such as call ID and tag information. The call ID and tag information are then used to form second level filter criteria. The second filter criteria are used to filter any subsequently transmitted messages that may or may not meet the initial filter criteria.

One benefit provided by such a system configuration is that the initial criteria may not hold for messages related to the call session it establishes. Once the dialog is established, SIP "changes" some of the message fields. If the initial filter relies on these fields, the initial "trigger" filter will miss these messages. One aspect of the present invention is to capture the dialog created by the initial message matched by the initial filter. To this end, embodiments of the present invention dynamically/algorithmically generate a second level "dialog" or "call" filter to capture intra-dialog messages. The dialog or call filter will expire when the dialog expires, or when a filter-defined inactivity timeout occurs or when a terminal message count threshold is exceeded.

The latter message count threshold may be specific to an individual instance of the second level "dialog" filter, or it may be specific to the trigger filter or dialog filter it generates, or it may be generic to the tracking application. Limit thresholds from any combination of this hierarchy may be implemented.

The initial filter criteria may remain active so that other conversations may be traced simultaneously or sequentially. The initial filter criteria need not support or maintain a context-based second-stage filter, however there may still be a remaining message limit counter that is shared between the second-stage filters that it generates.

In addition, after the second level filter criteria are created, the filter criteria may be applied before the initial filter criteria are applied. This allows dropped messages related to the dialog to be included in the call tracing criteria (second level) so that the dropped dialog can be fully traced. This is useful because malicious calls often contain messages that are corrupted and discarded by the communication server. Both triggers and call filters can be applied to discarded messages, enabling the capture and analysis of complete malicious call message sequences. Thus, another aspect of the present invention is to allow discarded messages to be recorded in connection with the trace filter associated with the secondary filter, without relying on messages that also meet the initial filter criteria.

It should be understood by those skilled in the art that embodiments of the present invention are not limited to calls, but may be used in any type of communication session. Adaptive contextual tracking may be extended to any use involving a communication session. For example, session-based text messaging or security camera streaming may involve the establishment of a session/conversation by an application user agent, which may be tracked using this adaptive technique.

In accordance with at least some embodiments of the present invention, there is provided a method, generally comprising:

receiving a subsequent message;

applying second filter criteria to the second message to determine whether the second message is to undergo the predetermined processing, wherein the second filter criteria are formed as a result of pre-analyzing attributes of the first message and determining that the first message is to undergo the predetermined processing;

determining that the second message satisfies second filter criteria; and

the second message is subjected to predetermined processing.

The term "transaction" as used herein refers to the exchange of information between two endpoints through an optional intermediate agent. This is typically accomplished by exchanging a variety of related messages, some of which are not end-to-end.

The term "conversation" or "session" as used herein is understood to refer to a communication context established by a transaction and optionally updated and/or terminated by a transaction. The dialog may optionally terminate by a timeout due to inactivity (no transaction).

The term "initial transaction" as used herein refers to a transaction that establishes a dialog.

The term "update transaction" as used herein refers to an in-conversation transaction associated with the conversation that neither establishes nor terminates the conversation.

The term "independent transaction" as used herein refers to a transaction that is not associated with a conversation and neither establishes nor terminates the conversation.

The term "terminating transaction" as used herein refers to a transaction that terminates a conversation.

The terms "trigger filter" and/or "initial filter" may be used interchangeably to refer to a first application filter or a first set of filter rules. Such filters contain attributes that are applied to the content of some or all of the messages in the initial transaction or independent transactions. If the match with the trigger filter or initial filter is successful, then the trigger message will be traced, followed by all other messages in the associated transaction. If a dialog is established, all messages associated with updating and terminating transactions will be tracked by the dialog filter.

The terms "conversation filter," "call filter," and/or "second filter" may also be used interchangeably to refer to any type of filter created by the trigger filter logic to filter all messages associated with a conversation. The matching attributes of the dialog filter include any combination of: 1) attributes derived from the matched one or more messages; 2) from the properties copied by the trigger filter, which properties may or may not have been matched by the filter application to the original message or messages in the original transaction, 3) properties computed from an external source, such as time or date, etc., and 4) properties computed from a combination of 1), 2), 3), and 4). Further, the dialog filter may match the remaining messages of the initial transaction if the trigger filter cannot match the remaining messages of the initial transaction.

The term "computer-readable medium" as used herein refers to any tangible storage and/or transmission medium that participates in providing instructions to a processor for execution. Such a medium may take many forms, including but not limited to, non-volatile media, and transmission media. Non-volatile media includes, for example, NVRAM or magnetic or optical disks. Volatile media includes dynamic memory, such as main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, magneto-optical medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, a solid state medium such as a memory card, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read. A digital file or other separate information archive or set of archives attached to an email is considered a distribution medium equivalent to a tangible storage medium. When the computer readable medium is configured as a database, it should be understood that the database may be any type of database, such as relational, hierarchical, object-oriented, and the like. Accordingly, the invention is considered to include a tangible storage medium or distribution medium and prior art-recognized equivalents or successor media, in which the software implementations of the present invention may be stored.

The terms "determine," "calculate," and variations thereof, as used herein, are used interchangeably and include any type of methodology, process, mathematical operation or technique.

The terms "module," "agent," or "tool" as used herein refer to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and software that is capable of performing the function associated with that element. Additionally, while the present invention has been described in terms of exemplary embodiments, it should be understood that various aspects of the invention may be separately claimed.

The foregoing is a brief summary of embodiments of the invention to facilitate an understanding of some aspects of the invention. This summary is not an extensive and exhaustive overview of the invention and its various embodiments. It is intended neither to identify key or critical elements of the invention nor to delineate the scope of the invention but to present selected concepts of the invention in a simplified form as an introduction to the more detailed description presented below. It will be appreciated that other embodiments of the invention are possible, using one or more of the features set out above or described in detail below, alone or in combination.

Drawings

FIG. 1 is a block diagram illustrating a communication system in accordance with at least some embodiments of the present invention;

FIG. 2 is a block diagram illustrating data structures used in accordance with at least some embodiments of the present invention; and is

FIG. 3 is a flow diagram illustrating a method of processing a message in accordance with at least some embodiments of the present invention.

Detailed Description

The present invention will be described in connection with an exemplary communication system. Although the present invention is well suited for use with systems that use, for example, server(s) and/or database(s), the present invention is not limited to use with any particular type of communication system or configuration of system elements. Those skilled in the art will recognize that the disclosed techniques may be used in any communication application where it is desirable to trace a call or invoke a similar application.

The exemplary systems and methods of the present invention will also be described in connection with analysis software, modules, and associated analysis hardware. However, to avoid unnecessarily obscuring the present invention, the following description omits well-known structures, components, and devices that may be shown in block diagram form, are well-known, or otherwise summarized.

For purposes of explanation, numerous details are set forth in order to provide a thorough understanding of the present invention. However, it should be understood that the present invention may be practiced in many ways beyond the specific details set forth herein.

Referring initially to fig. 1, an exemplary communication system 100 will be described in accordance with at least some embodiments of the present invention. More specifically, the communication system 100 includes a communication network 104 adapted to interconnect one or more communication devices 108 with an application server 112.

The trusted communication network 104 may be any type of known communication medium or collection of communication media and may use any type of protocol to transfer messages between endpoints. The communication network 104 may also include wired and/or wireless communication technologies. The internet is an example of a communication network 104 that constitutes an IP network consisting of many computers and other communication devices located around the world, which are connected through many telephone systems and other means. Other examples of communication network 104 include, but are not limited to, standard Plain Old Telephone System (POTS), Integrated Services Digital Network (ISDN), Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Session Initiation Protocol (SIP) network, any type of enterprise network, and any other type of packet-switched or circuit-switched network known in the art.

The communication device 108 may be any type of known communication or processing device, such as a personal computer, laptop, Personal Digital Assistant (PDA), cellular telephone, smart phone, telephone, analog telephone, DCP telephone, or a combination thereof. A single communication device 108 may be controlled by or associated with a single user, or may be adapted for use by many users (e.g., an enterprise communication device that allows any enterprise user to utilize the communication device after a valid username and password are given).

Two or more of the communication devices 108 may be associated with the same user. In other words, the two communication devices 108 may belong to a single user and may correspond to different types of communication devices. As one example, a user may have four communication devices 108, each of which corresponds to a personal phone, work phone, personal computer, and email retrieval device of a single user, respectively. Alternatively, each communication device 108 may be owned and operated by (e.g., associated with) a different user.

In general, the communication device 108 may be adapted to support video, audio, text, and/or data communications with other communication devices 108. The type of medium used by one communication device 108 to communicate with another communication device 108 may depend on the communication applications available on one or both communication devices 108.

The application server 112 is adapted to provide applications and functions to the communication device 108, particularly during communication sessions with other communication devices 108. In accordance with at least some embodiments of the present invention, the one or more applications stored on application server 112 may include a SIP application for providing features and functionality to SIP calls or SIP communication sessions. Such features and functionality may be provided through the processing of one or more messages that are part of a communication session. One example of an application that may be stored on the application server 112 includes a call tracing application 116, which when executed by a processor is adapted to perform call tracing functions on messages received by the application server 112.

In accordance with at least some embodiments of the present invention, the call tracing application 116 provides a particular function or set of functions associated with call tracing, such as message identification, logging, and storage. The call tracking application 116 may include one or more modules 128 for assisting the application 116 in performing such tasks.

In accordance with at least some embodiments of the present invention, the call tracking application 116 may also include two different sets of filter criteria. The first set of filter criteria may correspond to trigger filter criteria 120 for identifying a first message in a communication session that may be subject to call tracing processing. The second set of filter criteria may correspond to dialog or call filter criteria 124. The second filter criteria 124 can be formulated to more accurately and intelligently determine whether messages transmitted in a communication session, particularly a communication session that uses both content-bearing messages and non-content-bearing messages, should undergo call tracing processing.

In accordance with at least some embodiments of the present invention, the dialog or call filter criteria 124 are formed as a result of pre-analyzing attributes of the first message and determining that the first message is to undergo a call tracing process. In other words, the call tracing application 116 may be adapted to receive messages during a communication session, determine that one or more of the messages from the communication session satisfy the trigger filter criteria 120, and subject the messages to call tracing processing by invoking the tracing module 128. Additionally, messages that meet the trigger filter criteria 120 may be analyzed by the tracking module 128 or some other module in the call tracking application 116 to determine the conversation or call filter criteria 124. By way of example, the tracking module 128 analyzes messages that satisfy the trigger filter criteria 120 for certain types of call parameters or characteristics, such as call ID and tag information. The call ID (which may simply be an identifier that includes the call start time and a combination of the caller and/or callee, or may be a hash function generated using one or more of the call start time, caller, callee, or may be a randomly assigned call identifier) and tag information (which may be stored as a tag in one or more message headers) are then used to form the dialog or call filter criteria 124.

It should be noted that in SIP, a tag is associated with the caller and a different tag is associated with the callee. These tags should be considered application identifiers (there may be more than one application at an endpoint and thus more than one tag there). Tags are necessary in SIP but may not be present in other protocols. Establishing a session is simply a component of a set of information gathered from the initial message. This information is used to provide protocol-specific filters to capture the session. In the case of SIP, there will be tags in all sessions, including up to 2051090 tags that a participant may not be interested in tracking. Such tags are ignored.

The dialog or call filter criteria 124 are used to filter any subsequently transmitted messages that may or may not meet the trigger filter criteria 120. Thus, if the initial trigger is disabled, some messages that meet the trigger filter criteria 120 will not be traced if the dialog or call filter criteria 124 are not met. This is only true if the initial "trigger" filter is disabled. This helps to limit call tracing to related messages and reserves communication session tracing resources (e.g., processors, memory, etc.) for use only when desired and relevant. However, if the initial trigger filter criteria continue to be enabled, a new dialog or call filter 124 will be generated. As will be appreciated by those skilled in the art, the results of the call tracing may be stored in the application server 112 itself or in a remote database such as the enterprise database 132. Enterprise database 132 may also include information related to users (not necessarily limited to enterprise users) and their communication histories.

Referring now to FIG. 2, an exemplary data structure 200 will be described in accordance with at least some embodiments of the present invention. The data structure 200 may include several fields for storing information related to performing call tracing processing. Thus, data structure 200 may be stored on application server 112 and/or in enterprise database 132. The data structure 200 may also include information about the result of performing the call tracing process or a pointer to a storage unit storing the recorded content. More specifically, the data structure 200 may include a call attributes field 204, a trigger tracking filter criteria field 208, a dialog or call tracking filter criteria field 212, a related communications field 216, and a filter termination information field 220.

The call attributes field 204 may contain information related to attributes of the call or communication session. The call attributes field 204 may be populated by analyzing messages that satisfy the initial filter criteria 120. As an example, the call attributes field 204 may include identification information of participants of the communication session and a tag identifier that may be compared to tags of subsequently transmitted messages to determine whether call tracing processing is to be applied to the messages.

The trigger tracking filter criteria field 208 may include trigger filter criteria 120, the trigger filter criteria 120 defining, for example, a participant or communication device (typically utilizing a communication device identifier or port address) to which the call tracking process is to be applied. The information in the trigger tracking filter criteria field 208 is typically used to first determine whether a communication session is to have call tracking processing applied.

The dialog or call tracing filter criteria field 212, on the other hand, has information for subsequently determining whether a message in a communication session that satisfies the trigger filter criteria 120 should have call tracing processing applied thereto. Thus, the conversation or call tracing filter criteria field 212 may include the conversation or call filter criteria 124 as well as other relevant information for determining whether a communication session (which may also be referred to as a conversation) requires the trigger filter criteria 120 to be applied.

Other communication fields 216 may include information identifying relationships between various communication sessions. For example, if a call is dropped and then re-initiated between the same participants, the fact that the dropped call is related to a subsequent call may be maintained in the other communication field 216. This is particularly useful when the two calls are related to each other, as is often the case with multi-party conferences.

The filter termination information field 220 may include data used to determine when the second filter criteria 124 are to be discarded and/or are no longer used. More specifically, once a communication session is being tracked by the tracking module 128, it is generally advantageous to continue tracking the entire communication session. In this case, the second filter criteria 124 may be discarded or ignored after the communication session is ended. Alternatively, it may be advantageous to maintain the second filter criteria 124 for a predetermined amount of time after the end of the communication session, particularly if the call should be dropped. In this embodiment, the filter termination information field 220 may define that the second level filter criteria 124 should be applied during a predetermined amount of time (e.g., 5 minutes, 10 minutes, one day, etc.) after the tracked communication session ends. It should also be appreciated that the filter termination information field 220 may define that the second level filter criteria 124 should be applied during a predetermined amount of time after the start of the communication session. Basing the termination information on the start of the communication session may or may not be beneficial depending on the intended application and use of the call tracing process, particularly because the communication session may not end before the second filter criteria 124 is dropped. Of course, if the communication session continues after the second filter criteria 124 has terminated, the second filter criteria 124 may be re-formulated or re-created by analyzing another message of the communication session to refill the call attributes field 204 in accordance with the initial filter criteria 120.

Referring now to fig. 3, an exemplary method of message processing will be described in accordance with at least some embodiments of the present invention. The method is initiated when a message is received at the application server 112 (step 304). The received message is then analyzed based on existing dialog or call filter criteria 124 (step 308) to determine whether the message should undergo call tracing processing (step 312). More specifically, if the message is part of a communication session or conversation being tracked by the tracking module 128, the conversation or call filter criteria 124 may define that certain calls of the conversation should be processed by the tracking module 128. As described above, the conversation or call filter criteria 124 may be generated based on characteristics of previously received messages that are part of the same conversation as the currently received message.

If it is determined that the attributes of the call match the dialog or call filter criteria 124 and the message is to undergo call tracing, the method continues by invoking the call tracing module 128 (step 316). If the message does not satisfy the conversation or call filter criteria 124, the method continues by determining whether the message is part of a conversation that was previously analyzed (step 318). In this step, the application 116 may analyze its message processing history to determine whether the message belongs to any other conversation that has already been analyzed but has not undergone call tracing processing. This determination is made in an attempt to limit the amount of processing resources used, and in particular to avoid a re-determination that the session should not be tracked. If the answer to this query is in the affirmative, then the method continues by allowing the message to be processed by the application server 112 without invoking the tracking module 128 (step 328).

On the other hand, if the received message is the first message of a conversation (e.g., SIP INVITE message or a similar type of invitation to initiate a communication session) or if the message is the first content-bearing message of a conversation, the message is analyzed based on the trigger filter criteria 120 (step 320) to determine whether the message and its conversation are to undergo call tracing processing (step 324). If the answer to this query is negative (i.e., the message does not satisfy the initial filter criteria 120), then the method continues to step 328.

If the received message satisfies the initial filter criteria 120, the method continues by analyzing the message to define dialog or call filter criteria 124 that may be used to filter subsequent messages of the same dialog (step 332). The information retrieved from the message and used to form the dialog or call filter criteria 124 may include at least one of a call ID and tag information contained in the body and/or header of the message. Once the appropriate dialog or call filter criteria 124 have been formed, the method continues by storing the second level filter criteria 124 in the data structure 200 (step 336). At the same time, or shortly thereafter, the trace module 128 is invoked to perform a call trace function on the received message (step 316).

It should be noted that this process may be repeated an infinite number of times. Thus, embodiments of the invention are not limited to first and second sets or first or second layers of filter criteria. Embodiments of the present invention contemplate three and more stages of filters. Embodiments of the present invention contemplate creating at least a second set of filter criteria (for conversation matching) and a third set of filter criteria (for call matching) based on matching a single message to the trigger filter criteria. As mentioned above, an additional number of filter criteria are also within the scope of the present invention. As one example, in certain types of calls (e.g., conferences) that can be made up of several (even hundreds) of conversations, embodiments of the present invention can be used to create new filter matching patterns or rules as each participant is added to the conversation.

Messages for which the dialog filter is directed often have signatures that do not match the criteria that triggered the filter. This is particularly true in protocols such as SIP, where contact information is exchanged and replaces contact information that was used to establish a dialog. In accordance with at least some embodiments of the present invention, the trigger filter may or may not remain "ready" or active once a match with the trigger filter occurs. If it remains "ready," a new, independent conversation filter may be created to track messages associated with the new conversation.

New dialogs that are selected for tracking due to the fact that a trigger filter is matched may have a lifetime that overlaps with other dialogs that are matched by the same trigger filter.

In the event that the trigger filter attribute selected by the operator is not applicable to the changeable field of the conversation message, it is likely that the conversation message will match both the trigger filter and the conversation filter. In this case, the dialog filter plays a dominant role, and no duplicate dialog filter is created.

If the trigger filter is ready after the dialog has been established and the dialog message matches the trigger filter, then the dialog filter can be constructed and the remainder of the dialog will be traced.

In accordance with at least some embodiments of the present invention, there are situations where a communication server may impose itself on a call to act as a silent participant. This is sometimes referred to as a back-to-back agent. Typically, a conference call actually consists of several two-party calls, with the conference server acting as a common participant for each call. Whenever a "call" is so divided into multiple dialogs at the signaling level, it is desirable to track and associate each of these associated calls (troubleshooting, lawful interception, etc.). Embodiments of the present invention provide methods for supporting combinational calls by several methods: 1) the trigger filter may be designed to recognize the establishment of any individual low-level dialog and generate an individual dialog filter for each dialog, or 2) the trigger filter can be designed to recognize the establishment of any individual low-level dialog, and upon the first occurrence of such a match, a dialog filter is generated that is wide enough to match this and any subsequent multiple dialogs (possibly including multi-party calls), or 3) the first generated dialog filter may recognize that the call is expanded to include additional participants, and can modify its matching criteria on its own as each related dialog is created to extend to each related dialog, or 4) the first generated dialog filter may recognize that the call is expanded to include additional participants, and additional dialog filters may be generated as each related dialog is created to match each related dialog. The latter two methods are particularly useful when the initial trigger filter cannot monitor call expansion because it does not filter for in-conversation messages.

While the above-described flow diagrams have been discussed in connection with a particular sequence of events, it should be appreciated that such sequence can be altered without materially affecting the operation of the invention. Further, the order of events need not be exactly the same as set forth in the exemplary embodiments. The exemplary techniques described herein are not limited to the specifically illustrated embodiments, but may also be used in conjunction with other exemplary embodiments, and each described feature may each be separately claimed.

The systems, methods and protocols of this invention can be implemented on a special purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit element(s), ASIC or other integrated circuit, digital signal processor, hardwired electronic or logic circuits (e.g., discrete element circuits), programmable logic devices (e.g., PLD, PLA, FPGA, PAL), communication devices (e.g., servers), personal computers, any comparable means, or the like, in addition to or in place of the described communication devices. In general, any device capable of implementing a state machine that is in turn capable of implementing the methods described herein may be used to implement the various communication methods, protocols, and techniques in accordance with this invention.

In addition, the disclosed methods may be readily implemented in software using an object or object-oriented software development environment that provides portable source code that may be used on a variety of computer or workstation platforms. Alternatively, the disclosed system may be implemented in hardware, in part or in whole, using standard logic circuits or VLSI design. Whether software or hardware is used to implement a system in accordance with the present invention depends upon the speed and/or efficiency requirements of the system, the particular function, and the particular software or hardware system or microprocessor or microcomputer system being utilized. The analysis systems, methods, and protocols described herein can be readily implemented in hardware and/or software by those of ordinary skill in the art using any known or later developed systems or structures, devices, and/or software based on the functional descriptions provided herein using the general basic knowledge in the communication and computer arts.

In addition, the disclosed methods can be readily implemented in software that can be stored on a storage medium and executed on programmed general purpose computer, special purpose computer, microprocessor, or the like, in cooperation with a controller and memory. In these cases, the system and method of the present invention may be implemented as a program embedded on a personal computer (e.g., an applet,Or CGI scripts), as resources residing on a server or computer workstation, as routines embedded in a dedicated communication system or system component, and so forth. The system may also be implemented by physically incorporating the system and/or method into a software and/or hardware system, such as a hardware and software system of a communication device or system.

Thus, it is apparent that there has been provided, in accordance with embodiments of the present invention, systems, apparatuses, and methods for generating message filtering criteria based on analyzing messages that satisfy another set of filtering criteria. While the invention has been described in conjunction with several embodiments, it is evident that many alternatives, modifications and variations will be or are apparent to those of ordinary skill in the art. Accordingly, it is intended to embrace all such alternatives, modifications, equivalents and variations that fall within the spirit and scope of the present invention.

Claims (10)

1. A method, comprising:

receiving a second message;

applying second filter criteria to the second message to determine whether the second message is to be subjected to the predetermined processing, wherein the second filter criteria is formed as a result of pre-analyzing attributes of a first message received prior to the second message and determining that the first message is to be subjected to the predetermined processing;

determining that the second message satisfies the second level filter criteria; and is

Subjecting the second message to the predetermined processing.

2. The method of claim 1, wherein third messages that do not meet the second filter criteria are not subject to the predetermined processing.

3. The method of claim 2, wherein the third message and the second message are part of at least one of a common conversation and a common call.

4. The method of claim 3, wherein the second message is a content-bearing message and the third message is a non-content-bearing message.

5. The method of claim 3, wherein the second message and third message are communicated between common endpoints.

6. The method of claim 1, further comprising:

analyzing the first message using initial filter criteria, wherein the initial filter criteria indicates that the first message is to undergo predetermined processing if the first message is at least one of to and/or from a predetermined address, domain, or user;

determining that the first message is at least one of to and from the predetermined address; and is

Based on determining that the first message is at least one of to and from the predetermined address, initiating analysis of the first message to form one or more of the second and third level filter criteria.

7. The method of claim 1, wherein the predetermined process comprises a call tracing process.

8. The method of claim 7, wherein the payload of the second message comprises one or more of a voice message, a video message, and a text message.

9. An application server, comprising:

a memory adapted to store instructions, the instructions comprising:

an application adapted to subject a message to a predetermined process when executed, the application comprising initial filter criteria and second level filter criteria, wherein the application applies the second level filter criteria to a second message received by the application to determine whether the second message is to be subjected to the predetermined process, wherein the second level filter criteria is formed as a result of pre-analyzing attributes of a first message received at the application prior to the second message and determining that the first message is to be subjected to the predetermined process; and

a processor to execute the application.

10. The server of claim 9, wherein third messages received at the application that do not satisfy the second level filter criteria are not subject to the predetermined processing.