Systems and methods for initiating announcements in a SIP telecommunications network

Network servers in a session initiation protocol (SIP) telecommunication network implement playback of announcements to end-users by embedding programming scripts defining how the announcements are to be played in a SIP message. In particular, the scripts may define the sequence in which a series of announcements are to be played, duration information relating to a playback length of the announcements, and repetition information defining how many times an announcement is to be repeated. By including a script in a single message, announcement instructions may be efficiently communicated in the network.

BACKGROUND OF THE INVENTION

A. Field of the Invention

The present invention relates generally to voice over packet based networks, and more particularly, to SIP communication networks.

B. Description of Related Art

The transmission of voice and video over packet based networks, as compared to traditional dedicated-line telephone service, provides the possibility of significantly cheaper and more flexible voice and video connectivity.

SIP (session initiation protocol) is a signaling protocol for initiating, managing and terminating voice and video sessions across packet networks. SIP sessions involve one or more participants and can use unicast or multicast communication. Borrowing from ubiquitous Internet protocols, such as HTTP and SMTP, SIP is text-encoded and highly extensible. SIP may be extended to accommodate features and services such as call control services, mobility, and interoperability with existing telephony systems.

At certain times, telecommunication providers may wish to connect a calling party to a prerecorded announcement. For example, if the calling party dialed an invalid number, the telecommunication provider may wish to connect the party to an announcement that informs the party that the number is not recognized. Under the conventional SIP protocol, there is no provision for the effective playback of a such announcements.

Some solutions do exist for providing prerecorded announcements via the SIP protocol. These solutions tend to use one or more SIP messages for each pre-recorded announcement, or portion of the pre-recorded announcement. These solutions can be become quite message intensive, and are thus inefficient in handling announcements through SIP.

Accordingly, there is a need in the art to improve announcement playback in a SIP telecommunications network.

SUMMARY OF THE INVENTION

Systems and methods consistent with the principles of this invention provide for an efficient and flexible messaging scheme in a SIP network for playback of pre-recorded announcements.

One aspect of the invention is directed to a method that includes receiving a first message from a user that initiates a call in a packet-based network and transmitting a second message to an announcement server in the network. The second message includes a script file that defines a sequence for announcements that are to be transmitted to the user.

A second aspect of the invention is directed to a network server in a packet-based network. The network server includes a processor and a memory containing program instructions. The program instructions are configured to receive a first SIP message relating to a call in the network and to transmit a second SIP message to an announcement server in the network. The second message includes an indication of at least one pre-recorded announcement to playback and control information relating to the playback of the at least one prerecorded announcement.

A third aspect of the invention is directed to a method in a SIP network that includes receiving a SIP message that includes a script file that defines a playback sequence for announcements that are to be played to a user. The method further includes analyzing the script file to determine at least one of sequence information and duration information for the announcements defined by the script file and accessing resources corresponding to storage locations for the announcements. Still further, the method includes transmitting the announcements to the user in a real-time communication session based on the sequence information and the duration information.

A fourth aspect of the invention is directed to a system that includes a network server and an announcement server. The network server is configured to transmit a message to the announcement server. The message includes a script file that defines a playback sequence for announcements that are to be played to a user. The announcement server, based on the script file, accesses resources corresponding to storage locations for the announcements and transmits the announcements to an end-user in an announcement order defined by the script file.

DETAILED DESCRIPTION

The following detailed description of the invention refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and equivalents of the claim features.

As described below, a call controller provides sophisticated announcement playback in a SIP telecommunications network. In particular, a SIP call controller transmits announcement playback instructions to an announcement server by embedding a script file in a SIP message. The script file provides instructions that can define complex announcement playback sequences within a single SIP message.

System Overview

FIG. 1is a diagram illustrating an exemplary system100in which concepts consistent with the present invention may be implemented. System100may form a telecommunications network designed to carry voice and video data based on the SIP protocol.

