KR20040044849A - Method and system for providing media services - Google Patents

Abstract

The present invention provides a method and system for providing a media service in a VoIP telephone. A switch is connected between at least one audio source and the network interface controller. This switch may be a packet switch or a cell switch. The present invention also provides a distributed conference bridge processing method and system in a VoIP telephone. The distributed conference bridge multicasts the mixed audio content of the conference call in a way that mitigates the duplication at the mixing device. The invention also provides a method and system for noiseless switching between independent audio streams. This noiseless switching preserves valid RTP information upon switchover.

Description

METHOD AND SYSTEM FOR PROVIDING MEDIA SERVICES}

It's been a while since audio was delivered from telephone calls over the network. Conventional circuit switched time division multiplexing (TDM) networks have been used, including public-switched telephone networks (PSTNs) and plain old telephone networks (POTSs). These circuit-switched networks establish a circuit over the network for each call. Audio is delivered over this line in real time in analog and / or digital form.

With the advent of packet switched networks such as local area networks (LANs) and the Internet, audio must now be delivered digitally in the form of packets. Audio may include, but is not limited to, voice, music, or other types of audio data. VoIP (also called Voice over Internet Protocol, or Voice over IP) systems deliver digital audio data belonging to a telephone call over a packet switched network in the form of packets instead of a conventional circuit switched network. In one example, a VoIP system forms two or more connections using TCP / IP (Transmission Control Protocol / Internet Protocol) addresses to achieve a telephone call connection. Devices connected to the VoIP network must follow the standard TCP / IP packet protocol to interoperate with other devices in the VoIP network. Examples of such devices are IP telephones, integrated access devices, media gateways and media servers.

Media servers are often endpoints in VoIP phone calls. The media server is responsible for incoming and outgoing audio streams, ie audio streams entering or leaving the media server, respectively. The type of audio generated by the media server is limited by the application corresponding to the telephone call, such as voice mail, conference bridge, interactive voice response (IVR), and voice recognition. In many applications, the audio produced is unpredictable and may vary depending on the end user response. The entire audio segment, such as words, sentences, and music, is sent out to an audio stream and must be assembled dynamically in real time.

However, packet-switched networks can introduce delays and jitter in the audio stream carried on the telephone call. Real-time transport protocol (RTP) is often used to control delay, packet loss and latency in audio streams sent from media servers. The audio stream can be sent using RTP to a real time device (such as a telephone) or a non-real time device (such as an email client in unified messaging) via a network link. RTP runs on top of protocols such as UDP (User Datagram Protocol), which is part of the IP family. RTP packets include inter alia sequence numbers and time stamps. Sequence numbers allow the destination application to detect the occurrence of packet loss using RTP and ensure that the user is provided with the correct sequence of packets. The time stamp corresponds to the time the packet was assembled. Time stamps allow the destination application to ensure synchronized delivery to the destination user and to calculate delays and jitter. See D. Collins, Carrier Grade Voice over IP, Mc-Graw Hill: US Copyright 2001, pages 52-72, which is incorporated herein by reference in its entirety.

Media servers at endpoints in VoIP phone calls use protocols such as RTP to improve the communication quality for only one audio stream. However, such media servers are limited to outputting only one audio stream of RTP packets on a given telephone call.

Conference calls connect multiple parties across a network on a common call. The conference call was initially conducted through a circuit switched network such as POTS or PSTN. Conference calls may now be made through packet-switched networks such as LANs and the Internet. Indeed, the advent of VoIP systems has increased the demand for conference calls over the network.

A conference bridge connects participants in a conference call. Different types of conference bridges have been used, in part, depending on the type of network and how voice is passed through the network to the conference bridge. One type of conference bridge is described in US Pat. No. 5,436,896 (see the entire patent). This conference bridge 10 operates in an environment in which a voice signal is digitally encoded into a 64 Kbps data stream (first stage lines 21-26 of FIG. 1). Conference bridge 10 has a plurality of inputs 12 and outputs 14. The input 12 is connected to a common add amplifier 20 via respective voice detector 16 and switch 18. Voice detector 16 detects voice by sampling the input data stream and determining the amount of energy present over time (first stage lines 36-39). Each voice detector 16 controls the switch 18. When no voice is present, the switch 18 remains open to reduce noise. During the conference call, the inputs of all the participants speaking are connected to each of the outputs 14 through the adder amplifier 20. Subtractor 24 removes each participant's own voice data stream. Subsequently, several participants 1-n can talk and listen to each other in a connected state made via conference bridge 10. See, US Pat. No. 5,436,896, first row 12th to second row 16th.

Digitized voice is now also delivered in packet form over packet-switched networks. U. S. Patent No. 5,436, 896 describes an example of an asynchronous transmission mode (ATM) packet (also called a 'cell'). To support conference calls in this networking environment, conference bridge 10 converts the input ATM cell into a network packet. The digitized voice is extracted from the packet as described above and processed at the conference bridge 12. The summed output of the digitized voice is reconverted from the network packet to the ATM cell before being sent to the participants 1-n. See, US Pat. No. 5,436,896, second column 17 to second column 36.

U. S. Patent No. 5,436, 896 also describes a conference bridge 238 that processes an ATM cell without converting and reconverting the ATM cell into a network packet, as in conference bridge 10. This conference bridge 238 Is shown in FIGS. 2 and 3. Conference bridge 238 has inputs 302-306 one by one from each participant and outputs 308-312 one by one to each participant. The voice detectors 314-318 analyze the input data collected in the sample-hold buffers 322-326. The voice detectors 314-318 report to the controller 320 the detected voice and / or the volume of the detected voice. See, US Pat. No. 5,436,896, fourth column 16-39.

Controller 320 is coupled to selector 328, gain control 329, and replicator 330. The controller 320 determines who of the participants is speaking based on the output of the voice detectors 314-318. When one speaker (eg, participant 1) is speaking, controller 320 sets selector 328 to read data from buffer 322. The data is moved to replicator 330 via automatic gain control 329. The replicator replicates the data in the ATM cell selected by the selector 328 for all participants except the speaker. See, US Pat. No. 5,436,896, fourth column 40 to fifth column fifth. When two or more speakers are speaking, the loudest speaker is chosen for a given selection period. The next loudest speaker is then selected in the subsequent selection period. Scanning the voice detectors 314-318 at appropriate intervals, such as 6 milliseconds, and reconfiguring the selector 328 may also follow the appearance of simultaneous voice. See, US Pat. No. 5,436,896, fifth column 6 to 65.

Another type of conference bridge is described in US Pat. No. 5,983,192 (see all of these patents). In one embodiment, conference bridge 12 receives compressed audio packets via a real time protocol (RTP / RTCP). See, US Pat. No. 5,983,192, third column 66 to fourth row 40. Conference bridge 12 includes audio processors 14a-14d. Typical audio processor 14c associated with point C (ie, participant C) includes switch 22 and selector 26. The selector 26 includes a voice detector that determines which of the other points A, B or D is most likely to speak. See, US Pat. No. 5,983,192, fourth column 40-67. Other alternatives include the selection of one or more points and the use of an acoustic energy detector. See, US Pat. No. 5,983,192, fifth column to lines 1-7. In another embodiment described in US Pat. No. 5,983,192, selector 26 / switch 22 outputs the plurality of loudest speakers in a separate stream to a local mixing end-point site. do. The loudest streams are sent to multiple points. See lines 5 to 8, line 67 of U.S. Patent 5,983,192, supra. It is also referred to as "double-talk" and "triple-talk", as well as setting up a mixer / encoder to handle multiple speakers. See, US Pat. No. 5,983,192, line 7, line 20 to step 9, line 29.

VoIP systems continue to require improved conference bridges. For example, the softswitch VoIP architecture may use one or more media servers having a media gateway control protocol such as MGCP (RFC 2705). See D. Collins, Carrier Grade Voice over IP, Mc-Graw Hill: US Copyright 2001, pages 234-244, which is incorporated herein by reference in its entirety. Such media servers are often used to process audio streams in VoIP calls. These media servers are often the endpoints where audio streams are mixed in conference calls. These endpoints are also referred to as " conference bridge access points " because the media server is an endpoint where media streams from multiple callers are mixed and provided back to all callers. See page 242 of D. Collins's book above.

As the popularity and demand of IP telephony and VoIP calls increase, media servers are expected to handle conference call processing with carrier quality. Conference bridges within the media server need to be able to scale to handle different numbers of participants. Audio in the packet stream, such as RTP / RTCP packets, needs to be efficiently processed in real time.

The present invention relates generally to audio communication over a network.

1 is a diagram illustrating a media server in a typical VoIP environment according to the present invention.

2 is a diagram illustrating an exemplary media server including media services and resources according to the present invention.

3A and 3B illustrate an audio processing platform according to an embodiment of the present invention.

4 is a diagram of the audio processing platform shown in FIGS. 3A and 3B in accordance with an exemplary embodiment of the present invention;

5A is a flowchart illustrating setting of call and incoming packet processing according to an embodiment of the present invention;

5B is a flowchart illustrating outgoing packet processing and call termination according to an embodiment of the present invention;

6A to 6F illustrate a noiseless switchover system according to an embodiment of the present invention.

6A illustrates a noiseless switchover system for performing cell switching of an independent outgoing audio stream generated by an internal audio source according to an embodiment of the present invention.

6B illustrates audio data flow in a noiseless switchover system for performing cell switching of an independent outgoing audio stream generated by an internal audio source according to an embodiment of the present invention.

6C illustrates a noiseless switchover system for performing cell switching between independent outgoing audio streams generated by an internal and / or external audio source, in accordance with an embodiment of the present invention;

FIG. 6D illustrates audio data flow in a noiseless switchover system that performs cell switching between independent outgoing audio streams generated by an internal and / or external audio source in accordance with an embodiment of the present invention. FIG.

6E illustrates audio data flow in a noiseless switchover system that performs packet switching between independent outgoing audio streams generated by an internal and / or external audio source in accordance with an embodiment of the present invention.

FIG. 6F illustrates a noiseless switchover system for switching between independent outgoing audio streams generated by an external audio source in accordance with an embodiment of the present invention. FIG.

7A is a diagram schematically showing an IP packet having RTP information,

7B is a view schematically showing an inner packet according to an embodiment of the present invention,

8 is a flowchart illustrating a switching function according to an embodiment of the present invention;

9A, 9B and 9C are flowcharts illustrating call event processing for switching audio streams according to an embodiment of the present invention.

10 is a block diagram of a distributed conference bridge, in accordance with an embodiment of the present invention;

FIG. 11 illustrates a typical lookup table used in the distributed conference bridge of FIG. 10.

12 is a flowchart diagram of the operation of the distributed conference bridge of FIG. 10 in establishing a conference call, FIG.

13A, 13B and 13C are flow chart diagrams of the operation of the distributed conference bridge of FIG. 10 in processing a conference call.

14A illustrates an exemplary internal packet generated by an audio source during a conference call in accordance with an embodiment of the present invention.

14B illustrates typical packet content in a fully mixed audio stream and a set of partially mixed audio streams in accordance with the present invention.

FIG. 15 is a diagram illustrating typical packet contents after the packets of FIG. 14 are multicast in a 64 participant conference call according to the present invention, and after these packets are processed to become IP packets to be transmitted to the corresponding participant.

The present invention provides a method and system for providing a media service in a VoIP telephone. In one embodiment, a switch is connected between the multiple audio sources and the network interface controller. This switch may be a packet switch or a cell switch. The internal and / or external audio source produces an audio packet stream. Any type of packet can be used. In one embodiment, the inner packet includes a packet header and a payload.

In one embodiment, the packet header contains information identifying the talker in talk, and the speaker's audio is mixed. The payload carries the digitized mixed audio. According to one aspect of the invention, one fully mixed audio packet stream and a plurality of partially mixed audio packet streams are generated by an audio source (eg, a DSP). This fully mixed audio stream contains the audio content of a group of identified active speakers. The packet header information reveals each active speaker in the fully mixed stream. In one example, the audio source inserts a conference identification number (CID) associated with its active speaker into a header field in the packet. The audio source inserts mixed digital audio from the active speaker into the payload of the packet. The mixed digital audio corresponds to the voice or other type of audio input by the active speaker in the conference call.

Each of the partially mixed audio streams includes subtracting the audio content of each receiving active speaker from the audio content of the group of identified active speakers. The receiving active speaker is the active speaker in the active speaker group, with the partially mixed audio stream directed towards him. The audio source inserts into the packet payload the subtracted audio content of the receiving active speaker from the digital audio from the identified active speaker group. As such, the receiving active speaker does not receive audio corresponding to his or her own voice or audio input. The packet header information reveals the active speaker, whose audio content is contained within its respective partially mixed audio stream. In one example, the audio source inserts one or more conference identification numbers (CIDs) into the TAS and IAS headers of the packet. The TAS (Total Active Speakers) field lists the CIDs of all current active speakers in the conference call. The IAS field (Included Active Speakers) lists the CIDs of the active speakers whose audio content is in their partially mixed stream. In one embodiment, the audio source (or mixer, because it is mixing audio) dynamically generates an appropriate fully mixed and partially mixed audio packet stream with mixed audio with the CID information during the conference call. The audio source retrieves the corresponding CID information of the conference call participant from the relatively static lookup table created and stored at the beginning of the conference call.

