System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint
A method and apparatus for optimizing transmission of data to a plurality of second endpoints in a system wherein a first endpoint is providing data to the plurality of second endpoints each connected by a point-to-point communication channels. This may be useful in teleconferencing applications with a plurality of participants (endpoints) or broadcast server applications. The first endpoint activates a multicast communication channel having a first multicast address and commences broadcast of the data over the multicast communication channel. The first endpoint transmits a request message to each of the plurality of second endpoints in order to query each of the second endpoints whether they can receive transmissions broadcast to the first multicast address. Certain of the plurality of second endpoints transmit an acknowledgment message if they can receive transmissions broadcast to the first multicast address, and the first endpoint receives the acknowledgment message. Then, for each acknowledgment message received from certain of the plurality of second endpoints, the first endpoint deactivates the point-to-point communication channel and the certain of the plurality of second endpoints.
Latest Apple Patents:
- METHOD OF LIFE CYCLE MANAGEMENT USING MODEL ID AND MODEL FUNCTION
- APERIODIC SRS TRIGGERING MECHANISM ENHANCEMENT
- TIMING ADVANCE TECHNIQUES TO MANAGE CROSS LINK INTERFERENCE IN 5G COMMUNICATION SYSTEMS
- Mesh Compression Texture Coordinate Signaling and Decoding
- Devices, methods, and graphical user interfaces for assisted photo- taking
This application is a continuation reissue of U.S. application Ser. No. 10/857,798 filed May 28, 2004 now U.S. Pat. No. Re. 40,704, issued Apr. 28, 2009, which is a continuation of U.S. Reissue application Ser. No. 10/020,515, filed Dec. 7, 2001, which is a reissue application of U.S. Pat. No. 5,999,977, issued Dec. 7, 1999, which is a continuation of U.S. patent application Ser. No. 08/468,715, now abandoned, filed Jun. 5, 1995, which is a continuation of U.S. patent application Ser. No. 08/396,198, filed Feb. 24, 1995, now U.S. Pat. No. 5,854,898 issued Dec. 29, 1998. Notice: More than one reissue application has been filed for the reissue of U.S. Pat. No. 5,999,977. The reissue applications are application Ser. Nos. 10/020,515, 10/857,798 (now U.S. Pat. No. Re. 40,704), 10/857,799, 10/857,805, 10/857,806, and 12/210,847 (the present application).
BACKGROUND OF THE INVENTION1. Field of the Invention
The present invention relates to teleconferencing systems.
More specifically, the present invention relates to the addition of a data stream, such as an auxiliary data stream to a teleconference.
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.
SUMMARYA method and apparatus for optimizing transmission of data to a plurality of second endpoints in a system wherein a first endpoint is providing data to the plurality of second endpoints each connected by point-to-point communication channels. This may be useful in teleconferencing applications with a plurality of participants (endpoints) or broadcast server applications. The first endpoint activates a multicast communication channel having a first multicast address and commences broadcast of the data over the multicast communication channel. The first endpoint transmits a request message to each of the plurality of second endpoints in order to query each of the second endpoints whether they can receive transmissions broadcast to the first multicast address. Certain of the plurality of second endpoints transmit an acknowledgement message if they can receive transmissions broadcast to the first multicast address, and the first endpoint receives the acknowledgement message. Then, for each acknowledgement message received from certain of the plurality of second endpoints, the first endpoint deactivates the point-to-point communication channel and the certain of the plurality of second endpoints.
The broadcast of the data and the multicast communication channel is terminated if at least two of the plurality of second endpoints do not transmit the acknowledgement messages containing a positive acknowledgement. In this instance, communication channels are maintained as point-to-point. Subsequent to commencing broadcast of the data to the multicast address, the first endpoint can receive detach messages from certain of the plurality of second endpoints, and if at least two of the plurality of second endpoints are not receiving the data, then the first endpoint can terminate the broadcast of the data and the multicast communication channel. Communication of the data in this instance also reverts to point-to-point communication channels.
In implemented embodiments, the acknowledgement message includes a response code which indicates whether the second endpoint can receive transmissions broadcast to the first multicast address. Also, in implemented embodiments, prior to the first endpoint activating the multicast communication channel having the first multicast address, it is determined whether the single communication medium supports broadcasting to the first multicast address, and if not, multicast cannot be activated.
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:
The present invention relates to networking systems, more specifically, the present invention describes a messaging protocol for establishing and maintaining teleconference connections between a plurality of participants in a networking system. Applications for this include, transmitting application and/or system capabilities between participants or potential participants in a teleconference, notifying participants of a teleconference that more than one teleconference should be merged, and addition of an auxiliary data stream to an on-going teleconference. Although the present invention will be described with reference to certain specific embodiments thereof, especially, with relation to certain hardware configurations, data structures, packets, method steps, and other specific details, these should not be viewed as limiting the present invention. Various modifications and other may be made by one skilled in the art, without departing from the overall spirit and scope of the present invention.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. Copyright Apple Computer, Inc.
A typical system configuration in which a teleconference may take place is illustrated as 100 in
A teleconference display is shown at 200 at
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
System 150c may further be coupled to a display device adapter 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® 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.
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
The conference component's main function is to establish and maintain a bi-directional 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 of media and non-media information. For the remainder of this application, however, the focus will be on the establishment of communication between a first and second participant (referred to as endpoints) or group of participants which may participate in a teleconference.
Application Program Interface (API)The application program 401 controls the conference component 400 by the issuance of MovieTalk application API calls. The conference component operates using an event-driven model wherein events pertinent to the application are issued to the application program. The application program can then take appropriate action either by modifying internal data structures within (creating a source or sink), and/or issuance of appropriate messages over the network to other connected participants, or potential participants. According to messages received by the conference component, a current context and API calls from the application, the conference component can take appropriate action.
A typical series of events which occur after the establishment of a teleconference by the conference component in an application is illustrated in
A typical application's initialization is shown as process 700 of
1. optional;
2. desired;
3. required; or
4. a negotiation message.
These types of capabilities are included in a capabilities list which is transmitted to endpoints, as will be described below. An “optional” capability is a message which is not required to be exchanged before setting up a conference. A “desired” capability is one which is not required that it be exchanged before setting up a conference, however, it is preferred that it is. A “required” capability is one which requires that a message be exchanged before setting up a conference. This may include access control or other messages which are transferred prior to setting up a conference. An access control capability may include the transmission of a account number and password prior to the commencement of a teleconference. A “negotiation message” is a capability which indicates that the application wishes to query the receiving application. In the case of a negotiation message capability, the type field associated with the capability allows the requests of information about the applications prior to the establishment of a conference (e.g. about the type of software and hardware components the application is interested in, such as sound). Any other types of exchanges which require negotiated information between applications may be set.
Once all individual capabilities have been set by the issuance of “Set Capabilities” API calls (e.g. MTConferenceSetCapabilities) to the conference component at step 702, a member may set its operating mode at step 704. The mode will be contained within a mode mask value which is sent in the API call to the conference component, and moreover, is included in certain messages transmitted from the conference component in the sender to the conference component in the receiver. The mode mask specifies the characteristics of a conference that the member makes available. Different capabilities, modes, and other initialization operations shown in
1. send media;
2. receive media;
3. shareable; and
4. joiner.
The “send media” mode flag indicates that the member intends to send media data in its conferences. Most members will want to send media, however, there will be instances where the member will be a receive-only member, thus the send media mode flag will not be set. The receive media mode flag indicates that the member intends to receive media in conferences. In the case of a send-only member (e.g., a server providing a real-time video and/or audio source), will have the receive media mode flag set to “off” (e.g., a numeric value ‘0’). The “shareable” mode flag indicates that the member is willing to share the conference media data with new conference members. Thus, in the instance of a send-only media server, the shareable mode flag would be set indicating that new members can receive the conference data.
The “joiner” mode flag indicates that all conference members are allowed to interact. This would allow two-way transmission between each of the conference members. However, the setting of this flag to “off” (e.g., a numeric value ‘0’) results in broadcast type conferences wherein one member sends media data to other conference members, but the individual conference members do not exchange any media data among themselves. Each of these mode flags is transmitted at the beginning of a connection (e.g., contained within the “hello” message 1400 in
By default, the conference component establishes conferences that are fully two-way media data capable, shareable, and joinable. If different characteristics are desired, then the application must call “set mode” (e.g. MTConferenceSetMode) at step 704, along with the appropriate flag(s) set. Conference mode settings are stored and associated with a particular conference ID in the sender's conference component so that when messages are created for that conference ID, the appropriate mode flags are transmitted along with the initialization or other messages sent before any other communications.
In addition to the capabilities and mode settings at steps 702 and 704, a time-out value associated with calls placed from the member may be set (e.g. using the API call MTConferenceSetTimeOut). The time-out value is then included at the beginning of certain messages preceding a conference in order to enable a recipient to determine when the caller will stop listening for responses. This allows certain features to be incorporated into participant conference components such as the smart triggering of events based upon context. For example, if the recipient is receiving a call, but a user does not wish to take the call at that time, the recipient's conference knows the time-out occurs and can take certain context-dependent action (e.g., forward the call, send a message, etc.).
The application can then invoke an API call “Listen for Call” (e.g. MTConferenceListen) which implements steps 708 and 710. At step 708, using the underlying transport to which the system is connected, a high level address is registered and published. This then allows other potential participants in the system to call the member. The registration and publication of the address is implementation-dependent, depending upon the media to which the system is connected. Then, at step 710, the conference component waits for incoming calls.
The conference component in the member enters an idle state wherein incoming messages, alerts for the transport component, API and calls will be detected and acted upon. Note that the capabilities, mode, and time-out values are all optional, and the default settings may be used by the member if none of these functions is required by the application. In the call to the MTConferenceListen function, the application must specify the networks on which the member is willing to accept calls. The conference component proceeds to register the member on those networks, doing whatever is appropriate in the various network contexts, and sends an mtListenerStatusEvent to the application to specify whether the registration attempt was successful. After listeners are operational, if another application desires to establish communication with the application, then an mtIncomingCallEvent is forwarded to the application.
As shown in
Conference components exchange a number of messages in order to establish, maintain, and terminate conferences. Conference components also send messages that encapsulate user data, that is, the data that is exchanged by the programs that are using the conference.
After establishing a transport connection but prior to establishing a conference channel with a remote system, a conference member may send either a Capabilities message 1300 or an Auxiliary message 1700. The member then sends a Hello message 1400 to identify itself, specifically its mode of operation (send media, receive media, shareable, or joiner) followed by a Call message 1500 (to set up a conference) or a Join message 1800 (to join to an ongoing conference). The remote member sends a Response message 1600 in answer to the Call or a Join message 1800. Once a conference is established, a member can combine calls or conferences by sending a Merge message 1900. Conference members may send or receive a Terminate message 2300 to end a conference. Connections initially are point-to-point between members of a conference. If the transport medium supports multicast addresses and more than one member is participating in a conference, a broadcast to a multicast address can be used as an optimization. The conference component uses the BroadcastRequest and BroadcastAck messages 2400 and 2500 to negotiate the transition from point-to-point to multipoint connections using multicast addresses.
All messages supported in the conference messaging protocol are preceded by a 2-byte character identifying the message type. For example for a capabilities message shown in
capabilitiesList 1306
-
- The member's capabilities. This field is optional. If specified, it contains a list of the member's capablilities. An application specifies its capabilities by calling the conference component's MTConferenceSetMessageCapabilities function.
The Capabilities message 1300 shown in
In response to a negotiation Capabilities message, the remote member formats a user data message, for example, containing available component subtypes. Note that this list may contain duplicate entries and entries with a value of NULL. To parse this array, a member must determine the array's size. After sending a Capabilities message 1300, the member sends a Hello message 1400 to establish a conference.
A Hello message (e.g., 1400 of
minimumVersion 1404
-
- The oldest version of the conference protocol supported by the sending component
maximum Version 1408 - The newest version of the conference protocol supported by the sending component.
conferenceMode 1412 - The desired conference operating mode. This field contains a value that corresponds to the operating mode the sender desires for this conference. Applications specify their desired mode by a SetMode API call (e.g. MTConferenceSetMode discussed above).
name 1416 - The name of the prospective conference member. This name identifies the entity that wants to join the conference, and may represent either an auxiliary data source or a new user. Applications specify a user name by calling the MTConferenceListen API call. The auxiliary name is specified in a MTAttachAuxiliary API call.
- The oldest version of the conference protocol supported by the sending component
The Hello message 1400 is the first step in establishing a conference. This message allows conference components on different systems to exchange basic identification and capability information. Before sending a Hello message 1400, a conference component may send either a Capabilities 1300 or an Auxiliary message 1700. The type of message sent depends upon the role the member anticipates playing in the conference. If the member is looking to join or start a conference, the conference component sends a Capabilities message. If the member is setting up an auxiliary media data source, the component sends an Auxiliary message 1700. Following this message, the conference component can enter the call setup phase by sending the Call message 1500. If the member wants to provide an auxiliary data source to an existing conference, or join an existing conference, the component sends the Join message 1800.
Call message 1500 of
callTime-out 1504
-
- The amount of time the calling component is willing to wait for an answer. This field specifies the number of ticks ( 1/60 of a second) the calling component will wait before deciding that the call has not been answered. Called components must respond within this time period. This value may be used by a potential responder for taking some automatic action if the user doesn't answer before the timeout.
ConferenceName 1508 - The conference name. If the caller is establishing a conference, this is the name the caller has assigned to the conference. If the caller is connecting to a conference server, the is the name of the server's conference. Applications set the conference name by calling the MTConferenceCall function.
callingConfID 1512 - The caller's unique conference identifier. This field uniquely identifies the caller's conference endpoint on the network. Conference components create conference identifiers on behalf of calling applications which are unique within the conference component. Call ID's are discussed with reference to 2200 of
FIG. 22 .
- The amount of time the calling component is willing to wait for an answer. This field specifies the number of ticks ( 1/60 of a second) the calling component will wait before deciding that the call has not been answered. Called components must respond within this time period. This value may be used by a potential responder for taking some automatic action if the user doesn't answer before the timeout.
The Call message 1500 shown in
The response message 1600 of
callResponse 1604
-
- The result. This field indicates the result of the preceding Call request. This field is set to ‘0’ if the request was successful. Otherwise, it contains an appropriate result code.
destinationConfID 1608 - The other endpoint's unique identifier. This field identifies the other participant in the conference.
The Response message 1600 allows the caller to determine the success of a Call or Join request. The Response message 1600 indicates how the user at the remote system reacted to the call (for example, whether the user answered the call). The callResponse field 1604 contains the request's result code. If non-zero, an error occurred and the request was not successful. Otherwise, the destinationConfID field 1608 identifies the endpoint with which the caller may now communicate.
- The result. This field indicates the result of the preceding Call request. This field is set to ‘0’ if the request was successful. Otherwise, it contains an appropriate result code.
The auxiliary message 1700 allows one member to alert the other members of a conference that it is about to provide an auxiliary media data source (a source associated with an ongoing conference). This message may be used in place of the Capabilities message 1300 if a participant is being alerted about the presence of an auxiliary media source. The member sends this message before sending the Hello and Join Messages 1400 and 1800, and then proceeds to adding an auxiliary data source to the conference.
parentConfID 1704
-
- The member's conference identifier. This field identifies the member's existing conference endpoint (the conference identifier the member supplied in the Call message when it first joined the conference). This allows other conference participants to identify the source of the auxiliary data within each participant.
The Auxiliary message 1700 informs other conference participants that a member is about to provide an auxiliary conference data source. For auxiliary data sources, this message replace the Capabilities message during early interactions. The member must send this message to each conference participant. The member then sends a Hello 1400 and a Join message 1800 to each participant. Other participants then accept the new data source by accommodating the Join request.
A Join message 1800 of
destinationConf ID 1804
-
- The remote endpoint's unique conference identifier. This field identifies the conference to join on.
callingConfID 1808 - Unique conference identifier. This field uniquely identifies the caller's conference endpoint on the network. Conference components create conference identifiers on behalf of calling applications. If the message is adding an auxiliary media data source, this is the auxiliary's identifier.
memberList 1812 - A list of other conference participants. This list identifies all other known conference participants that are willing to exchange data with new participants (that is, they have the Joiner Mode Mask [e.g. mtJoinerModeMask] set in their conference mode). The conference component can connect with each participant with whom it is not already connected. If the message is adding an auxiliary (via the issuance of an auxiliary message 1700), this list contains the endpoint identifier of each participant to which the caller is making the auxiliary available. It is up to each of them to respond.
- This is a list of conference endpoint identifiers; each element in the list is followed by a newline character.
- The remote endpoint's unique conference identifier. This field identifies the conference to join on.
The Join message 1800 allows a member to add an auxiliary data source to an existing conference or to merge two existing conferences. The caller sends this message to members of the conference in response to a merge or join request instead of a call message.
The Merge message 1900 of
conferenceName 1904
-
- The new conference name resulting from the merge. This is the name that was assigned to the conference when the conference was established. Applications specify the conference name by calling the MTConferenceCall API function.
myConfID 1908 - Unique conference identifier. This field uniquely identifies the caller's conference endpoint in the target conference. Conference components create conference identifiers on behalf of calling applications.
memberList 1912 - A list of other conference participants. This list identifies other current conference participants. This list contains the endpoint identifier of each new participant. This is a list of conference endpoint identifiers; each element in the list is followed by a newline character.
- The new conference name resulting from the merge. This is the name that was assigned to the conference when the conference was established. Applications specify the conference name by calling the MTConferenceCall API function.
The Merge message causes the combination of two conferences. This is the mechanism for creating conferences with more than two participants. The caller sends this message to each existing conference member, specifying the conference's name. Each endpoint establishes communications with any new endpoints. By convention, the endpoint with the higher conference identifier value establishes the connection (to avoid duplicate or missed connections). Members of the conference receive a Join message 1900 instead of a Call message 1500 when contacted by each new member.
Field SpecificsA capabilities list such as shown in
type 2002
-
- Identifies a message by reference to a unique type value.
version 2006 - Message version number. Specifies the most-recent version of the message that the application supports.
desires 2010 - Support level. This field indicates the level of support required by the application. Possible values are:
- mtMessageOptionalCapability
- Optional. Indicates that the message is optional. The value corresponding to this option is ‘O’.
- mtMessageDesiredCapability
- Desired. While still optional, this value indicates that the application prefers to receive this message early in the call (e.g. prior to establishing a call, one member may request that the recipient send his business card for long-term storage). The value corresponding to this option is ‘D’.
- mtMessageRequiredCapability
- Required. The application must receive this message. The value corresponding to this option is ‘R’.
- mtNegotiationMessageCapability
- Negotiate. The application wants to learn about the recipient's facilities. The value corresponding to this option is ‘N’.
- mtMessageOptionalCapability
- Identifies a message by reference to a unique type value.
Conference identifiers such as 2200 shown in
UniqueID 2202
-
- Unique numeric identifier. This field contains a unique numeric endpoint identifier. Each conference component assigns its own identifiers in order to guarantee uniqueness within the context of a given name specified in the name field 2206.
name 2206 - A unique name. Identifies the system on the network. The name is unique within the context of a given transport interface. It includes the type of the selected transport and network interface.
- Unique numeric identifier. This field contains a unique numeric endpoint identifier. Each conference component assigns its own identifiers in order to guarantee uniqueness within the context of a given name specified in the name field 2206.
A member list such as 1812 of
The Terminate message 2300 of
The Terminate message 2300 is the last step in ending a member's participation in a conference. This message ends the member's conference communication with all participants to which it sends the message. If a member is leaving a conference altogether, it must send this message to each conference participant.
The BroadcastRequest message 2400 allows a member to find out if another conference member can accept broadcast (multicast) messages.
subtype 2406
-
- The broadcast message subtype. This field must be set to ‘R’.
multicastAddress 2410 - The proposed multicast address. This field contains the multicast address on which the member proposes to send broadcast messages.
- The broadcast message subtype. This field must be set to ‘R’.
The BroadcastRequest message 2400 allows a member to determine whether another conference member can accept broadcast messages over a given multicast network address. The recipient indicates its ability to support the broadcast messages by sending a BroadcastAck message 2500 (described below). If the recipient cannot support broadcast messaging or cannot access this particular broadcast transmission, the calling member should continue to send point-to-point messages to the recipient.
The BroadcastRequest message 2400 is typically uses as part of the negotiation process that follows merging two conferences or the joining of any new members to a conference. As an optimization, conference participants may choose to set up broadcast capabilities as a more-efficient alternative to maintaining several different point-to-point connections.
The BroadcastAck message 2500 allows a member to respond to a BroadcastRequest message 2400.
subtype 2504
-
- The broadcast message subtype. This field must be set to ‘A’.
broadcastResponse 2508 - The result. This field indicates whether the member can support the multicast address proposed in the BroadcastRequest message 2500.
- The broadcast message subtype. This field must be set to ‘A’.
The BroadcastAck message 2500 allows a member to indicate whether it can receive messages over a proposed multicast address. Another conference participant proposes a multicast address by sending a BroadcastRequest message 2408. If the recipient can support that address, it sets the broadcastResponse field 2508 to ‘0’. Otherwise, the broadcastResponse field 2580 contains an appropriate non-zero result code. This message is typically used as part of the negotiation process that follows merging two conferences. As an optimization, conference participants may choose to set up broadcast capabilities as a more-efficient alternative to maintaining several different point-to-point connections.
Join operations have the protocol illustrated in
The merge membership function 2664 is shown in more detail in
Merge operations are initiated using a “Merge” message (e.g., 1900 of
In addition to using conference ID's for performing merge and subsequent join operations, contained within each Merge and Join message is a list of members of the conferences being merged or joined. These are included in the memberList fields 1812 or 1912 of messages 1800 or 1900. For example, due to propagation delays in a networking system, old conference ID's may still exist in peripheral participants, and therefore during merging and or joining operations, conference ID's may become invalid due to members merging conferences, etc. . . . , or reference conference ID's which no longer exist. Thus, contained within each conference component in a member is a current conferences table such as 2900 shown in
An auxiliary media source can become part of an ongoing conference. The media source is associated with an ongoing conference by a invoking reference to the main conference stored in each conference component (e.g. by the API call MTConferenceAttachAuxiliarySource), however, it is treated as a separate conference in each conference component. For example, as illustrated with reference to
An example session using the protocols described above is shown in
Subsequent to the exchange of capabilities, hello, and call and response, a merge message 3514 is received by the first endpoint including the conference name “Some Conference”, a conf ID=137 “mtlkatlk Hillary Rodham: Video Phone: Video Zone” and a member list. The endpoint then processes the merge, placing a call sending capabilities, and hello to a member of the old conference, and a join along with the member list as shown by messages 3516, 3518, and 3520. Once the connection has been established, capabilities and hello messages 3524 and 3526 are received from the recipient. Responsive to the join the recipient sends a response message 3528 with the result=0 (request successful). Subsequent thereto, the endpoint then attempts to use a multicast address by transmitting broadcast request messages 3530 and 3532. The other members respond with broadcast Acks 3534 and 3536, allowing the use of multicast. The conference can then be terminated at any time by any of the members via the transmission of terminate messages to all of the members, such as 3538 and 3540.
Thus, by use of the foregoing, connections between endpoints, such as for teleconferences between teleconferencing systems, can be enabled. This includes, but is not limited to, the exchange of capabilities and notification of connections between endpoints, the addition of auxiliary data streams to such connections, and the merging of existing connections. It will be appreciated that though the foregoing has been described especially with reference to
Claims
1. In a system wherein a first endpoint is providing data to a plurality of second endpoints each connected by a point-to-point communication channel with said first endpoint, an automatic method for optimizing the transmission of said data to said plurality of second endpoints comprising the following steps:
- a. said first endpoint activating a multicast communication channel having a first multicast address and commencing broadcast of said data over said multicast communication channel;
- b. Said first endpoint transmitting a request message to each of said plurality of second endpoints in order to query each of said second endpoints whether they can receive transmissions broadcast to said first multicast address;
- c. certain of said plurality of second endpoints transmitting an acknowledgment message and said first endpoint receiving said acknowledgment message;
- d. for each said acknowledgment message received from said certain of said plurality of second endpoints which indicates that said certain of said plurality of second endpoints can receive transmissions broadcast to said first multicast address, deactivating said point-to-point communication channel with said first endpoint and said certain of said plurality of second endpoints; and
- e. terminating said broadcast of said data and said multicast communication channel if at least two of said plurality of second endpoints do not transmit said acknowledgment messages containing a positive acknowledgment.
2. The method of claim 1 further comprising the step of receiving detach messages from certain of said plurality of second endpoints, and if at least two of said plurality of second endpoints are not receiving said data, then terminating said broadcast of said data and said multicast communication channel.
3. The method of claim 1 wherein said each acknowledgment message includes a response code.
4. The method of claim 3 wherein said response code indicates whether each said certain of said plurality of second endpoints can receive transmissions broadcast to said first multicast address.
5. The method of claim 1 wherein said data includes teleconference data.
6. The method of claim 1 further comprising, prior to said step of said first endpoint activating said multicast communication channel having a first multicast address, determining whether more than one of said plurality of second endpoints is coupled to said first endpoint on a single communication medium, and if not, aborting said method.
7. The method of claim 6 further comprising, prior to said first endpoint activating said multicast communication channel having said first multicast address, determining whether said single communication medium supports broadcasting to said first multicast address.
8. The method of claim 1 wherein said data includes teleconference data between said first endpoint and said plurality of second endpoints.
9. An apparatus in a first endpoint for transmitting data to a plurality of second endpoints receiving said data from said first endpoint on point-to-point communication channels comprising:
- a. a circuit for activating a multicast communication channel having a first multicast address and commencing broadcast of said data over said multicast communication channel;
- b. a circuit for transmitting a request message to each of said plurality of second endpoints in order to query each of said second endpoints whether they can receive transmissions broadcast to said first multicast address;
- c. a circuit for receiving acknowledgment messages, if any, from certain of said plurality of second endpoints;
- d. a circuit for deactivating each said point-to-point communication channel with said certain of said plurality of second endpoints responsive to receiving each said acknowledgment message; and
- e. a circuit for terminating said broadcast of said data and said multicast communication channel if at least two of said acknowledgment messages containing a positive acknowledgment are not received.
10. The apparatus of claim 9 further comprising a circuit for receiving detach messages from others of said plurality of second endpoints, and if at least two of said plurality of second endpoints are not receiving said data, then terminating said broadcast of said data and said multicast communication channel.
11. The apparatus of claim 9 wherein said each acknowledgment message includes a response code.
12. The apparatus of claim 11 wherein said response code indicates whether each of said certain of said plurality of second endpoints can receive transmissions broadcast to said first multicast address.
13. The apparatus of claim 9 wherein said data includes teleconference data.
14. The apparatus of claim 9 further comprising a detection circuit operative prior to said first endpoint activating said multicast communication channel having said first multicast address for determining whether more than one of said plurality of second endpoints is coupled to said first endpoint on a single communication medium, and if not, not activating said circuits b and c.
15. The apparatus of claim 14 further comprising, prior to activation of said detection circuit a circuit for determining whether said single communication medium supports broadcasting to said first multicast address.
16. A method for merging at least two teleconferences by an initiating member, wherein said initiating member is participating in at least one of said teleconferences, said method comprising:
- providing a membership of a first teleconference and a membership of a second teleconference, wherein said first teleconference has a first unique conference identifier, and said second teleconference has a second unique conference identifier;
- transmitting at least a first message, wherein said first message comprises said first and second unique conference identifiers and a request to merge said first teleconference with said second teleconference;
- responsive to said first message, at least one of said membership of said first or second teleconferences establishing at least one communications link; and
- merging said membership of said first teleconference with said membership of said second teleconference based at least on said first or second unique conference identifier.
17. The method of claim 16, wherein said merging said membership of said first teleconference with said membership of said second teleconference based at least on said first or second unique conference identifier comprises merging based on both of said first and second unique conference identifiers.
18. The method of claim 16, wherein said membership of said first teleconference comprises a plurality of first members, and said membership of said second teleconference comprises a plurality of second members.
19. The method of claim 16, wherein said establishing said at least one communications link comprises establishing a point-to-point communications link between a member of said first teleconference and a member of said second teleconference.
20. The method of claim 16, additionally comprising the step of storing a merged membership, said merged membership based at least in part on said act of merging.
21. The method of claim 20, additionally comprising the step of assigning said merged membership to said first unique conference identifier.
22. The method of claim 16, additionally comprising no longer using at least one of said first and second unique conference identifiers after said merging is performed.
23. The method of claim 16, wherein after said merging is performed, said membership of said first teleconference and said membership of said second teleconference utilize said first identifier to identify the merged teleconference.
24. An apparatus for use in a first teleconference, said first teleconference comprising at least one member, said apparatus adapted to merge at least one member of a second teleconference with said first teleconference, said apparatus comprising:
- a first apparatus adapted to communicate within said first and second teleconferences;
- a second apparatus adapted to store and modify a list of members of said first and second teleconferences; and
- a computer readable apparatus comprising media adapted to contain a computer program having a plurality of instructions which, when executed: transmit a first message to one or more members of at least one of said first or second teleconferences, said first message comprising at least a first unique conference identifier and a second unique conference identifier; responsive to receipt of said first message, cause said one or more members to join said second teleconference to said first teleconference by negotiating one or more communications links; and create a merged teleconference comprised of at least a subset of the members of said first teleconference and said second teleconference.
25. The apparatus of claim 24, wherein said first message further comprises at least a portion of said list of members of said first and second teleconferences.
26. The apparatus of claim 24, wherein said negotiating said one or more communications links comprises establishing a point-to-point link between said one or more members of said first or second teleconference and a member of the other teleconference.
27. The apparatus of claim 24, wherein said apparatus is associated with a member of both said first and second teleconferences.
28. The apparatus of claim 24, wherein said apparatus is an endpoint device within at least one of said first and second teleconferences.
29. The apparatus of claim 24, further comprising:
- at least one application process;
- at least one conferencing process;
- at least one transport process;
- at least one network process; and
- at least one system process.
30. The apparatus of claim 24, further comprising at least one wireless network interface adapted to permit transmission of data to or from said apparatus without a wireline medium.
31. The apparatus of claim 24, wherein said plurality of instructions additionally, when executed, store a merged membership based at least in part on said merged teleconference.
32. The apparatus of claim 31, wherein said plurality of instructions additionally, when executed, assign said merged membership to said first unique conference identifier.
33. The apparatus of claim 24, wherein said at least one member of said second teleconference comprises an auxiliary source.
34. The apparatus of claim 33, wherein said auxiliary source comprises an auxiliary media source.
35. The method of claim 24, wherein said first message additionally comprises a request to merge said first teleconference with said second teleconference.
36. A method for merging at least two teleconferences by an initiating member, comprising:
- receiving a first message from said initiating member, wherein said first message comprises a merge request, a first unique conference identifier corresponding to a first teleconference, and a second unique conference identifier corresponding to a second teleconference;
- determining first and second lists of members, wherein said first list of members corresponds to said first unique conference identifier, and said second list of members corresponds to said second unique conference identifier;
- for at least one member of said first or second list, transmitting a second message initiating communication with said at least one member;
- receiving a third message, sent in response to said second message, from said at least one member of said first or second list, wherein said third message establishes a connection; and
- merging said first and second teleconferences based at least in part on said third message.
37. The method of claim 36, further comprising participating in said first teleconference having said first unique conference identifier, said first teleconference also having merged said at least one member of said first or second list.
38. The method of claim 36, additionally comprising storing a merged membership, said merged membership based at least in part on said act of merging.
39. The method of claim 36, wherein at least one member of said second list comprises an auxiliary source.
40. The method of claim 39, wherein said auxiliary source comprises a media source adapted to provide one or more media services to at least one of said members of said first teleconference.
41. A method for merging at least two conferences by an initiating member, wherein said initiating member is participating in at least one of said conferences, said at least two conferences comprising a first conference and a second conference, said first conference having a first membership and a first unique conference identifier associated therewith, and said second conference having a second membership and a second unique conference identifier associated therewith, said method comprising:
- transmitting at least a first message, wherein said first message comprises said first and second unique conference identifiers and a request to merge said first conference with said second conference, said first message causing at least one of said first membership or said second membership to establish at least one communications link; and
- allowing merging said first membership with said second membership based at least on said first or second unique conference identifier.
42. The method of claim 41, additionally comprising the step of storing a merged membership, said merged membership being based at least in part on said merging.
43. The method of claim 42, additionally comprising the step of assigning said merged membership to said first unique conference identifier.
44. The method of claim 43, additionally comprising no longer using at least one of said first and second unique conference identifiers after said merging is performed.
45. The method of claim 41, wherein after said merging is performed, said first and second membership utilize said first unique conference identifier to identify the merged conference.
46. An apparatus adapted to merge at least two conferences, said at least two conferences comprising a first conference and a second conference, said first conference having a first membership and a first conference identifier associated therewith, and said second conference having a second membership and a second conference identifier associated therewith, said apparatus comprising:
- a digital processor;
- a storage medium in data communication with said processor, comprising at least one table, said at least one table comprising a plurality of unique conference identifiers and corresponding memberships; and
- at least one computer program resident in said storage medium, said at least one program comprising a plurality of instructions which, when executed: transmit at least a first message, wherein said first message comprises a request to merge said first conference with said second conference, said first message being configured to cause at least one of said first membership or said second membership to establish at least one communications link; and allow a merge of said first membership with said second membership based at least on said first or second conference identifier.
47. The apparatus of claim 46, further comprising:
- a network interface in communication with said processor; and
- a network, said network comprising a plurality of other apparatus in data communication therewith, said other apparatus corresponding to individual ones of said first and second memberships.
48. The apparatus of claim 46, wherein said merge of said conferences is initiated by an initiating member participating in at least one of said conferences.
49. The apparatus of claim 46, wherein said plurality of instructions additionally, when executed, store a merged membership to said table, said merged membership based at least in part on said merged conference.
50. The apparatus of claim 49, wherein said plurality of instructions additionally, when executed, assign said merged membership to said first conference identifier in said table.
51. The apparatus of claim 50, wherein said plurality of instructions additionally, when executed, remove said second conference identifier and said second membership from said table.
52. The apparatus of claim 46, wherein at least one member of said second conference comprises an auxiliary source.
53. The apparatus of claim 52, wherein said auxiliary source comprises a multimedia source.
54. The apparatus of claim 46, wherein said apparatus is associated with a member of both said first and second conferences.
55. The apparatus of claim 46, wherein said apparatus is an endpoint within at least one of said first and second conferences.
56. An apparatus adapted to merge at least two sessions, said at least two sessions comprising a first session and a second session, said first session having a first membership and a first identifier associated therewith, and said second session having a second membership and a second identifier associated therewith, said apparatus comprising:
- a digital processor;
- a storage medium in data communication with said processor; and
- at least one computer program resident in said storage medium, said at least one program comprising a plurality of instructions which, when executed:
- transmit at least a first message, wherein said first message comprises said first and second unique conference identifiers and a request to merge said first session with said second session, said first message being configured to cause at least one of said first membership or said second membership to establish at least one point-to-point communications link; and
- allow a merge of said first membership with said second membership based at least on said first or second identifier and said first message.
57. The apparatus of claim 56, wherein said first identifier comprises a first session identifier, and wherein said second identifier comprises a second session identifier.
58. A method for attaching an auxiliary media source having a first identifier to an ongoing first conference having a plurality of members and a second identifier, said method comprising:
- identifying at least one of the members of said first conference;
- transmitting a first message, wherein said first message comprises a request to provide a media stream from said auxiliary media source to said at least one member;
- responsive to said first message, said at least one member establishing at least one communications link with said auxiliary media source; and
- associating said auxiliary media source with said first identifier.
59. The method of claim 58, wherein said attaching is initiated by an initiating member, wherein said initiating member is participating in said ongoing first conference.
60. The method of claim 59, wherein said first message additionally comprises said first and second identifiers.
61. The method of claim 59, wherein said initiating member comprises a moderator of said ongoing first conference.
62. The method of claim 61, wherein said media stream is controlled by said moderator.
63. The method of claim 58, wherein said at least one communications link comprises a point-to-point link.
3584142 | June 1971 | Schoeffler |
4100377 | July 11, 1978 | Flanagan |
4387271 | June 7, 1983 | Artom |
4506358 | March 19, 1985 | Montgomery |
4507781 | March 26, 1985 | Alvarez, III et al. |
4509167 | April 2, 1985 | Bantel et al. |
4516156 | May 7, 1985 | Fabris et al. |
4525779 | June 25, 1985 | Davids et al. |
4574374 | March 4, 1986 | Scordo |
4627052 | December 2, 1986 | Hoare et al. |
4645872 | February 24, 1987 | Pressman et al. |
4650929 | March 17, 1987 | Boerger et al. |
4653090 | March 24, 1987 | Hayden |
4686698 | August 11, 1987 | Tompkins et al. |
4691314 | September 1, 1987 | Bergins et al. |
4707831 | November 17, 1987 | Weir et al. |
4710917 | December 1, 1987 | Tompkins et al. |
4734765 | March 29, 1988 | Okada et al. |
4748620 | May 31, 1988 | Adelmann et al. |
4756019 | July 5, 1988 | Szybicki |
4760572 | July 26, 1988 | Tomikawa |
4763317 | August 9, 1988 | Lehman et al. |
4785415 | November 15, 1988 | Karlquist |
4827339 | May 2, 1989 | Wada et al. |
4847829 | July 11, 1989 | Tompkins et al. |
4849811 | July 18, 1989 | Kleinerman |
4882743 | November 21, 1989 | Mahmoud |
4888795 | December 19, 1989 | Ando et al. |
4893326 | January 9, 1990 | Duran et al. |
4897866 | January 30, 1990 | Majmudar et al. |
4905231 | February 27, 1990 | Leung et al. |
4918718 | April 17, 1990 | Emmons et al. |
4924311 | May 8, 1990 | Ohki et al. |
4926415 | May 15, 1990 | Tawara et al. |
4932047 | June 5, 1990 | Emmons et al. |
4935953 | June 19, 1990 | Appel et al. |
4937856 | June 26, 1990 | Natarajan |
4942470 | July 17, 1990 | Nishitani et al. |
4942540 | July 17, 1990 | Black et al. |
4942569 | July 17, 1990 | Maeno |
4943994 | July 24, 1990 | Ohtsuka et al. |
4945410 | July 31, 1990 | Walling |
4949169 | August 14, 1990 | Lumelsky et al. |
4953159 | August 28, 1990 | Hayden et al. |
4953196 | August 28, 1990 | Ishikawa et al. |
4962521 | October 9, 1990 | Komatsu et al. |
4965819 | October 23, 1990 | Kannes |
4991169 | February 5, 1991 | Davis et al. |
4991171 | February 5, 1991 | Teraslinna et al. |
4995071 | February 19, 1991 | Weber et al. |
4999766 | March 12, 1991 | Peters et al. |
5003532 | March 26, 1991 | Ashida et al. |
5014267 | May 7, 1991 | Tompkins et al. |
5020023 | May 28, 1991 | Smith |
5034916 | July 23, 1991 | Ordish |
5042006 | August 20, 1991 | Flohrer |
5042062 | August 20, 1991 | Lee et al. |
5046079 | September 3, 1991 | Hashimoto |
5046080 | September 3, 1991 | Lee et al. |
5050166 | September 17, 1991 | Cantoni et al. |
5056136 | October 8, 1991 | Smith |
5062136 | October 29, 1991 | Gattis et al. |
5072442 | December 10, 1991 | Todd |
5077732 | December 31, 1991 | Fischer et al. |
5079627 | January 7, 1992 | Filo |
5083269 | January 21, 1992 | Syobatake et al. |
5099510 | March 24, 1992 | Blinken et al. |
5101451 | March 31, 1992 | Ash et al. |
5109483 | April 28, 1992 | Baratz et al. |
5132966 | July 21, 1992 | Hayano et al. |
5136581 | August 4, 1992 | Muehrcke |
5136692 | August 4, 1992 | Barrett et al. |
5140417 | August 18, 1992 | Tanaka et al. |
5140584 | August 18, 1992 | Suzuki |
5155594 | October 13, 1992 | Bernstein et al. |
5157662 | October 20, 1992 | Tadamura et al. |
5163045 | November 10, 1992 | Caram et al. |
5177604 | January 5, 1993 | Martinez |
5192999 | March 9, 1993 | Graczyk et al. |
5195086 | March 16, 1993 | Baumgartner et al. |
5200951 | April 6, 1993 | Grau et al. |
5206934 | April 27, 1993 | Naef, III |
5210836 | May 11, 1993 | Childers et al. |
5220653 | June 15, 1993 | Miro |
5231492 | July 27, 1993 | Dangi et al. |
5241625 | August 31, 1993 | Epard et al. |
5243596 | September 7, 1993 | Port et al. |
5247626 | September 21, 1993 | Firoozmand |
5253251 | October 12, 1993 | Aramaki |
5276679 | January 4, 1994 | McKay et al. |
5283638 | February 1, 1994 | Engberg et al. |
5289470 | February 22, 1994 | Chang et al. |
5291492 | March 1, 1994 | Andrews et al. |
5297143 | March 22, 1994 | Fridrich et al. |
5307351 | April 26, 1994 | Webster |
5309433 | May 3, 1994 | Cidon et al. |
5311585 | May 10, 1994 | Armstrong et al. |
5313454 | May 17, 1994 | Bustini et al. |
5313455 | May 17, 1994 | van der Wal et al. |
5315586 | May 24, 1994 | Charvillat |
5323445 | June 21, 1994 | Nakatsuka |
5333135 | July 26, 1994 | Wendorf |
5333299 | July 26, 1994 | Koval et al. |
5341374 | August 23, 1994 | Lewen et al. |
5355371 | October 11, 1994 | Auerbach et al. |
5367637 | November 22, 1994 | Wei |
5371534 | December 6, 1994 | Dagdeviren et al. |
5373549 | December 13, 1994 | Bales et al. |
5374952 | December 20, 1994 | Flohr |
5375068 | December 20, 1994 | Palmer et al. |
5377196 | December 27, 1994 | Godlew et al. |
5384770 | January 24, 1995 | Mays et al. |
5392344 | February 21, 1995 | Ash et al. |
5402412 | March 28, 1995 | Duffie et al. |
5422883 | June 6, 1995 | Hauris et al. |
5422942 | June 6, 1995 | Kakwashima |
5432525 | July 11, 1995 | Maruo et al. |
5434860 | July 18, 1995 | Riddle |
5440624 | August 8, 1995 | Schoof, II |
5442749 | August 15, 1995 | Northcutt et al. |
5444709 | August 22, 1995 | Riddle |
5453780 | September 26, 1995 | Chen et al. |
5455826 | October 3, 1995 | Özveren et al. |
5455854 | October 3, 1995 | Dilts et al. |
5459725 | October 17, 1995 | Bodner et al. |
5473679 | December 5, 1995 | La Porta et al. |
5475746 | December 12, 1995 | Miller et al. |
5477546 | December 19, 1995 | Shibata et al. |
5483587 | January 9, 1996 | Hogan et al. |
5483588 | January 9, 1996 | Eaton et al. |
5487167 | January 23, 1996 | Dinallo et al. |
5490247 | February 6, 1996 | Tung et al. |
5491798 | February 13, 1996 | Bonsall et al. |
5502726 | March 26, 1996 | Fischer |
5506844 | April 9, 1996 | Rao |
5506954 | April 9, 1996 | Arshi et al. |
5509010 | April 16, 1996 | La Porta et al. |
5511168 | April 23, 1996 | Perlman et al. |
5515491 | May 7, 1996 | Bates et al. |
5522073 | May 28, 1996 | Courant et al. |
5524110 | June 4, 1996 | Danneels et al. |
5526037 | June 11, 1996 | Cortjens et al. |
5530808 | June 25, 1996 | Hammond et al. |
5530902 | June 25, 1996 | McRoberts et al. |
5532937 | July 2, 1996 | Graziano et al. |
5537548 | July 16, 1996 | Fin et al. |
5541927 | July 30, 1996 | Kristol et al. |
5544300 | August 6, 1996 | Skarbo et al. |
5546395 | August 13, 1996 | Sharma et al. |
5550754 | August 27, 1996 | McNelley et al. |
5557724 | September 17, 1996 | Sampat et al. |
5557749 | September 17, 1996 | Norris |
5566000 | October 15, 1996 | Propach et al. |
5572232 | November 5, 1996 | Rhodes et al. |
5572582 | November 5, 1996 | Riddle |
5574934 | November 12, 1996 | Mirashrafi et al. |
5577208 | November 19, 1996 | Couturier |
5587928 | December 24, 1996 | Jones et al. |
5594859 | January 14, 1997 | Palmer et al. |
5600646 | February 4, 1997 | Polomski |
5600797 | February 4, 1997 | Marshall |
5604742 | February 18, 1997 | Colmant et al. |
5606554 | February 25, 1997 | Shibata et al. |
5608653 | March 4, 1997 | Palmer et al. |
5612788 | March 18, 1997 | Stone |
5617539 | April 1, 1997 | Ludwig et al. |
5621894 | April 15, 1997 | Menezes et al. |
5623483 | April 22, 1997 | Agrawal et al. |
5623490 | April 22, 1997 | Richter et al. |
5623690 | April 22, 1997 | Palmer et al. |
5625407 | April 29, 1997 | Biggs et al. |
5627978 | May 6, 1997 | Altom et al. |
5632022 | May 20, 1997 | Warren et al. |
5649105 | July 15, 1997 | Aldred et al. |
5652887 | July 29, 1997 | Dewey et al. |
5659692 | August 19, 1997 | Poggio et al. |
5664126 | September 2, 1997 | Hirakawa et al. |
5664164 | September 2, 1997 | Riddle |
5664226 | September 2, 1997 | Czako et al. |
5671428 | September 23, 1997 | Muranaga et al. |
5673393 | September 30, 1997 | Marshall et al. |
5674003 | October 7, 1997 | Andersen et al. |
5689641 | November 18, 1997 | Ludwig et al. |
5708697 | January 13, 1998 | Fischer et al. |
5710591 | January 20, 1998 | Bruno et al. |
5717863 | February 10, 1998 | Adamson et al. |
5721729 | February 24, 1998 | Klingman |
5724508 | March 3, 1998 | Harple, Jr. et al. |
5724578 | March 3, 1998 | Morinaga et al. |
5729687 | March 17, 1998 | Rothrock et al. |
5737599 | April 7, 1998 | Rowe et al. |
5742670 | April 21, 1998 | Bennett |
5742773 | April 21, 1998 | Blomfield-Brown et al. |
5754306 | May 19, 1998 | Taylor et al. |
5754765 | May 19, 1998 | Danneels et al. |
5758079 | May 26, 1998 | Ludwig et al. |
5760769 | June 2, 1998 | Petrie |
5764915 | June 9, 1998 | Heimsoth et al. |
5793365 | August 11, 1998 | Tang et al. |
5799151 | August 25, 1998 | Hoffer |
5801700 | September 1, 1998 | Ferguson |
5809237 | September 15, 1998 | Watts et al. |
5841763 | November 24, 1998 | Leondires et al. |
5841976 | November 24, 1998 | Tai et al. |
5848143 | December 8, 1998 | Andrews et al. |
5854898 | December 29, 1998 | Riddle |
5857189 | January 5, 1999 | Riddle |
5859979 | January 12, 1999 | Tung et al. |
5864678 | January 26, 1999 | Riddle |
5872923 | February 16, 1999 | Schwartz et al. |
5887170 | March 23, 1999 | Ansberry et al. |
5903754 | May 11, 1999 | Pearson |
5907324 | May 25, 1999 | Larson et al. |
5913062 | June 15, 1999 | Vrvilo et al. |
5920732 | July 6, 1999 | Riddle |
5931961 | August 3, 1999 | Ranganathan et al. |
5933597 | August 3, 1999 | Hogan |
5973724 | October 26, 1999 | Riddle |
5983261 | November 9, 1999 | Riddle |
5995491 | November 30, 1999 | Richter et al. |
5999977 | December 7, 1999 | Riddle |
6008806 | December 28, 1999 | Nakajima et al. |
6104706 | August 15, 2000 | Richter et al. |
6151619 | November 21, 2000 | Riddle |
6175856 | January 16, 2001 | Riddle |
6189034 | February 13, 2001 | Riddle |
6295549 | September 25, 2001 | Riddle |
6505234 | January 7, 2003 | Riddle |
6738357 | May 18, 2004 | Richter et al. |
6745228 | June 1, 2004 | Riddle |
7039019 | May 2, 2006 | Niiya et al. |
7050425 | May 23, 2006 | Richter et al. |
RE39135 | June 13, 2006 | Riddle |
7075924 | July 11, 2006 | Richter et al. |
7167897 | January 23, 2007 | Riddle |
7392286 | June 24, 2008 | Riddle |
7415499 | August 19, 2008 | Riddle |
7437420 | October 14, 2008 | Riddle |
20020029350 | March 7, 2002 | Cooper et al. |
20020073150 | June 13, 2002 | Wilcock |
20020076025 | June 20, 2002 | Liversidge et al. |
2080530 | April 1994 | CA |
0279232 | August 1988 | EP |
0453128 | October 1991 | EP |
1670197 | June 2006 | EP |
1816786 | August 2007 | EP |
2289149 | November 1995 | GB |
WO 2005/104466 | November 2005 | WO |
- U.S. Appl. No. 10/857,806, filed May 28, 2004, Riddle.
- U.S. Appl. No. 10/857,805, filed May 28, 2004, Riddle.
- U.S. Appl. No. 10/857,799, filed May 28, 2004, Riddle.
- U.S. Appl. No. 10/857,798, filed May 28, 2004, Riddle.
- U.S. Appl. No. 10/020,515, filed Dec. 7, 2001, Riddle.
- Deering, S., “Host Extensions for IP Multicasting,” RFC 1112, Internet Engineering Task Force, Aug. 1989.
- Fenner, W., “Internet Group Management Protocol, Version 2,” RFC 2236, Internet Engineering Task Force, Nov. 1997.
- European Search Report and Search Opinion, European Patent Application No. EP 07009592.2, Jul. 18, 2007.
- European Search Report and Search Opinion, European Patent Application No. EP 07009591.4, Jul. 17, 2007.
- European Search Report and Search Opinion, European Patent Application No. EP 07009590.6, Jul. 24, 2007.
- “Adaptive Audio Playout Algorithm for Shared Packet Networks,” IBM Technical Disclosure Bulletin, Apr. 1993, pp. 255-257, vol. 36, No. 4, Armonk, NY.
- Aguilar, L., et al., “Architecture for a Multimedia Teleconferencing System,” Proceedings of ACM SIGCOMM'86, Aug. 1986, pp. 126-136.
- Ahuja, S. R., et al., “The Rapport Multimedia Conferencing System,” Proceedings of Conference on Office Information Systems, Mar. 1988, pp. 1-8.
- Barberis, G., et al., “Coded Speech in Packet-Switched Networks: Models and Experiments,” IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1028-1038, vol. Sac-1, No. 6.
- Le Boudec, J., “The Asynchronous Transfer Mode: A Tutorial,” Computer Networks and ISDN Systems, May 15, 1992, pp. 279-309, vol. 24, No. 4.
- Carne, E. B., “Modern Telecommunication,” Applications of Communications Theory, GTE Laboratories Incorporated, 1984, pp. 44-47.
- Casner, S., et al., “First IETF Internet Audiocast,” Reprinted from ACM SIGCOM Computer Communications Review, Jul. 1992, vol. 22, No. 3, ISI Reprint Series, ISI/RS-92-293, Jul. 1992, pp. 1-6.
- Casner, S., et al., “N-Way Conferencing with Packet Video,” Reprinted from the Proceedings of the Third International Workshop on Packet Video held Mar. 22-23, 1990 in Morristown, NJ, ISI Reprint Series, ISI/RS-90-252, Apr. 1990, pp. 1-6.
- Cohen, D., “Specifications for the Network Voice Protocol,” USC/Information Sciences Institute, Mar. 1976, ISI/RR-75-39, Available from DTIC (AD # A023506).
- Cohen, D., “Specifications for the Network Voice Protocol (NVP),” NWG/RFC 741, Nov. 1977.
- Comer, D., “Internetworking with TCP/IP, vol. 1: Principles, Protocols, and Architecture,” 2nd Edition, 1991, pp. 1-8, 337-346, 505, Prentice Hall, Englewood Cliffs, NJ.
- Degan, J. J., et al., “Fast Packet Technology for Future Switches,” AT&T Technical Journal, Mar./Apr. 1989, pp. 36-50, vol. 68, No. 2.
- Eng, K. Y., et al., “Multicast and Broadcast Services in a Knockout Packet Switch,” Proceedings of the IEEE INFOCOM'88, pp. 29-34.
- Forsdick, H., “Explorations into Real-Time Multimedia Conferencing,” Proceedings of the 2nd International Symposium on Computer Message Systems, IFIP, Sep. 1985, pp. 331-347.
- Gemmell, J., et al., “A Scalable Multicast Architecture for One-to-Many Telepresentations,” Multimedia Computing and Systems, Proceedings, IEEE International Conference, 1998, pp. 128-139.
- Gemmell, J. et al., “An Architecture for Multicast Telepresentations,” Journal of Computing and Information Technology—CIT, pp. 255-272, vol. 6, No. 3.
- Ghafoor, A., et al., “An Efficient Communication Structure for Distributed Commit Protocols,” IEEE Journal on Selected Areas in Communications, Apr. 1989, pp. 375-389, vol. 7, No. 3.
- Hoberecht, W. L., “A Layered Network Protocol for Packet Voice and Data Integration,” IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1006-1013, vol. SAC-1, No. 6.
- Lantz, K. A., “An Experiment in Integrated Multimedia Conferencing,” Proceedings of the Conference on Computer-Supported Cooperative Work'86, Dec. 1986, pp. 533-552, Reading 19.
- Lee, T. T., et al., “The Architecture of a Multicast Broadband Packet Switch,” Proceedings of IEEE INFOCOM'88, pp. 1-8.
- Leung, W. H., et al., “A Set of Operating System Mechanisms to Support Multi-Media Applications,” Proceedings of 1988 International Zurich Seminar on Digital Communications, Mar. 1988, pp. B4.1-84.6.
- Leung, W. F., et al., “A Software Architecture for Workstations Supporting Multimedia Conferencing in Packet Switching Networks,” IEEE Journal on Selected Areas in Communications, Apr. 1990, pp. 380-390, vol. 8, No. 3.
- Maeno, K., et al., “Distributed Desktop Conferencing System (MERMAID) Based on Group Communication Architecture,” ICC '91, Jun. 28, 1991, pp. 0520-0525.
- Magill, D. T., “Adaptive Speech Compression for Packet Communication Systems,” Conference Record of the IEEE National Telecommunications Conference, 1973, pp. 29D-1-29-D5.
- Mark, J. W., et al., “A Dual-Ring LAN for Integrated Voice/Video/Data Services,” Department of Electrical and Computer Engineering and Computer Communications Networks Group, IEEE, 1990, pp. 850-857, University of Waterloo, Waterloo, Ontario, Canada.
- Minzer, S. E., et al., “New Directions in Signaling for Broadband ISDN,” IEEE Communications Magazine, Feb. 1989, pp. 6-14.
- Montgomery, W. A., “Techniques for Packet Voice Synchronization,” IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1022-1028, vol. SAC-1, No. 6.
- Musser, J. M., et al., “A Local Area Network as a Telephone Local Subscriber Loop,” IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1046-1054, vol. SAC-1, No. 6.
- Nicolaou, C., “An Architecture for Real-Time Multimedia Communication Systems,” IEEE Journal on Selected Areas in Communications, Apr. 1990, pp. 391-400, vol. 8, No. 3.
- Nojima, S., et al., “High Speed Packet Switching Network for Multi-Media Information,” Proceedings of IEEE 1986 Computer Networking Symposium, pp. 141-150.
- “OSF/Motif Programmer's Guide, Revision 1.1,” Open Software Foundation, 1990, 1991, pp. i-xviii, 1-1-1-9, GL-1-GL-15, Index-1-Index-34, Prentice-Hall, Inc., Englewood Cliffs, NJ.
- “Output Throttle Mechanism,” IBM Technical Disclosure Bulletin, Apr. 1990, pp. 274-279, vol. 32, No. 11.
- Palmer, L., et al., “Desktop Meeting,” LAN Magazine, Nov. 1991, pp. 111-121, vol. 6, No. 11.
- Poggio, A., et al., “CCWS: A Computer-Based, Multimedia Information System,” Computer, Oct. 1985, pp. 92-103.
- Schooler, E. M., “A Distributed Architecture for Multimedia Conference Control,” ISI Research Report, Nov. 1991, ISI/RR-91-289, 20 pages, University of Southern California, Information Sciences Institute.
- Schooler, E. M., et al., “A Packet-Switched Multimedia Conferencing System,” Reprinted from ASM SIGOIS Bulletin, Jan. 1989, pp. 12-22, vol. 1, No. 1, University of Southern California, Information Sciences Institute.
- Schooler, E. M., et al., “An Architecture for Multimedia Connection Management,” Reprinted from the Proceedings of the IEEE 4TH Comsoc International Workshop on Multimedia Communications, MM '92, Apr. 1992, pp. 271-274, Monterey, CA, ISI Reprint Series, ISI/RS-92-294, Aug. 1992, pp. 1-4.
- Schooler, E. M., “Case Study: Multimedia Conference Control in a Packet-Switched Teleconferencing System,” Reprinted from the Journal of Internetworking: Research and Experience, Jun. 1993, pp. 99-120, vol. 4, No. 2, ISI Reprint Series, ISI/RS-93-359, Aug. 1993, pp. 1-17.
- Schooler, E. M., “Conferencing and Collaborative Computing,” Multimedia Systems, 1996, pp. 210-225, vol. 4.
- Schooler, E. M., et al., “Multimedia Conferencing: Has it come of age?,” IEEE Journal on Selected Areas in Communications, 1991, pp. 707-716.
- Schooler, E. M., “The Connection Control Protocol: Architecture Overview,” USC/Information Sciences Institute, Version 1.0, Jan. 28, 1992, pp. 1-6.
- Schooler, E. M., “The Connection Control Protocol: Specification,” USC/Information Sciences Institute, Version 1.1, Jan. 29, 1992, pp. 1-6.
- Schulzrinne, H., “A Transport Protocol for Real-Time Applications,” Audio-Video Transport WG, Internet Engineering Task Force, Internet Draft, draft-ietf-avt-rtp-00, Dec. 15, 1992, pp. 1-12.
- Schulzrinne, H., et al. “A Transport Protocol for Real-Time Applications,” Audio-Video Transport WG, Internet Engineering Task Force, Internet Draft, draft-ietf-avt-rtp-01, May 6, 1993, pp. 1-18.
- Shenker, S., et al., “Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism,” Lecture Notes in Computer Science, 1994, vol. 882, 69.
- Turner, J. S., “Design of a Broadcast Packet Switching Network,” IEEE Transactions on Communications, Jun. 1988, pp. 734-743, vol. 36, No. 6.
- Ueda, H., et al., “Evaluation of an Experimental Packetized Speech and Data Transmission System,” IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 1039-1045, vol. SAC-1, No. 6.
- “ULTRIX Worksystem Software X Window System Protocol: X Version 11,” ULTRIX Worksystem Software, Version 2.0, Digital Equipment Corporation, 1988, Order No. AA-MA98A-TE.
- Watabe, K., et al., “Distributed Desktop Conferencing System with Multiuser Multimedia Interface,” IEEE Journal on Selected Areas in Communications, May 1991, pp. 531-539, vol. 9, No. 4.
- Weinstein, C. J., et al., “Experience with Speech Communication in Packet Networks,” IEEE Journal on Selected Areas in Communications, Special Issue on Packet Switched Voice and Data Communication, Dec. 1983, pp. 963-980, vol. SAC-1, No. 6.
- Yukimatsu, K., et al., “Multicast Communication Facilities in a High Speed Packet Switching Network,” Proceedings of ICCC'86, pp. 276-281.
- “Apple Media Conference Guide,” Apple Computer, Inc., screen shots, 14 pages.
- “Apple QuickTime Conferencing,” Apple Computer, Inc., Apple QuickTime Fact Sheet, Jan. 1995, 2 pages.
- “Apple QuickTime Conferencing Kit,” Apple Computer, Inc., Aug. 1995, 2 pages.
- Baker, S., “Remote-Access Protocols,” UNIX Review, May 1995, pp. 1-4.
- Burton, J., “Standard Issue,” Byte, Sep. 1995, pp. 1-10.
- Chong-Kwon, K., et al., “Performance of Call Splitting Algorithms for Multicast Traffic,” INFOCOM 1990, pp. 348-356.
- “Draft ITU-T Recommendation H.245, Line Transmission of Non-Telephone Signals; Control Protocol for Multimedia Communication,” International Telecommunication Union, Nov. 27, 1995, pp. 1-189.
- Finnegan, J., “Building Windows NT-Based Client/Server Applications Using Remote Procedure Calls,” Microsoft Systems Journal, Oct. 1994, pp. 1-17.
- Handley, M., et al., “The Conference Control Channel Protocol (CCCP): A scalable base for building conference control applications,” ACM, SIGCOMM, 1995, pp. 275-287.
- Jamsa, K., et al., “Internet Programming,” Jan. 1995, pp. 152-218.
- Kalman, S., “CTI Systems: Now's the Time,” Network VAR, Aug. 1995, pp. 1-5.
- Shinjo, Y., et al., “The Object-Stacking Model for Structuring Object-Based Systems,” International Workshop on Object-Orientation in Operating Systems, I-WOOOS '02, Sep. 1992, Paris, France, pp. 328-340.
- Wong, W., “Welcome to Teleconferencing,” Stacks, Jun. 1995, pp. 1-7.
- Bubenik, R., et al., “Multipoint Connection Management in High Speed Networks,” IEEE Infocom '91, pp. 59-67 (1991).
- Chen, M.S., et al. “Designing a Distributed Collaborative Environment,” Dec. 6-9, 1992, IEEE Global Telecommunications Conference, Orlando, FL, pp. 213-219.
- Kim, C., et al., “Performance of Call Splitting Algorithms for Multicast Traffic,” INFOCOM '90, pp. 348,356 (1990).
- Ott, J., et al., “Multicasting the ITU MCS: Integrating Point-to-Point & Multicast Transport,” Singapore ICCS, 1994, pp. 1013-1017.
- “Control of Video Telephony from a Data Conferencing System,” IBM Technical Disclosure Bulletin, v. 37, Oct. 1994, pp. 327-332.
- “Intelligent Packet Relay in Distributed Multimedia Systems,” IBM Technical Disclosure Bulletin, v. 37, Jul. 1994, pp. 211-214.
- Office Action received for U.S. Appl. No. 10/857,806, Jul. 27, 2009, 22 Pages.
- European Search Report for European Patent Application No. EP 09000330.2, Sep. 13, 2010, 7 pages.
- Donath, J., et al., “The Sociable Web,” Proceedings of Second International WWW Conference, 1994, 7 pages, [Online] [Retrieved on Feb. 2, 2008] Retrieved from the internet <URL: http://www.nicoladoering.de/Hogrefe/donath.htm>.
- Oikarinen, J., et al., “Request for Comments: 1459: Internet Relay Chat Protocol,” Internet Engineering Task Force, Network Working Group, May 1993, 65 pages.
- PCT International Search Report (PCT/US96/02459) mailed Aug. 7, 1996.
- Mon-Song Chen, et al., “Designing a Distributed Collaborative Environment,” Communications for Global Users, including a Communications Theory Mini Conference, Orlando, Dec. 6-9, 1992, Institute of Electrical and Electronics Engineers, pp. 219-219.
- W.H. Leung, et al., “Multimedia Conferencing Capabilities in an Experimental Fast Packet Network,” Proceedings of the International Switching Symposium, Yokohama, Oct. 25, 1992, Institute of Electronics, Information and Communication Engineers, pp. 258-262.
- “Dynamic Conference Call Participation” IBM Technical Disclosure Bulletin, V. 28, Aug. 1995, pp. 1135-1138.
Type: Grant
Filed: Sep 15, 2008
Date of Patent: Jun 18, 2013
Assignee: Apple Inc. (Cupertino, CA)
Inventor: Guy G. Riddle (Los Gatos, CA)
Primary Examiner: Kenny Lin
Application Number: 12/210,847
International Classification: G06F 15/16 (20060101);