Patent Application
20090003582
Voice and data communications are increasingly being managed using digital, packet-switched, systems, rather than analog, circuit-switched systems. Examples of such digital systems may include server-based systems that enable a variety of different callers to communicate with one another, perhaps using dissimilar devices, signaling protocols, and/or transmission techniques. Put differently, the servers may host and manage any number of different calls at any given time.
As these servers manage more calls, and different types of calls, some operations may involve locating a given call out of many active calls that the server is currently handling. While it is possible to perform a linear search on a list of these active calls, this type of a brute-force approach may prove expensive in the context of servers handling, for example, hundreds or thousands of calls or callers.
Tools and techniques for optimized replacement of calls using a grid parameter are described herein. The tools may provide machine-readable storage media containing machine-readable instructions for receiving indications of incoming calls, and for populating fields in a contact header structure that are associated with the incoming call. The fields may include a field for containing a globally unique identifier (GUID) associated with the incoming call. The tools may also receive requests to replace a call within a plurality of active calls that are handled by a server. In response to such requests, the tools may search for the call using the GUID.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term “tools,” for instance, may refer to system(s), method(s), computer-readable instructions, and/or technique(s) as permitted by the context above and throughout the document.
Tools related to optimized replacement of calls using a grid parameter are described in connection with the following drawing figures. The same numbers are used throughout the disclosure and figures to reference like components and features. The first digit in a reference number indicates the drawing figure in which that reference number is introduced.
The following document describes tools capable of performing and/or supporting many techniques and processes. The following discussion describes exemplary ways in which the tools provide for optimized replacement of calls using a grid parameter. Without limiting possible implementations, and only to facilitate understanding of the description herein, the term “grid” as used herein refers to a value field within a globally routable user agent uniform resource identifier (URI) (GRUU). The GRUU parameter is part of a contact header used to pass information between endpoints as part of, for example, establishing and maintaining communication sessions under the Session Initiation Protocol (SIP). Similarly, the term “replace” is used herein to refer to replacing one participant with another in a multimedia conversion in an atomic operation. This discussion also describes other techniques and/or processes that the tools may perform.
The server 102 may enable callers to place calls to one another, thereby connecting the callers with one another so as to enable them to exchange audio, video, data communications (whether alone or in combination) therebetween.
Turning to the callers 104c, 104d, and 104n, these callers may communicate using telephones 114 and 116, as well as desktop computing system 118. The server 102 may enable the telephones 114 and 116 and the desktop computing system 118 to communicate with one another over voice over IP (VoIP) technologies.
Turning to the server 102 in more detail, the server may be a computer-based system that includes one or more processors, denoted at 122. These processors may also be categorized or characterized as having a given type or architecture, but in implementations that include more than one processor, these processors may or may not have the same type or architecture.
The device may also include one or more instances of machine-readable or computer-readable storage media, denoted generally at 124. The processor may communicate with the computer-readable media, and other components or sub-systems of the devices, via one or more busses 126. These busses 126 may be of any suitable width, and may comply with any convenient bus architecture.
The computer-readable media 124 may contain instructions that, when executed by the processor 122, perform any of the tools or related functions that are described herein as being performed by the server. The processor may access and/or execute the instructions embedded or encoded onto the computer-readable media, and/or may access data stored in the computer-readable media. Additionally, it is noted that the computer-readable storage media, and any software stored thereon, may reside on hardware other than that shown in
Turning in more detail to the computer-readable media 124, it may include one or more modules of software instructions for optimizing replacement of calls using a grid parameter, denoted generally as a grid creation and maintenance module 128. As a non-limiting example of optimized replacement of calls using a grid parameter, one or more of the callers 104a or 104b may wish to join an ongoing conference (e.g., 108). Assuming that the server 102 operates under the Session Initiation Protocol (SIP), the server may issue a SIP Invite with Replace command to replace the call as connected to the two-party call 106 with a call connected to the conference call 108. For example, if the caller 104a wishes to join an ongoing conference call 108, then the call 120a would be replaced with a corresponding call linking the caller 104a to the conference call.
The grid creation and maintenance module 128 may manage a dictionary 202, which in turn may include a contact header structure 204 corresponding to a call 120. In the interests of clarity,
Turning to the contact header 204 in more detail, it may include a call identifier (ID) field or tag 208. Typically, the call ID is a relatively lengthy alphanumeric string, generated based on an address or URL, combined with randomly-generated strings of digits and/or characters. The contact header may also include a “from” field or tag 210, which indicates which caller initiated or originated a given call. A “to” field 212 may indicate which caller received a given call. A grid field 214 may contain a globally unique identifier (GUID), as represented generally at 216, that is associated with a given call 120. In some implementations, a server (e.g., 102) may generate the GUID, while in other implementations, the call request or invitation incoming to the server may include the GUID, with other devices (e.g., 110-118) generating the GUID and including it in the invitation.
As detailed further in
Block 302 represents receiving an indication of a given incoming call request.
Block 304 represents instantiating a contact header structure for the incoming call, if such a structure has not already been instantiated.
Block 306 represents populating or filling the various fields or tags defined by the contact header structure. For example, block 306 may include populating a call ID field (e.g., 208 in
Block 314 represents receiving a GUID for the contact header associated with the incoming call.
Block 316 represents populating the contact header with the GUID.
Assuming that the process flows 300 are implemented in a SIP environment, the foregoing process blocks 302-318 may be implemented using appropriate SIP commands.
Having described the process flows 300 for building the contact header and dictionary structures as incoming calls arrive, the discussion now turns to a description of process flows that the tools may perform upon a request to replace a given one of the calls, now presented with
Block 402 represents receiving a request to replace a given call (e.g., 120 in
Block 404 represents locating the call to be replaced from among all active calls currently being handled. As shown in
Block 410 represents evaluating whether a call was found for the GUID. If yes, the process flows 400 may take Yes branch 412 to block 414, which represents replacing the call located in block 404. Assuming a SIP implementation, block 414 may include, for example, executing a SIP-compliant invite-with-replace command.
Returning to block 410, if block 404 did not locate a call corresponding to the GUID, then most likely, an error has occurred. In this case, the process flows 400 may take No branch 416 to block 418 to report an error or other suitable condition.
Having described the above process flows 400, several observations are noted. In contrast to previous techniques that involved searching records for potentially all active calls when locating the call to be replaced, the tools described herein locate and retrieve the record with one query, which specifies the GUID as an index or search key. These previous techniques may include searching each active call, and comparing the call ID (e.g., 208), From tag (e.g., 210), and To tag (e.g., 212) to a set of input call parameters to locate the call to be replaced. Thus, the search effort drops from a linear search having complexity level O(3n) to a single search having complexity level O(1).
Although the systems and methods have been described in language specific to structural features and/or methodological acts, it is to be understood that the system and method defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed system and method.
In addition, regarding certain data and process flow diagrams described and illustrated herein, it is noted that the processes and sub-processes depicted therein may be performed in orders other than those illustrated without departing from the spirit and scope of the description herein. Also, while these data and process flows are described in connection with certain components herein, it is noted that these data and process flows could be performed with other components without departing from the spirit and scope of the description herein.
