Conference call bridge arrangement

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] The present application is related to copending U.S. patent application Ser. No. IRI05436 being assigned to the same assignee as the present invention.

BACKGROUND OF THE INVENTION

[0002] The present invention pertains to teleconferencing arrangements and more particularly to conference call bridges in a voice over internet protocol environment.

[0003] Special telephony functions are provided by telephone operating companies or by teleconference facilitator companies. These companies provide the special service of teleconference facilitating by interconnecting three or more conference users in one common telephone call. As a result, each of the users is able to talk and to hear each of the other users. The number of total teleconference users may be quite high. In the internet protocol environment, bandwidths are typically very large compared to basic voice telephony. Voice data becomes almost incidental to the large packets of data carried on the internet. Therefore, voice over internet protocol (VOIP) enables the internet system to carry telephone traffic which typically requires far less data to be exchanged via the internet than does data packages of information.

[0004] Telephone operating companies or teleconference facilitator companies typically implement a teleconference arrangement by a conference bridge. This conference bridge includes a bank of varied codecs, converters, mixers and vocoders. Each particular user has a codec in his teleconference terminal and must be connected with a similar codec at the conference bridge arrangement in the teleconference facilitator's equipment. The conference users may have different and varied codecs, therefore the conference bridge must be capable of serving many different kinds of codec interfaces. In addition, this conference bridge must perform conversions of the voice data from one codec to another; mix the various voice signals together and then revocode them for distribution to each of the conference users. Such teleconference bridge arrangements require much real time voice processing computing engines to perform these functions and a varied array of equipment to support the various codecs conference users might have and must dedicate much of this equipment to each particular conference call.

[0005] What is needed is a means for simply facilitating conference call bridging in a voice over internet protocol environment. Further what is needed is a conference call bridge arrangement which may be controlled by a teleconference terminal, possible a remote.

BRIEF DESCRIPTION OF THE DRAWING

[0006]FIG. 1 is a block diagram of a conference call bridge arrangement using voice over internet protocol in accordance with the present invention.

[0007]FIGS. 2 and 3 are a flow chart of a call origination and set up in accordance with the present invention.

[0008]FIG. 4 is a flow chart of the token passing arrangement in accordance with the present invention.

[0009]FIG. 5 is a block diagram of the conference bridge in accordance with the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0010] In providing the present invention, session internet protocol (SIP) is used. SIP provides terminal capability negotiations and invitation to multicast conferences. Further, SIP provides the necessary protocol mechanisms so that the user terminals and any proxy servers can provide the following services: user location, user capabilities, terminal capability negotiation, and invitations to multicast conference.

[0011]FIG. 1 depicts a block diagram of a conference bridge arrangement according to the present invention. User terminals <b>10</b>, <b>11</b>, <b>12</b> and <b>13</b> are shown with data transfer interconnections <b>20</b>, <b>21</b>, <b>22</b> and <b>23</b> respectively connecting user terminals <b>10</b>-<b>13</b> to the controller <b>32</b> of conference bridge <b>30</b>. Conference bridge <b>30</b> may be a voice packet switched bridge. These data transfer interconnections <b>20</b>-<b>23</b> are termed bearer traffic (voice data) interconnections. Similarly, each of the user terminals <b>10</b>-<b>13</b> are interconnected to the conference bridge <b>30</b> via signaling or control interconnections <b>44</b>, <b>54</b>, <b>64</b> and <b>74</b> respectively.

[0012] In conventional bridge arrangements, all signaling would be controlled by the conference bridge <b>30</b> via the signaling leads <b>44</b>, <b>54</b>, <b>64</b> and <b>74</b>. As can be seen from FIG. 1, each of the user terminals (teleconference terminals) <b>10</b>-<b>13</b> has a different set of codecs <b>80</b>-<b>83</b> associated with the user terminal. The conventional conference bridge would be required to convert the data flow from each of the codecs <b>80</b>-<b>83</b>; mix the information and separately vocode four different codecs before retransmitting the information for the conference call back to each of the user terminals <b>10</b>-<b>13</b>. Such arrangement requires great processing power within the conference bridge. In an implementation of such a conference bridge, multiple signal processors (DSP) would be required at conference bridge <b>30</b> to perform these various functions.