For example, in a conference call where there are 64 participants, three of which are identified as active speakers 1-3, one fully mixed audio stream includes audio from all three active speakers. This fully mixed stream is ultimately sent to each of the 61 passive participants. Three partially mixed audio streams are also generated. The first partially mixed stream 1 contains audio from speakers 2-3 but no speaker 1 audio. The second partially mixed stream 2 includes audio from speakers 1-3 but does not include audio from speaker 2. The third partially mixed stream 3 contains audio from speakers 1-2 but does not contain audio from speaker 3. The first to third partially mixed audio streams are ultimately sent to speakers 1-3 respectively. As such, only four mixed audios need be produced by the audio source.

A fully mixed audio stream and a plurality of partially mixed audio streams are sent from the audio source (eg, DSP) to the packet switch. Cell layers may also be used. The packet switch multicasts each of the fully mixed audio and the partially mixed audio stream to a network interface controller (NIC). The NIC then processes each packet to determine whether to deliver to the participant a packet for a fully mixed or partially mixed audio stream. This determination may be made in real time based on the lookup table in the NIC and the packet header information in the multicast audio stream.

In one embodiment, during the initiation of a conference call, each participant of that call is assigned a CID. Switched virtual circuits (SVCs) are also associated with conference call participants. A lookup table that contains entries for conference call participants is created and stored. Each entry contains network address information (eg, IP, UDP address information) and the CID of the respective conference call participant. The lookup table may be stored for connection by both the NIC processing the packet and the audio source mixing the audio during the conference call.

The packet switch multicasts each of the fully mixed and partially mixed audio streams to the NIC through both the SVCs assigned to the conference call. The NIC processes each packet arriving through the SVC, specifically examining the packet header to determine whether to send or discard the packet to the participant for a fully mixed or partially mixed audio stream. One advantage of the present invention is that this packet processing decision can be performed quickly and in real time during a conference call based on the CID information and packet header information obtained from the lookup table. In one embodiment, the transmitted network packet includes the participant's network address information (IP / UDP), RTP packet header information (time stamp / order information) and audio data obtained from the lookup table.

In summary, the benefits of the present invention include providing conference bridge processing using less resources with less bandwidth and processing than is typically required for mixing devices in other conference bridges. The conference bridge system and method of the present invention are multicast in a manner that reduces the duplication of the mixing device. For a conference call with N participants and c active speakers, the audio source only needs to generate c + 1 mixed audio streams (one fully mixed audio stream and c partially mixed audio stream). The work is distributed to multicasters within the switch that perform replication and multicast the mixed audio streams. An additional advantage is that the conference bridge according to the invention can be extended to accommodate a large number of participants. For example, for N = 1000 participants and c = 3 active speakers, the audio source only needs to generate c + 1 = 4 mixed audio streams. Packets in the multicast audio stream are processed in real time at the NIC to determine the appropriate packet to output to the participants of the conference call. In one example, an internal outgoing packet with a header and payload is used at the conference bridge to further reduce processing at the audio source mixing audio for the conference call.

In addition, as the use of audio networking increases and the number of users and applications increases, the need for multiple audio streams even on a given telephone call increases. The inventors have recognized that multiple audio streams need to be dynamically switched without causing RTP errors in calls made in audio networking environments such as VoIP networks. This RTP error can cause unwanted noise such as clicks and pops.

The present invention provides a method and system for noiseless switching between independent audio streams. This noiseless switching preserves valid RTP information upon switchover. In the case of an established VoIP call, the present invention can switch noiselessly from one audio source to another. This switching system is dynamic and can be extended to handle multiple calls.

In embodiments of the present invention, a switch is used to send audio data from multiple audio sources to a network interface controller. This switch may be a cell switch or a packet switch. The audio source may be an internal audio source and / or an external audio source. The network interface controller (NIC) can be any interface with an IP network and includes one or more packet processors. The outgoing audio controller controls the operation of the internal audio source, switch and network interface controller to perform noiseless switching in accordance with the present invention.

In one aspect of the invention, priority information is used by the network interface controller to determine which of the audio streams from an internal or external audio source to transmit in the established VoIP telephone call. Consider the case of two internal audio sources. These audio sources create their own audio stream of internal outgoing packets for one destination outgoing audio channel. In one embodiment, each inner outgoing packet includes a payload that carries audio and control header information. The control header information has priority information. This priority information is then used by the network interface controller to determine which audio stream is delivered because only one RTP stream can be output at a given time for each VoIP call.

In one aspect of the invention, the inner outgoing packet is smaller than the IP packet and consists only of payload and control header information. As such, the processing work required to generate the entire IP packet need not be performed by an internal audio source such as a DSP and is distributed to the packet processor in the network interface controller.

According to a further feature, a cell switch is used, which is a fully meshed cell switch such as an ATM cell switch with a lot of available bandwidth. Internal outgoing packets for different audio streams are converted into cells. The cell switch synthesizes the merged cells from different sources and passes them through the SVC to the NIC. SVC is associated with one outgoing output audio channel serving a established telephone call.

In one embodiment, an outgoing audio controller is used to control noiseless switching of audio in a VoIP telephone call. This noiseless switching according to the invention is also referred to herein as "noiseless switch over". In one embodiment, noiseless switchover of additional audio is performed for calls that may use this service. As such, an additional fee may be charged for providing a noiseless switchover service. In other embodiments, noiseless switchover is performed for any call.

Any call event with additional audio triggers a noiseless switchover. This noiseless switchover is performed using the noiseless switching system and method of the present invention. Examples of call events include, but are not limited to, the following situations: emergency, call signaling, call event based on caller or callee information, or request of different audio information. The request for audio information can be any audio request, such as a request for advertising, news, sports, finance, music or other audio content.

The audio source can produce any type of audio. For example, an audio stream of outgoing packets may include audio payloads representing voice, music, tones, and / or any other sound.

The outgoing audio controller may be a standalone device or part of a call control and audio feature manager in an audio processing platform. The invention may be implemented in a media server, audio processor, router, packet switch, or audio processing platform.

Another embodiment includes switching an audio stream including an audio stream from an external audio source. In this case, the NIC receives the IP packet containing the audio stream and converts the IP packet into an internal outgoing packet. At this point, the internal outgoing packet is processed as if it were generated from an internal audio source. The inner outgoing packet may include priority information. The internal outgoing packet may be sent as a packet or cell through the switch to the NIC via the switch. When the external audio stream has a relatively high priority and is scheduled to switch over, the packet processor on the NIC generates an IP packet with synchronized header information (e.g. RTP information) and sends this IP packet to the destination device. send.

In one embodiment, a noiseless switch over system according to the present invention comprises switching of an audio stream only from an internal audio source such as a DSP. In another embodiment, a noiseless switch over system according to the present invention comprises switching of an audio stream from an internal audio source and an external audio source. In another embodiment, the noiseless switchover system according to the present invention comprises the switching of an audio stream only from an external audio source, in which case the switchover system acts as a general switch for the audio stream and requires an internal DSP. I never do that.

Further embodiments, features, and advantages of the present inventions, as well as the structure and operation of the various embodiments of the present invention, are described in detail below with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and form a part of this specification, illustrate the principles of the invention, together with the description, and help to enable those skilled in the art to make and use the invention.

The present invention will now be described with reference to the accompanying drawings. In the drawings, like reference numerals refer to like or similar components. Furthermore, looking at the left digit (s) of the reference number reveals the figure in which the reference number first appeared.

I. Overview and Description

The present invention provides a method and system for distributed conference bridge processing in a VoIP telephone. The work of the mixing device such as the DSP is distributed and saved. Specifically, the distributed conference bridge according to the present invention uses internal multicast and packet processing at the network interface to reduce the work at the audio mixing device. A conference call agent is used to set up and terminate the conference call. An audio source, such as a DSP, mixes the audio of an active conference call participant. Only one fully mixed audio stream and a set of partially mixed audio streams need to be created. A switch is connected between the audio source that mixes the audio content and the network interface controller. This switch includes a multi-caster. The multicaster duplicates packets in only one fully mixed audio stream and a set of partially mixed audio streams and multicasts these duplicated packets onto a link (eg, SVC) associated with each call participant. The network interface controller processes each packet to determine whether to forward or discard a packet of a fully mixed or partially mixed audio stream to the participant. This determination can be made in real time based on the lookup table in the NIC and the packet header information in the multicast audio stream.

In one embodiment, the conference bridge according to the present invention is implemented in a media server. According to embodiments of the present invention, the media server may include a call control and audio feature manager to manage the operation of the conference bridge.

The present invention is described in relation to a typical VoIP environment. The description in this respect is merely provided for convenience. It is not intended that the present invention be limited to applications in these typical environments. In fact, it will be apparent to those skilled in the art after reading the following description how to implement the present invention in other environments that are presently known or will appear in the future.

II. Term description

In order to more clearly describe the present invention, efforts have been made to follow the following term definitions as consistently as possible throughout the specification.

According to the invention the term noiseless refers to the preservation of packet sequence information in switching between independent audio streams. The term synchronized header information refers to the fact that packet sequence information is preserved in a packet having a header. The packet sequence information may include valid RTP information, but is not limited thereto.

The term digital signal processor (DSP) includes, but is not limited to, an apparatus used to code or decode digitized speech samples in accordance with a program or application service.

The term digitized voice or voice includes, but is not limited to, audio byte samples generated by pulse code modulation (PCM) by standard line telephone compressors / decompressors (CODECs).

The term packet processor refers to any type of packet processor that generates a packet for a packet switched network. In one example, a packet processor is a special microprocessor designed to inspect and modify Ethernet packets according to a program or application service.

The term packetized speech refers to a digitized speech sample carried in a packet.

The term Real Time Protocol (RTP) audio stream refers to a sequence of RTP packets associated with one packetized voice channel.

The term switched virtual circuit (SVC) refers to a temporary virtual circuit that is set up and used only while data is being transmitted. When the communication between the two hosts is terminated, the SVC disappears. In contrast, the permanent virtual circuit (PVC) is always available.

III. Audio networking environment

The present invention can be used in any audio networking environment. Such audio networking environments may include, but are not limited to, wide area networks (WANs) and / or local area networks (LANs). In typical embodiments, the present invention is included within an audio networking environment as a standalone device or as part of a media server, packet router, packet switch or other network component. For simplicity, the present invention will be described with respect to the embodiments included in the media server.

The media server delivers the audio over one or more circuit switched and / or packet switched networks via a network link to a local client or a remote client. The client may be, but is not limited to, any type of device that processes audio, including telephones, cellular phones, personal computers, personal data assistants (PDAs), set-top boxes, consoles, or audio players. 1 is a diagram illustrating a media server 140 in a typical VoIP environment in accordance with the present invention. This example includes a telephony client 105, a public switched telephone network (PSTN) 110, a softswitch 120, a gateway 130, a media server 140, a packet switched network (s) 150, and a computer client ( 155). The telephony client 105 can be any type of (wired or wireless) telephone capable of transmitting and receiving audio over the PSTN 110. PSTN 110 is any type of circuit switched network (s). Computer client 155 may be a personal computer.

The telephony client 105 is connected to the media server 140 via a public switched telephone network (PSTN) 110, a gateway 130, and a network 150. In this example, call signaling and control are separate from the media path or link carrying the audio. The softswitch 120 is provided between the PSTN 110 and the media server 140. Softswitch 120 supports call signaling and control to establish and remove voice calls between telephony client 105 and media server 140. In one example, the softswitch 120 follows a Session Initiation Protocol (SIP). The gateway 130 is responsible for converting and passing audio between the PSTN 110 and the network 150. This may include various known functions, such as converting a circuit switched telephone number to an Internet Protocol (IP) address and vice versa.

Computer client 155 is coupled to media server 140 via network 150. The media gateway controller (not shown) may also use SIP to support call signaling and control to establish and block a link, such as a voice call, between the computer client 155 and the media server 140. An application server (not shown) may also be connected to the media server 140 to support VoIP services and applications.

The present invention has been described in connection with these exemplary embodiments. The description in this respect is merely provided for convenience. It is not intended that the present invention be limited to applications in these typical environments, including media servers, routers, switches, network components, or standalone devices in a network. Indeed, it will be apparent to those skilled in the art after reading the following description how to implement the present invention in other environments, which are currently known or will appear in the future.

IV. Media server, services, and resources

