Intelligent voice bridging

[0002] This application is related to and claims the benefit of co-pending applications Ser. No. 09/658,771, entitled “Voice Integrated VOIP System” Ser. No. 09/658,802, entitled “Intelligent Voice Converter” and Ser. No. 09/659,233, entitled “Message Store Architecture”, all filed Sep.11, 2000, the disclosures of which are incorporated herein by reference.

[0003] Telecommunication application servers that provide services using either VOIP (Voice over IP) or traditional PSTN (Public Switched Telephone Network) are known. However, one problem encountered by all applications is that VOIP platforms use data formats that are optimized for IP based networks. Most of the TTS (text-to-speech) and ASR (automatic speech recognition) systems that are in the industry today were designed for public switched telephone networks (PSTNs) and do not support native VOIP formats. Because of this, all of the VOIP data needs to be converted into a format that that can be handled by the ASR and TTS subsystems. However, such conversion is expensive and further, if every new component is handling data in a different way then multiple simultaneous conversion is not possible.

[0004] From the above it is evident that an improved mechanism is required that can couple external functional components like ASR, TTS, etc., into a VOIP data path to provide reach functionality for a VOIP application.

[0005] According to one aspect of the invention, voice bridging enables coupling between VOIP and external components in a scalable manner to support a large subscriber base.

[0006] According to another aspect of the invention, a software base data coupling module non-intrusively couples data from external components, such as TTS/ASR into a VOIP application.

[0007] According to another aspect of the invention, intelligent voice bridging controls the duration that such coupling is effective to equal the time that the functional component is required, hence enabling multiplexing of the same resource across many users and hence increasing efficiency for resource utilization. One embodiment enables multiple functional components to be inserted in a non-intrusive manner into the existing VOIP data path.

[0008] According to another aspect of the invention, a method and a mechanism couples data from industry standard functional components into the data path of a VOIP (Voice Over IP) application. In one embodiment, the VOIP application creates a special User Datagram Protocol (UDP) port that is used to receive bridge data that has to be sent to the VOIP application. The bridging may couple voice data in either a single direction called half-duplex mode or in both directions at the same time, known as full-duplex mode. The half-duplex mode of coupling may be done downstream or upstream.

[0009] According to another aspect of the invention, a cache is maintained that may be activated for the downstream data. Caching adds additional optimization so that, in the event of a replay request, the data from the cache may be played rather than having to generate the data again from the source.

[0010] According to another aspect of the invention, packets provided from the external application include a session number that may be used to identify portions of returned data to be played back at a user's request.

[0011] A further understanding of the nature and advantages of the invention herein may be realized by reference to the remaining portions of the specification and the attached drawings.

[0012] FIG. 1 is a block diagram of the architecture of a VOIP telecommunication server system;

[0013] FIG. 2 is a block and flow diagram of an embodiment of a voice bridging system for VOIP;

[0014] FIG. 3 is more detailed depiction of parts of FIG. 2;

[0015] FIG. 4 is a block and flow diagram depicting half-duplex upstream bridging;

[0016] FIG. 5 is a block and flow diagram depicting half-duplex downstream bridging; and

[0017] FIG. 6 is a block diagram of the format of a bridge voice packet.

[0018] The invention will now be described with reference to the preferred embodiments. FIG. 1 shows a distributed client server system 100 that is used to provide telecommunication application services to callers/subscribers over a managed VOIP network 102. The architecture comprises the following systems in one embodiment:

[0019] GAS 104 is a server that runs the telecommunication applications. It has a functional component called voice bridging that enables external systems and features to be integrated into the data path of the application running on GAS 104. As shown, GAS 104 includes any number of servers, GAS l-N.

[0020] TTS server 106 is responsible for converting text into speech that may be played to the user. Some of the applications that use this feature include listening to email and other text-based content from the phone. Many existing TTS servers are designed to operate in PSTN and to generate voice data not in native VOIP format.

[0021] ASR server 108 is responsible for recognition of voice data sent to it and translating it to text that is sent back to the requester. Many existing ASR servers are designed to operate in PSTN and to process voice data not in native VOIP format.

[0022] VC 110 is a server that converts one format of the voice into another. For this particular embodiment, VC 110 converts PCM voice data into G723.1 format and vice-versa. The VC 110 may be utilized to convert output from TTS 106 to native VOIP format and to convert VOIP format to PSTN format for use by ASR. Additionally, VC 110 may convert voiced data to other VOIP formats.

[0023] Y!Mail 112 (Yahoo! Mail Servers): GAS 104 talks to Yahoo! mail servers 112 to enable subscribers to listen to their email using the phone.

[0024] The art of data transfer over TCP/IP and UDP/IP is well known and will not be addressed in detail here. The intelligent voice bridge described below enables a VOIP application to interact with standard PSTN external functional components, like TTS, ASR, etc., by coupling the voice data from these components to the application's VOIP data path.