[0013] In the present invention, each use of terminal is also interconnected via a session initiation protocol (SIP) connection to each of the other user terminals in the conference. That is, for example, user terminal <b>10</b> is interconnected to user terminal <b>11</b> via interconnection <b>41</b>; to user terminal <b>12</b> via interconnection <b>42</b>, which is shown in a dashed line in part to indicate that there is no connection to bridge <b>30</b> or controller <b>32</b>, and to user terminal <b>13</b> via interconnection <b>43</b>.

[0014] Similarly, user terminal <b>11</b> is interconnected to user terminal <b>12</b> via interconnection <b>52</b>; and to user terminal <b>13</b> via interconnection <b>53</b>, which is shown in a dashed line in part to indicate that there is no connection to bridge <b>30</b> or controller <b>32</b>. User terminal <b>12</b> is connected to user terminal <b>13</b> via interconnection <b>63</b>.

[0015] A preferred embodiment of the present invention includes each user terminal <b>10</b>-<b>14</b> negotiating with the other user terminals directly via session initiation protocol and the internet to determine what compatible codec the terminals have with one another.

[0016] As an example, user terminal <b>10</b> originates the conference call and includes two codecs <b>80</b> and <b>82</b> while user terminal <b>11</b> includes three codecs <b>81</b>, <b>82</b> and <b>83</b>. As a result, user terminals <b>10</b> and <b>11</b> will negotiate the use of a codec by each of the terminals via internet interconnection <b>41</b>. User terminals <b>10</b> and <b>11</b> may have many or only one codec in common. This particular common codec is codec <b>82</b> and will be selected between terminals <b>10</b> and <b>11</b>.

[0017] User terminal <b>10</b> then will negotiate with user terminal <b>12</b> via internet interconnection <b>42</b>. User terminal <b>12</b> includes only one codec <b>82</b>. Therefore, the compatible codec of the user terminals <b>10</b> and <b>12</b> will be selected so that communication may be established between user terminals <b>10</b> and <b>12</b>. This compatible codec is codec <b>82</b>. If a different codec other than <b>82</b> was common between user terminals <b>10</b> and <b>12</b> this would mean that user terminal <b>10</b> must renegotiate use of the codec with user terminal <b>11</b> so as to establish a new common codec.

[0018] Similarly, user terminal <b>10</b> will negotiate selection of a codec via interconnection <b>43</b> with user terminal <b>13</b>. In this example, user terminal <b>13</b> has a successful negotiation with user terminal <b>13</b> to codec <b>82</b>. User terminal will not have to renegotiate the selection of a codec with the other user terminals <b>11</b> and <b>12</b>. Again in this example, selection of an appropriate compatible codec could mean renegotiating the codec interconnections between user terminal <b>10</b> and user terminals <b>11</b> and <b>12</b>. In this embodiment, user terminals <b>10</b> through <b>13</b> negotiate codecs to a “least common denominator” (LCD) codec. That is, a codec which will support communications between any of the user terminals <b>10</b>-<b>13</b>. In this example, codec <b>82</b> met the criteria for LCD codec selection.

[0019] In another embodiment, the conference bridge may be asked to convert, mix and revocode certain data packets transmitted among the conference callers. Those data packets would be limited to those for users which have different codecs than the other users in the conference call. Therefore, this embodiment would support an arrangement in which each user terminal could speak in its native bearer format (codec translation) with the other conference callers. All packets would not have to be converted, mixed and revocoded; only the packets with those special user terminals having non-homogeneous bearer formats would be required to be thusly processed. This conversion and mixing may be done by one or more of the user terminals instead of the conference bridge.