2 illustrates an exemplary media platform 200 in accordance with one embodiment of the present invention. Media platform 200 provides scalable VoIP telephony. Media platform 200 includes a media server 202, which is connected to resource (s) 210, media server (s) 212 and interface (s) 208. . Media server 202 includes one or more applications 210, resource manager 220 and audio processing platform 230. Media server 202 provides resources 210 and services 212. The resource 210 includes, but is not limited to, modules 211a-f as shown in FIG. 2. The resource module 211a-f includes a play announcement / collect digits IVR resource 211a, a tone / numeric voice scanning resource 211b, a transcoding resource 211c, an audio recording / playback resource ( 211d), a text-to-speech resource 211e and a speech recognition resource 211f. Media service 212 includes, but is not limited to, modules 213a-e as shown in FIG. The media service module 213a-e includes conventional services such as telebrowsing 213a, voice mail service 213b, conference bridge service 213b, video streaming 213d and VoIP gateway 213e. Doing.

The media server 202 includes an application central processing unit (CPU) 210, a resource manager CPU 220, and an audio processing platform 230. Application CPU 210 is any processor that supports and executes program interfaces for applications and applets. The application CPU 210 enables the media platform 200 to provide one or more of the media services 212. The resource manager CPU 220 is any processor that controls the connection between the resource 210 and the application CPU 210 and / or the audio processing platform 230. The audio processing platform 230 provides a communication connection with one or more of the network interfaces 208. Media platform 200 receives and transmits information via network interface 208 via audio processing platform 230. Interface 208 includes Asynchronous Transfer Mode (ATM) 209a, LAN Ethernet 209b, Digital Subscriber Line (DSL) 209c, Cable Modem 209d, and Channelized T1-. The T3 line 209e may be included, but is not limited thereto.

V. Audio Processing Platform with Packet / Cell Switch for Noiseless Switching of Independent Audio Streams

In one embodiment of the invention, the audio processing platform 230 includes a dynamic fully-meshed cell switch 304 and other components for receiving and processing packets, such as IP packets. . The audio processing platform 230 is shown in FIG. 3A in connection with audio processing including noiseless switching in accordance with the present invention.

As shown, the audio processing platform 230 includes a call control and audio feature manager 302, a cell switch 304 (a packet / cell to indicate that the cell switch 304 may be a cell switch or a packet switch). Also referred to as a switch], a network connection 305, a network interface controller 306, and an audio channel processor 308. The network interface controller 306 further includes a packet processor 307. Call control and audio feature manager 302 is coupled to a cell switch 304, a network interface controller 306, and an audio channel processor 308. In one configuration, call control and audio feature manager 302 is directly connected to network interface controller 306. The network interface controller 306 then controls the operation of the packet processor 307 based on the control commands sent by the call control and audio feature manager 302.

In one embodiment, call control and audio feature manager 302 includes cell switch 304, network interface controller 306 (packet processor 307) to provide noiseless switching of independent audio streams in accordance with the present invention. And the audio channel processor 308. Such noiseless switching will be further described below with reference to FIGS. 6 to 9. An embodiment of the call control and audio feature manager 302 according to the present invention is further described below with reference to FIG. 3B.

The network connection 305 is connected to the packet processor 307. The packet processor 307 is also connected to the cell switch 304. The cell switch 304 is then connected to the audio channel processor 308. In one embodiment, the audio channel processor 308 includes four channels capable of processing four calls. That is, there are four audio processing sections. In alternative embodiments, there are more or fewer audio channel processors 308.

A data packet such as an IP packet including a payload having audio data arrives at the network connection 305. In one embodiment, the packet processor 307 includes one or more or eight 100Base-TX full-duplex Ethernet links that support high speed network traffic in the range of 300,000 packets per second per link. In another embodiment, the packet processor 307 supports 1,000 G.711 voice ports per link and / or 8,000 G.711 voice channels per system.

In another embodiment, the packet processor 307 recognizes the IP header of the packet and handles all RTP routing decisions with minimal packet delay or jitter.

In one embodiment of the invention, the packet / cell switch 304 is a non-blocking switch with a total bandwidth of 2.5 Gbps. In another embodiment, the packet / cell switch 304 has a total bandwidth of 5 Gbps.

In one embodiment, the audio channel processor 308 includes any audio source, such as a digital signal processor, described in greater detail below with reference to FIG. The audio channel processor 308 may perform an audio related service including one or more of the services 211a-f.

VI. Typical audio processing platform implementation

4 is exemplary and shows an exemplary embodiment unless it is intended to limit the invention. As shown in FIG. 4, the audio processing platform 230 may be a shelf controller card (SCC). System 400 implements one of these SCCs. System 400 includes cell switch 304, call control and audio feature manager 302, network interface controller 306, interface circuit 410, and audio channel processor 308a-d.

In more detail, system 400 receives packets at network connections 424 and 426. Network connections 424 and 426 are connected to network interface controller 306. Network interface controller 306 includes packet processors 307a-b. The packet processor 307a-b includes a controller 420, 422, a forwarding table 412, 416, and a forwarding processor (EPIF) 414, 418. As shown in FIG. 4, the packet processor 307a is connected to a network connection 424. The network connection 424 is connected to the controller 420. Controller 420 is coupled to forwarding table 412 and EPIF 414. The packet processor 307b is connected to a network connection 426. The network connection 426 is connected to the controller 422. Controller 422 is connected to forwarding table 416 and EPIF 418.

In one embodiment, the packet processor 307 may be implemented on one or more LAN daughtercard modules. In other embodiments, each network connection 424, 426 may be a 100Base-TX or 1000Base-T link.

The IP packet received by the packet processor 307 is processed into an internal packet. If a cell layer is used, the inner packet is transformed into a cell (eg, an ATM cell by a conventional segmentation and reassembly (SAR) module). The cells are delivered to the cell switch 304 by the packet processor 307. The packet processor 307 is connected to the cell switch 304 via cell buses 428, 430, 432, 434. Cell switch 304 delivers the cell to interface circuit 410 via cell buses 454, 456, 458, and 460. Cell switch 304 analyzes each cell and forwards each cell to the appropriate cell bus of cell buses 454, 456, 458, and 460 based on the audio channel that is the cell's destination. Cell switch 304 is a fully meshed dynamic switch.

In one embodiment, the interface circuit 410 is a backplane connector.

Resources and services available for processing and switching packets and cells in system 400 are provided by call control and audio feature manager 302. The call control and audio feature manager 302 is connected to the cell switch 304 via a processor interface (PIF) 436, a SAR and a local bus 437. Local bus 437 is also connected to buffer 438. The buffer 438 stores and queues instructions between the call control and audio feature manager 302 and the cell switch 304.

Call control and audio feature manager 302 is also connected to memory module 442 and configuration module 440 via bus connection 444. In one embodiment, configuration module 440 provides control logic for booting, initial diagnostics, and operational parameters of call control and audio feature manager 302. In one embodiment, memory module 442 includes a dual in-line memory module (DIMM) for RAM operation of call control and audio feature manager 302.

Call control and audio feature manager 302 is also connected to interface circuit 410. The network circuit 408 connects the resource manager CPU 220 and / or the application CPU 210 to the interface circuit 410. In one embodiment, the call control and audio feature manager 302 monitors the status of the interface circuit 410 and additional components connected to the interface circuit 410. In another embodiment, call control and audio feature manager 302 controls the operation of components coupled to interface circuit 410 to provide resources 210 and services 212 of media platform 200.

Console port 470 is also connected to call control and audio feature manager 302. Console port 470 provides direct access to the operation of call control and audio feature manager 302. For example, the console port 470 can be used to manage the operation of the call control and audio feature manager 302 and thus the system 400, reboot its media processor or otherwise affect its performance.

Reference clock 460 is coupled to interface circuit 410 and other components of system 400 to provide a consistent means for time stamping packets, cells, and instructions of system 400.

The interface circuit 410 is connected to each of the audio channel processors 308a-308d. Each of the processors 308 includes a PIF 476, a group 478 of one or more card processors (also referred to as a "bank" processor), and a group 480 of one or more digital signal processors (DSPs) and SDRAM buffers. In one embodiment, there are four card processors in group 478 and 32 DSPs in group 480. In this embodiment, each card processor in group 478 connects to and operates with the eight DSPs in group 480.

VII. Call Control and Audio Feature Manager

3B is a block diagram of call control and audio feature manager 302 in accordance with an embodiment of the present invention. Call control and audio feature manager 302 is described as a functional processor 302. Processor 302 includes a call signaling manager 352, a system manager 354, a connection manager 356, and a feature controller 358.

The call signaling manager 352 manages call signaling operations such as call establishment and removal, interface with a softswitch, and signaling protocol processing such as SIP.

System manager 354 performs bootstrap and diagnostic operations on the components of system 230. System manager 354 also monitors system 230 and controls various hot-swapping and redundant operations.

The connection manager 356 manages EPIF forwarding tables, such as tables 412 and 416, and provides routing protocols (e.g., Routing Information Protocol (RIP), Open Shortest Path First (OSPF)). Etc.]. Connection manager 356 also establishes an internal ATM permanent virtual circuit (PVC) and / or SVC. In one embodiment, connection manager 356 is a two-way connection between network connections, such as network connections 424 and 426, and DSP 480a- such that data flow can be sourced or processed by a DSP or other type of channel processor. d) Set the DSP channel.

In another embodiment, connection manager 356 creates a summary of the details of the EPIF and ATM hardware. Call signaling manager 352 and resource manager CPU 220 may access these details so that their operation is based on the appropriate service set and performance parameters.

Feature controller 358 provides a communication interface and protocols such as H.323 and MGCP (Media Gateway Control Protocol).

In one embodiment, the card processor 478a-d is the call control and audio feature manager 302 and its modules, namely the call signaling manager 352, the system manager 354, the connection manager 356 and the feature controller 358. Function as a controller with a local administrator for processing commands from any of The card processor 478a-d then manages media streams such as DSP banks, network interfaces, and audio streams.

In one embodiment, DSPs 480a-d provide resources 210 and services 212 of media platform 200.

In one embodiment, the call control and audio feature manager 302 of the present invention uses an applet to control the EPIF of the present invention. In this embodiment, commands for setting parameters (eg, port MAC address, port IP address, etc.), managing lookup tables, uploading statistics, etc. are indirectly passed through the applet.

EPIF provides a search engine that handles functions related to the creation, deletion and retrieval of entries. Since media platform 200 operates on the source and destination of the packet, EPIF provides a search function of the source and destination. The source and destination of the packet are stored in a lookup table for called and originating addresses. The EPIF also manages RTP header information and evaluates the relative priority of the outgoing audio stream to be transmitted, as described in more detail below.

VIII. Audio processing platform behavior

Operation of the audio processing platform 230 is described in the flowcharts of FIGS. 5A and 5B. 5A is a flowchart of call setup and incoming packet processing according to an embodiment of the present invention. 5B is a flowchart illustrating outgoing packet processing and call termination according to an embodiment of the present invention.

A. Incoming Audio Stream

In FIG. 5A, the process for an incoming (or inbound) audio stream begins at step 502 and proceeds directly to step 504.

At step 504, call control and audio feature manager 302 establishes a call with a client communicating over network connection 305. In one embodiment, call control and audio feature manager 302 negotiates and authorizes the connection to the client. If the client connection is granted, the call control and audio feature manager 302 provides the client with IP and UDP address information for that call. If the call is established, the process immediately proceeds to step 506.

In step 506, the packet processor 307 receives an IP packet carrying audio over the network connection 305. Any type of packet may be used including, but not limited to, IP packets such as Appletalk, IPX, or other types of Ethernet packets. If the packet is received, the process proceeds to step 508.

In step 508, the packet processor 307 examines the IP and UDP header addresses in the lookup table to find the relevant SVC, and then converts the VoIP packet into an inner packet. This inner packet may consist of a payload and a control header, for example, as described further below with respect to FIG. 7B. The packet processor 307 then uses at least some of the data and routing information to create a packet and assign a switched virtual circuit (SVC). SVC is associated with one of the audio channel processors 308, and in particular with one of the respective DSPs handling the audio payload.

When the cell layer is used, the inner packet is further transformed or merged into a cell such as an ATM cell. As such, the audio payload in the inner packet is converted into an audio payload in a stream of one or more ATM cells. Conventional disassembly and reassembly (SAR) modules can be used to convert internal packets into ATM cells. If the packet is converted to a cell, the process proceeds to step 510.

At step 510, cell switch 304 switches the cell to the appropriate audio channel of audio channel processor 308 based on the SVC. The process proceeds to step 512.

In step 512, the audio channel processor 308 converts the cell into a packet. The audio payload in the ATM cell arriving for each channel is converted into an audio payload in a stream of one or more packets. Conventional SAR modules can be used to convert ATM cells into packets. The packet may be an internal outgoing packet with an audio payload or an IP packet. If the cell is converted into an inner packet, the process proceeds to step 514.

