U.S. patent application number 10/871852 was filed with the patent office on 2005-02-24 for audio mixer and method.
This patent application is currently assigned to Marconi Communications, Inc.. Invention is credited to Hill, Peter D., Huber, Richard E., Punj, Arun.
Application Number | 20050041646 10/871852 |
Document ID | / |
Family ID | 33418495 |
Filed Date | 2005-02-24 |
United States Patent
Application |
20050041646 |
Kind Code |
A1 |
Punj, Arun ; et al. |
February 24, 2005 |
Audio mixer and method
Abstract
A telecommunications system includes a first node having audio
and video streams. The system includes a second node having only an
audio stream. The system includes a mechanism for forming a call
between the first node and the second node so the first node and
the second node communicate their audio streams with each other.
The forming mechanism is in communication with the first and second
nodes. Preferably, a third node can communicate with the first and
second nodes through the forming means. A method for forming a
telecommunications call including the steps of calling from a first
node having audio and video streams a second node having only an
audio stream. There is the step of forming a call between the first
node and the second node so the first node and the second node
communicate their audio streams with each other.
Inventors: |
Punj, Arun; (Cranberry
Township, PA) ; Hill, Peter D.; (Monroeville, PA)
; Huber, Richard E.; (Harmony, PA) |
Correspondence
Address: |
Ansel M. Schwartz
Attorney at Law
Suite 304
201 N. Craig Street
Pittsburgh
PA
15213
US
|
Assignee: |
Marconi Communications,
Inc.
|
Family ID: |
33418495 |
Appl. No.: |
10/871852 |
Filed: |
June 17, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60483137 |
Jun 27, 2003 |
|
|
|
Current U.S.
Class: |
370/352 |
Current CPC
Class: |
H04M 7/006 20130101;
H04L 65/104 20130101; H04L 29/06027 20130101; H04L 65/1043
20130101; H04M 3/567 20130101; H04M 2207/203 20130101; H04L 65/1006
20130101; H04L 65/103 20130101; H04L 65/1069 20130101; H04M 2201/50
20130101; H04M 3/568 20130101; H04L 65/403 20130101; H04M 7/1205
20130101 |
Class at
Publication: |
370/352 |
International
Class: |
H04L 012/66 |
Claims
What is claimed is:
1. A method for forming a telecommunications call comprising the
steps of: calling from a first node having audio and video streams
a second node having only an audio stream; and forming a call
between the first node and the second node so the first node and
the second node communicate their audio streams with each
other.
2. A method as described in claim 1 including the step of adding a
third node having an audio stream and a video stream to the call to
form a conference between the first, second and third nodes so the
first and third nodes communicate their audio and video streams
with each other, and the first, second and third nodes communicate
their audio streams with each other.
3. A method as described in claim 2 wherein the step of adding a
third node includes the step of communicating with a host node to
host the conference.
4. A method as described in claim 3 wherein the forming step
includes the step of terminating a first connection of the call
between the first node and a mixer and creating a second connection
of the call between the mixer and the second node in which data
from the first connection is sent from the mixer to the second
node.
5. A telecommunications system comprising: a first node having
audio and video streams; a second node having only an audio stream;
and means for forming a call between the first node and the second
node so the first node and the second node communicate their audio
streams with each other, the forming means in communication with
the first and second nodes.
6. A system as described in claim 5 including a third node having
an audio stream and a video stream, and wherein the forming means
includes a mixer which connects a conference between the first,
second and third nodes so the first, second and third nodes
communicate their audio streams with each other.
7. A system as described in claim 6 including a host node and
wherein the mixer communicates with the host node to host the
conference.
8. A system as described in claim 7 wherein the mixer terminates a
first connection of the call between the first node and the mixer
and creates a second connection of the call between the mixer and
the second node in which data from the first connection is sent
from the mixer to the second node.
9. A system as described in claim 8 including a fourth node having
only an audio stream, a first network in which the first, second
and third nodes are disposed, and a second network different from
the first network in which the fourth node is disposed, and the
mixer bridges audio streams between the fourth node of the second
network and the first, second and third nodes of the first
network.
10. A telecommunications system comprising: a first network having
a first media type in which audio streams are transmitted; a second
network having the first media type in which audio streams are
transmitted; a third network having a second media type different
from the first media type in which audio streams are transmitted;
and a mixer which bridges audio streams between the first, second
and third networks.
11. A telecommunications system comprising: a first network having
a first media type in which signals are transmitted; a second
network having the first media type in which signals are
transmitted; a third network having a second media type different
from the first media type in which signals are transmitted; and a
mixer which bridges signals between the first, second and third
networks.
12. A telecommunications system comprising: a plurality of audio
terminals which produce audio streams; a plurality of audio and
video terminals which produce audio and video streams; a mixer
which receives an audio stream from each audio stream and transmits
the audio stream to the audio and video terminals; and a network in
which the audio terminals, the audio and video terminals and the
mixer are in communication to communicate with each other.
13. A method for creating a conference call between at least two
nodes where at least a first node of the two nodes is a first
audio/video terminal and at least a second node of the two nodes is
a first audio terminal comprising the steps of: calling the first
audio terminal from the first audio/video terminal; routing the
audio streams from both terminals to a mixer; adding at least a
second audio/video terminal as a conference participant by routing
its audio stream to the mixer and to the first audio/video
terminal; adding at least a second audio terminal as a conference
participant by routing its audio stream to the mixer; sending a
mixed audio stream to each audio terminal by mixing audio streams
from all the terminals except the audio stream of the terminal
receiving the mixed audio stream.
14. A telecommunications system comprising: a first audio terminal
having a first format in which audio streams are transmitted from
the first audio terminal; a second audio terminal having a second
format in which audio streams are transmitted from the second audio
terminal; a third audio terminal having a third format in which
audio streams are transmitted from the third audio terminal; a
mixer which translates respective audio streams from the first,
second and third terminals into a respective format so they can be
understood by the first, second and third terminals when they
receive them; and a network through which the first, second and
third terminals communicate their respective audio streams with
each other.
Description
[0001] This application is related to contemporaneously filed U.S.
provisional patent application Ser. No. 60/483,217 titled "Gateway
and Method", by Rich Newpol, Arun Punj, Richard E. Huber and Brian
Rosen, having attorney docket number FORE-101, now U.S. patent
application ______, incorporated by reference herein.
FIELD OF THE INVENTION
[0002] The present invention is related to a telecommunications
call between one or more terminals having audio and video streams
and one or more terminals having only audio streams. More
specifically, the present invention is related to a
telecommunications call between one or more terminals having audio
and video streams and one or more terminals having only audio
streams with a mixer.
BACKGROUND OF THE INVENTION
[0003] Prior Art Products Information
[0004] Network Phones
[0005] Networks such as IP/Ethernet, T1 and ISDN can connect
telephony terminals to one another. Voice and video data streams
are carried on these networks per their respective protocols.
Telephony devices such as SIP phones are network based equivalents
to the conventional telephone. Telephony Gateways provide an
interface between phones on a local data network such as a local
area network (LAN) and a conventional telephony network such as
analog phone lines, digital telephone interfaces such as T1 and
ISDN commonly found in the PBX.
[0006] Mediatrics PSTN Gateway
[0007] This device provides a SIP to PSTN interface. It terminates
a SIP call on Ethernet IP side and relays it on PSTN side.
[0008] Intel Audio PBX Gateway
[0009] This device provides a SIP to PBX interface. It terminates a
SIP call on Ethernet IP side and relays it on PBX side.
[0010] AudioCodes PRI Gateway
[0011] This device provides a SIP to PBX interface. It terminates a
SIP call on Ethernet IP side and relays it on PBX side.
[0012] CISCO SIP Phone
[0013] Pingtel Xpressa SIP Phone
[0014] These phones are connected to an Ethernet network instead of
dedicated telephone lines. They send and receive a single audio
data stream and require a media conferencing unit (MCU) to connect
3 or more telephones into the same call.
[0015] H.320/H323 Phones
[0016] These devices use the H.320/H.323 protocol instead of the
SIP protocol to establish connections. They also require the use of
an MCU to conference 3 or more phones.
[0017] Present Invention
[0018] The conventional phone terminals connect to a central
processing device that receives the audio and video streams from
the terminals, mixes the audio and formats the incoming video. The
results are sent back to the terminal for display and playback.
[0019] The ViPr.TM. system differentiates itself from other
conferencing systems in that in a conference call of 3 or more
terminals each terminal sends audio and video data to the other
terminals using multicast IP or point-to-multipoint (PMP) ATM and
each terminal receives the audio and video data streams from each
of the other terminals and processes them accordingly. The incoming
audio streams were encoded using standardized algorithms by the
transmitting terminals. The terminals receiving these audio streams
decode and add the incoming audio streams. The blended audio stream
is played out of a speaker system for the user to hear.
[0020] The distributed video and audio processing that ViPr uses is
incompatible with the MCU architecture that the SIP phones and H
devices use. In order to interface to these devices, a means and
apparatus called the Unicast Audio Mixer (UAM) was developed.
[0021] ViPr terminals communicate to the UAM as if it was another
ViPr terminal without video. The unicast devices such as SIP phones
communicate with the UAM as if it was another SIP phone. This
function of presenting one interface to the ViPr terminals and
another to the unicast devices is called a back-to-back user agent
(B2BUA). The UAM is the only device that can implement a B2BUA
between ViPr terminals and unicast devices.
[0022] The UAM handles a large number of simultaneous conferences
involving one or more unicast devices and one or more ViPr
terminals.
[0023] Another feature of the UAM is to act as a bridge between two
different networks. For example, if all the ViPr terminals are on
an ATM network and the unicast devices are on an Ethernet network
then the UAM would be configured with one ATM NIC and one Ethernet
NIC. Along with the SIP signaling and audio processing, the UAM
would bridge these two networks.
[0024] In order to support this functionality, the ViPr system
includes a UAM that adds seamless conferencing functionality
between the ViPr terminals and telephone users (i.e. PSTN, Mobile
phones and SIP phones) by converting an upstream unicast telephone
audio stream to point-to-multipoint audio streams (i.e. PMP-SVC or
IP Multicast) and mixing/converting downstream PMP/multicast ViPr
audio streams to unicast telephone audio streams as well as
performing downstream audio transcoding of ViPr audio from the
wideband 16 bit/16 KHz PCM encoding to G.711 or G.722.
[0025] An additional functionality provided by the UAM is that of
an Intermedia gateway that converts IP/UDP audio streams to ATM SVC
audio streams and vice-versa. This functionality enables the
interoperability between ViPr systems deployed in ATM environments
and SIP-based Voice-over-IP (VoIP) telephony gateways on Ethernet
networks.
[0026] The current ViPr system provides support for telephony
systems through SIP-based analog and digital telephony gateways.
This functionality enables ViPr users to make/receive
point-to-point calls to/from telephone users. However, they do not
allow a ViPr user to add a telephone call to a ViPr conference.
This is due to the unicast nature of telephone calls and the
inability of the telephony gateways to convert them to
PMP/multicast streams. The ViPr UAM will enhance the ViPr system's
support for telephony by enabling ViPr users to add unicast
telephone calls to ViPr conferences.
[0027] The UAM adds conferencing capabilities between the ViPr
terminals and telephone users (i.e. PSTN, Mobile phones and SIP
phones) by converting upstream unicast voice-only telephone streams
into point-to-multipoint streams (i.e. PMP-SVC or IP Multicast) and
converting downstream ViPr multicast/PMP audio streams to unicast
telephone voice-only streams as well as performing downstream audio
transcoding of ViPr audio from wideband 16 bit/16 KHz PCM encoding
to G.711 or G.722.
[0028] The UAM is designed to:
[0029] a. Enable point-to-point voice-only calls between one ViPr
user and one telephone user.
[0030] b. Enable adding one voice-only telephone call to a
multi-party ViPr audio/video conference.
[0031] c. Perform downstream audio transcoding of ViPr audio
streams from the wideband 16 bit/16 KHz PCM to G.711 or G.722.
[0032] d. Operate as an Intermedia gateway bridging between ViPr
terminals on an ATM network and SIP-based VOIP telephony gateways
on Ethernet networks.
SUMMARY OF THE INVENTION
[0033] The present invention pertains to a telecommunications
system. The system comprises a first node having audio and video
streams. The system comprises a second node having only an audio
stream. The system comprises means for forming a call between the
first node and the second node so the first node and the second
node communicate their audio streams with each other. The forming
means is in communication with the first and second nodes.
[0034] The present invention pertains to a method for forming a
telecommunications call. The method comprises the steps of calling
from a first node having audio and video streams a second node
having only an audio stream. There is the step of forming a call
between the first node and the second node so the first node and
the second node communicate their audio streams with each
other.
[0035] The present invention pertains to a telecommunications
system. The system comprises a first network having a first media
type in which audio streams are transmitted. The system comprises a
second network having the first media type in which audio streams
are transmitted. The system comprises a third network having a
second media type different from the first media type in which
audio streams are transmitted. The system comprises a mixer which
bridges audio streams between the first, second and third
networks.
[0036] The present invention pertains to a telecommunications
system. The system comprises a first network having a first media
type in which signals are transmitted. The system comprises a
second network having the first media type in which signals are
transmitted. The system comprises a third network having a second
media type different from the first media type in which signals are
transmitted. The system comprises a mixer which bridges signals
between the first, second and third networks.
[0037] The present invention pertains to a telecommunications
system. The system comprises a plurality of audio terminals which
produce audio streams. The system comprises a plurality of audio
and video terminals which produce audio and video streams. The
system comprises a mixer which receives an audio stream from each
audio stream and transmits the audio stream to the audio and video
terminals. The system comprises a network in which the audio
terminals, the audio and video terminals and the mixer are in
communication to communicate with each other.
[0038] The present invention pertains to a method for creating a
conference call between at least two nodes where at least a first
node of the two nodes is a first audio/video terminal and at least
a second node of the two nodes is a first audio terminal. The
method comprises the steps of calling the first audio terminal from
the first audio/video terminal. There is the step of routing the
audio streams from both terminals to a mixer. There is the step of
adding at least a second audio/video terminal as a conference
participant by routing its audio stream to the mixer and to the
first audio/video terminal. There is the step of adding at least a
second audio terminal as a conference participant by routing its
audio stream to the mixer. There is the step of sending a mixed
audio stream to each audio terminal by mixing audio streams from
all the terminals except the audio stream of the terminal receiving
the mixed audio stream.
[0039] The present invention pertains to a telecommunications
system. The system comprises a first audio terminal having a first
format in which audio streams are transmitted from the first audio
terminal. The system comprises a second audio terminal having a
second format in which audio streams are transmitted from the
second audio terminal. The system comprises a third audio terminal
having a third format in which audio streams are transmitted from
the third audio terminal. The system comprises a mixer which
translates respective audio streams from the first, second and
third terminals into a respective format so they can be understood
by the first, second and third terminals when they receive them.
The system comprises a network through which the first, second and
third terminals communicate their respective audio streams with
each other.
BRIEF DESCRIPTION OF THE DRAWINGS
[0040] In the accompanying drawings, the preferred embodiment of
the invention and preferred methods of practicing the invention are
illustrated in which:
[0041] FIG. 1 is a schematic representation of an audio mixer of
the present invention.
[0042] FIG. 2 is a block diagram of the architecture for the
mixer.
[0043] FIG. 3 is a block diagram of an SBU.
[0044] FIG. 4 is a schematic representation of a videophone UAM in
a video phone conference.
[0045] FIG. 5 is a schematic representation of a videophone UAM in
a two-way telephone call.
[0046] FIG. 6 is a schematic representation of a network for a
mixer.
DETAILED DESCRIPTION
[0047] Referring now to the drawings wherein like reference
numerals refer to similar or identical parts throughout the several
views, and more specifically to FIG. 4 thereof, there is shown a
telecommunications system 10. The system 10 comprises a first node
12 having audio and video streams. The system 10 comprises a second
node 14 having only an audio stream. The system 10 comprises means
16 for forming a call between the first node 12 and the second node
14 so the first node 12 and the second node 14 communicate their
audio streams with each other. The forming means 16 is in
communication with the first and second nodes 12, 14.
[0048] Preferably, the system 10 includes a third node 18 having an
audio stream and a video stream, and wherein the forming means 16
includes a mixer 20 which connects a conference between the first,
second and third nodes 12, 14, 18, respectively, so the first,
second and third nodes 12, 14, 18, communicate their audio streams
with each other. The system 10 preferably includes a host node 22
and wherein the mixer 20 communicates with the host node 22 to host
the conference. Preferably, the mixer 20 terminates a first
connection of the call between the first node 12 and the mixer 20
and creates a second connection of the call between the mixer 20
and the second node 14 in which data from the first connection is
sent from the mixer 20 to the second node 14.
[0049] The system 10 preferably includes a fourth node having only
an audio stream, a first network in which the first, second and
third nodes 12, 14, 18 are disposed, and a second network different
from the first network in which the fourth node is disposed, and
the mixer 20 bridges audio streams between the fourth node of the
second network and the first, second and third nodes 12, 14, 18 of
the first network.
[0050] The present invention pertains to a method for forming a
telecommunications call. The method comprises the steps of calling
from a first node 12 having audio and video streams a second node
14 having only an audio stream. There is the step of forming a call
between the first node 12 and the second node 14 so the first node
12 and the second node 14 communicate their audio streams with each
other.
[0051] Preferably, there is the step of adding a third node 18
having an audio stream and a video stream to the call to form a
conference between the first, second and third nodes 12, 14, 18,
respectively, so the first and third nodes 12, 18 communicate their
audio and video streams with each other, and the first, second and
third nodes 12, 14, 18 communicate their audio streams with each
other. The step of adding a third node 18 preferably includes the
step of communicating with a host node 22 to host the conference.
The forming step preferably includes the step of terminating a
first connection of the call between the first node 12 and a mixer
20 and creating a second connection of the call between the mixer
20 and the second node 14 in which data from the first connection
is sent from the mixer 20 to the second node 14.
[0052] The mixer 20 comprises a computer having at least one
Network Interface Card (NIC), and preferably 2 or more NICs, with
ideally one NIC for each distinct network that the mixer 20
communicates with, and for instance a line card to communicate with
a node having only an audio stream, such as a PSTN line, PBX line
or PRI line.
[0053] A description of a system and method involving nodes having
video and audio streams, otherwise known as ViPrs is found in PCT
application PCT/IB03/01468 claiming priority from U.S. application
Ser. No. 10/114,402, incorporated by reference herein.
[0054] The present invention pertains to a telecommunications
system 10. The system 10 comprises a first network having a first
media type in which audio streams are transmitted. The system 10
comprises a second network having the first media type in which
audio streams are transmitted. The system 10 comprises a third
network having a second media type different from the first media
type in which audio streams are transmitted. The system 10
comprises a mixer 20 which bridges audio streams between the first,
second and third networks.
[0055] The present invention pertains to a telecommunications
system 10. The system 10 comprises a first network having a first
media type in which signals are transmitted. The system 10
comprises a second network having the first media type in which
signals are transmitted. The system 10 comprises a third network
having a second media type different from the first media type in
which signals are transmitted. The system 10 comprises a mixer 20
which bridges signals between the first, second and third
networks.
[0056] The present invention pertains to a telecommunications
system 10. The system 10 comprises a plurality of audio terminals
which produce audio streams. The system 10 comprises a plurality of
audio and video terminals which produce audio and video streams.
The system 10 comprises a mixer 20 which receives an audio stream
from each audio stream and transmits the audio stream to the audio
and video terminals. The system 10 comprises a network in which the
audio terminals, the audio and video terminals and the mixer 20 are
in communication to communicate with each other.
[0057] The present invention pertains to a method for creating a
conference call between at least two nodes where at least a first
node 12 of the two nodes is a first audio/video terminal and at
least a second node 14 of the two nodes is a first audio terminal.
The method comprises the steps of calling the first audio terminal
from the first audio/video terminal. There is the step of routing
the audio streams from both terminals to a mixer 20. There is the
step of adding at least a second audio/video terminal as a
conference participant by routing its audio stream to the mixer 20
and to the first audio/video terminal. There is the step of adding
at least a second audio terminal as a conference participant by
routing its audio stream to the mixer 20. There is the step of
sending a mixed audio stream to each audio terminal by mixing audio
streams from all the terminals except the audio stream of the
terminal receiving the mixed audio stream.
[0058] The present invention pertains to a telecommunications
system 10. The system 10 comprises a first audio terminal having a
first format in which audio streams are transmitted from the first
audio terminal. The system 10 comprises a second audio terminal
having a second format in which audio streams are transmitted from
the second audio terminal. The system 10 comprises a third audio
terminal having a third format in which audio streams are
transmitted from the third audio terminal. The system 10 comprises
a mixer 20 which translates respective audio streams from the
first, second and third terminals into a respective format so they
can be understood by the first, second and third terminals when
they receive them. The system 10 comprises a network through which
the first, second and third terminals communicate their respective
audio streams with each other.
[0059] In the operation of the invention, a first node 12 which can
produce an audio stream and a video stream, and which is part of an
ATM network having quality of service capability, wishes to form a
point to point call with a second node 14. The second node 14 only
has audio capability and is, for instance, a PSTN phone. The second
node 14 is not a part of the ATM network.
[0060] The first node 12 begins the formation of the call to the
second node 14 by sending signaling information to an SIP server,
also part of the ATM network, which identifies to the server that
the second node 14 is the destination of the call that the first
node 12 is initiating. The server, which already has address
information concerning the second node 14, adds the address
information to the signaling information received from the first
node 12, and transmits the signaling information with the address
information of the second node 14 to an audio mixer 20 that is also
part of the ATM network.
[0061] When the mixer 20 receives the signaling information that
has originated from the first node 12, it determines from this
information that it is the second node 14 with which the first node
12 wishes to form a connection. The mixer 20 then sends an
invitation to the second node 14 through which it is somehow in
communication, such as by a T1 line or ethernet but not by way of
the ATM network, to identify itself in regard to its features and
the form that the data needs to be provided to it so it can
understand the data. In response, the second node 14 identifies to
the mixer 20 the specific form the data needs to be in so that the
second node 14 can understand the data, and also indicates to the
mixer 20 it is OK to send data to it so the connection can be
formed.
[0062] The mixer 20 then sends a signal to the first node 12 that
it is ready to form the connection. To the first node 12, the mixer
20, which is part of the ATM network, represents the second node 14
and gives the impression to the first node 12 that the second node
14 is part of the ATM network and is similar to the first node 12.
To the second node 14, the mixer 20, which is also part of the
network or connectivity that the second node 14 belongs, represents
the first node 12 and gives the impression to the second node 14
that the first node 12 is part of the same network or connectivity
to which the second node 14 belongs and is similar to the second
node 14.
[0063] The first node 12 then initiates streaming of the data,
which includes audio data, and unicast packets of the data to the
mixer 20, as is well known in the art. When the mixer 20 receives
the packets, it buffers the data in the packets, as is well known
in the art, effectively terminating the connection in regard to the
packets from the first node 12 that are destined for the second
node 14. The mixer 20, having been informed earlier through the
invitation that was sent to the second node 14, of the form the
data needs to be in so that the second node 14 can understand it,
places the buffered data into the necessary format, and then
subject to proper time constraints, sends the properly reformatted
data effectively in a new and separate connection from the mixer 20
to the first node 12. In this way, a point to point call is formed,
although it really comprises two distinct connections, and neither
the first node 12 nor the second node 14 realize that two
connections are utilized to create the desired point to point call
between the first node 12 in the second node 14. Similarly, when
data is sent from the second node 14 back to the first node 12, the
process is repeated, although in reverse so that after the data
from the second node 14 is received by the mixer 20, the mixer 20
reformats the data into a form that the first node 12 can
understand and unicasts the data from the second node 14, that has
been buffered in the mixer 20, to the first node 12. If IP instead
of ATM is used, then the mixer 20 sends unicast IP packets to the
first node 12, as is well known in the art.
[0064] A scenario involving conferencing, otherwise known as a
point to multi point connection, will now be described using the
present invention. Continuing the discussion involving a point to
point connection from above, the first node 12 desires to join in
the connection to form a conference, a third node 18 that is part
of the ATM network and has essentially the same characteristics as
the first node 12. The first node 12 sends a signaling invitation
to a host node 22 that will host the conference. The host node 22
can be the first node 12 or it can be a distinct node. The first
node 12 communicates with the host node 22 through the server to
form a conference and join the third node 18 into the conference.
The host node 22 invites and then forms a connection for signaling
purposes with the mixer 20 and causes the original signaling
connection between the first node 12 and the mixer 20 to be
terminated. The host node 22 also invites and forms a connection
with the third node 18 in response to the request from the first
node 12 for the third node 18 to be joined into the connection. In
each case that a node which is part of the ATM network is to be
joined into the connection, signaling goes through the server and
is properly routed, as is well known in the art. The host node 22
acts as a typical host node for a conferencing connection in the
ATM network. The mixer 20 represents any nodes that are not part of
the ATM network, but that are to be part of the overall
conferencing connection.
[0065] In regard to any of the nodes on the ATM network, the mixer
20 makes any nodes that are part of the connection but not part of
the ATM network appear as though they are just like the other nodes
on the ATM network. Through the signaling connections, that are
formed between the host and the mixer 20, and the mixer 20 and the
second node 14 (as represented by the mixer 20), the required
information from all the nodes of the connection is provided to
each of the nodes so that they can understand and communicate with
all the other nodes of the connection. In fact, the host node 22
informs all the other nodes, not only the information of the
characteristics of the other nodes, but also returns the
information to the nodes that they had originally provided to the
host node 22 so that essentially each node gets its own information
back. Once this information is distributed, the streaming
information is carried out as would normally be the case in any
typical conferencing situation. In an ATM network scenario, the
first node 12 and the third node 18 would ATM multicast using PMP
tree the information in packets to each other and to the mixer 20.
In an IP environment, the first node 12 and the third node 18 would
IP multicast packets to all nodes (the mixer 20 being a node for
this purpose) in the network, and only those nodes which are part
of the connection would understand and utilize the specific packet
information that was part of the connection.
[0066] The mixer 20 receives the packets from the first node 12 and
the third node 18 and buffers them, as described above. The packets
from the different nodes that are received by the mixer 20 are
reformatted as they are received and mixed or added together
according to standard algorithms well known to one skilled in the
art. At a predetermined time, as is well known in the art, the
reformatted data by the mixer 20 is then transmitted to the second
node 14. In the same way, but only in reverse, the data from the
second node 14 is received by the mixer 20 and buffered. It is then
multicast out in a reformatted form to the first node 12 and the
third node 18.
[0067] When a fourth node, that only has audio capability, like the
second node 14, and which is not part of the ATM network, is joined
into the conference, the host node 22 forms a second signaling
connection with the mixer 20. The mixer 20 in turn forms a distinct
connection with the fourth node separate from the connection the
mixer 20 has formed with the second node 14. The mixer 20 maintains
a list of sessions that it is supporting. In the session involving
the subject conference, it identifies two cross connects through
the mixer 20. The first cross connect is through the signaling
connection from the host node 22 to the second node 14, and the
second cross connect is from the host node 22 to the fourth node.
In this way, the first and third nodes 12, 18, as well as the host
node 22, believes that there are two separate nodes, representing
the second node 14 and the fourth node, to which they are
communicating. In fact, the mixer 20 represents both the second
node 14 and the fourth node and separately multicasts data from
each of them to maintain this illusion, as well as the illusion the
second node 14 and the fourth node are like the first node 12 and
the third node 18, to the first node 12 and the third node 18.
[0068] The ViPr system is a highly advanced videoconferencing
system providing `Virtual Presence` conferencing quality that far
exceeds the capabilities of any legacy videoconferencing systems on
the market today. The ViPr system relies on point-to-multipoint
SVCs (PMP-SVC) and IP multicast to establish point-to-multipoint
audio/video media streams among conference participants. While
users participating in a ViPr conference enjoy an unprecedented
audio and video quality conference, there is a need to enable other
non-ViPr users to join a ViPr conference. The system 10 enables a
unicast voice-only telephone call (i.e. PSTN, Mobile phones and SIP
phones) to be added to a multi-party ViPr conference.
[0069] The current ViPr system provides support for telephony
systems through SIP-based analog and digital telephony gateways.
This functionality enables ViPr users to make/receive
point-to-point calls to/from telephone users. However, they do not
allow a ViPr user to add a telephone call to a ViPr conference.
This is due to the unicast nature of telephone calls and the
inability of the telephony gateways to convert them to
PMP/multicast streams. The ViPr UAM will enhance the ViPr system's
support for telephony by enabling ViPr users to add unicast
telephone calls to ViPr conferences.
[0070] In order to support this functionality, the ViPr UAM adds
seamless conferencing functionality between the ViPr terminals and
telephone users (i.e. PSTN, Mobile phones and SIP phones) by
converting an upstream unicast telephone audio stream to
point-to-multipoint audio streams (i.e. PMP-SVC or IP Multicast)
and mixing/converting downstream PMP/multicast ViPr audio streams
to unicast telephone audio streams as well as performing downstream
audio transcoding of ViPr audio from the wideband 16 bit/16 KHz PCM
encoding to G.711 or G.722.
[0071] An additional functionality provided by the UAM is that of
an Intermedia gateway that converts IP/UDP audio streams to ATM SVC
audio streams and vice-versa. This functionality enables the
interoperability between ViPr systems deployed in ATM environments
and SIP-based Voice-over-IP (VoIP) telephony gateways on Ethernet
networks.
[0072] The UAM allows one or more ViPr phones to work with one or
more phone gateways.
[0073] The UAM will support ViPr Conference calls with unicast
audio devices present in following configurations:
[0074] Type 1: Support one conference call with only one audio
unicast device present as a participant.
[0075] Type 2: Support multiple conference calls. Each conference
call could potentially have multiple audio Unicast devices present
as a participant.
[0076] Type 3: Support multiple conference calls with each
conference call having exactly one audio unicast device present as
a participant.
[0077] Preferably, 20 participants (unicast devices plus ViPr
phones) can be serviced by a single Unicast Manager
application.
[0078] The unicast device will be used in the configuration shown
in FIG. 1.
[0079] As shown in FIG. 1, all calls to and from a unicast device
to a ViPr are always sent to the UAM. The UAM implements a B2B SIP
UA to connect the unicast device to a ViPr.
[0080] Example: User A at POTS1 calls user B at ViPr V1. The
following sequence of events takes place:
[0081] 1. UD1 (Mediatrics or whatever unicast device) receives the
request from User_A to connect to User_B.
[0082] 2. UD1 sends an INVITE to UAM. The To field or the Display
Name in the INVITE identifies the call is for User_B.
[0083] 3. UAM receives INVITE as incoming call C1.
[0084] 4. UAM extracts the sip address of User_B from the INVITE on
C1 and initiates a call C2 to this user by sending out an INVITE to
V1.
[0085] 5. UAM also cross connects C1 to C2.
[0086] 6. V1 sees an incoming INVITE from UAM, which is identified
by the SDP as a ViPr class device. Thus software on V1 knows that
the peer software is capable of supporting all the functionality
expected of a ViPr device including Replaces/Refers etc.
[0087] 7. Say User_B at V1 replies back to INVITE with OK.
[0088] 8. The UAM will mark the connection C2 as up. It then sends
OK on C1.
[0089] Media Streams in This Example
[0090] The media streams between V1 and UD1 are sent in either of
following ways:
[0091] 11. The media is sent directly from V1 to UD1. This can be
done by UAM writing the right SDP. Thus while sending INVITE to V1
it puts the IP address, port of UD1 for receive. And while sending
OK to UD1 it puts the IP address, port of V1 as receive
address.
[0092] 12. The media is relayed by UAM. In this case, UAM relays
data from V1 to UD1 and vice-a-versa. It is easy to see that if UAM
and ViPr communicate are connected via an ATM cloud, then an SVC
between V1 and UAM could be set up. Thus, the UAM acts as an ATM to
Ethernet gateway for media traffic.
[0093] Extending the example 1 further, User_A decides to join
User_B at V2 into the conference. The following events happen:
[0094] 1. The Sip connection between UAM and V1 is replaced by A
conference call C3 with V1, V2 and UAM as participants. Thus, the
B2B UA is now cross connecting a conference call (C3) with a
unicast call (C1).
[0095] 2. UAM always relays traffic between C3 and C4. Option 11
above. It mixes the traffic from V1 and V2 and relays it to UD1. It
also multicasts traffic from UD1 to V1 and V2.
[0096] The functionality performed by the UAM can be broken into
following components:
[0097] SIP B2B UA Unit [SBU]. This unit performs the sip signaling
required to implement the B2B SIP UA.
[0098] Media Cross Connect and Mixer [MCMU].
[0099] The UAM functionality will be decided across three
processes: SBU, Unicast Mixer Manager and Sip stack, as shown in
FIG. 2.
[0100] The SipServer process will implement the SIP functionality
and would provide the SBU with an abstracted signaling API
(Interface Ia). Interface Ia also stays unchanged.
[0101] The SBU implements the call control and glue logic for
implementing the B2B UA. This unit derives from Callmanager/Vupper
code base. The SBU is responsible for setting up the right mixer
streams too. For this purpose, SBU interfaces with the UMM process
through RPC.
[0102] UMM implements the functionality for cross-connecting media
streams as well as implementing the audio mixing functionality.
[0103] The SBU implements the call control and glue logic for
implementing the B2B UA. The SBU is responsible for setting up the
right mixer streams too. For this purpose, SBU interfaces with the
UMM process through RPC.
1 Session Class MediaSession { int SelfID // Self ID CVString GUID
// Conference Call ID CVList XIDList; // List of cross connects
GUID } SIPB2BCrossConnect Class SIPB2BCrossConnect { int SelfID //
Self ID int SessionID // Of session of which it is a member Int
ViPrLegID // SiPCallLeg connected to ViPr Int UDLegID // Leg
connected to unicast device. } SIPB2BCallLeg Class
SIPB2BCrossConnect { int SelfID // Self ID - returned by
callmanager int XID // ID of Cross Connect who owns this leg
SipCallLeg ViPrLeg // Leg connected to ViPr SipCallLeg UDLeg // Leg
connected to unicast device. }
[0104] The SBU unit is internally structured as follows:
[0105] As can be seen from FIG. 3, the design for SBU reuses and
extend the SIP/Media Stream interface offered by the CallManager to
implement the signaling call control logic for UAM.
[0106] The following text presents the flow of control when the
user A initiates a call to User_B.
[0107] In the following SipServer refers to SipServer at UAM, SBU
refers to SBU at UAM and UMM refers to UMM at UAM.
[0108] To clarify the example further, assume the following:
[0109] The entire network is Ethernet network
[0110] IP address of V1 is 172.19.64.101
[0111] IP address of V2 I 172.19.64.101
[0112] IP address of interface of UAM which is connected to V1/V2
cloud is 172.19.64.51, IP interface of UAM connected to UD1 cloud
is 169.144.50.100
[0113] IP address of UD1 is 169.144.50.48
[0114] Address is represented as <IpAddress, port>tuple
[0115] All the addresses and ports in the example are illustrative,
they are not required to be fixed but are rather allocated by
OS.
[0116] In the following example, all the SIP events received by SBU
(at UAM) are actually received by SipServer and than passed to SBU.
However, the Sipserver receiving the event and passing it to SBU is
not shown for brevity.
2 Flow of control for a P2P call between UD1 and V1 # Loc Action 1
UD1 INVITE sent from UD1 to SD1. This invite contains the Address
<169.144.50.48, 50000> for receiving stream from UD1 for this
call. 2 SBU SBU gets an incoming call C1. SBU examines the call and
sees it is from a Unicast device. It then performs the following
actions. Extracts the address (User_B) of final destination UD1 is
trying to reach. It allocates address <172.19.64.51, 40002>
for receiving media stream from V1. It initiates an outgoing call
(C2) to User_B by asking sipserver to send an INVITE to User_B.
This invite contains the address <172.19.64.51, 40002>. It
also allocates a sip cross connect (XID = 1) and binds C1 and C2 to
XID = 1. At this point sip cross connect XID = 1 C1 and C2 as a
back-to-back calls. It also stores XID = 1 in the calls C1 and C2.
This is to enable retrieving XID from Call ID. 3 V1 V1 receives an
incoming INVITE and accepts the call by sending an OK to UAM. The
OK contains address <172.19.64.101, 10002> for receiving
traffic from UAM. 4 SBU SBU Gets OK (call accept event) on C2. It
the performs following steps: Receives the cross connect (XID = 1)
of which C2 is a member. Allocates an address for use of C2.
<169.144.50.100, 40001> Instructs SipServer to send OK On
call C2. This OK contains address <1169.144.50.100, 40001>
for receiving media from UD1. Allocates a Session with ID (say, SID
= 100). This session ID is stored in Sip Cross connect XID = 1. The
SipCross connect with XID = 1 is also added to the list of
Cross-connects part of this session. At this time, there is just
one SIP cross connect in the list. SBU then allocates a media
channel to be used for receiving and sending data from UD1, say
with CHID = 0. SBU allocates a media channel to be used for sending
and receiving data from V1, say CHID-1. SBU then informs UMM to
setup channels for sending and receiving data from V1 and UD1 as
follows: SBU informs UMM that channel = 0 should be used to
send/receive data to/from UD1. This is done by asking UMM to
associate channel = 0 with send address <169.144.50.48,
50000> and Receive address <169.144.50.100,40001>. SBU
informs UMM that channel = 1 should be used to send/receive data
to/from V1. This is done by asking UMM to associate channel = 0
with send address <172.19.64.101, 10001> and Receive address
<172.19.64.51, 40002>. SBU then instructs the UMM to
construct a media cross connect by informing UMM that Channels CID
= 0 and CID = 1 are part of same session SID = 100. It should be
noted that UMM is not informed (nor does it care) about the SIP
calls C1 and C2. 5 UD1 Receives an OK from UAM. It knows from OK
that for sending audio media to UAM it must use the address
<169.144.50.100, 40001>.
[0117] The above table explains what happens for a pass through
call. The following is the control flow when this call is converted
into a conference call. In this case, say User_B conferences User_C
at V2 into the call.
[0118] Further assume the following:
3 IP address of V2 is 171.19.64.102 Initiating a conference with a
user on unicast device. # Loc Action 6 V1 V1 # Sends an INVITE to
Conference Host H (at V1) to initiate conference. The INVITE
contains the multicast IP address <239.192.64.101, 10002> on
which V1 would multicast its audio stream. 7 H Host Gets an INVITE
to start a conference call. It sends an OK back to V1. H also
constructs a globally unique ID for this conference call. (say,
GUID = 900). 8 V1 Refers UAM into the conference (with Replaces =
C2). 9 H Sends an INVITE to UAM with following information: GUID =
900 Replaces = C1 Stream information for V1(User_B)
<239.192.64.101, 10002> 10 SBU On getting Invite for a
conference call (C3) SBU performs following: Sees that Replace ID =
C2. It thus knows that V1 wants to bring POTS1(UD1) into Conference
GUID = 100. It Retrieves the SIP Cross-connect XID = 1 from C2. It
retrieves the Session ID from the SipCross Connect, SID = 100. And
sets the GUID member of the Session to GUID = 900. It Sets the GUID
in Sip Cross-connect XID = 1 to GUID = 100. It releases the sip
connection C2 by informing SipServer to send a Bye on C2. Removes
C2 from SIP Cross-connect XID = 1 and replaces it with C3. It also
sets the SIP cross connect ID in C3 to XID = 1. It also sets the
XID member within C3 to point to XID = 1. It allocates address
<239.192.64.51, 40003> for transmitting data on behalf of
UD1. It informs UMM to delete channel CID = 1. Thus UMM will now
stop transmitting media to address <172.19.64.101, 10001> and
stop receiving media at address <172.19.64.51, 40002>. It
sends an OK back to the Host. The OK contains information that
everyone on the conference should send receive media streams from
POTS1(UD1) on address <239.192.64.51, 40003>. SBU then
instructs UMM to set up the right audio streams for conference
(GUID = 900) with V1 and UD1 present as participants as follows:
SBU informs that channel = 2 should be used to send/receive data
to/from V1. Thus channel = 2 is associated with send address
<239.192.64.51, 40003> and Receive address
<239.192.64.101, 10002>. SBU informs UMM to associate channel
= 2 with Session SID = 100. SBU informs the UMM to set the
retransmit address field for channel = 0 <239.192.64.51,
40003>. It should again be noted that UMM is not aware of either
the presence of SIP calls C1 and C3, nor does not it know that
there is a conference call with GUID = 900. Internally, UMM does
not really look at the send address in channel = 2 to relay data
from UD1 to conference. Rather, it looks at the retransmit address
in the Channel ID = 2. 11 Host Gets OK from UAMD. It sends a
RE_INVITE to V1 indicating the presence of stream from User_A at
<239.192.64.51, 40003>. 12 V1 Refers User_C at V2 into the
conference. 13 H Sends an INVITE to V2 indicating presence of
streams from User_A at and User_B. 14 V2 V2 sends an OK. The OK
contains the multicast IP address <239.192.64.102, 20001> on
which V1 would multicast its audio stream. At this point, User_C
can start listening to audio from User_A and User_B by registering
to appropriate multicast addresses. 15 H Sends a RE_INVITE to V1
and UAMD indicating presence of a new participant User_C sending
audio at <239.192.64.102, 20001>. 16 V1 Gets a RE_INVITE and
sees that party User_C is now on the call. It sends an OK back to
H. 17 SBU Gets a RE_INVITE and sees that a new party User_C is also
on conference call with GUID = 900. It then performs following
steps: Sends an OK back to the Host through sip server. Allocates a
media channel CID = 3 for receiving traffic from User_C. Informs
UMM to join media from User_C into the conference call identified
by GUID = 900 as follows: SBU informs UMM that channel = 3 should
be used to send/receive data to/from (User_C) at V2. Thus, channel
= 3 is associated with send address <239.192.64.51, 40003>
and Receive address <239.192.64.102, 20001>. SBU informs UMM
to associate channel = 2 with Session SID = 100. It should be noted
again that all UMM knows is that there are three channels (CID = 0,
2 and 3) which all belong to the same session. UMM knows that CID =
2 and 3 are streams from ViPr phone and CID = 0 are from a unicast
device. Thus, UMM reads multicast data from channels CID = 2
(<239.192.64.102, 20001> and CID = 3 (<239.192.64.101,
10002>) mixes them and sends it on channel = 0<169.144.50.48,
50000>. Also the data read from channel CID = 0, is
retransmitted on retransmit address associated with CID = 0
<239.192.64.51, 40003>. The details of how UMM performs this
appropriate mixing are in a different section. 18 H Gets the OK for
re-invites sent in step 16. The conference call is now up.
[0119] To add another ViPr user to the conference, steps 12 through
18 are repeated. Consider the steps that are required to another
Unicast Device user say User_D on POTS2.
[0120] Assume the following:
[0121] User_C on ViPr V2 decides to conference in User_D on POTS2
into the conference.
4 Flow of control for adding second unicast user to a conference. #
Loc Action 19 V2 Refers User_D at POTS2 into the conference. 20 H
Sends an INVITE to UAM with following information: User_A, User_B
and User_C call along with the addresses on which they are
generating media streams. GUID = 900 21 SBU Gets Request for an
incoming conference call (C4) with GUID = 900 To address = Address
of User_D It then performs following tasks: It allocates a SIP
Cross-connect with ID, XID = 2. It adds C4 to the sip cross connect
XID = 2. It also sets the XID member within C4 to XID = 2. It
searches all the Session structures to see if there is a session
with GUID = 900. It finds that a session with ID = 100 is
associated with this conference call. It then adds SIP cross
connect with XID = 2, to the list of cross connects attached to
Session SID = 100. At this point there are two SIP cross connects
(XID = 1, and XID = 2) which are part of the SIP session SID = 100.
It also stores information within sip cross connect XID = 2, to
indicate it is associated with Session = 100. It allocates an
address <169.144.50.51, 40011> for receiving traffic from
User_D. It allocates a media channel CHID = 4 for receiving traffic
from User_D <239.192.64.51, 40012>. It initiates a connection
C5 by sending an INVITE to UD1 for User_D. The INVITE contains the
information that UD1 should send audio media streams for this call
at <169.144.50.51, 40004>. It adds C5 to the sip cross
connect of XID = 2. Thus XID = 2 is now connecting CID = 4 and CID
= 5 as back to back SIP calls. It also sets XID member of C5 to XID
= 2. 22 UD1 Receives INVITE from UAM and sends back an OK to UAM.
It indicates in the OK that the address on which it should be sent
data for call C5 is <169.144.50.48, 50002>. 23 SBU Receives
OK from UAM for C5. It then performs following steps: It retrieves
the sip cross connect of which C5 is a member, XID = 2. It
retrieves the session from sip cross connect, SID = 100. It then
allocates an address <239.192.64.51, 40012> to relay data
received on User_D into the conference, GUID = 900. It then sends
an OK to Host indicating that User_D would be generating traffic on
<239.192.64.51, 40012>. It then allocates channels for
receiving traffic User_A (CHID = 5), User_B (CHID = 6) and (CHID =
7). It then asks UMM to add User_D into the conference as follows:
SBU informs UMM that channel = 4 should be used to send/receive
data to/from User_D. Thus channel = 3 is associated with send
address <169.144.50.51, 40011> and Receive address
<169.144.50.48, 50002>. SBU also informs UMM to set the
retransmit address of CHID = 4 to <239.192.64.51, 40012>. SBU
informs UMM that Channel = 5, 6 and 7 should be used to exchange
traffic with User_A, User_B and User_C. The following information
is provided for these channels. CHID = 5 [Rx = <239.192.64.102,
20001>, Tx = <239.192.64.51, 40012> CHID = 6 [Rx =
<239.192.64.101, 10001>, Tx = <239.192.64.51, 40012>
CHID = 7 [Rx = <<239.192.64.51, 40012>, Tx =
<239.192.64.51, 40012> SBU informs UMM to associate channel =
4, 5, 6, 7 with Session SID = 100 {Please note that CHID = 5 the
information for receiving packets from User_A is same as one
present in CHID = 2 and would seem like a waste and troublesome but
this has in fact has a desirable effect of not requiring any change
in call manager and also eliminates needs for book keeping in SBU.
Same holds for CHID = 3 and CHID = 6. The UMM would never receive
anything on CHID = 7 because multicasts are not received by the
host which transmitted them.} In the UMM there are two channels
CHID = 2 and 5 which are referring to the same receive multicast
address, now since both the channels belong to the same session =
100, it is not a problem. Since the UMM will not read packets from
duplicate channels. However, if Channel = 2 is deleted then UMM
will go and read packets from CHID = 5. 24 H Host receives the OK
on C5 (from UAM) with information added to receive audio streams
from User_D. It Sends a Re-Invite to User_A, User_B and User_C
indicating presence of a new stream from User_D. 25 SBU Gets a
REINVITE on C3 indicating presence of another user User_D
transmitting on multicast address <239.192.64.51, 40012> It
then performs following tasks: Sends an OK back to host on C3
through sip server. It retrieves the sip cross connect of which C3
is a member, XID = 1. It retrieves the session SID = 100 from sip
cross connect XID = 1 It allocates channel CHID = 8 to receive
audio from the User_D. It then instructs UMM to receive and mix
traffic from User_D into the Session SID = 100. as follows: SBU
informs UMM that channel = 8 should be used to send/receive data
to/from User_D. Thus channel = 8 is associated with send address
and Receive address <239.192.64.51, 40012>. SBU also sets the
session ID for channel CHID = 8 to SID = 100. [NOTE: Since UAMD
programs the IP sockets to never receive packets it has transmitted
on a multicast address, no traffic would be received on CHID = 8.
Which is exactly what is desired.]. 26 V1 Sends an OK to re-invite
sent by Host and V2 27 H Receives OK from all the participants, the
conference call now has 4 parties on call. Two of which are unicast
devices.
[0122] UMM implements the functionality for cross-connecting media
streams as well as implementing the audio mixing functionality.
[0123] Deployment Scenario 1
[0124] Referring to FIG. 4, this scenario covers two cases:
[0125] A ViPr user in a multi-party ViPr audio/video conference
adding a unicast audio-only telephone user to the conference:
[0126] In this case, ViPr users in multi-party ViPr conference
decide to add a unicast telephone user to the conference. As a
result, one of the participants initiates a call to the destination
telephone number. The ViPr SIP server redirects the call to the
ViPr UAM. The ViPr UAM terminates the ViPr audio-only call and
establishes a back-to-back call to the destination telephone via
the telephony gateway.
[0127] Once the call is established, the ViPr UAM converts the
unicast G.711/G.722 audio stream received from the telephone into a
PMP/multicast stream and forwards it to the ViPr terminals without
any transcoding. On the other hand, the ViPr UAM performs
transcoding and mixing of the wideband 16 bit/16 KHz PCM ViPr audio
streams received from the various ViPr terminals into one G.711 or
G.722 unicast audio stream and forwards it to the telephone
destination.
[0128] A ViPr user in point-to-point audio-only conference with a
telephone user adding another ViPr user to the conference:
[0129] In this case, a ViPr user (V1) in point-to-point audio-only
call with a telephone user (T) decides to add another ViPr user
(V2) to the conference. As a result, the ViPr user V1 initiates an
audio/video call to the destination ViPr user V2. The ViPr system
tears down the established point-to-point call between V1 and the
ViPr UAM and re-establishes a PMP/multicast call between V1, V2 and
the ViPr UAM.
[0130] The ViPr UAM terminates the new ViPr audio/video call and
bridges it to the already established back-to-back telephone call.
Throughout this process, the telephone call remains active and the
switching is transparent to the telephone user.
[0131] Once the call is established, the ViPr UAM converts the
unicast G.711/G.722 audio stream received from the telephone into a
PMP/multicast stream and forwards it to the ViPr terminals without
any transcoding. On the other hand, the ViPr UAM performs
transcoding and mixing of the wideband 16 bit/16 KHz PCM ViPr audio
streams received from the various ViPr terminals into one G.711 or
G.722 unicast audio stream and forwards it to the telephone
destination.
[0132] ViPr uses Session Initiation Protocol (SIP) as a means of
establishing, modifying and clearing multi-stream multi-media
sessions. The UAM will add conferencing capabilities between the
ViPr terminals and telephone users (i.e. PSTN, Mobile phones and
SIP phones) by converting upstream unicast voice-only telephone
streams into point-to-multipoint streams (i.e. PMP-SVC or IP
Multicast) and converting downstream ViPr multicast/PMP audio
streams to unicast telephone voice-only streams as well as
performing downstream audio transcoding of ViPr audio from wideband
16 bit/16 KHz PCM encoding to G.711 or G.722.
[0133] Deployment Scenario 2
[0134] Referring to FIG. 5, this scenario covers two cases:
[0135] A Telephone User Calling a ViPr User
[0136] In this case, a telephone user initiates a call (audio only)
to a ViPr user. The telephony gateway redirects the call to the
ViPr UAM. The ViPr UAM terminates the telephone call and
establishes a back-to-back ViPr audio-only call to the destination
ViPr terminal.
[0137] Once the call is established, the ViPr UAM forwards the
G.711/G.722 audio stream received from the telephone to the ViPr
terminal without any transcoding. On the other hand, the ViPr UAM
performs transcoding of the ViPr audio stream from wideband 16
bit/16 KHz PCM to G.711 or G.722 and forwards it to the telephone
destination.
[0138] A ViPr User Calling a Telephone User
[0139] In this case, a ViPr user initiates a call to a telephone
user. The ViPr SIP server redirects the call to the ViPr UAM. The
ViPr UAM terminates the ViPr audio-only call and establishes a
back-to-back PSTN call to the destination telephone via the
telephony gateway. Transcoding is done in the same way as described
in the previous paragraph.
[0140] FIG. 6 gives a typical usage context for UAM. The features
provided by the UAM are the following.
[0141] Feature 1
[0142] Say that ViPr V1 and V2 are in a point-to-point call and
they wish to engage Unicast Device UD1 in a conference call. Put in
other words the intent is to form a conference call with UD1, V1
and V2 in conference. Say user at V1 requests that user at UD1 be
joined into the conference call with V1 and V2 as other parties.
This request is forwarded by one of the SIP servers to the UAM. UAM
then performs the following tasks:
[0143] It joins the conference call on behalf of UD1. Call this
conference call C1.
[0144] It also makes a point-to-point call with the Unicast Device.
Call this conference call C2.
[0145] It relays audio data received on C2 to C1.
[0146] It accepts the audio data from V1 and V2 parties in call C2,
mixes and forwards this data to UD.
[0147] Feature 2
[0148] Consider the case where vipr-net in the figure above is ATM
and UD-net is an IP network. Also, suppose that it is desired that
to the extent possible only SVCs be used over the ATM network for
audio rather than LANE/CLIP. This could be for security concerns or
for performance issues.
[0149] In this case, if a ViPr V1 on vipr-net wishes to engage a
unicast device (UD1) in an audio conversation, than UAM is used to
provide functionality to use SVC in the ATM network and IP in the
IP network.
[0150] To do this all call from V1 to UD1 is broken into two calls
from V1 to UAMD and from UAMD to V2.
[0151] The configuration required for features supported by UAM can
be broken into following categories:
[0152] Configuration for ViPr to UD calls.
[0153] Configuration for UD to ViPr calls.
[0154] General configuration
[0155] General Configuration
[0156] The B2BUA SIP UA is made to run on any desired port (other
than 5060). This is done by modifying the vipr.ini file to include
following parameter:
[0157] SIP_Port=7070[any valid port number]
[0158] Configuration For ViPr to UD Calls
[0159] For a typical ViPr call when a user dials a "number" its
"call-request" is sent to SIP Server which than forwards it to the
appropriate destinations. However, this case is different. In this
case, when a user says I wish to talk to unicast device (UD1) the
SIP Server forwards the request to UAM. In addition, it also puts
information in the request to identify that this call should be
forwarded to UD1. Thus, the SIP Server is programmed to route calls
made to the SIP-URIs serviced by the UAM devices to the appropriate
UAMD Server.
[0160] It is also possible to specify a default unicast device SIP
address to which to forward all calls received by the UAM. This
default address can be specified in vipr.ini file by adding
following lines:
[0161] UD_SERVER_ADDRESS=169.144.50.48
[0162] X_FORWARD_AVAILABLE=0
[0163] It should be noted that when a call is made from a unicast
device to a ViPr, the call has to be delivered to the UAM. To do
this, appropriate configuration is performed at unicast device,
please refer to unicast device specific documentation for this.
[0164] Configuration for UD to ViPr call
[0165] The calls originating at the UD for a ViPr are routed to the
UAM. One way to achieve this is by programming the UD to
direct/forward all calls to UAM. Also, the eventual destination of
the calls (say V1) is specified in the call request to UAM.
Typically, this address will be the To field in the SIP message.
These configurations are performed at the UD or the SIP Server.
[0166] In addition, when UAM receives a call request from a UD, it
forwards it to a gateway Marshall server for performing sanity
checks on the called party. This gateway address can be specified
in the vipr.ini file
GatewayMarshallServer=sip.eng.fore.com:5065
[0167] List of Acronyms
5 ATM Asynchronous Transfer Mode ISDN Integrated Services Digital
Network IP Internet Protocol LAN Local Area Network MC Multicast
(IP) MCMU Media Cross Connect and Mixer MCU Media Conferencing Unit
PBX Private Branch Exchange (private telephone switchboard) PCM
Pulse-Code Modulation PMP Point-to-Multipoint (ATM) POTS "Plain Old
Telephone System" PRI Primary Rate Interface (ISDN) PSTN Public
Switched Telephone Network SBU SIP back-to-back user agent SIP
Session Initiation Protocol SVC Switched Virtual Circuit (ATM) UAM
Unicast Audio Mixer ViPr .TM. Virtual Presence System WAN Wide Area
Network
[0168] Although the invention has been described in detail in the
foregoing embodiments for the purpose of illustration, it is to be
understood that such detail is solely for that purpose and that
variations can be made therein by those skilled in the art without
departing from the spirit and scope of the invention except as it
may be described by the following claims.
* * * * *