System100includes a number of end-user stations110. Communication sessions are performed between two or more end-user stations110. End-user stations110, generally at the requests of users of these stations, initiate and terminate sessions by exchanging requests and responses. Under the SIP protocol, end-user stations110are referred to as user agents, which may include both a user agent client (UAC)111and a user agent server (UAS)112. UAC111may be a client application that initiates SIP requests. UAS112may be a server application that contacts the user when a SIP request is received and that returns a response on behalf of the user. Each of end-user stations110may be one of a number of different physical devices, including workstations, IP-phones, telephony gateways, call agents, and automated answering services.

SIP server130facilitates communications between end-user stations110. SIP server130may act as a number of logical entities that perform separate SIP functions. Specifically, under the SIP protocol, SIP server130may act as a Proxy Server, a Redirect Server, or a Registrar. Although shown inFIG. 1as a single SIP server130, in some implementations, SIP server130may be implemented as a number of different computing devices, with potentially different computing device(s) handling each of the functions of Proxy Server, Redirect Server, and Registrar.

A Proxy Server is an intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced either internally or by passing them on, possibly after translation, to other servers. A Proxy Server may interpret, and if necessary, rewrite a request message before forwarding it.

A Redirect Server is a server that accepts a SIP request, maps the SIP address of the called party into zero or more new addresses and returns them to the client. Unlike Proxy Servers, Redirect Servers do not pass the request on to other servers.

A Registrar is a server that accepts SIP “register” requests for the purpose of updating a location database with the contact information of the user specified in the request.

Network120may include any type of packet network, such as a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), an intranet, the Internet, or a combination of networks. End-user stations110and SIP server130may connect to network120via wired, wireless, and/or optical connections.

FIG. 2is a diagram of an exemplary computing device that may correspond to one of end-user stations110or SIP server130. Computing device110/130may include bus210, processor220, main memory230, read only memory (ROM)240, storage device250, input device260, output device270, and communication interface280. Bus210permits communication among the components of computing device110/130.

Processor220may include any type of conventional processor or microprocessor that interprets and executes instructions. Main memory230may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor220. ROM240may include a conventional ROM device or another type of static storage device that stores static information and instructions for use by processor220. Storage device250may include a magnetic and/or optical recording medium and its corresponding drive.

Input device260may include one or more conventional mechanisms that permit an operator to input information to computing device110/130, such as a keyboard, a mouse, a pen, a number pad, a microphone and/or biometric mechanisms, etc. Output device270may include one or more conventional mechanisms that output information to the operator, including a display, a printer, speakers, etc. Communication interface280may include any transceiver-like mechanism that enables computing device110/130to communicate with other devices and/or systems. For example, communication interface280may include mechanisms for communicating with another device or system via a network, such as network120.

SIP Signaling

FIG. 3is a diagram illustrating an exemplary call set-up between two end-user stations301and302with the assistance of a network server, such as a SIP proxy server310. It should be understood that end-user stations301and302may correspond to any of the end-user stations110shown inFIG. 1. Similarly, proxy server310may be implemented on SIP server130inFIG. 1. Location service database315may be a database or a server connected to a database that returns a user's current address or contact information in response to a request relating to the user.FIG. 4is a corresponding flow chart illustrating the call set-up. In this example, a user at end-user station301invites “Bob” at end-user station302to join a telephone call.

The user at station301begins by sending an “INVITE” message, through proxy server310, to the address at which Bob resides. Proxy server310responds with the SIP response code “100,” which indicates that the proxy server310is trying to locate Bob (Act402). Proxy server310may look up Bob's current location in location service database315via a routing request (Act403). The routing request between proxy server310and location service database315may be implemented using a non-SIP protocol. Location service database315returns Bob's current address to proxy server310(Act404). Locations service database may be a conventional database located either locally or remotely to proxy server310.

The proxy server310sends a new INVITE message to end-user station302, whose address was identified by the location service database315(Act405). The user agent server of end-user station302responds with response code100(trying), (Act406), and then with a response code180, (Act407), which indicates Bob's phone is ringing. Proxy server310may forward ringing response code180back to end-user station301(Act408). When the call is accepted by Bob, end-user station302sends a response code200(OK) (Act409). Proxy server310forwards the OK response code to end-user station301(Act410). The OK response code may include Bob's correct IP address. End-user station301may then send an acknowledge (ACK) message to end-user station302(Act411). Additional data sent during the communication session may then be directly transferred between user-stations301and302.