In step 514, the audio channel processor 308 processes the audio data of the packet in its respective audio channel. In one embodiment, the audio channel is associated with one or more of the media services 213a-e. For example, these media services may be media services for telebrowsing, voice mail, conference bridges (also called conference calling), video streaming, VoIP gateway services, telephones, or any other audio content.

B. Outgoing Audio Stream

In FIG. 5B, the process for an outgoing (also called outbound) audio stream begins at step 522 and proceeds directly to step 524.

In step 524, call control and audio feature manager 302 identifies the audio source for noiseless switchover. This audio source may be associated with an established call or other media service. If the audio source is identified, the process immediately proceeds to step 526.

In step 526, the audio source generates a packet. In one embodiment, the DSP in audio channel processor 308 is an audio source. Audio data may be stored in SDRAM associated with the DSP. This audio data is then packetized into packets by the DSP. Any type of packet may be used including, but not limited to, an IP packet such as an inner packet or an Ethernet packet. In one preferred embodiment, the packet is an internal outgoing packet generated as described in connection with FIG. 7B.

In step 528, the audio channel processor 308 converts the packet into a cell, such as an ATM cell. The audio payload in the packet is converted into an audio payload in a stream of one or more ATM cells. In summary, packets are parsed and data and routing information are analyzed. The audio channel processor 308 then uses at least some of the data and routing information to create the cell and assign a switched virtual circuit (SVC). Conventional SAR modules may be used to convert packets into ATM cells. The SVC is associated with one of the audio channel processors 308, and in particular with circuitry connecting the respective DSP of the audio source with the destination port 305 of the NIC 306. If the packet is converted to a cell, the process proceeds to step 530.

In step 530, the cell switch 304 switches the cell of the audio channel of the audio channel processor 308 to the destination network connection 305 based on the SVC. The process proceeds to step 532.

At step 532, the packet processor 307 converts the cell into an IP packet. The audio payload in the ATM cell arriving for each channel is converted into an audio payload in a stream of one or more internal packets. Conventional SAR modules can be used to convert ATMs into inner packets. Any type of packet may be used including, but not limited to, IP packets such as Ethernet packets. If the cell is converted into a packet, the process proceeds to step 534.

In step 534, each packet processor 307 further adds RTP, IP and UDP header information. The lookup table is checked to find the IP and UDP header address information associated with the SVC. The IP packet is then transmitted via the network connection 305 to the destination device (telephone, computer, palm device, PDA, etc.) via the network. The packet processor 307 processes the audio data of the packet in its audio channel. In one embodiment, the audio channel is associated with one or more of the media services 213a-e. For example, these media services may be media services for telebrowsing, voice mail, conference bridging (also called conference calling), video streaming, VoIP gateway service, telephone, or any other audio content.

IX. Noiseless Switching of Outgoing Audio Streams

According to one aspect of the invention, the audio processing platform 230 performs noiseless switching between independent outgoing audio streams. Audio processing platform 230 is exemplary. Although the present invention has been described in terms of noiseless switching of outgoing audio streams, it can be used in any media server, router, switch, or audio processor and is not intended to be limited to audio processing platform 230.

A. Cell Switch-Internal Audio Source

FIG. 6A illustrates a noiseless switchover system for performing cell switching of independent outgoing audio streams generated by an internal audio source in accordance with an embodiment of the present invention. 6A illustrates one embodiment of a system 600A for switching outgoing audio streams from an internal audio source. System 600A includes components of audio processing platform 230 configured for an outgoing audio stream switching mode of operation. Specifically, as shown in FIG. 6A, system 600A includes a call control and audio feature manager 302, a cell switch 304, and a network connected to a number of n internal audio sources 604n. Interface controller 306. The internal audio sources 604a-604n can be two or more audio sources. Any type of audio source can be used including, but not limited to, a DSP. In one example, DSP 480 may be an audio source. To generate audio, audio source 604 may internally generate audio and / or convert audio received from an external source.

Call control and audio feature manager 302 further includes an outgoing audio controller 610. Outgoing audio controller 610 sends control signals to audio source 604n, cell switch 304, and / or network interface controller 306 to perform noiseless switching between independent outgoing audio streams in accordance with the present invention. Export control logic. The control logic may be implemented in software, firmware, microcode, hardware, or any combination thereof.

Cell layers are also provided, including SARs 630, 632, 634. SARs 630 and 632 are connected between cell switch 304 and each audio source 604a-n. SAR 634 is coupled between cell switch 304 and NIC 306.

In one embodiment, the independent outgoing audio stream comprises a stream of IP packets with RTP information and internal outgoing packets. Therefore, it is helpful to first describe the IP packet and the inner outgoing packet (FIGS. 7A-7B). Next, the system 600A and its operation will be described in detail with reference to an independent outgoing audio stream (FIGS. 8-9).

B. Packet

In one embodiment, the present invention uses two types of packets: (1) IP packets with RTP information and (2) inner originating packets. All of these types of packets are shown in the examples of FIGS. 7A and 7B and are described with reference to this. IP packet 700A is transmitted and received via an external packet switched network by packet processor 307 within NIC 306. Internal outgoing packet 700B is generated by an audio source (e.g., DSP) 604a-604n.

1. IP packet with RTP information

A standard specification IP packet 700A is shown in FIG. 7A. IP packet 700A contains various components: MAC (Media Access Control) field 704, IP field 706, UDP (User Datagram Protocol) field 708, RTP field 710, digital data. Is shown having a payload 712, and a cyclic redundancy check (CRC) field 714. RTP (Real Time Transfer Protocol) is a standardized protocol for delivering periodic data, such as digitized audio, from a source device to a destination device. Another protocol, RTCP (Real Time Control Protocol), can be used with RTP to provide information about the quality of the session.

More specifically, the MAC field 704 and the IP field 706 have address designation information that allows each packet to pass through an IP network interconnecting two devices (source and destination).

The UDP field 708 has a 2-byte port number that identifies the RTP / audio stream channel number so that when received from the network interface it can be internally routed to the audio processor destination. In one embodiment of the invention, the audio processor is a DSP as described herein.

The RTP field 710 has a packet sequence number and a timestamp. Payload 712 has digitized audio byte samples and can be decoded by an endpoint audio processor. As will be apparent to those skilled in the art from the description herein, any payload type and encoding scheme may be used for RTP compatible audio and / or video type media. The CRC field 714 provides a way to verify the integrity of the entire packet. D. Collins, Carrier Grade Voice over IP, pp. See the description of RTP packets and payload types described in 52-72 (hereby incorporated by reference in their entirety).

2. Internal Outgoing Packets

7b is a more detailed view of an exemplary internal outgoing packet of the present invention. Packet 700B includes a control (CTRL) header 720 and a payload 722. The advantage of the inner outgoing packet 700B is that it is simpler and smaller in size than the IP packet 700A. This relieves the burden and work required on the audio source and other components that process internal outgoing packets.

In one embodiment, the audio sources 604a-604n are DSPs. Each DSP adds a CTRL header 720 in front of the payload 722 generated for its respective audio stream. CTRL 720 is then used to relay control information downstream. This control information can be, for example, priority information associated with a particular outgoing audio stream.

The packet 700B is converted into one or more cells, such as an ATM cell, and sent internally via a cell switch 304 to the packet processor 307 in the network interface controller 306. After the cell is converted to an inner outgoing packet, the packet processor 307 decodes the inner header CTRL 720 and removes it. The remainder of the IP packet information is added before the payload 722 is transmitted over the IP network as an IP packet 700A. This is advantageous because the processing work in the DSP is reduced. The DSP only needs to add a relatively short control header to the payload. The remaining processing work of adding the information to generate a valid IP packet with RTP header information may be distributed to the packet processor 307.

C. Priority Level

The NIC (network interface controller) 306 processes all internal outgoing packets as well as all outgoing IP packets destined for the external network. Thus, the NIC 306 can make a final dispatch decision for each packet that has come to it based on the contents of each packet. In some embodiments, NIC 306 manages the sending of outgoing IP packets based on priority information. This may include switching over an outgoing IP packet of higher priority to an audio stream and buffering or not sending other audio streams of a lower priority outgoing IP packet.

In one embodiment, the internal audio sources 604a-604n determine the priority level. In another alternative, the NIC 306 may determine the priority for audio received at the NIC 306 from an external source. Any number of priority levels can be used. The priority level distinguishes the relative priority of the audio source and its respective audio stream. The priority level may be based on any criteria selected by the user, including but not limited to, time of day, identifier or group of caller or called party, or other similar factors related to audio processing and media services. Components of system 600 may filter and deliver priority level information in the audio stream. In one embodiment, a resource manager within system 600 may talk to external systems to change the priority level of the audio stream. For example, the external system may be an operator who tells the system to queue a billing notification or advertisement when there is a call. Thus, the resource manager may be involved in the audio stream. This noiseless switchover may be triggered automatically by the user or based on some predetermined event, such as a situation in which the handset is lifted, a signaling situation such as an emergency event or a timed event.

D. Noiseless Fully Mesh Cell Switch

System 600A may be thought of as a "free pool" of multiple input (incoming) and output (outgoing) audio channels, because a full meshed packet / cell switch 304 may be any given This is because it is used to switch outgoing audio channels to join the call. Any outgoing audio channel can be called to join a telephone call at any time. During both initial call setup and while the call is established, any outgoing audio channel can be switched to enter or exit the call. The fully meshed switching function of the system 600A of the present invention provides an accurate noiseless switching function that does not miss or corrupt the IP packet or cell of the present invention. In addition, a two-stage outgoing switching technique is used.

E. Two-Stage Outgoing Switching

System 600A includes at least two stages of switching. In the case of outgoing switching, the first step is the cell switch 304. The first step uses a switched virtual circuit (SVC) to switch the audio stream from separate physical sources (audio sources 604a-604n) to only one destination originating network interface controller (NIC) 306 as cell based. . Priority information is provided in the CTRL header 720 of the cell generated by the audio source. The second step is contained within the originating NIC 306 and thus selects which of the audio streams from multiple audio sources 604a-604n to process and transmit over a packet network, such as a packet switched IP network. The selection of which audio stream to deliver may be performed by the NIC 306 based on the priority information provided in the CTRL header 720. As such, the second audio stream with higher priority may be delivered by the NIC 306 over the same channel as the first audio stream. When viewed at the destination device receiving the audio stream, the insertion of the second audio stream on the channel is taken as a noiseless switch between independent audio streams.

More specifically, in one embodiment, outgoing audio switching may occur on a telephone call. As previously described, the call is first established using the audio source 604a by negotiating with the MAC, IP and UDP information of the destination device. The first audio source 604a starts generating a first audio stream during the call. The first audio stream consists of an internal outgoing packet with audio payload and CTRL header 720 information, as described above with respect to packet format 700B. Internal outgoing packets are sent out over the channel established for that call. Any type of audio payload can be used, including voice, music, tones, or other audio data. SAR 630 converts the inner packet into a cell for transmission to SAR 634 via cell switch 304. SAR 634 then converts the cell back into an internal outgoing packet prior to delivery to NIC 306.

During the flow from the audio source 604a, the NIC 306 decodes and removes the CTRL header 720 and adds the appropriate RTP, UDP, IP, MAC, and CRC fields as described above. CTRL header 720 includes a priority field used by NIC 306 to process the packet and send the corresponding RTP packet. NIC 306 evaluates the priority field. If it is a relatively high priority field (the first audio source 604a is the only transmission source), then the NIC 306 may have an IP with synchronized RTP header information that forwards the first audio stream over the network to the destination device associated with that call. Deliver the packet. [CTRL header 720 may also include other synchronized header information that may be used or ignored by NIC 306 when RTP or NIC 306 generates and appends RTP header information.]

When the outgoing audio controller 610 determines a call event for which no noise switchover will be made, the second audio source 604n begins to generate a second audio stream. Audio may be generated by converting audio originally generated by the audio source 604n directly or by an external device. The second audio stream consists of internal outgoing packets with audio payload and CTRL header 720 information as described with reference to packet format 700B. Any type of audio payload can be used, including voice, music, or other audio data. Assume that the second audio stream is given a higher priority field than the first audio stream. For example, the second audio stream may represent an advertisement, an emergency public service message, or other audio data that is desired to be noise-free inserted into the first channel established with the destination device.

The inner outgoing packet of the second audio stream is then converted into cells by the SAR 632. The cell switch 304 switches the cell to an SVC destined for the same destination NIC 306 as the first audio stream. SAR 634 converts this cell back into an inner packet. The NIC 306 now receives internal packets for the first and second audio streams. The NIC 306 evaluates the priority field in each stream. The second audio stream with the higher priority inner packet is converted into an IP packet with synchronized RTP header information and delivered to the destination device. The first audio stream having lower priority inner packets may be stored in a buffer or converted into IP packets having synchronized RTP header information and stored in the buffer. The NIC 306 may resume delivery of the first audio stream when the second audio stream is complete, after a predetermined time has elapsed, or when a manual or automatic control signal is received to resume.