[0020] The control of setting up the appropriate codecs for interfacing and negotiating to either a least common denominator codec or to codecs which are variable may be extended to add additional parties to the conference call. When each of the callers in the conference call has been suitably negotiated for a corresponding codec, the data flow is then established through the conventional conference bridge <b>30</b> to each of the data ports of the user terminals <b>10</b>-<b>13</b>.

[0021] Referring to FIGS. 2 and 3, a call origination <b>100</b> conference call arrangement of FIG. 1 is shown. Party A (user terminal <b>10</b>) is to enter into a conference call, block <b>101</b>. Party A originates a call via internet interconnection <b>41</b> to party B (user terminal <b>11</b>), block <b>103</b>. Next, block <b>105</b> determines a common bearer format (codec) between parties A and B. A call is then originated to user terminal <b>12</b> via internet interconnection <b>42</b>, block <b>107</b>.

[0022] Next, block <b>109</b> negotiates a bearer format between party A and party C (user terminal <b>12</b>), block <b>109</b>. An attempt is made to negotiate the same bearer format (codec) as was negotiated between parties A and C. Block <b>110</b> determines whether there are any other user terminals (parties) to be interconnected to the conference call. If there are other parties to be coupled, then block <b>110</b> transfers control to block <b>107</b> for repeating the processes of blocks <b>107</b> and <b>109</b> with a new party to be coupled to the conference call. If no other user terminals (parties) are to be coupled to the conference call, then block <b>110</b> transfers control to block <b>111</b> via the NO path.

[0023] Next, block <b>111</b> determines whether the user terminal support multiple interoperable bearer formats. If each of the user terminals supports multiple bearer formats, control is transferred from block <b>111</b> to block <b>121</b> via the YES path. Block <b>121</b> indicates to each of the user terminals that each of the user terminals will transmit and receive in their own native bearer format.

[0024] If each of the user terminals will not support multiple bearer formats, block <b>111</b> transfers control to block <b>113</b> via the NO path. Block <b>113</b> determines whether the bearer formats which were negotiated are homogeneous. If the formats are homogeneous, block <b>113</b> transfers control to block <b>123</b> via the YES path. This indicates that there is a LCD codec for use by each of the parties. If the negotiated formats are not homogeneous, block <b>113</b> transfers control to block <b>115</b> via the NO path.

[0025] Block <b>115</b> determines whether any common bearer format exists among each of the parties or users. If no common format exists, there is a failure and the conference call bridge may not be set up to all members, block <b>115</b> transfers control to block <b>117</b> via the NO path. The conference call bridge may continue to set up for a subset of the initial parties or cancel the setup completely, block <b>117</b>. If a common bearer via the YES path. Block <b>119</b> modifies A, B, C, etc. bearer formats to obtain a common bearer format between the parties in the conference call. Then block <b>119</b> transfers control to block <b>123</b>.

[0026] Block <b>123</b> originates call to conference bridge <b>30</b> with all the parties or users being addressed. The conference bridge establishes the data path communications via conference bridge <b>30</b> and controller <b>32</b>, block <b>125</b>. The bridge for conference calling is then established, block <b>127</b>.

[0027] In response to the call origination process <b>100</b>, conference bridge executes, block <b>125</b>, the following setup procedure, block <b>141</b>.

[0028] For example, the conference bridge <b>30</b> receives the origination request from party A with a list of targets to connect to the conference call of parties B and C, block <b>143</b>. Block <b>145</b> originates the data hook up to parties B and C.

[0029] Conference bridge <b>30</b> sends a message to parties A, B and C (user terminals <b>10</b>, <b>11</b> and <b>12</b>) via internet interconnections <b>44</b>, <b>54</b> and <b>64</b> to use the conference bridge as an end point for the voice packet data transmissions, block <b>147</b>. The conference bridge is then an established block <b>149</b> and procedure <b>140</b> is ended. The user terminals update their states to reflect that the conference bridge Is now the bearer endpoint, instead of the user terminals. The conference bridge is established and procedure <b>100</b> is also ended, block <b>127</b>.