[0025] Referring to FIGS. 2 and 3, the embodiment includes a UDP port called the bridging port 20. All the data that is bridged is sent from or received using this port. GAS 104 has a process called TeleTask 22, which has several threads called channel threads 24. Each of the channel threads 24 is responsible for one subscriber over the VOIP system. A channel thread then splits into two threads called a call flow thread 26 and an IO thread 28. Call flow thread 26 runs the application call flow while IO thread 28 is responsible for all of the IO. In a preferred embodiment, the bridging functionality resides in IO thread 28 and interacts with call flow thread 26.

[0026] As shown in FIGS. 2 and 3, IO thread 28 has two UDP/IP ports. The first port is a VOIP port 30 that is used to send and receive data to VOIP network 102. The second port is the bridge port 20 that is used to bridge the external functional components. A bridge cache buffer 32 is shown in FIG. 3.

[0027] Intelligent Voice Bridging is a process having the capability of enabling an external application to interact with a VOIP application by sending data to a dedicated UDP port called bridge UDP port 20. The VOIP application creates and uses bridge UDP port 20 to interact with external application components like TTS 106, ASR 108, etc. The external application data may be queued in UDP port 20 when ready to be sent to VOIP network 102. I/O thread 28 may copy data from bridge port 20 to VOIP port 30 and from VOIP port 30 to the bridge port 20.

[0028] As shown in FIGS. 4 and 5, external applications components may now be added to the VOIP solution. The embodiment supports following modes of operation.

[0029] For example, a PSTN email reading application uses TTS 106, which converts text to voice data in PSTN format. With automatic voice bridging, the PSTN format voice data is automatically sent to a voice converter 110 to convert the PSTN format voice data to VOIP format voice data that may be used by a VOIP email reading application.

[0030] FIG. 5 shows an example of half-duplex upstream voice bridging system 500. In this mode, the VOIP data will be sent to the external application using the UDP bridge socket 20. If the external recipient of the data is capable of receiving the native VOIP data format, then the data will be sent as is. If the recipient requires a different data format then, data will be sent to a voice converter that transcodes the data to the desired format and sends it to the external application.

[0031] The VOIP application has a capability to specify the duration for which upstream bridging is required. The application may request upstream bridging along with message record operation. During message record operation, IO thread 26 will read the data and store it into a record buffer for the application to store the message if required and also send it to the external resource.

[0032] IO thread 26 is capable of doing data end pointing while performing bridging if requested by the application. Data end pointing is the process of identifying possible start of voice and end of voice utterance in a given data stream, accessing requested voice data based on the silence boundaries, and sending only the end pointed data to the destination.

[0033] For example if the application does as follows:

[0034] Application: “Please say the city name for which you want the weather”

[0035] Subscriber: “- - - - - San—Jose - - - - ”, where “-” represents silence.

[0036] The response is the name of the city. Now transcoding is performed on the voice data that contains the city. However from the data stream the process has to identify where the city utterance starts and this process is called endpointing. The process looks for extended silence at the beginning and at the end. Everything in between is the data of interest. This data is then bridged to the voice converter for transcoding.

[0037] The use of data endpointing in conjunction with intelligent voice bridging reduces the cost of a system by allowing voice data from other subscribers to be processed during silences.

[0038] FIG. 4 shows an example of a half-duplex upstream voice bridging system 400. In this mode, the call flow requests external application data to be bridged into the VOIP stream. For example, if the call flow requires an e-mail to be read to the caller, it will request the external TTS engine to convert text into voice. If the output voice data is in the native VOIP format, then the voice data will be bridged directly. However, if the voice data requires conversion into the VOIP format, then the voice data may be sent to VC 110 (Voice Converter). Voice converter 110 converts the voice data to VOIP format and sends the converted voice data to UDP bridging socket 20. At this point the call flow will call bridge 30, which starts reading the data out of the bridge port 20 and sending it to VOIP network 102 at a network transfer rate.

[0039] This mode is very similar to the half duplex down stream bridging mode described previously, but with additional caching functionality. In this mode, as the bridged data is sent to VOIP network 102, a copy of the bridged data is also maintained in the bridge cache. The cached data is used in the event the user requests a replay operation so that the external system need not regenerate the data. Instead, the data from the cache is used to play back to network 102.

[0040] For example, if the user wants to listen to an e-mail, the user request to listen to e-mail is sent to the application call flow. The call flow retrieves the e-mail text from memory and sends the text to external TTS system 106, which converts the text to speech. If the voice data is not in the VOIP network native CODEC format, then the voice data is sent to voice converter 110. The voice converter transcodes the voice data and sends it to bridge port 20. After placing enough voice data in bridge port 20, voice converter 110 will send a “ready to play” signal to the call flow. At that point, the call flow can call bridge operation with caching. This call will trigger IO thread 28 to read voice data from bridge port 20, store a copy of it in the cache, and then send the voice data to VOIP network 102.