F. Call Event Triggering Noiseless Switchover

The function of the priority field in one embodiment of noiseless switching according to the present invention will now be described with reference to FIGS. 8, 9A and 9B.

8 is a flow diagram of a noiseless switching routine 800 in accordance with one embodiment of the present invention. For simplicity, the noiseless switching routine 800 is described with reference to the system 600.

Flow 800 begins at step 802 and proceeds directly to step 804.

In step 804, the call control and audio feature manager 302 establishes a call from the first audio source 604a to the destination device. The call control and audio feature manager 302 negotiates with the destination device to determine the MAC, IP and UDP ports to use in the first audio stream of IP packets sent across the network.

Audio source 604a delivers the first audio stream on one channel for the established call. In one embodiment, the DSP delivers a first audio stream of internal outgoing packets to cell switch 304 and then to NIC 306 over one channel. The process proceeds to step 806.

In step 806, the outgoing audio controller 610 sets a priority field for the first audio source. In one embodiment, outgoing audio controller 610 sets the priority field to value1. In another embodiment, the priority field is stored in the CTRL header of internally routed internal outgoing packets. The process proceeds directly to step 808.

In step 808, the outgoing audio controller 610 determines the state of the call. In one embodiment, the outgoing audio controller 610 determines whether or not the call is intended to be configured to interact with the call event. In one embodiment of the present invention, the call may be configured such that only emergency call events interrupt the call. In other embodiments, the call may be configured to receive certain call events based on the caller (s) or callee (s) (ie, one or more of the call parties). The process proceeds directly to step 810.

In step 810, the outgoing audio controller 610 monitors for call events. In one embodiment, call events such as time notifications, weather, advertisements, and billing (“add more coins” or “five minutes left”) may be generated within the system 600. In other embodiments, call events, such as requests for news, sports information, and the like may be sent to the system 600. The outgoing audio controller 610 monitors for call events internally as well as externally. The process immediately proceeds to step 812.

In step 812, the outgoing audio controller 610 receives a call event. If not, the outgoing audio controller 610 continues to monitor as mentioned in step 810. If so, the process immediately proceeds to step 814.

In step 814, the outgoing audio controller 610 determines the call event and performs the operations accompanying the call event. The process then proceeds to step 816 to end or return to step 802. In one embodiment, process 800 is repeated as long as the call continues.

9A-9C, a flow diagram 900 of call event processing for priority based audio stream switching in accordance with one embodiment of the present invention is shown. In one embodiment, flow 900 illustrates in more detail the operation performed at step 814 of FIG.

Process 900 begins at step 902 and proceeds directly to step 904.

In step 904, the outgoing audio controller 610 reads the call event for the established call. In this operation, the first audio stream from the audio source 604a is already being transmitted as part of the call established from the NIC 306. The process proceeds to step 906.

In step 906, the outgoing audio controller 610 determines whether the call event includes a second audio source. If yes, the process proceeds to step 908. If no, the process proceeds to step 930.

In step 908, the outgoing audio controller 610 determines the priority of the second audio source. In one embodiment, the outgoing audio controller 610 sends a command to the second audio source 604n to instruct the second audio source to generate a second audio stream of internal outgoing packets. Priority information for the second audio stream may be generated automatically by the second audio source 604n or based on commands from the outgoing audio controller 610. The process then proceeds to step 910.

At step 910, the second audio source 604n begins to generate a second audio stream. The second audio stream consists of internal outgoing packets with audio payload and CRTL header 720 information as described with respect to packet format 700B. Any type of audio payload can be used, including voice, music or other audio data. An audio payload is meant to include audio data that is broadly included as part of the video data. The process then proceeds to step 912.

In step 912, outgoing packets of the second audio stream are then converted into cells. In one example, the cell is an ATM cell. The process then proceeds to step 914.

At step 914, cell switch 304 switches the cell to an SVC destined for the same destination NIC 306 via the same outgoing channel as the first audio stream. The process then proceeds to step 915.

As shown in step 915 of FIG. 9B, the SAR 634 now receives cells for the first and second audio streams. This cell is in turn converted to a stream of internal outgoing packets and has a control header containing respective priority information for the two audio streams.

At step 916, NIC 306 compares the priorities of these two audio streams. If the second audio stream has a higher priority, the process proceeds to step 918. Otherwise, the process proceeds to step 930.

In step 918, transmission of the first audio stream is suspended. For example, the NIC 306 buffers the first audio stream or even sends a control command to the audio source 604a to suspend transmission of the first audio source. The process immediately proceeds to step 920.

In step 920, transmission of the second audio stream begins. The NIC 306 instructs the packet processor (s) 307 to generate IP packets having an audio payload of internally outgoing packets of the second audio stream. The packet processor (s) 307 adds additional synchronized RTP header information (RTP packet information) and other header information (MAC, IP, UDP fields) to the audio payload of the inner outgoing packet of the second audio stream.

The NIC 306 then sends an IP packet with synchronized RTP header information on the same outgoing channel of the first audio stream. As such, the destination device receives second audio stream noise instead of the first audio stream. In addition, from the point of view of the destination device, this second audio stream is received in real time without noise, without delay or interruption. Steps 918 and 920 may of course be performed simultaneously or in any order. The process immediately proceeds to step 922.

As shown in FIG. 9C, the NIC 306 monitors to see if it is the end of the second audio stream (step 922). The process proceeds directly to step 924.

In step 924, the NIC 306 determines whether the second audio stream is over. In one example, NIC 306 reads the last packet of the second audio stream with a lower priority level than the preceding packet. If so, the process immediately proceeds to step 930. If not, the process proceeds to step 922.

In step 930, the NIC 306 continues to serve the first audio stream (after step 906) or returns to serving the first audio stream (after step 916 or step 924). The process proceeds to step 932.

In one embodiment, NIC 306 maintains a priority level threshold. The NIC 306 then increments and sets its threshold based on the priority information in the audio stream. When the NIC 306 encounters multiple audio streams, it delivers audio streams having priority information that is higher than or equal to its priority level threshold. For example, if the first audio stream has a priority value of 1, the priority level threshold is set to 1 and the first audio stream is transmitted (prior to step 904). If a second audio stream with higher priority is received at NIC 306, NIC 306 increments the priority threshold to two. The second audio stream is then transmitted as described above at step 920. When the last packet of the second audio stream whose priority field value is set to 0 (or null or other special value) is read, the priority level threshold is reduced back to 1 as part of step 924. In this case, the first audio stream with priority information 1 is then transmitted by NIC 306 as described above in connection with step 930.

In step 932, the outgoing audio controller 610 processes any remaining call events. The process then proceeds to step 934 and ends until it is resumed. In one embodiment, the steps of the above-described process take place at about the same time, so that the processes can be executed in parallel or overlapping on one or more processes in system 600.

G. Audio Data Flow

6B is a diagram of the audio data flow 615 in the noiseless switchover system of FIG. 6A in one embodiment. In particular, FIG. 6B illustrates the flow of internal packets from audio sources 604a-n to SARs 630 and 632, the flow of cells through cell switch 304 to SAR 634, SAR 634 and packet processor 307. Internal packet flow), and the IP packet flow from the NIC 306 through the network.

H. Other Examples

The invention is not limited to internal audio sources or cell layers. Noiseless switchover may also be performed in other embodiments that use only internal audio sources, use internal and external audio sources, use external audio sources only, use cell switches, or use packet switches. For example, FIG. 6C illustrates no cell switching between independent outgoing audio streams generated by an internal audio source 604a-n and / or an external audio source (not shown) in accordance with one embodiment of the present invention. A diagram of a noise switch over system 600C is shown. The noiseless switchover system 600C operates similarly to the system 600A described above in detail, except that noiseless switchover is performed on audio received from an external audio source. As shown in Fig. 6C, this audio is received in an IP packet and buffered in the NIC 306. The NIC 306 splits the IP information (stores it in a forward table entry associated with the external audio source and destination device) to generate an internal packet that is assigned to the SVC. The SAR 634 routes an internal packet to a cell and routes it through the switch 304 via the link 662 back to the SAR 634 via the link 662 on the SVC to convert the inner packet into a cell. As mentioned above, the inner packet is then processed by the packet processor 307 to generate an IP packet with synchronized header information. The NIC 306 sends the IP packet to the destination device. As such, the user at the destination device is noiseless switched over to receive audio from an external audio source. FIG. 6D illustrates an audio data flow 625 for an outgoing audio stream received from an external audio source in the noiseless switchover system of FIG. 6C. In detail, FIG. 6D shows the flow of IP packets from an external audio source (not shown) to NIC 306, the flow of internal packets from NIC 306 to SAR 634, and SAR 634 back from cell switch 304. Cell flow to the network, internal packet flow between the SAR 634 and the packet processor 307, and IP packet flow from the NIC 306 to the destination device (not shown).

6E illustrates audio data flow in a noiseless switchover system 600E that performs packet switching between independent outgoing audio streams generated by an internal and / or external audio source in accordance with an embodiment of the present invention. 635 and 645 are shown. The noiseless switch over system 600E operates similarly to the systems 600A and 600C described above in detail except that the packet switch 694 is used instead of the cell switch 304. In this embodiment, the cell layer including the SARs 630, 632, and 634 is omitted. In audio data flow 635, internal packets travel from internal audio source 604a-n to packet processor 307 via packet switch 694. IP packets go out to the network. In audio data flow 645, IP packets from an external audio source (not shown) are received at NIC 306. Audio is received in the form of packets as shown in FIG. 6E and buffered in the NIC 306. The NIC 306 splits the IP information (stores it in a forward table entry associated with the external audio source and destination device) and generates an internal packet that is assigned to the SVC (or other type of path) associated with this destination device. This inner packet is routed through the SVC to the NIC 306 via the packet switch 694. As mentioned above, the inner packet is then processed by the packet processor 307 to generate an IP packet with synchronized header information. The NIC 306 then sends an IP packet to the destination device. As such, the user at the destination device is noiseless switched over to receive audio from an external audio source.

FIG. 6F illustrates a noiseless switchover system 600F for switching between independent outgoing audio streams generated by only an external audio source in accordance with one embodiment of the present invention. No switch or internal audio source is required. The NIC 306 splits the IP information (stores it in a forward table entry associated with the external audio source and destination device) and generates an internal packet that is assigned to the SVC (or other type of path) associated with this destination device. This inner packet is routed to NIC 306 via SVC. [NIC 306 may be a common source and destination point.] As mentioned above, the inner packet is then processed by packet processor 307 to generate an IP packet with synchronized header information. The NIC 306 then sends this IP packet to the destination device. As such, the user at the destination device is noiseless switched over to receive audio from an external audio source.

The functions described above with respect to the operation of the outgoing audio switching system 600 may be implemented in control logic. Such control logic may be implemented in software, firmware, hardware or any combination thereof.

X. Conference Call Processing

A. Distributed Conference Bridge

10 illustrates a distributed conference bridge 1000 in accordance with an embodiment of the present invention. Distributed conference bridge 1000 is coupled to network 1005. The network 1005 may be any type of network or combination of networks, such as the Internet. For example, network 1005 may comprise a packet switched network, or a packet switched network coupled with a circuit switched network. Multiple conference call participants C1-CN may connect to distributed conference bridge 1000 via network 1005. For example, conference call participants C1-CN may send a VoIP call over network 1005 to contact distributed conference bridge 1000. Distributed conference bridge 1000 is scalable and can handle any number of conference call participants. For example, distributed conference bridge 1000 may handle conference calls between two conference call participants and up to 1000 or more conference call participants.

As shown in FIG. 10, distributed conference bridge 1000 includes a conference call agent 1010, a network interface controller (NIC) 1020, a switch 1030, and an audio source 1040. Conference call agent 1010 is coupled to NIC 1020, switch 1030, and audio source 1040. The NIC 1020 is connected between the network 1005 and the switch 1030. The switch 1030 is connected between the NIC 1020 and the audio source 1040. The lookup table 1025 is connected to the NIC 1020. Lookup table 1025 (or a separate lookup table, not shown) may also be coupled to audio source 1040. The switch 1030 includes a multicaster 1050. The NIC 1020 includes a packet processor 1070.

Conference call agent 1010 sets up a conference call for a number of participants. During the conference call, packets carrying audio such as digitized voice travel from the conference call participants C1-CN to the conference bridge 1000. These packets may be, but are not limited to, IP packets including RTP / RTCP packets. The NIC 1020 receives the packet and delivers the packet along the link 1028 to the switch 1030. Link 1028 may be any type of logical link and / or physical link, such as PVC or SVC. In one embodiment, NIC 1020 converts the IP packet (as described above with reference to FIG. 7A) into an inner packet having only a header and payload (as described above with reference to FIG. 7B). The use of inner packets further reduces processing at the audio source 1040. Incoming packets processed by the NIC 1020 may also be combined by the SAR into cells such as ATM cells and sent to the switch 1030 over the link 1028. The switch 1030 forwards the incoming packet (or cell) from the NIC 1020 to the link 1035 audio source 1040. The link 1035 may also be, but is not limited to, any type of logical link and / or physical link, including PVC or SVC.