[0030] Turning now to FIG. 4, a flow chart of a “token” or control passing arrangement is shown. Once the conference bridge is established, control of speech is passed among the users via their user terminals. The real time protocol (RTP) is a protocol used for carrying the bearer traffic, and is associated with the session initiation protocol (SIP). SIP negotiates the kind of bearer/payloads to be transported in the RTP packets. There is a particular indicator in the header of the RTP voice packet which designates the voice packet as a packet with silence. This indicator is readily ascertainable without examining each bit of the voice sample in the packet.

[0031] While in a conference bridge arrangement block <b>201</b>, the controller of the conference bridge detects if there is speech on any “leg” or input of the conference bridge, block <b>203</b>. That is, the conference bridge detects the first user terminal to provide a speech or voice input. If no speech input is detected, block <b>203</b> transfers control again to make the detection by transferring control to itself via the NO path. Silence is the lack of speech. Silence may be detected by an indicator in the header of the voice packet or by sampling the data of the packet itself. When speech is detected, block <b>203</b> will transfer control to block <b>205</b> via the YES path.

[0032] Block <b>205</b> will disable the other inputs (“legs”) of the conference bridge from providing any input to the conference bridge. That is, the first speaker will seize control of the conference and other speakers will be disabled from having their voice transferred to each of the users in the conference call. Only one speaker will speak at a given time.

[0033] The next block <b>207</b> initiates a “babble” timer. A babble timer is a timer set to prevent one speaker on the conference call from tying up and monopolizing the conference forever from (“babbling”) or if a noisy background causes the user terminal to never generate the silence packets, thereby monopolizing the conference bridge. The intent of the babble timer is to force the passage of control or token passing of the right to speak to another caller in the conference call at a predetermined time. The term “babble” is to prevent one speaker from babbling on forever, to prevent the noisy environment from never allowing silence packets to be generated.

[0034] The next block <b>209</b> takes the input voice packet and replicates it for transmission to each of the legs or inputs of the conference call. That is, each caller in the conference call, including the speaker, receives back the voice packets input from the speaking party including the speaking party.

[0035] Next, a determination is made as to whether the “babble” timer has expired, block <b>211</b>. This indicates that one speaker has monopolized the conference call and it is time to pass the control or token to another speaker in the conference call who may be initiating speech (trying to speak). If the babble timer has expired, block <b>211</b> transfers control to block <b>213</b> via the YES path. Block <b>213</b> enunciates a cut off tone or message to the present speaker so that the speaker will be aware that he is temporarily losing control of the token or control of the conference call. This means that the speaker is being forced to relinquish his ability to speak to the others in the conference call in an uninterrupted fashion.

[0036] Block <b>215</b> disables the present speaker's input leg temporarily. This is so that the other input legs may be examined for speech and a determination of passing control or the token to another speaker may be made. Block <b>215</b> then transfers control to block <b>203</b> which detects bearer speech on an input leg, except for the disabled past speaker's input. If speech is not detected after a predetermined number of times of checking by block <b>203</b>, the past speaker's input will be re-enabled and he will again be able to seize the token or control of the conference call. The reader is reminded that speech is quite slow compared to today's real time processing capabilities and that the checks made by the conferencing bridge method <b>200</b> are done in fractions of a second so that the speaker who is disabled temporarily may not even know that he has been temporarily disabled from speaking. If block <b>203</b> detects speech of another speaker, the steps of blocks <b>205</b>, <b>207</b>, <b>209</b>, <b>211</b> and <b>217</b> are then performed.