Pre-Recorded Announcements in SIP

In certain situations, it may be desirable for a SIP server, such as proxy server310, to initiate playback of a pre-recorded announcement to an end-user, such as the user at end-user station301. In other implementations, the “pre-recorded” announcement may be automatically generated by, for example, computer-implemented text-to-speech processing. As an example of a possible announcement, assume that the address of the party that end-user station301attempts to call is not valid, in which case SIP server310may direct that a prerecorded message informing end-user station301that the called address is incorrect may be played.FIG. 5is a diagram illustrating the playing of a prerecorded message to an end-user station501in a SIP network.

InFIG. 5, end-user station501may correspond to any of the end-user stations110shown inFIG. 1. Network server510may correspond to a SIP server, such as a proxy server. Announcement server520may be a SIP server dedicated to forming SIP connections that transmit pre-recorded announcements. Announcement storage server525may correspond to a database or server that stores and forwards the pre-recorded messages to announcement server520.

End-user station501(user “A”) begins by sending an INVITE message530to the intended callee (illustrated as “b@wcom.com”). Network server510is in the signaling path of the INVITE message, and intercepts the INVITE message. Network server510responds with the SIP response code “100,” which indicates that the network server510is trying to locate the callee (message531). Network server510may submit routing requests to location server database515in an attempt to locate the current address of the callee. In this example, assume that network server510is unable to locate the current address of the callee and therefore decides to play a pre-recorded announcement to user A, such as an announcement informing user A that the address b@wcom.com is not recognized.