Audio provided via link 1035 is referred to as " external audio " in connection with this conference bridge processing because it is from the conference call participant over network 1005. Audio may also be provided internally through one or more links 1036 as shown in FIG. 10. Such "internal audio" may be voice, music, advertisements, news, or other audio content that is mixed in a conference call. Internal audio may be provided by any audio source or accessed from a storage device connected to the conference bridge 1000.

Audio source 1040 mixes the audio for the conference call. The audio source 1040 generates an outbound packet that contains the mixed audio and sends the packet to the switch 1030 over the link 1045. In detail, the audio source 1040 produces a fully mixed audio packet stream and a set of partially mixed audio streams. In one embodiment, the audio source 1040 (or mixer, because it is mixing audio) is partially mixed with a suitable fully mixed audio packet stream with conference identification information (CID) and mixed audio during the conference call. Dynamically generated audio packet streams. The audio source retrieves the corresponding CID information of the conference call participant from a relatively static lookup table (e.g., table 1025 or a separate table closer to the audio source 1040) created and stored at the beginning of the conference call. do.

Multicaster 1050 multicasts the packets within the fully mixed audio stream and the set of partially mixed audio streams. In one embodiment, multicaster 1050 replicates the packets in each of the fully mixed audio streams and the set of partially mixed audio streams N times corresponding to N conference call participants. These N replicated packets are then passed through each of the N switched virtual circuits (SVC1-SVCN) to the endpoint at NIC 1020. One advantage of the distributed conference bridge 1000 is that it reduces the duplication of the audio source 1040 (ie the mixing device). This replication job is distributed to multicaster 1050 and switch 1030.

The NIC 1020 then processes the outbound packets that arrive at each SVC1-SVCN to determine whether to deliver or discard the packets of the fully mixed audio and the partially mixed audio stream to the conference call participants C1-CN. This determination is made in real time based on packet header information during the conference call. For each packet arriving at the SVC, the NIC 1020 determines whether the packet is suitable for transmission to the participant associated with the SVC based on packet header information such as the TAS and IAS fields. If appropriate, the packet is delivered for further packet processing. This packet is processed into a network packet and delivered to its participants. Otherwise, this packet is discarded. In one embodiment, the network packet includes a lookup table 1025, network address information (IP / UDP address) and audio data of the destination call participant obtained from the RTP / RTCP packet header information (time stamp / order information). IP packet. This audio data is mixed audio data appropriate for a particular conference call participant. Operation of the distributed conference bridge 100 is described below with reference to the typical lookup table 1025 shown in FIG. 11, 12 and 13A-13C, and the typical packet diagrams shown in FIGS. 14A, 14B and 15. More on this.

B. Distributed Conference Bridge Behavior

12 shows a routine 1200 (steps 1200 to 1280) for setting up conference bridge processing of the present invention. At step 1220, a conference call is initiated. A number of conference call participants C1-CN call the distributed conference bridge 1000. Each participant may use any VoIP terminal, including, but not limited to, telephones, computers, PDAs, set-top boxes, network appliances, and the like. The conference call agent 1010 performs conventional IVR processing to obtain the network address of each conference call participant to indicate that the conference call participant wants to join the conference call. For example, the network address information may include IP and / or UDP address information, but is not limited thereto.

At step 1240, lookup table 1025 is generated. The conference call agent 1010 may generate a lookup table or instruct the NIC 1020 to generate a lookup table. As shown in the example of FIG. 11, lookup table 1025 includes N entries corresponding to N conference call participants in the conference call initiated at step 1220. Each entry in lookup table 1025 includes an SVC identifier, conference ID (CID), and network address information. An SVC identifier is any number or tag that identifies a particular SVC. In one example, the SVC identifier is a Virtual Path Identifier / Virtual Channel Identifier (VPI / VCI). Instead, the SVC identifier or tag information may be omitted from the lookup table 1025 and may instead be implicitly related to the position of an entry in that table. For example, the first SVC may be associated with the first entry in the table, and the second SVC may be associated with the second entry in the table, and so on. The CID is any number or tag assigned by the conference call agent 1010 to the conference call participants C1-CN. The network address information is network address information collected by the conference call agent 1010 for each of N conference call participants.

At step 1260, the NIC 1020 assigns each SVC to each participant. For N conference call participants, N SVCs are allocated. The conference call agent 1010 instructs the NIC 1020 to allocate N SVCs. The NIC 1020 then establishes N SVC connections between the NIC 1020 and the switch 1030. At step 1280, the conference call begins. The conference call agent 1010 sends a signal to the NIC 1020, the switch 1030 and the audio source 1040 to begin the conference call processing. 12 is described with respect to SVCs and SVC identifiers, the present invention is not limited thereto, and any type of link (physical link and / or logical link) and link identifier may be used. Also, in embodiments where an internal audio source is included, the conference call agent 1010 adds the internal audio source as one of the potential N audio participants, whose inputs are mixed at the audio source 1040.

The operation of distributed conference bridge 1000 during conference call processing is illustrated in FIGS. 13A-13C (steps 1300-1398). Control begins at step 1300 and proceeds to step 1310. In step 1310, the audio source 1040 monitors the energy of the incoming audio stream of the conference call participants C1 -CN. The audio source 1040 may be any type of audio source, including but not limited to a digital signal processor (DSP). Any conventional technique for monitoring the energy of digitized audio samples can be used. In step 1320, the audio source 1040 determines the number of active speakers based on the energy monitored in step 1310. Any number of active speakers can be selected. In one embodiment, the conference call is limited to three active speakers at a given time. In this case, up to three active speakers corresponding to up to three audio streams with the most energy during the monitoring in step 1320 are determined.

The audio source 1040 then generates and transmits a fully mixed audio stream and a partially mixed audio stream (steps 1330 through 1360). In step 1330, one fully mixed audio stream is generated. The fully mixed audio stream includes the audio content of the active speaker determined in step 1320. In one embodiment, the fully mixed audio stream is an audio stream of packets with a packet header and payload. The packet header information identifies the active speaker whose audio content is contained in the mixed audio stream. In one example, as shown in FIG. 14A, the audio source 1040 generates a packet header 1401 having a TAS, IAS, and order fields, and an outbound inner packet 1400 having a payload 1403. The TAS field lists the CIDs of all current active speakers in the conference call. The IAS field lists the active speaker's CID whose audio content is in the mixed stream. The order information may be a time stamp, numerical order value, or other type of order information. Other fields (not shown) may include checksums or other packet information, depending on the particular application. In the case of a fully mixed audio stream, the TAS field and the IAS field are the same. Payload 1403 includes a portion of digitized mixed audio in a fully mixed audio stream.

In step 1340, the audio source 1040 transmits the fully mixed audio stream generated in step 1330 to the switch 1030. Eventually, the passive participant in the conference call (i.e., the participant not included in the number of active speakers determined in step 1320) will all hear the mixed audio from the mixed audio stream.

In step 1350, the audio source 1040 generates a set of partially mixed audio streams. This set of partially mixed audio streams is then sent to a switch 1030 (step 1360). Each of the partially mixed audio streams generated at step 1350 and sent at step 1360 includes subtracting the audio content of each receiving active speaker from the mixed audio content of the group of identified active speakers determined at step 1320. The receiving active speaker is an active speaker belonging to the group of active speakers determined in step 1320, to which the partially mixed audio stream is directed.

In one embodiment, the audio source 1040 inserts the audio content of the receiving active speaker subtracted from the digital audio from the group of active speakers identified in the packet payload. As such, the receiving active speaker does not receive audio corresponding to his or her voice or audio input. However, the receiving active speaker hears the voice or audio input of another active speaker. In one embodiment, the packet header information is included in each partially mixed audio stream to identify the active speaker whose audio content is included in each partially mixed audio stream. In one example, the audio source 1040 uses the packet format of FIG. 14A and inserts one or more CIDs into the TAS and IAS fields of the packet. The TAS field lists the CIDs of all current active speakers in the conference call. The IAS field lists the active speaker's CID whose audio content is in each partially mixed stream. For partially mixed audio streams, the TAS and IAS fields are not the same because the IAS field has one less CID. In one example, to create a packet at steps 1330 and 1350, the audio source 1040 is a relatively static lookup table (e.g., table 1025 or separate table) created and stored at the beginning of the conference call. Retrieves the corresponding CID information of the conference call participant.

For example, in a conference call where there are 64 participants (N = 64), three of which are identified as active speakers (1-3), one fully mixed audio stream includes audio from all three active speakers. do. This fully mixed stream is ultimately sent to each of the 61 passive participants. Three partially mixed audio streams are then generated in step 1350. The first partially mixed stream 1 contains audio from speakers 2-3 but no speaker 1 audio. The second partially mixed stream 2 includes audio from speakers 1-3 but does not include audio from speaker 2. The third partially mixed stream 3 contains audio from speakers 1-2 but does not contain audio from speaker 3. The first to third partially mixed audio streams are ultimately sent to speakers 1-3 respectively. As such, only four mixed audios (one fully mixed audio and three partially mixed audio) need be produced by the audio source. This saves the work of the audio source 1040.

As shown in FIG. 13B, in step 1370, the multicaster 1050 duplicates the fully mixed audio stream and a set of partially mixed audio streams to assign the duplicated packet copy to the SVC (SVC1-SVCN) assigned to the conference call. ) Multicast through all The NIC 1020 then processes each packet received via the SVC (step 1380). For simplicity, each packet processed internally in distributed conference bridge 1000 (including packets received in SVC by NIC 1020) is referred to as an inner packet. The inner packet may be any type of packet format including an IP packet and / or the inner outgoing packet described above in FIGS. 7A and 7B and the typical inner outgoing packet described above with reference to FIG. 14A, i.e., the inner outbound packet. It is not limited to this.

For each SVC, the NIC 1020 determines whether to deliver or discard the received internal packet to the corresponding conference cone participant for further packet processing and ultimate transmission (step 1381). The received inner packet may be from a fully mixed audio stream or a partially mixed audio stream. If so, the packet is delivered and control then proceeds to step 1390. If not, the packet is not delivered and control proceeds to step 1380 to process the next packet. At step 1390, the packet is processed into a network IP packet. In one embodiment, the packet processor 1070 generates a packet header having at least the participant's network address information (IP and / or UDP address) obtained from the lookup table 1025. The packet processor 1070 also adds order information, such as RTP / RTCP packet header information (eg, time stamps and / or other types of order information). Packet processor 1070 is based on the order of received packets and / or order information (eg, order fields) provided in packets generated by audio source 1040 (or by multicaster 1050). Such order information can be generated. The packet processor 1070 also adds in each network packet a payload containing audio from the received internal packet being delivered to the participant. The NIC 1020 (or packet processor 1070) then sends the generated IP packet to the participant (step 1395).

One feature of the present invention is that the packet processing decision in step 1381 can be performed quickly and in real time during the conference call. 13C shows an exemplary routine (steps 1382 through 1389) for performing a packet processing decision step 1381 according to the present invention. This routine is performed for each outbound packet arriving over each SVC. The NIC 1020 acts as a filter or selector in determining which packet to discard and which packet to convert to an IP packet to send to the call participant.

When the inner packet arrives through the SVC, the NIC 1020 retrieves an entry corresponding to the particular SVC from the lookup table 1025 to obtain a CID value (step 1382). The NIC 1020 then determines whether the obtained CID value matches any CID value in the TAS field of the inner packet (step 1383). If so, then control proceeds to step 1384. If there is a mismatch, control proceeds to step 1386. In step 1384, the NIC 1020 determines whether the obtained CID value matches any CID value in the IAS field of the inner packet. If so, then control passes to step 1385. If there is no match, control proceeds to step 1387. In step 1385, the packet is discarded. Control then proceeds to step 1389 and returns to step 1380 to process the next packet. In step 1387, control jumps to step 1390 to generate an IP packet from an inner packet.

In step 1386, a comparison of the TAS field and the IAS field is made. If this field is the same (as in the case of fully mixed audio stream packets), control proceeds to step 1387. In step 1387, control jumps to step 1390. If the TAS and IAS fields are not the same, control proceeds to step 1385 and the packet is discarded.

C. Outbound Packet Flow Through Distributed Conference Bridge