[0037] If the babble timer has not expired, block <b>211</b> transfers control to block <b>217</b> via the NO path. Block <b>217</b> detects silence. Silence in a real time protocol SIP configuration is indicated by a particular setting in the header of each packet of speech information. Also, silence may be detected by examining the actual input stream which would be coded to indicate silence. The latter solution requires considerable real time processing power. If silence is detected, block <b>217</b> transfers control to block <b>203</b> via the NO path which indicates that the past speaker has relinquished the token and the conference bridge is waiting to detect a new speaker by block <b>203</b>. When this happens, each of the above mentioned steps is again repeated. If silence is not detected, block <b>217</b> transfers control to block <b>209</b> which replicates the input packet to all the output legs (user terminals) of the conference call. This means that the present speaker has not relinquished control and the timer has not indicated to him to release control and he is continuing to talk with his voice packets of information being distributed to each of the conference callers including himself.

[0038] In the token or control passing arrangement <b>200</b>, token control is simplified by examining the header of the real time protocol to determine a data packet of silence in the preferred embodiment. This greatly simplifies the processing capability required for the conference call and such conferencing circuitry may be employed in a user terminal or even in a mobile handset. In an alternate embodiment, each data packet may be examined for the voice coded silence (as well as moise detection to determine “babble” or a noisy environment). This embodiment requires considerably more real time processing power.

[0039]FIG. 5 depicts a block diagram of the conference bridge <b>30</b>. Hardware <b>310</b> includes a processor <b>311</b> interconnected with memory <b>312</b> and internet protocol based interface <b>313</b>. Memory <b>312</b> is also interconnected with IP based interface <b>313</b>. IP based interface <b>313</b> provides the bearer traffic and control signaling inputs and outputs mentioned above.

[0040] The software <b>320</b> of the conference bridge includes SIP user agent server <b>321</b> which is interconnected to packet replicator <b>322</b>. Packet replicator <b>322</b> is interconnected with the token passing control logic <b>323</b> which is shown in FIG. 4. The SIP user agent server software <b>321</b> is depicted in FIGS. <b>1</b>-<b>3</b> discussed above. Packet replicator <b>322</b> is believed well known in the art and will not be discussed further. Token passing control logic <b>323</b> was previously described in FIG. 4. These various functions interact as discussed above to provide the conference bridge arrangement of the present invention.

[0041] New wire line cable and DSL infrastructure is being positioned to support voice along with data. In addition, third generation mobile networks are currently being developed. Much of the new infrastructures use internet protocol technology which enables voice over internet protocol services to be supplied. The present invention leverages off of session initiation protocol applicable to such voice over internet protocol capabilities to provide a conference bridge in accordance with the above description. The present invention simplifies the way in which conference calling can work in a voice over internet protocol environment. The present conference bridge arrangement allows negotiation of codecs directly between each of the participants in a conference call. This negotiation occurs over the internet which allows each user to be found regardless of whether he is at his typical location or is in a mobile location. This eliminates the need for complex conversions and vocoding to occur at the central conference bridge. The conference bridge is greatly simplified to be a basically packet replicator and distributor. This greatly simplifies the requirements for conference bridges located within telephone operating companies or conference facilitator providers.

[0042] The conference bridge is removed from handling the set up of the conference call and handles just the transmission of bearer traffic between the conference call participants. Conventional conference arrangements require the conference bridge to include virtually every conceivable codec for information interchange among varied users. In addition, the conference bridge needs to include much processing power in the form of digital signal processors to implement conversion, mixing and revocoding functions required. The present invention eliminates all such functional requirements in the conference bridge by having the user terminals themselves negotiate a compatible codec (bearer format) with the other user terminals in the conference call. Suitably equipped user terminals including remote terminals may perform the conference bridge function directly.

[0043] The token control arrangement leverages off of the real time protocol (RTP) to quickly detect silence for passing the token to another caller in the conference. In addition, the token passing arrangement allows for cutting off the speaker who is monopolizing the conference call. The control for such token passing arrangements may reside even in the user terminal of one of the conference callers.

[0044] Although the preferred embodiment of the invention has been illustrated, and that form described in detail, it will be readily apparent to those skilled in the art that various modifications may be made therein without departing from the spirit of the present invention or from the scope of the appended claims.