|
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to teleconferencing systems. More
specifically, the present invention relates to a messaging protocol and
method for identifying application capabilities for teleconference
connections.
2. Background Information
Teleconferencing is increasingly becoming a popular application in personal
computer systems. Such applications typically allow the transfer of audio
and video data between users so that they can speak and otherwise
communicate with one another. Such applications sometimes also include
data sharing wherein various types of data such as documents,
spreadsheets, graphic data, or other types of data, can be shared and
manipulated by all participants in the teleconference. Different
teleconference applications perhaps residing on different hardware
platforms have different capabilities. Moreover, a wide variety of
features has been implemented in different teleconference applications,
and the proliferation of different types of computer systems with
different capacities, and different networking media has created
challenges for teleconferencing.
For example, for most teleconferencing applications, it is assumed that the
sender and the receiver have certain minimum capabilities. However, with
the wide diversity of systems having different computation capacities, and
in addition, the wide variety of networking media, that certain systems
may not have certain capabilities. For example, the first system may be a
high performance workstation coupled to a high performance communication
medium whereas a second system may employ an earlier generation processor,
operate at a substantially slower clock rate, and/or be coupled to a lower
capacity communication medium. Certain network capabilities such as
multicast or other optimization features, may not be present in certain
networking media. Thus, in order for some teleconference applications to
function, the participants in the conference can only operate at the
fastest possible configuration provided by any minimum system which may
participate in the teleconference. Of course, this results in certain
inefficiencies, especially if both of the participants are capable of
transmitting in a higher capacity than the system with the least possible
capability.
Another issue in teleconference applications is the ability of certain
stations to participate in more than one teleconference. In fact, in
certain circumstances, multiple individual conferences may be desired to
be merged by a user according to operating circumstances. Due to the
distributed nature of certain networks, during this merge operation,
certain circumstances may change. That is, that while a single station is
merging more than one conference it is participating in, a second station
at a remote location may further have other operating circumstances
changing (e.g., participants leaving, entering, or otherwise joining an
on-going teleconference), and thus, the management of such merging
operations becomes unduly burdensome.
Yet another shortcoming of certain prior art teleconference applications is
the ability to associate an independent data stream with an on-going
teleconference. For example, a source participant may desire to provide an
additional data stream to other participants in a teleconference. This
additional source may include, but not be limited to, video, data, audio
or any other type of data available to the source participant. For
example, such an additional source may include other audio information for
a receiver. Other types of data may also be desired to be associated with
an on-going teleconference, which may be accessible to other participant
in the teleconference. Certain prior art teleconferencing applications
lack these abilities.
SUMMARY
An automatic method for communicating information, such as teleconference
data between teleconferencing systems. A first endpoint identifies
communication capabilities to a second endpoint via a first message. The
first endpoint notifies the second endpoint of the desire to connect via a
second message. The second endpoint notifies the first endpoint of
confirmation to connect via a third message. The first and the second
endpoint then establish communication according to the communication
capabilities. The first and the second endpoint can optimize transfers of
teleconference data according to the identified communication
capabilities.
The method can further include the step of the first endpoint identifying
application capabilities to the second endpoint prior to the step of
identifying communication capabilities. The application capabilities can
include required, desired, optional, or negotiated capabilities. The
method can also further comprise the steps of the second endpoint
retrieving a timeout value from the second message and dynamically
responding to the first endpoint according to the timeout value and a
current context.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation
in the figures of the accompanying in which like references indicate
similar elements and in which:
FIG. 1 illustrates an example configuration in which various embodiments of
the present invention may be implemented.
FIG. 2 shows a typical teleconferencing display which has both media and
non-media sources displayed during the course of the teleconference.
FIG. 3 shows a single system in which embodiments of the present invention
may be implemented.
FIG. 4 shows an example architecture of a system employing various
embodiments of the present invention.
FIG. 5 shows a more detailed view of the conference component illustrated
in FIG. 4.
FIG. 6 shows a sequence of typical conference events in a conference
component which are issued to an application.
FIG. 7 shows a typical sequence of steps performed for member
initialization within the conference component.
FIGS. 8-10 show typical exchanges of messages for different operations.
FIG. 11 shows a detail of a first endpoint establishing a teleconference.
FIG. 12 shows a sequence of steps performed in a second endpoint receiving
the messages sent from a first endpoint during the establishment of a
teleconference.
FIGS. 13-25 show details of the messages transmitted between endpoints
during various teleconferencing applications.
FIGS. 26a-26d show the steps taken for performing merge operations.
FIGS. 27a and 27b show the conferences before and after a merge operation
between teleconferences.
FIGS. 28a-28b show a sequence of steps performed by the conference
component during a merge operation.
FIG. 29 shows an example of a merged conferences table within a single
participant.
FIG. 30a-30b shows a sequence of steps performed for converting point to
point connections to multicast connections for a teleconference.
FIGS. 31 and 32 show the adding of an auxiliary source and the messages
during the adding of the source to an existing teleconference.
FIGS. 33-34 show the details of a sequence of steps performed within a
participant for adding an auxiliary source.
FIGS. 35a-35b show an example sequence of messages which are sent between a
first endpoint and a plurality of other endpoints in a networking system,
and showing various messages transmitted therebetween.
DETAILED DESCRIPTION
A typical system configuration in which a teleconference may take place is
illustrated as 100 in FIG. 1. For example, a first workstation 150 may
communicate via teleconference with a second workstation 155, as
illustrated. Workstations 150/155 may include a central processing unit
150c/155c which is coupled to a display 150d/155d, a video input device
150a/155a, and a sound input device 150b/155b. The workstation 150 may
communicate with workstation 155 over networking medium 170 via network
adapter 160 which may include any number of network adapters commercially
available such as using Ethernet, Token Ring, or any other networking
standard commercially available. Note that network adapter 160 may also
include a wireless network adapter which allows transmission of data
between components without a medium 170. Communication is thus provided
via network adapter 165 coupled to workstation 155, and bi-directional
communications may be established between the two workstations.
Workstations 150/155 further include a keyboard 150e/155e and a pointing
device 150f/155f, such as a mouse, track ball, or other device for
allowing user selections and user input.
A teleconference display is shown at 200 at FIG. 2. In implemented
embodiments of the present invention, there is a source window, such as
201, showing a monitor of the local media source, and there are other
media windows, such as 202 or 203 for each other user with which a
participant is having communication. In the illustrated example, each of
the windows 201-203 provides media information, that is, real-time audio
and/or video information for bidirectional teleconferencing. In alternate
embodiments of the present invention, non-media information such as 204
may also be displayed within the teleconferencing display. As will become
apparent in the description below, in addition to media and non-media
information, messaging information may also be transmitted between
stations. In addition, an auxiliary media source (e.g. audio or video
information) may be transmitted with a specified conference. The details
of this will be discussed in more detail below.
In implemented embodiments of the present invention, a general purpose
computer system is used for implementing the teleconferencing applications
and associated processes to be described here. Although certain of the
concepts to be described here will be discussed with reference to
teleconferencing, it is apparent that the methods and associated apparatus
can be implemented for other applications, such as file sharing, real time
data acquisition, or other types of applications which sends data from a
first participant to a second participant or set of participants. A
computer system such as that used for implementing embodiments of the
present invention will now be described.
A computer system, such as a workstation, personal computer or other
processing apparatus 150c or 155c as shown in FIG. 1 is illustrated in
more detail in FIG. 3. 150c comprises a bus or other communication means
301 for communicating information, and a processing means 302 coupled with
bus 301 for processing information. System 150c further comprises a random
access memory (RAM) or other volatile storage device 304 (referred to as
main memory), coupled to bus 301 for storing information and instructions
to be executed by processor 302. Main memory 304 also may be used for
storing temporary variables or other intermediate information during
execution of instructions by processor 302. Included in memory 304 during
run-time may be the conference component module which operates according
to the communication protocols to be described below. System 150c also
comprises a read only memory (ROM) and/or other static storage device 306
coupled to bus 301 for storing static information and instructions for
processor 302, and a data storage device 307 such as a magnetic disk or
optical disk and its corresponding disk drive. Data storage device 307 is
coupled to bus 301 for storing information and instructions.
System 150c may further be coupled to a display device adapter and display
321 such as a cathode ray tube (CRT) or liquid crystal display (LCD)
coupled to bus 301 for displaying information to a computer user. Such a
display 321 may further be coupled to bus 301 for the receipt of video or
image information. An alphanumeric input device 322, including
alphanumeric and other keys may also be coupled to bus 301 for
communicating information and command selections to processor 302. An
additional user input device is cursor control 323, such as a mouse, a
trackball, stylus, or cursor direction keys, coupled to bus 301 for
communicating direction information and command selections to processor
302, and for controlling cursor movement on display 321. For
teleconferencing applications, system 150c may also have coupled to it a
sound output device 324, a video input device 325, and sound input device
326, along with the associated D/A (Digital-to-Analog) and A/D
(Analog-to-Digital) converters for inputting or outputting media signal
bitstreams. System 150c may further be coupled to communication device 327
which is coupled to network adapter 160 for communicating with other
teleconferencing stations.
Note, also, that any or all of the components of system 150c and associated
hardware may be used in various embodiments, however, it can be
appreciated that any configuration of the system may be used for various
purposes according to the particular implementation.
In one embodiment, system 150c is one of the Apple Computer.RTM. brand
family of personal computers such as the Macintosh 8100 brand personal
computer manufactured by Apple Computer, Inc. of Cupertino, Calif.
Processor 302 may be one of the PowerPC brand microprocessors manufactured
by Motorola, Inc. of Schaumburg, Ill.
Note that the following discussion of various embodiments discussed herein
will refer specifically to a series of routines which are generated in a
high-level programming language (e.g., the C or C++programming language)
and compiled, linked, and then run as object code in system 150c during
run-time within main memory 304 by processor 302. For example the object
code may be generated by the C++Compiler available from Symantec, Inc. of
Cupertino, Calif.
Although a general purpose computer system has been described, it can be
appreciated by one skilled in the art, however, that the following methods
and apparatus may be implemented in special purpose hardware devices, such
as discrete logic devices, large scale integrated circuits (LSI's),
application-specific integrated circuits (ASIC's), or other specialized
hardware. The description here has equal application to apparatus having
similar function.
FIG. 4 illustrates a plurality of processes and/or apparatus which may be
operative within system 150c. At the highest level, for example, at the
highest level in the ISO/OSI networking model, an application program 401,
such as a teleconferencing application, an audio/video server, or a data
server, communicates with conference component process 400 in the form of
Application Program Interface (API) calls. The conference component 400
allows the application to establish communications between two or more
teleconference stations. Control information, and media information can be
transmitted between the first participant system and a second participant
system. The conference component will be shown in more detail in FIG. 5.
Conference component 400 communicates with the transport component 402 by
sending MovieTalk messages for other teleconferencing stations which are
encapsulated and placed into a form that the transport component 402, the
network component 403, and the system network component 404 can packetize
and transmit over networking medium 170. For the purposes of the remainder
of this disclosure, certain of the MovieTalk API calls and MovieTalk
messages which are transmitted between conference components in a
teleconferencing system will be described in more detail.
The transport component 402 and the networking component 403 provide the
necessary operations for communication over the particular type of network
adapter 160 and networking medium 170 according to implementation. For
example, networking component 402 may provide the TCP or ADSP protcols and
packetizing, according to those respective standards.
A more detailed view of the conference component 400 is shown in FIG. 5.
Specifically, the conference component 400 is shown in two portions 400a
and 400b which show input and output portions of the conference component.
Although illustrated as a separate transmitter and receiver, each
conference component in the system has both capabilities, so that full
bi-directional communication between conference components in respective
participant teleconference systems in a network may communicate with one
another. As illustrated, the input portion of the conference component
400a receives video and sound information over media input channels 510
and 520. The video channel component and sound channel component 504
present media data at regular intervals to sequence grabber 502. The
real-time sound and video data (hereinafter referred to as "media data")
are provided to a source stream director 500 from sequence grabber 502
which then provides the media messages to the transport component 402.
Flow Control 501 then lets the video and sound data flow through at an
implementation-dependent frequency. The video channel component 503, sound
channel component 504, and sequence grabber 502 all are implemented using
prior art products such as those commercially available (e.g., the
QuickTime video channel, sound channel components, and sequence grabbers,
available from Apple Computer, Inc. of Cupertino, Calif.) Flow control 501
may be implemented using known flow control apparatus and/or method as are
commercially available, such as those which regulate flow based upon
bandwidth, and other constraints in the source participant system. The
conference component further comprises a sink stream director 510 which
comprises a portion of the component 400b of the conference component for
receipt of media data from transport component 402. Corresponding flow
control 511, video and sound stream players 512 and 513, and compression
and sound manager 514 and 515, for output of video streams 530 and 540,
also form part of the conference component for full bi-directional
conferencing capabilities.
The conference component's main function is to establish and maintain a
bidirectional connection between every member of a conference.
Conferencing applications use a pre-established control channel to
exchange control data that is pertinent to the conference. This data might
include user identification information or other information that is
germane to the application's operation. Conferencing applications (e.g.,
401) define the format and content of these control messages by
establishing their own control protocols. The conferencing component
further establishes communication channels between a first endpoint and a
second endpoint, using the underlying transport component 402. Thus, once
a media channel has been established, the conference component uses the
transport component 402's media channel which is provided for transmission
| | |