Outbound packet flow at distributed conference bridge 1000 is further described with reference to typical packets in the 64 conference calls shown in FIGS. 14 and 15. In Figures 14 and 15, the mixed audio content in the packet payload is indicated in parentheses surrounding each participant whose audio is being mixed (e.g. {C1, C2, C3}). The CID information in the packet header is indicated by underlining each active speaker participant (eg, Etc). The sequence number is simply indicated by sequence numbers 0, 1 and the like.

In this example, there are 64 participants (C1-C64) in the conference call, three of which are identified as active speakers at a given time (C1-C3). The audio participants C4-C64 are considered passive participants and their audio is not mixed. Audio source 1040 produces one fully mixed audio stream FM with audio from all three active speakers C1-C3. 14B shows two typical inner packets 1402, 1404 generated by the audio source 1040 during this conference call. Packets 1402 and 1404 in the stream FM have a packet header and payload. The payloads in packets 1402 and 1404 each contain mixed audio from each of three active speakers C1-C3. Packets 1402 and 1404 include packet headers having TAS and IAS fields, respectively. The TAS field contains the CIDs for all three active speakers (C1-C3). The IAS field contains the CID for the active speaker C1-C3 whose content is actually mixed in the payload of the packet. Packets 1402 and 1404 also further include order information 0 and 1, respectively, to indicate that packet 1402 precedes packet 1404. The mixed audio from the fully mixed stream FM is ultimately sent to each of the 61 current passive participants C4-C64.

Three partially mixed audio streams PM1-PM3 are generated by the audio source 1040. FIG. 14B shows two packets 1412, 1414 of the first partially mixed stream PM1. Payloads in packets 1412 and 1414 contain mixed audio from speakers C2 and C3, but not mixed audio from speaker C1. Packets 1412 and 1414 each include a packet header. The TAS field contains CIDs for all three active speakers (C1-C3). The IAS field contains the CIDs for two active speakers (C2, C3) whose contents are actually mixed in the payload of the packet. Packets 1412 and 1414 have order information 0 and 1, respectively, to indicate that packet 1412 precedes packet 1414. FIG. 14B shows two packets 1422 and 1424 of the second partially mixed stream PM2. The payloads in packets 1422 and 1424 include mixed audio from speakers C1 and C3, but not mixed audio from speaker C2. Packets 1422 and 1424 each include a packet header. The TAS field contains CIDs for all three active speakers (C1-C3). The IAS field contains the CIDs for the two active speakers C1 and C3 whose contents are actually mixed in the payload of the packet. Packets 1422 and 1424 have order information 0 and 1, respectively, to indicate that packet 1422 precedes packet 1424. 14C shows two packets 1432, 1434 of the third partially mixed stream PM3. Payloads in packets 1432 and 1434 include mixed audio from speakers C1 and C2, but not mixed audio from speaker C3. Packets 1432 and 1434 each include a packet header. The TAS field contains CIDs for all three active speakers (C1-C3). The IAS field contains the CIDs for two active speakers (C1, C2) whose contents are actually mixed in the payload of the packet. Packets 1432 and 1434 have order information 0 and 1, respectively, to indicate that packet 1432 precedes packet 1434.

15 is a diagram illustrating typical packet contents after the packets of FIG. 14 to be transmitted to the appropriate conference call participant in accordance with the present invention are multicast and processed into an IP packet. In detail, packets 1412, 1422, 1432, 1402, and 1414 are shown as multicasting through SVC1-SVC64 to reach NIC 1020, respectively. As discussed above in connection with step 1381, the NIC 1020 is responsible for which of the packets 1412, 1422, 1432, 1402, 1414 are forwarded to their respective conference call participants C1-C64 for each SVC1-SVC64. Determine if appropriate. Network packets (eg, IP packets) are then generated by the packet processor 1070 and sent to respective conference call participants C1-C64.

As shown in FIG. 15, in the case of SVC1, it is determined that packets 1412 and 1414 are delivered to C1 based on the packet header thereof. Packets 1412 and 1414 have a CID of C1 in the TAS field but no in the IAS field. Packets 1412 and 1414 are converted into network packets 1512 and 1514. Network packets 1512 and 1514 have mixed audio from speaker C2 and C3 with IP address C1ADDR of C1 but no mixed audio from speaker C1. Packets 1512 and 1514 have order information 0 and 1, respectively, to indicate that packet 1512 precedes packet 1514. For SVC2 (corresponding to conference call participant C2), it is determined that packet 1422 is delivered to C2. Packet 1422 has a CID of C2 in the TAS field but not in the LAS field. Packet 1422 is converted into network packet 1522. Network packet 1522 includes C2's IP address (C2ADDR), order information 0 and mixed audio from speakers C1 and C3 but no mixed audio from speaker C2. For SVC3 (corresponding to conference call participant C3), it is determined that packet 1432 is delivered to C3. Packet 1432 has a CID of C3 in the TAS field but not in the LAS field. The packet 1432 is converted into a network packet 1532. Network packet 1532 includes C3's IP address C3ADDR, order information 0 and mixed audio from speakers C1 and C2 but no mixed audio from speaker C3. For SVC4 (corresponding to conference call participant C4), it is determined that packet 1402 is delivered to C4. The packet 1402 does not have a CID of C4 in the TAS field, and the TAS and LAS fields are the same to represent a completely mixed stream. Packet 1402 is converted into network packet 1502. Network packet 1502 includes IP address C4ADDR, order information 0 of C4, and mixed audio from speakers C1, C2, C3. Each of the other passive participants C5-C64 receive similar packets. For example, for SVC64 (corresponding to conference call participant C64), packet 1402 is determined to be delivered at C64. Packet 1402 is converted into network packet 1503. Network packet 1503 includes mixed audio from C64's IP address C64ADDR, order information 0, and active speakers C1, C2, C3.

D. Control Logic and Additional Embodiments

The functions described above with respect to the operation of conference bridge 1000 (including conference call agent 1010, NIC 1020, switch 1030, audio source 1040, and multicaster 1050) are implemented in control logic. Can be. Such control logic may be implemented in software, firmware, hardware or any combination thereof.

In one embodiment, distributed conference bridge 1000 is implemented in a media server such as media server 202. In one embodiment, distributed conference bridge 1000 is implemented in audio processing platform 230. Conference call agent 1010 is part of call control and audio feature manager 302. The NIC 306 performs the network interface function of the NIC 1020, and the packet processor 307 performs the function of the packet processor 1070. Switch 304 is replaced by switch 1030 and multicaster 1050. Any of the audio sources 308 can perform the function of the audio source 1040.

XI. conclusion

While specific embodiments of the invention have been described above, it should be understood that they are presented by way of example only, and not limitation. Those skilled in the art will recognize that various changes may be made in form and detail without departing from the spirit and scope of the invention as defined in the appended claims. Accordingly, the scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims (76)