Network server510sends an INVITE message532to announcement server520. INVITE message532may include an indication of the pre-recorded announcement that is to be played to user A. As shown, this indication is embodied as a “play” tag540that includes a reference541(“http://wcom/wrong_number.wav”) to the resource that contains the announcement. Reference541may be structured as a hypertext transfer protocol (HTTP) link. Announcement server520retrieves the referenced announcement. The announcement may be retrieved, for example, from a network storage device such as announcement storage server525(signal533). In other implementations, the announcement may be stored locally to announcement server520.

After successfully retrieving the announcement, announcement server520may send a response code200(OK) back to network server510(message534). Proxy server510may then send a response code, such as response code183, which is an informational response code that indicates the a session is in progress, back to user A (message535). Additionally, network server510may send an ACK message to announcement server520(message536). Network server510and end-user station501may further exchange a final response and an ACK message that ends the session between network server510and end-user station501(not shown). At this point, announcement server520and end-user station501form a direct connection and begin real-time transmission and reception of the pre-recorded announcement (link537)

Consistent with an aspect of the invention, reference541may correspond to a script that includes multiple instructions for announcement server520. In general, a script is a sequence of instructions that are interpreted or carried out by another program rather than by a computer processor (as a compiler program is). The instructions in the script may, for example, identify that a sequence of multiple announcements is to be played in a specified order for specified time periods.

An example of a generic set of commands that may be implemented by a script that may be substituted for reference541is as follows:1. Play a filler announcement/music (first announcement) for X seconds.2. When X seconds has elapsed, play a second announcement (e.g., a “still trying” announcement).3. When the second announcement is complete, continue with the filler announcement from the point it was interrupted by the second announcement.4. Go to step (2).
In this example, the value X and an identification of the first announcement and the second announcement would be specifically identified in the actual programming script.

FIG. 6is a diagram illustrating an exemplary script600that performs steps (1)-(4), above. The first line, line601, of script600, instructs the announcement server520to play a file (“filler.wav”) for 10 seconds. After 10 seconds, the announcement server520plays the audio file “still_trying.wav” (line602). Line603instructs the announcement server520to indefinitely repeat lines601and602.

The script sequence shown inFIG. 6may be executed by announcement server520until network server510interrupts the announcement by transmitting a SIP BYE, CANCEL, or Re-INVITE message to announcement server520.

One of ordinary skill in the art will recognize that the script syntax shown inFIG. 6is exemplary only. In practice, any set of programming semantics and syntax that allows multiple announcements to be specified, sequenced, and played may be used. In some implementations, the script may additionally include semantic provisions that allow control information, such as duration information (see line601) and repetition information (see line603) to be included in a script file.

Exemplary Successful Call Including Announcement Messages

FIGS. 7A and 7Bare call flow diagrams illustrating an exemplary successful call setup that includes announcement messages played to the user in a manner consistent with aspects of the present invention. In the call shown inFIGS. 7A and 7B, an end-user station701(user “A”) attempts to place a call with an end-user “B”. It should be understood that end-user stations701and702may correspond to end-user stations110inFIG. 1. User B has customized her personal profile so that the telecommunications system first tries to contact user B at station702(labeled as station “F1”), and then, if user B is not available at station702, at station703(labeled as station “F2”). The telecommunications network additionally includes a network server710, location server715, announcement server720, and an announcement storage server725, implemented in a manner similar to network server510, location service database515, announcement server520, and announcement storage server525, respectively. Network server710may be one server, such as a SIP proxy server, or a combination of local or distributed SIP servers.

The actions relating to a call-setup inFIGS. 7A and 7Bare illustrated in a manner similar to the actions shown inFIGS. 3 and 5. However, because of the greater number of messages shown inFIGS. 7A and 7B, devices701,702,703,710,715, and720are shown as smaller blocks at the top ofFIGS. 7A and 7B, with vertical lines extending downward that represent these devices.

The call begins in a manner similar to the call shown inFIG. 5. In particular, end-user station701begins by sending an INVITE message (message730) to the intended callee (illustrated as “b@wcom.com”) through network server710. Network server710responds with the SIP response code “100,” which indicates that the network server710is trying to locate the callee. Network server710may submit routing requests to location server715in an attempt to locate the current address of the callee. Network server710sends an INVITE message (message732) to announcement server720. INVITE message733includes an indication of the announcement(s) to play as “play” tag760and script761. Script761may include multiple instructions for announcement server720, as previously described with reference toFIG. 6. In this example, however, script761merely includes a reference to play the single audio file “greeting.wav”.

Announcement server720retrieves the announcement(s) referenced in script761(message733). The announcement(s) may be retrieved, for example, from announcement storage server725. In other implementations, the announcement may be stored locally to announcement server720. After successfully retrieving the announcement, announcement server720may send a response code200(OK) back to network server710(message734). Network server710may then send response code183back to end-user station701(message735). Additionally, network server710may send an ACK message to announcement server720(message736). At this point, announcement server720and end-user station701form a direct connection and begin real-time transmission and reception of the pre-recorded announcement referenced in script761(connection737). The real-time communication session is shown inFIG. 7Aas the dashed line “RTP.” The announcements may be an initial greeting that is played to user A.

Announcement server720signals the end of playback of the prerecorded greeting to network server710with the SIP BYE message (message738). In other implementations, other SIP messages, such as Re-INVITE may be used to end playback of an announcement. Network server710may respond to BYE message738via response code200(message739). At this point, the announcement being transmitted between end-user station701and announcement server720is terminated (link740).

Network server710may next begin to contact user B at station702. While contacting station702, network server may direct that a “trying to contact callee” announcement be played to user A. Network server710initiates the “trying to contact callee” announcement through INVITE message741, which is sent to announcement server720. INVITE message741includes script763that describes the announcement to play and the manner in which the announcement is to be played. In this example, assume that script763is identical to script600(FIG. 6). Thus, as previously discussed, script600indicates that the announcement “filler.wav” and the announcement “still_trying.wav” are to be played in sequence and repeated indefinitely until interrupted.

As well as sending INVITE message741, network server710may transmit an INVITE message, such as INVITE message742, to station702. Station702may be the primary station listed for user B in the request returned from location server715. Concurrently, announcement server720may retrieve the first announcement that is specified in INVITE message741(“filler.wav”) from announcement storage server725, and begin transmission of this announcement with user A (messages743-745). The real-time transmission of the “filler” announcement between end-user station701and announcement server720is shown as connection746(FIG. 7B).

Assume that end-user station702eventually returns a response code in the400's (message747), which indicates that the recipient can not be reached. Network server710acknowledges message747and transmits INVITE message748to station703, which may be the secondary station listed for user B in the request returned from location server715. At this point, the original “filler” announcement may finish (i.e., 10 seconds have elapsed). In response, as directed by script763, announcement server720retrieves the “still trying” filler from announcement storage server725, and begins sending this new announcement in place of the “filler” announcement (connection749).

Station703may transmit a status message, such as response code180(ringing) (message750). At this point, the “still trying” announcement may finish. Because script763indicated that the “filler” and “still trying” announcements were to be repeated indefinitely, announcement server720returns to transmitting the “filler” announcement (connection751).

At some point, station703may transmit a response code200, indicating that station703will accept the call (message752). Network server710may then end announcement playback via BYE message753and forward the response code200to user A (message754). User A and B are then connected for a SIP conversation via messages755-757. In message755, announcement server720responds to the BYE message753. In message756, end-user station701receives an acknowledgement of the successful connection and in message757, network server710acknowledges that network server710received message756and user A is ready to engage in the call. At this point, the real-time SIP call can be set-up directly between end-user stations701and703(connection758).

Exemplary Failed Call Including Announcement Messages

FIGS. 8A and 8Bare call flow diagrams illustrating an exemplary failed call setup that includes announcement messages played to the user in a manner consistent with aspects of the present invention. Certain portions of the description relating toFIGS. 8A and 8Bare similar to that ofFIGS. 7A and 7B. In the call setup shown inFIGS. 8A and 8B, end-user station701(user “A”) attempts to place a call with an end-user “B” in a manner similar to the call setup shown inFIGS. 7A and 7B.

More specifically, as shown inFIG. 8, messages830-851are transmitted between end-user station701, end-user station702, end-user station703, network server710, announcement server720, and announcement storage server725in an attempt to perform the call set-up illustrated inFIG. 7. Messages830-851are identical to the corresponding messages730-751. In the example ofFIG. 8B, however, end-user station703returns a response code486(message852), which indicates that end-user station703could not be reached. Network server710acknowledges message852(message853).

At this point, network server710does not have any further addresses at which user B may reside, and thus decides to return a “busy” announcement to user A. Network server710transmits INVITE message854to announcement server720. INVITE message854includes a reference865to an audio file that contains a busy signal announcement. After successfully retrieving this announcement, from, for example, announcement storage server725, announcement server720may send a response code200(OK) back to network server710(message855). Network server710may then send response code183back to end-user station701(message856). End-user station701and announcement server720may then exchange the busy signal announcement with one another (connection857).

Network server710acknowledges message855(message858), and when the busy signal announcement completes, announcement server720sends BYE message859to network server710. Network server710sends a response code200back to announcement server710. Network server710and end-user station701may further exchange a final response and an ACK message to end their session (not shown).

CONCLUSION

As described above, network servers in a SIP telecommunication network efficiently allow for announcements to be played back to users of the network. SIP messages may include scripts that can define sophisticated playback sequences for the pre-recorded announcements.

Further, although the present invention is discussed in the context of the Session Initiation Protocol (SIP) and an Internet Protocol (IP)-based network, one of ordinary skill in the art will recognize that the present invention may be generally applicable to other equivalent or analogous communication protocols or communications networks.

The foregoing description of preferred embodiments of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. Moreover, while a series of acts have been presented with respect toFIG. 4, the order of the acts may be different in other implementations consistent with the present invention.

Certain portions of the invention have been described as software that performs one or more functions. The software may more generally be implemented as any type of logic. This logic may include hardware, such as an application specific integrated circuit or a field programmable gate array, software, or a combination of hardware and software.