[0041] If the entire e-mail was played, then IO thread 26 will send a “bridge done” event to the call flow. In the event a user interrupts the bridging, the user's input is sent to the call flow and the call flow will analyze the user input. If the input is a request to skip to the next e-mail, then the call flow will cancel the current bridge operation and stop TTS 106 and VC 110 and then get them ready to start working on the next e-mail. If the user request was to replay the e-mail, then the call flow will pause TTS 106, VC 110, and the bridge procedures, and will call a method called re-bridge, which will read the data from the cache memory and replay it to network 102. When all data from the cache has been played, IO thread 26 will send an event called “Bridge Resume” and will start reading from the bridge socket, store a copy of the read data in the cache, and also send the read data to VOIP network 102. In the meantime, the call flow will react to the “Bridge Resume” event by resuming TTS 106 and VC 110, which are in the Pause State, waiting to be resumed.

[0042] Full duplex bridging, as shown in FIG. 2, is the mode in which both upstream and downstream bridging happens at the same time. The embodiment being described supports both upstream and downstream bridging independently. Full duplex bridging enables both upstream and downstream bridging at the same time.

[0043] An embodiment of a voice packet format that is used by the bridge is shown in FIG. 6. The voice packet format includes a packet sequence number 600, a packet session flag 602, and a packet voice data 604. The first part of the packet is sequence number 600, which is an incremental number from 0 to 255. Sequence number 600 is used to resequence packets in case the packets arrive out of sequence at the destination, and also to identify packet loss. The next section in the packet is session flag 602. Flag 602 enables the bridge to support multiple simultaneous sessions.

[0044] If session flag 602 for a particular session of bridging is set to a specific number, then all the voice packets belonging to that session will have same value. This flag value is used to separate packets based on functionality into separate sessions.

[0045] The third part of the packet is packet voice data 604, which includes the voice packets.

[0046] A subscriber of this service may want to listen to an e-mail message. At the beginning of the e-mail message, there is an envelope information describing, for example, the subject, sender and recipients. The envelope information is played and then the body of the e-mail is played. While listening to the e-mail, if the subscriber requests to hear the envelope information, then the call flow may use session flag 602 to distinguish the envelope information from the body of the email, and thus enable instant replay of this information. The following steps are an example of a user interaction using the session flag:

[0047] 1. The call flow plays the envelope information with session flag 602 set to “1”. All the voice packets that belong to the envelope information will be set to 1.

[0048] 2. Call flow sets up a downstream bridging with caching for session number 1. At this point, IO thread 28 will read data from bridge port 20 and, if the session is set to 1, will store the data in bridge cache 32 and also send it over to VOIP network 102. The process continues until session “1” is complete.

[0049] 3. The call flow the sets up a downstream bridging with caching for session number 2. This session contains the body of the email.

[0050] 4. Now IO thread 28 starts bridging data for session number 2.

[0051] 5. The user interrupts and requests for the envelope information. The bridge is suspended and the call flow issues “bridge from cache” command to IO thread 28 for session 1. The call flow also pauses TTS 106 and VC 110.

[0052] 6. IO thread 28 reads from cache all the data associated with session 1 and sends the data to VOIP network 102.

[0053] 7. The call flow commands IO thread 28 to “bridge from cache” for session 2. At this point IO thread 28 reads from the cache all the data for session 2 and will start sending it to VOIP network 102. When all the data in the cache for session 2 is sent, IO thread 28 will notify the call flow thread by sending a “BRIDGE CONTINUE” event, and then start reading data from the bridge port 20 and sending to VOIP network 102.

[0054] 8. The call flow thread will resume operation of TTS 106 and the VC 110.

[0055] Because of the cached bridging, the user of this system may instantly listen to various parts of the data.

[0056] Voice bridge cache 32 is a piece of the memory. It is used to cache the downstream bridging data. Cache 32 may store several sessions of bridging data at any given time. The cache enables instant replay of data that has been cached. Call flow thread 26 clears the cache by issuing the flush cache command to IO thread 28. Cache 32 is always in the control of the IO thread.

[0057] According to one embodiment, the following commands are supported by the bridging interface. All of these commands are asynchronous and their result will be indicated back by using events.

[0058] 1. Half duplex upstream bridge start command

[0059] 2. Half duplex downstream bridge start command

[0060] 3. Half duplex downstream bridge start with cache command

[0061] 4. Full duplex bridge start command

[0062] 5. Bridge from cache command

[0063] 6. Flush cache by segment

[0064] 7. Flush entire cache

[0065] According to one embodiment, the following events are used to indicate various conditions that could occur during bridging.

[0066] 1. Bridge Done

[0067] 2. Bridge Error

[0068] 3. Bridge Interrupted

[0069] 4. Bridge Resume

[0070] 5. Bridge Started

[0071] The invention has now been described with reference to the preferred embodiments. Alternatives and substitutions will now be apparent to persons of skill in the art. Accordingly, it is not intended to limit the invention except as provided by the appended claims.