A media platform that provides media services over a network. A resource manager for managing a resource used to support the media service, and An audio processing platform that manages the call and the media services provided by this call, The audio processing platform, A network interface having a set of packet processors for processing packets of audio data entering and leaving the media platform in the call being processed; A set of audio processors for processing the audio data in accordance with the media service provided in the call, and And a switch for switching packets of audio data transmitted between the audio processor and the packet processor. The media platform of claim 1, wherein the audio processing platform further comprises a call control and audio feature manager that controls media services and resources provided in the call processed by the audio processor. The method of claim 2, wherein the call control and audio feature manager, Call signaling manager, system administrator, Connection manager, and And a feature controller. 3. The media platform of claim 2, wherein the audio processing platform comprises a shelf controller card. The method of claim 1, further comprising a set of ports connected to the network, Wherein said network interface further comprises a respective controller and forwarding information table for each packet processor. The media platform of claim 1, wherein the switch comprises a packet switch. The media platform of claim 1, further comprising a cell layer that combines the packets of audio data into cells of audio, wherein the switch is a cell switch that switches the cells. The media platform of claim 1, wherein each audio processor comprises a digital signal processor. The media platform of claim 1, wherein each audio processor comprises a plurality of card processors coupled to a plurality of digital signal processors. The media platform of claim 1, wherein for at least one incoming audio stream, each packet processor receives an IP packet having RTP information from the network and converts the IP packet into an internal packet having a payload and a header. . The media platform of claim 10, wherein each audio processor processes internal packets. The media platform of claim 1, wherein for an outgoing audio stream, each packet processor receives an internal packet and generates an IP packet having RTP information to be transmitted over the network. A media platform that provides media services over a network. Means for managing a resource used to support the media service, and Interface means including means for processing packets of audio data entering and leaving the media platform in a call being processed as interface means for interfacing with a network, Means for processing the audio data in accordance with the media service provided in the call, and Means for switching a packet of audio data transmitted between the audio processor and a packet processor. A scalable audio processing platform for managing VoIP calls and media services provided by the calls, A network interface having a set of packet processors for processing packets of audio data entering and leaving the platform in the call being processed; A set of audio processors for processing the audio data in accordance with the media service provided in the call, and And a switch coupled between the network interface and the set of audio processors to switch packets of audio data. As a method of providing media services over a network, Managing resources used to support at least one media service provided in the VoIP call, Processing IP packets of audio data in the incoming and outgoing audio streams in the call, converting IP packets into internal packets in the incoming audio stream and converting internal packets into IP packets in the outgoing audio stream. An IP packet processing step, Switching the inner packet of audio data in an incoming audio stream and an outgoing audio stream in the call being processed, and Processing the inner packet of audio data in an incoming audio stream and an outgoing audio stream to provide at least one media service in the call. A method of handling audio in conference calls between participants, (a) generating a fully mixed audio packet stream (each packet having a packet header and a payload), (b) generating a set of partially mixed audio packet streams, each packet having a packet header and a payload, (c) multicasting each packet in the fully mixed audio stream and the set of partially mixed audio streams, and (d) determining which of the multicast packets are to be delivered based on packet header information in the respective packet. The method of claim 16, wherein prior to steps (a) and (b), Initiating the conference call between the participants, and Storing conference identifier information (CID) and network address information associated with each participant in the disclosed conference call. 18. The method of claim 17, further comprising assigning a switched virtual circuit (SVC) to respective participants in the conference call, And the storing step further comprises storing the CID and network address information so that the CID and network address information for each participant can be retrieved based on their assigned SVC. 17. The method of claim 16, further comprising: monitoring energy of the inbound audio streams of the participants, and Determining the number of active speakers based on the monitored energy. 20. The method of claim 19, wherein the generating steps (a) and (b) generate a packet header based on the determined number of active speakers, and the determining step (d) comprises the active speaker information in the respective packet header. And determining which of the multicast packets are to be delivered to the participants based on the method. 21. The method of claim 20, wherein the active speaker information comprises a TAS and IAS field, and wherein the generating step (a) generates a fully mixed audio packet stream having a packet header comprising the TAS and IAS fields. (b) generates a set of partially mixed audio packet streams having packet headers comprising TAS and IAS fields. 22. The conference call of claim 21 wherein the determining step (d) determines which of the multicast packets are to be delivered to participants based on information in the TAS and IAS fields in the respective packet header. How to handle audio in. The method of claim 21, wherein the determining step (d) is for each packet being processed in the SVC. Obtaining a CID value for the SVC, and Determining whether the obtained CID value matches any CID value in the TAS field of the packet, and if so, determining whether the obtained CID value matches any CID value in the IAS field of the packet. And determining that the packet is discarded when a value matches any CID value in the TAS field and the obtained CID value matches any CID value in the ISA field. Way. 24. The method of claim 23, wherein when the obtained CID value does not match any CID value in the TAS field of the packet, the packet is converted into a network packet when the compared fields are equal by comparing the TAS field and the ISA field. And a comparing step in which the packet may be discarded when the compared fields are not equal. The method of claim 21, wherein the packet header further comprises sequence information, The generating step (c) generates a fully mixed audio packet stream having a packet header including the sequence information, And said generating step (d) generates a set of partially mixed audio packet streams having a packet header comprising said sequence information. 17. The method of claim 16, wherein the generating step (a) generates a fully mixed audio packet stream, each packet having a packet header and a payload, wherein the payload includes mixed audio from at least three active speakers. and, The generating step (b) generates a set of partially mixed audio packet streams, each packet having a packet header and a payload, and for each partially mixed audio packet stream the payload is from at least three active speakers. Subtracting the audio of each receiving active speaker from the mixed audio of < RTI ID = 0.0 > 17. The method of claim 16, further comprising: processing the packet determined to be delivered in the determining step (d) to produce a network packet having the network address of the participants of the conference call, and Sending the network packet to the participants. 17. The method of claim 16, further comprising mixing audio received over a network from participants of the conference call that is an active speaker. 17. The method of claim 16, further comprising mixing audio received from an internal audio source with audio received over a network from participants of the conference call that is an active speaker. A conference bridge that handles audio in conference calls between participants. An audio source that produces a fully mixed audio packet stream and a set of partially mixed audio packet streams, each packet having a packet header and payload, Switch, and A network interface controller, The switch is connected between the network interface controller and the audio source, The switch further comprises a multicaster, The multicaster multicasts each packet of the fully mixed audio stream and the set of partially mixed audio streams to the network interface controller, And the network interface controller determines which of the multicast packets is to be delivered based on packet header information in the respective packet. 31. The conference bridge of claim 30 further comprising a conference call agent initiating a conference call between the participants. 32. The conference bridge of claim 31 further comprising a storage device for storing conference identifier information (CID) and network address information associated with each participant of the established conference call. 33. The conference bridge of claim 32 wherein the storage device comprises a lookup table. 33. The system of claim 32, wherein the network interface controller assigns a switched virtual circuit (SVC) to respective participants of the initiated conference call, And the storage device stores the CID and network address information so that the CID and network address information for each participant can be retrieved based on their assigned SVC. 31. The conference bridge of claim 30 wherein the audio source monitors the energy of the participants' inbound audio stream and determines the number of active speakers based on the monitored energy. 36. The apparatus of claim 35, wherein the packet header generated by the audio source has active speaker information based on the determined number of active speakers, The network interface controller determining which of the multicast packets are to be delivered to participants based on the active speaker information in the respective packet header. 37. The method of claim 36, wherein the active speaker information includes a TAS field and an IAS field. Wherein the network interface controller determines which of the multicast packets are to be delivered to participants based on the information in the TAS field and the IAS field in the respective packet header. 38. The conference bridge of claim 37 wherein the packet header generated by the audio source further includes sequence information. 31. The system of claim 30, wherein the fully mixed audio packet stream has a payload comprising mixed audio from at least three active speakers, Wherein each stream in the set of partially mixed audio packet streams has a payload comprising subtracting audio from a respective receiving side active speaker from mixed audio from the at least three active speakers. 33. The conference bridge of claim 30 further comprising a packet processor for processing the packets determined to be delivered to a network packet having network addresses of participants of the conference call. 31. The conference bridge of claim 30 wherein the audio source mixes audio received over a network from participants in the conference call that is an active speaker. 31. The conference bridge of claim 30 wherein the audio source mixes audio received from an internal audio source with audio received over a network from participants in the conference call that is an active speaker. A system for processing audio in conference calls between participants, (a) means for generating a fully mixed audio packet stream (each packet having a packet header and a payload), (b) means for generating a set of partially mixed audio packet streams, each packet having a packet header and a payload, (c) means for multicasting each packet in the fully mixed audio stream and the set of partially mixed audio streams, and (d) means for determining which of the multicast packets are to be delivered based on packet header information in the respective packet. As a media server for use in a VoIP network, A distributed conference bridge that processes audio in conference calls between participants, the distributed conference bridge comprising: An audio source that produces a fully mixed audio packet stream and a set of partially mixed audio packet streams, each packet having a packet header and payload, Switch, and A network interface controller, The switch is connected between the network interface controller and the audio source, The switch further comprises a multicaster, The multicaster multicasts each packet in the fully mixed audio stream and the set of partially mixed audio streams to the network interface controller, And the network interface controller determines which of the multicast packets is to be delivered based on packet header information in the respective packets. A method of noiselessly switching audio provided over a network through an outgoing audio channel, (a) generating a first audio stream of outgoing packets for the outgoing audio channel, each outgoing packet comprising a payload carrying audio and control header information; (b) switching and delivering the first audio stream to a first network interface controller associated with the outgoing audio channel, (c) generating a second audio stream of outgoing packets, each outgoing packet comprising a payload carrying audio and control header information; (d) switching and forwarding the second audio stream to a first network interface controller associated with the outgoing audio channel, and (e) based on priority information in control header information of the outgoing packet to determine which of the first and second audio streams is a higher priority audio stream to be transmitted over the network via the outgoing audio channel. Estimating the relative priority of the first and second audio streams. 46. The method of claim 45, further comprising: packetizing the higher priority audio stream to produce an output outgoing audio stream of packets with synchronized header information, and Transmitting said output outgoing audio packet stream over said outgoing audio channel over said network. 46. The method of claim 45, further comprising packetizing a lower priority audio stream to produce an output outgoing audio stream of packets having synchronized header information, whereby the synchronized header information is generated. And noiselessly preserved in an IP packet transmitted across the network via the outgoing audio channel for both audio from both a first and a second audio stream. 46. The method of claim 45, further comprising: converting the first audio stream of outgoing packets into a first cell, and Converting the second audio stream of outgoing packets into a second cell, The switching step (b) comprises switching the converted first cell to an SVC associated with the outgoing audio channel, And said switching step (d) comprises switching said converted second cell to an SVC associated with said outgoing audio channel. 47. The method of claim 46, wherein the synchronized header information includes valid RTP information. 46. The method of claim 45, further comprising: (f) prior to transmitting an IP packet having audio payloads of the respective first and second audio streams over the outgoing audio channel over the network. Determining the synchronized RTP header information for each. A method for noiselessly switching audio from a second audio source to an outgoing audio channel that is already carrying audio from a first audio source. Generating an audio stream of outgoing packets at the second audio source, Converting the audio stream of outgoing packets into cells, Switching the converted cells to a switched virtual circuit (SVC) associated with the outgoing audio channel, Converting the switched cells back into the audio stream of outgoing packets; Packetizing the audio stream to produce an output outgoing audio stream of packets with synchronized header information, and And transmitting said output outgoing audio packet stream over a network over said outgoing audio channel in place of the audio from said first audio source. 53. The method of claim 51, wherein the generating step generates an audio stream of outgoing packets at the second audio source in response to a call event. 53. The method of claim 51, wherein the generating step generates an audio stream of outgoing packets at the second audio source in response to a call event, wherein the audio stream of outgoing packets is at least one of voice, music, tone, or sound. Noiseless switching method comprising one type of audio selected from one. 54. The method of claim 53, further comprising generating the call event based on at least one of the following situations: an emergency, a call signaling situation, a call event based on caller or callee information, or a request for audio information. Noiseless switching method. 54. The method of claim 53, further comprising generating the call event based on a request for audio information, wherein the request for audio information includes at least one of a request for advertising, news, sports, finance, music, or other audio content. Noise-free switching method comprising. A method of introducing noiseless switchover audio for VoIP phone calls, Establishing a VoIP phone call between the destination device and the media server, Setting priority information for the first audio source, Delivering a first audio stream of outgoing packets including the set priority information; Determining a call state with respect to the availability of reception of noiseless switchover audio, and And processing a call event including noiseless switchover audio when the set VoIP telephone call indicates that the set VoIP telephone call is a candidate for reception of noiseless switchover audio. The method of claim 56, wherein the processing step comprises: Determining priority information for the noiseless switchover audio, and When the determined priority information for the noiseless switchover audio is higher than the set priority information of the first audio stream, the noiseless switchover audio is output to the output audio packet stream in the set VoIP telephone call. Noise-free switch over audio inflow method. 58. The method of claim 57, further comprising: generating a second audio stream of outgoing packets at a second audio source, the audio stream having the noiseless switchover audio in a payload; Converting a second audio stream of the outgoing packets into cells, Switching the converted cells to an SVC associated with an outgoing audio channel of the established VoIP telephone call; Converting the switched cells back to a second audio stream of the outgoing packets; Packetizing the second audio stream with synchronized header information to generate the output audio packet stream in the established VoIP telephone call, and Transmitting the output audio packet stream over a network over the outgoing audio channel in the established VoIP telephone call instead of the audio from the first audio source. A system for noiseless switching of audio provided over a network through an outgoing audio channel, First and second audio sources, A switch connected to the first and second audio sources, and A network interface controller coupled to the switch, The first audio source generates a first audio stream of outgoing packets for the outgoing audio channel, each outgoing packet comprising a payload carrying audio and control header information, The second audio source generates a second audio stream of outgoing packets, each outgoing packet including a payload that carries audio and control header information, and the switch replaces the first and second audio streams. Noiseless switching system for switching to the network interface controller for transmission. 60. The system of claim 59, further comprising an outgoing audio controller coupled to the second audio source, And the outgoing audio controller sends a control signal to the second audio source to initiate generation of the second audio stream. 61. The apparatus of claim 60, wherein the outgoing audio controller is also connected to the first audio source, the switch and the network interface controller. The outgoing audio controller sends a control signal to the first audio source to initiate generation of the first audio stream when a VoIP telephone call is established, and transmits a control signal to the switch so that the network interface controller sets the VoIP. And identify that it is associated with an outgoing audio output channel associated with a telephone call, and transmit a control signal to the network interface controller associated with an outgoing audio output channel associated with the established VoIP telephone call. 62. The system of claim 61 wherein the outgoing audio controller is also connected to the first audio source, And the outgoing audio controller sends a control signal to the first and second audio sources to set priority information in the first and second audio streams. 60. The system of claim 59, further comprising at least one packet processor for generating an IP packet having synchronized header information and audio payload, And the audio payload comprises an audio payload carried in the first and second audio streams. 64. The apparatus of claim 63, wherein the network interface controller dynamically selects which of the IP packets to send based on the relative priority of the first and second audio streams. And the switch comprises a packet switch or a cell switch. 60. The noiseless switching system of claim 59, wherein at least one of the first audio source and the second audio source internally generates the audio for the respective first and second audio streams. 60. The method of claim 59, wherein at least one of the first audio source and the second audio source converts audio from an external source to produce the audio for the respective first and second audio streams. Noise switching system. A system for noiseless switching of audio from a second audio source to an outgoing audio channel that is already carrying audio from a first audio source. Means for generating an audio stream of outgoing packets at the second audio source, Means for converting an audio stream of the outgoing packets into cells; Means for switching the converted cells to an SVC associated with the outgoing audio channel; Means for converting the switched cells back to an audio stream of the outgoing packets; Means for packetizing the audio stream to produce an output outgoing audio packet stream, and Means for transmitting the output outgoing audio packet stream over a network over the outgoing audio channel instead of the audio from the first audio source. A system for introducing noiseless switchover audio for VoIP phone calls. Means for establishing a VoIP phone call between the destination device and the media server, Means for setting priority information for the first audio source, Means for delivering a first audio stream of outgoing packets containing the set priority information; Means for determining a call state with respect to the availability of reception of noiseless switchover audio, and And processing a call event including noiseless switchover audio when the set VoIP state call indicates that the set VoIP telephone call is a candidate for reception of noiseless switchover audio. The method of claim 68, wherein the processing means, Means for determining priority information for the noiseless switchover audio, and Outputting the noiseless switchover audio with synchronized header information in the set VoIP telephone call when the determined priority information for the switch over audio is higher than the set priority information of the first audio stream. And a means for transmitting in an audio packet stream. 70. The apparatus of claim 69, further comprising: means for generating a second audio stream of outgoing packets at a second audio source, the audio stream having the noiseless switchover audio in a payload; Means for converting a second audio stream of the outgoing packets into cells; Means for switching the converted cells to an SVC associated with an outgoing audio channel of the established VoIP telephone call; Means for converting the switched cells back to a second audio stream of the outgoing packets; Means for packetizing the second audio stream to produce the output audio packet stream in the established VoIP telephone call, and And means for transmitting the output audio packet stream over a network over the outgoing audio channel in the established VoIP telephone call instead of the audio from the first audio source. A method of introducing noiseless switchover audio for a VoIP phone call, Establishing a VoIP phone call, and And transmitting the noiseless switchover audio into an output audio packet stream having synchronized header information in the set VoIP telephone call. A method of noiseless switching between audio sources in a VoIP network, (A) selecting one audio source, (B) inserting audio from the selected one audio source into an output audio packet stream having synchronized header information and transmitting it to a destination device over an outgoing audio channel; (C) selecting another audio source, and (D) inserting audio from the selected another audio source into an output audio packet stream with synchronized header information and transmitting it to the destination device over the same outgoing audio channel. 73. The apparatus of claim 72, wherein the another audio source comprises an internal audio source, Generating an audio payload of the output audio packet stream prior to the transmitting step (B). 73. The apparatus of claim 72, wherein the another audio source comprises an external audio source, Extracting an audio payload for the output audio packet stream from an IP packet generated at the external audio source prior to the transmitting step (B). (A) inserting audio from one audio source into an output audio packet stream with synchronized header information and transmitting it to a destination device over an outgoing audio channel; (B) inserting audio from another independent audio source into an output audio packet stream with synchronized header information and transmitting it to the destination device over the same outgoing audio channel, Accordingly, the user at the destination device is aware of noiseless switchover between transmitted audio from independent audio sources in the VoIP network. (A) means for inserting audio from one audio source into an output audio packet stream with synchronized header information and transmitting it to a destination device over an outgoing audio channel; (B) means for putting audio from another independent audio source into an output audio packet stream with synchronized header information and transmitting it to the destination device over the same outgoing audio channel, Accordingly, the user at the destination device is aware of noiseless switchover between transmitted audio from independent audio sources in the VoIP network.