WO1998051040A1 - Method for managing multicast addresses in an internet protocol (ip) network - Google Patents
Method for managing multicast addresses in an internet protocol (ip) network Download PDFInfo
- Publication number
- WO1998051040A1 WO1998051040A1 PCT/US1998/006447 US9806447W WO9851040A1 WO 1998051040 A1 WO1998051040 A1 WO 1998051040A1 US 9806447 W US9806447 W US 9806447W WO 9851040 A1 WO9851040 A1 WO 9851040A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- conference
- multicast
- client
- address
- clients
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Definitions
- This invention relates to data communications, and more particularly, to the real-time interactive distribution of multimedia information using the multicast Internet Protocol (IP).
- IP Internet Protocol
- Conferencing systems are typically characterized by the following: a directory service which lists the set of conferences; a dynamic mechanism for keeping track of the members of a conference as they join or leave the conference; tools for generating and processing the audio, video and data sharing components of a conference; a data network for interconnecting the members of a conference; and transport mechanisms for distributing the multimedia conference content among the conference members.
- Two basic communication capabilities are: unicast communication, meaning a point-to- point communication between a source and a destination end-point; and multicast communication, meaning that one source end-point reaches multiple destination end-points. Since conferencing inherently implies the possibility of more than one destination end-point, if the network is capable only of unicast communication, then either the source must create multiple unicast connections, or multicast servers external to the network must be employed. In the former case, each sender of information sets up multiple connections to every receiver, and replicates the data on each connection. Each receiver has multiple incoming connections, one for every sender of information. This approach becomes inefficient as the number of participants (N) gets large for two reasons.
- the number of network connections is proportional to the square of N.
- each end-point needs to replicate the data N times, possibly leading to both an excessive and unnecessary use of bandwidth in the network and an excessive amount of computation at the source.
- external multicast servers are employed, then these servers perform the data replication function.
- Each sender of information needs to have a single unicast connection to the multicast server.
- Each receiver is connected to the multicast server.
- the number of connections is proportional to N, as all senders share the same set of connections to the set of receivers.
- the disadvantage of this scheme is that the multicast server becomes a bottleneck when N gets large.
- the interconnection network is multicast capable, more efficient alternatives are possible.
- the source of the information sends the data only once - the replication is handled by the network. It is as if the multicast servers described in the previous paragraph are bundled into the network.
- Efficient techniques for replication may exist in the network.
- the data replication can be performed in hardware, and the replication function can be distributed over the switches or routers of the network.
- the replication topology may be very efficient, e.g. a spanning tree, where receivers are leafs of the tree, and the data source is the root of the tree.
- the multicast server may be connected to the receivers by multicast mechanisms, and to the sources by unicast mechanisms.
- IP Internet Protocol
- API IP application programming interface
- application programs may write data to, or read data from a so- called socket just as if the socket was a "file descriptor" on the local computer.
- a socket is linked to a pair of numbers, i.e. an IP address and a positive integer referred to as a port number.
- the IP address used is the destination address to be placed in the destination field IP packet header, and the port number to be used by the application process on a remote machine for receiving the data.
- the IP address is implicitly the local machine address (or in the case of IP multicast, the multicast group address of interest) , and the port number to be used by the application process on the local machine for receiving the data.
- Multicast IP the primary mechanism by which IP networks support multicast, is an emerging capability of the IP protocol.
- IP multicast service unlike the unicast IP service where the address represents a specific and unique end-system, a sender transmits data addressed to an abstraction called a multicast address group.
- each media- type e.g., audio, video
- All receivers for the given media-type listen to the specific socket consisting of the known multicast IP address and port number.
- All senders for the given media-type send to the specified socket consisting of the same multicast IP address and port number.
- a different socket is utilized to enable different application programs to handle the different media of the conference.
- the multicast IP address may be the same or different among media types, but the port number is almost always different.
- Receivers find out about the existence of multicast groups and port numbers through various (centralized or distributed) directory mechanisms. For example, a well-known multicast IP address may be reserved for directory announcements. Alternatively, a centralized server may contain a list of multicast groups and distribute this list to clients upon request. Once the appropriate multicast IP address information has been obtained from the directory mechanism, receivers send messages to multicast server processes (e.g., in multicast routers) indicating that they want to join a particular group. The routers then exchange information about the set of users that want to communicate, and build up interconnection trees among themselves.
- multicast server processes e.g., in multicast routers
- each conference rather than being represented by a single multicast IP address and port number for each media type that is used by each of the senders, is instead represented by a set of sockets, each socket comprising a multicast IP address and a port number.
- each transmitting client terminal is assigned a separate socket for each media type for which the multicast IP address of each is unique with respect to the sockets assigned to any other client terminal.
- Each client terminal can thus select the specific multicast IP addresses from which it wishes to receive.
- each client terminal can select to receive those media types from only those transmitting client terminals whose transmissions it has an interest in receiving. Further, it and does not need to perform internal processing to discard transmissions those clients whose transmissions it doesn't want to receive.
- routing of transmissions from a transmitting terminal to a receiving terminal of each media type is only effected to those receiving endpoint clients who have elected to receive such transmission.
- a Directory Server allocates from the then available and unused multicast IP addresses, a group of such addresses to be used for the conference based on the maximum number of expected participants, which number is provided by a conference originator.
- the particpant's client terminal is assigned a port number and multicast IP address on which to transmit for each media type, wherein the multicast IP address is from the group of multicast IP addresses allocated for use by that conference.
- the multicast IP address is assigned to a client terminal, it is marked as being unavailable for use by any other client terminal.
- Each packet transmitted by the client terminal for each media type then thereafter includes its assigned identifier in its header.
- FIG. 1 is a block diagram showing a plurality of client terminals connected to a multicast capable IP network, to which is also connected a Directory Server for establishing a conference in accordance with the present invention
- FIG. 2 is a chart illustrating the steps associated with establishing a conference by a conference originator on the network of FIG. 1 ;
- FIG. 3 is a chart illustrating the steps associated with a user joining an already established conference on the network of FIG. 1.
- multimedia client terminals 101-1 - 101-5 are connected to a multicast capable Internet Protocol (IP) data network 102, which may, for example, be the Internet or a private IP network.
- IP Internet Protocol
- the connections to the IP network 102 could be made via a Local Area Network (LAN) over T1/T3 facilities, an Asynchronous Digital Subscriber Loop (ADSL) link running a Frame Relay protocol, or over an ISND BRI link running the X.25 protocol, or any other digital or analog link.
- Network 102 may likely comprise plural sub- networks, with a multicast router (MR) routing packets in a multicast fashion to and from the client terminals connected to that sub-network.
- MR multicast router
- client terminals 101-1 and 101-2 are connected to a common sub-network through MR 103
- client terminals 101-3 and 101-4 are connected to a common second sub-network through MR 104
- client terminal 101-5 is connected to a third sub-network through MR 105.
- a Directory Server (DS) 106 which need not operate in a multicast fashion, is connected to the network through router 107, which need not be multicast capable.
- Directory server 106 functions to maintain a list of multicast IP addresses and ports available for use for a plurality of different and possibly concurrent conferences, to assign a subset of those addresses and ports to a particular conference when a conference is initiated, and to assign from that subset a unique multicast IP address and port number to each media type of each client as that client makes a request to become a member of that conference.
- the assigned multicast IP addresses are marked as being unavailable and cannot be assigned to any other client attempting to join that same conference.
- the multicast IP addresses assigned to that participant's client are marked as being available and can be assigned to the client of a later joining participant.
- the client may decide how it wants to interact in the conference. Specifically, for each media type the client may only want to only receive, or to both receive and transmit, or to just transmit. Further, the client may choose to receive a particular media type from only select other clients on the conference. When a conference is established and a client joins an established conference, therefore, it receives a list of sockets used for transmitting by the other clients associated with the conference.
- the conference may then receive packets from the other clients in the conference on the sockets assigned for transmission to those other clients, or it may choose not to receive packets of any or all media types from other clients by either not adding the other client's socket(s) to its Multicast Receive Address List (MRAL), or by deleting the other client's socket from its MRAL if it was previously receiving transmissions from the other client.
- MRAL Multicast Receive Address List
- the client sets its local interface to receive only those packets whose IP addresses/port numbers match the ones in its MRAL. If a receiving client is located on a different sub-network than other transmitting clients, the receiving client may be periodically queried by the MR to which it is connected as to whether it wishes to receive packets with a given socket.
- the client will respond positively only for those sockets in its MRAL and the MRs will forward multicast packets with specific addresses to only those sub-networks from which a positive indication about receiving such specifically addressed packets is received.
- the MRs will forward multicast packets with specific addresses to only those sub-networks from which a positive indication about receiving such specifically addressed packets is received.
- only those multicast packets that are requested to be received by a client on one sub-network from a transmitting client on another sub-network need to be routed between sub-networks. Unnecessary inter sub-network transmission of packets is thus eliminated, thereby minimizing use of valuable transmission facilities.
- the conference may comprise the client terminals 101-1 - 101-5.
- One the conference is established by the conference originator on Directory Server 106, the user at each client may elect to receive audio signals from each of the other clients but may elect to receive video from only select other clients.
- the MRAL of each client includes the sockets of each of the other clients for the media type of audio signals. Multicast audio packets from each client are thus routed and transmitted through the multicast routers 103, 104 and 105 to each client.
- the users at clients 101-3, 101-4 and 101-5 may, however, elect to not receive video signals from clients 101-1 and 101-2.
- the MRALs of clients 101-3 - 101- 5 thus do not include the sockets for video packets for clients 101-1 and 101-2. Multicast video packets transmitted by clients 101-1 and 101-2 are thus not routed by multicast router 103 and remain only within their common subnetwork.
- the steps to originate a conference by a conference originator are detailed.
- a user by sending a packetized message, a user contacts the Directory Server to create a conference. This could be accomplished by the user clicking on an icon on a browser running on the client, or by the user inputting a particular URL address.
- the Directory Server requests the authorization of the user as a conference originator.
- the user provides his or her ID plus a password.
- the Directory Server returns to the user, for example, an HTML-formatted page requesting information from the originator such as the name and description of the conference, the media types involved with the conference, the types of encoding used by each of the media types, the time at which the conference is scheduled to take place and its expected duration, the maximum number of participants, a list of valid participants, and the name and phone number of a contact point for the proposed conference.
- the user provides the requested information at step 206.
- the Directory Server returns to the conference originator a password to be used by the participants in order to join the conference and allocates a set of multicast IP addresses and port numbers from the space of available multicast IP addresses and port numbers for each media type.
- a block of multicast IP addresses of a size a power of two is reserved for the conference.
- multicast routers can group adjacent addresses together and route a block of multicast addresses based on an entry for a single multicast address prefix in the multicast routing table.
- the Directory Server marks the assigned multicast IP addresses as being unavailable for assignment to any other conference. In other embodiments, the addresses could be incremented by a positive or negative integer of one or greater.
- a potential conferee contacts the DS by sending a packetized request either by clicking on an icon or inputting the URL address of the DS on the client's browser.
- the client receives from the DS a list of ongoing conferences from which the user selects the conference to which he or she wants to join.
- the DS sends a form back to the user's client requesting the user's ID and the password assigned by the DS to the conference. It is assumed that the password is made available to the conferees by an external system, such as a phone call/message, or encrypted e-mail.
- the user inputs the requested information and, at step 304, the DS compares the inputted information with its list of valid conference participants as inputted by the conference originator, and the password established for the conference. If the user is not authenticated at step 305, he or she is precluded from joining the conference and the process ends at step 310. If authenticated at step 305, the DS provides an address and port number for each media type for the client terminal to transmit on and a list of sockets for each media type to receive on for the other client terminals which are participating in the conference. At step 307, the user selects those clients from which to receive each media type from the list of sockets on which the other clients are transmitting.
- the Directory Server marks the addresses and ports assigned to the conference as available so they can be assigned to another conference.
- the Directory Server 106 is shown as being a centralized single server connected to the multicast capable IP network 102 in FIG. 1.
- the Directory Server could, alternatively, be a distributed algorithm on the network 102 that is executable by a client terminal desiring to create a conference and/or join a conference in accordance with the methods described above.
Abstract
In a multicast capable IP network, each client terminal on a multimedia conference, for each media type it transmits, is assigned a multicast IP address and a port number (together known as a socket) on which to transmit packets, wherein each assigned multicast IP address is unique and different than the multicast IP address assigned to any other client for any media type. Each client terminal then selects, for each media type, which clients on the conference it wants to receive packets from. Only packets that are in fact requested by a client are routed over the multicast IP network to the requesting client. When a conference originator establishes the conference, a number of multicast IP addresses are allocated for later assignment to the clients during the conference. As each client joins the conference, it is assigned a multicast IP address from the allocated group for each media type it will transmit. Those assigned addresses are then marked as unavailable for assignment to any other client that subsequently joins the conference. When the original client later exits the conference, its assigned multicast IP address(es) is (are) marked as available for assignment to a later joining client. At the conclusion of the conference, all multicast IP addresses allocated to the conference are marked as available for use in another conference.
Description
METHOD FOR MANAGING MULΗCAST ADDRESSES IN AN INTERNET PROTOCOL (IP) NETWORK
Technical Field
This invention relates to data communications, and more particularly, to the real-time interactive distribution of multimedia information using the multicast Internet Protocol (IP).
Background of the Invention
Conferencing systems are typically characterized by the following: a directory service which lists the set of conferences; a dynamic mechanism for keeping track of the members of a conference as they join or leave the conference; tools for generating and processing the audio, video and data sharing components of a conference; a data network for interconnecting the members of a conference; and transport mechanisms for distributing the multimedia conference content among the conference members.
Different transport mechanisms can be used to interconnect participants depending on the underlying capabilities of the data network. Two basic communication capabilities are: unicast communication, meaning a point-to- point communication between a source and a destination end-point; and multicast communication, meaning that one source end-point reaches multiple destination end-points. Since conferencing inherently implies the possibility of more than one destination end-point, if the network is capable only of unicast communication, then either the source must create multiple unicast
connections, or multicast servers external to the network must be employed. In the former case, each sender of information sets up multiple connections to every receiver, and replicates the data on each connection. Each receiver has multiple incoming connections, one for every sender of information. This approach becomes inefficient as the number of participants (N) gets large for two reasons. Firstly, the number of network connections is proportional to the square of N. Secondly, each end-point needs to replicate the data N times, possibly leading to both an excessive and unnecessary use of bandwidth in the network and an excessive amount of computation at the source. If external multicast servers are employed, then these servers perform the data replication function. Each sender of information needs to have a single unicast connection to the multicast server. Each receiver is connected to the multicast server. The number of connections is proportional to N, as all senders share the same set of connections to the set of receivers. The disadvantage of this scheme is that the multicast server becomes a bottleneck when N gets large.
When the interconnection network is multicast capable, more efficient alternatives are possible. With multicast service, the source of the information sends the data only once - the replication is handled by the network. It is as if the multicast servers described in the previous paragraph are bundled into the network. Efficient techniques for replication may exist in the network. For example, the data replication can be performed in hardware, and the replication function can be distributed over the switches or routers of the network. Furthermore the replication topology may be very efficient, e.g. a spanning tree, where receivers are leafs of the tree, and the data source is the root of the tree. Note that it is also possible to use external multicast servers in conjunction with a multicast network. For example, the multicast server may be connected to
the receivers by multicast mechanisms, and to the sources by unicast mechanisms.
The Internet Protocol (IP) is a widely used transport/networking protocol. In the IP application programming interface (API) (known as IP sockets or WINSOCK), application programs may write data to, or read data from a so- called socket just as if the socket was a "file descriptor" on the local computer. A socket is linked to a pair of numbers, i.e. an IP address and a positive integer referred to as a port number. For sending, the IP address used is the destination address to be placed in the destination field IP packet header, and the port number to be used by the application process on a remote machine for receiving the data. For receiving, the IP address is implicitly the local machine address (or in the case of IP multicast, the multicast group address of interest) , and the port number to be used by the application process on the local machine for receiving the data. Multicast IP, the primary mechanism by which IP networks support multicast, is an emerging capability of the IP protocol. In IP multicast service, unlike the unicast IP service where the address represents a specific and unique end-system, a sender transmits data addressed to an abstraction called a multicast address group. In the prior art, for a given conference, each media- type (e.g., audio, video) is associated with a particular port number and multicast IP address. All receivers for the given media-type listen to the specific socket consisting of the known multicast IP address and port number. All senders for the given media-type send to the specified socket consisting of the same multicast IP address and port number. Among different media-types, a different socket is utilized to enable different application programs to handle the different media of the conference. In prior art systems, the multicast IP
address may be the same or different among media types, but the port number is almost always different.
Receivers find out about the existence of multicast groups and port numbers through various (centralized or distributed) directory mechanisms. For example, a well-known multicast IP address may be reserved for directory announcements. Alternatively, a centralized server may contain a list of multicast groups and distribute this list to clients upon request. Once the appropriate multicast IP address information has been obtained from the directory mechanism, receivers send messages to multicast server processes (e.g., in multicast routers) indicating that they want to join a particular group. The routers then exchange information about the set of users that want to communicate, and build up interconnection trees among themselves. Note that in the prior art, for a given media type, since a common multicast IP address is used by all senders and receivers in a conference, and since the multicast IP address is the atomic unit of routing, this implies that the transmissions of all senders get routed to all receivers, even if each receiver is interested in a (possibly different) subset of the senders. This requires the receiver's application program to receive, process, and discard unwanted information; furthermore the typically expensive network bandwidth required to transport the unwanted information is wasted.
Summary of the Invention
In accordance with the present invention each conference rather than being represented by a single multicast IP address and port number for each media type that is used by each of the senders, is instead represented by a set of sockets, each socket comprising a multicast IP address and a port number.
Specifically, each transmitting client terminal is assigned a separate socket for each media type for which the multicast IP address of each is unique with respect to the sockets assigned to any other client terminal. Each client terminal can thus select the specific multicast IP addresses from which it wishes to receive. Thus, each client terminal can select to receive those media types from only those transmitting client terminals whose transmissions it has an interest in receiving. Further, it and does not need to perform internal processing to discard transmissions those clients whose transmissions it doesn't want to receive. Therefore, in establishing the network routing within the multicast capable IP network, routing of transmissions from a transmitting terminal to a receiving terminal of each media type is only effected to those receiving endpoint clients who have elected to receive such transmission. Thus, there is no wasted use of valuable transmission bandwidth and network facilities to carry and route transmissions to those endpoint client terminals on the conference who have not elected to receive them.
When a conference is established, in accordance with the present invention, a Directory Server allocates from the then available and unused multicast IP addresses, a group of such addresses to be used for the conference based on the maximum number of expected participants, which number is provided by a conference originator. As each participant joins the conference, the particpant's client terminal is assigned a port number and multicast IP address on which to transmit for each media type, wherein the multicast IP address is from the group of multicast IP addresses allocated for use by that conference. As each multicast IP address is assigned to a client terminal, it is marked as being unavailable for use by any other client terminal. Each packet transmitted by the client terminal for each media type then
thereafter includes its assigned identifier in its header. Upon joining the conference, or at any time during the conference, a conference participant can select which other clients' transmissions it desires to receive. Only those transmissions are then routed by the network to that client.
Brief Description of the Drawings
FIG. 1 is a block diagram showing a plurality of client terminals connected to a multicast capable IP network, to which is also connected a Directory Server for establishing a conference in accordance with the present invention;
FIG. 2 is a chart illustrating the steps associated with establishing a conference by a conference originator on the network of FIG. 1 ; and
FIG. 3 is a chart illustrating the steps associated with a user joining an already established conference on the network of FIG. 1.
Detailed Description
With reference to FIG. 1 , multimedia client terminals 101-1 - 101-5 are connected to a multicast capable Internet Protocol (IP) data network 102, which may, for example, be the Internet or a private IP network. The connections to the IP network 102 could be made via a Local Area Network (LAN) over T1/T3 facilities, an Asynchronous Digital Subscriber Loop (ADSL) link running a Frame Relay protocol, or over an ISND BRI link running the X.25 protocol, or any other digital or analog link. Network 102 may likely comprise plural sub- networks, with a multicast router (MR) routing packets in a multicast fashion to and from the client terminals connected to that sub-network. Thus, as
illustrated in FIG. 1 , client terminals 101-1 and 101-2 are connected to a common sub-network through MR 103, client terminals 101-3 and 101-4 are connected to a common second sub-network through MR 104, and client terminal 101-5 is connected to a third sub-network through MR 105. A Directory Server (DS) 106, which need not operate in a multicast fashion, is connected to the network through router 107, which need not be multicast capable.
Directory server 106 functions to maintain a list of multicast IP addresses and ports available for use for a plurality of different and possibly concurrent conferences, to assign a subset of those addresses and ports to a particular conference when a conference is initiated, and to assign from that subset a unique multicast IP address and port number to each media type of each client as that client makes a request to become a member of that conference. Once each socket (multicast IP address and port number) is assigned to a particular client for each media type for use during a conference, the assigned multicast IP addresses are marked as being unavailable and cannot be assigned to any other client attempting to join that same conference. Once a participant departs a still ongoing conference, the multicast IP addresses assigned to that participant's client are marked as being available and can be assigned to the client of a later joining participant.
Upon receiving the set of sockets assigned to it for the conference, the client may decide how it wants to interact in the conference. Specifically, for each media type the client may only want to only receive, or to both receive and transmit, or to just transmit. Further, the client may choose to receive a particular media type from only select other clients on the conference. When a conference is established and a client joins an established conference,
therefore, it receives a list of sockets used for transmitting by the other clients associated with the conference. At any time during the conference, it may then receive packets from the other clients in the conference on the sockets assigned for transmission to those other clients, or it may choose not to receive packets of any or all media types from other clients by either not adding the other client's socket(s) to its Multicast Receive Address List (MRAL), or by deleting the other client's socket from its MRAL if it was previously receiving transmissions from the other client. The client then sets its local interface to receive only those packets whose IP addresses/port numbers match the ones in its MRAL. If a receiving client is located on a different sub-network than other transmitting clients, the receiving client may be periodically queried by the MR to which it is connected as to whether it wishes to receive packets with a given socket. The client will respond positively only for those sockets in its MRAL and the MRs will forward multicast packets with specific addresses to only those sub-networks from which a positive indication about receiving such specifically addressed packets is received. Advantageously, therefore, only those multicast packets that are requested to be received by a client on one sub-network from a transmitting client on another sub-network need to be routed between sub-networks. Unnecessary inter sub-network transmission of packets is thus eliminated, thereby minimizing use of valuable transmission facilities.
In FIG. 1, for example, the conference may comprise the client terminals 101-1 - 101-5. One the conference is established by the conference originator on Directory Server 106, the user at each client may elect to receive audio signals from each of the other clients but may elect to receive video from only select other clients. Thus, for the media type of audio signals, the MRAL of
each client includes the sockets of each of the other clients for the media type of audio signals. Multicast audio packets from each client are thus routed and transmitted through the multicast routers 103, 104 and 105 to each client. The users at clients 101-3, 101-4 and 101-5 may, however, elect to not receive video signals from clients 101-1 and 101-2. The MRALs of clients 101-3 - 101- 5 thus do not include the sockets for video packets for clients 101-1 and 101-2. Multicast video packets transmitted by clients 101-1 and 101-2 are thus not routed by multicast router 103 and remain only within their common subnetwork. With reference to FIG. 2, the steps to originate a conference by a conference originator are detailed. At step 201 , by sending a packetized message, a user contacts the Directory Server to create a conference. This could be accomplished by the user clicking on an icon on a browser running on the client, or by the user inputting a particular URL address. At step 202, the Directory Server requests the authorization of the user as a conference originator. At step 203, the user provides his or her ID plus a password. At step 204, if recognized by the DS as an authorized conference originator, the user is authenticated and permitted to proceed to establish the conference. If not, the process ends at step 209. If authenticated, at step 205, the Directory Server returns to the user, for example, an HTML-formatted page requesting information from the originator such as the name and description of the conference, the media types involved with the conference, the types of encoding used by each of the media types, the time at which the conference is scheduled to take place and its expected duration, the maximum number of participants, a list of valid participants, and the name and phone number of a contact point for the proposed conference. The user provides the requested
information at step 206. At step 207, the Directory Server returns to the conference originator a password to be used by the participants in order to join the conference and allocates a set of multicast IP addresses and port numbers from the space of available multicast IP addresses and port numbers for each media type. Specifically, in accordance with this invention, a block of multicast IP addresses of a size a power of two is reserved for the conference. As each client later joins the conference, it is assigned an address one higher than the previously assigned address. Beneficially, multicast routers can group adjacent addresses together and route a block of multicast addresses based on an entry for a single multicast address prefix in the multicast routing table. At step 298, the Directory Server marks the assigned multicast IP addresses as being unavailable for assignment to any other conference. In other embodiments, the addresses could be incremented by a positive or negative integer of one or greater. Once the conference originator has established the conference with the
Directory Server, users at the client terminals may join the conference within its scheduled time. With reference to FIG. 3, at step 301 a potential conferee contacts the DS by sending a packetized request either by clicking on an icon or inputting the URL address of the DS on the client's browser. At step 302, the client receives from the DS a list of ongoing conferences from which the user selects the conference to which he or she wants to join. At step 303, in response to the selected conference, the DS sends a form back to the user's client requesting the user's ID and the password assigned by the DS to the conference. It is assumed that the password is made available to the conferees by an external system, such as a phone call/message, or encrypted e-mail. The user inputs the requested information and, at step 304, the DS
compares the inputted information with its list of valid conference participants as inputted by the conference originator, and the password established for the conference. If the user is not authenticated at step 305, he or she is precluded from joining the conference and the process ends at step 310. If authenticated at step 305, the DS provides an address and port number for each media type for the client terminal to transmit on and a list of sockets for each media type to receive on for the other client terminals which are participating in the conference. At step 307, the user selects those clients from which to receive each media type from the list of sockets on which the other clients are transmitting. This is done by either adding the other client's address to its MRAL or deleting the other client's address(es) from its MRAL if it has been previously receiving a currently unwanted media type of transmission from that other client. When a client elects to exit a conference, it deletes all the addresses /ports associated with the conference from its MRAL. When the conference is concluded, the Directory Server, at step 309, marks the addresses and ports assigned to the conference as available so they can be assigned to another conference.
As described hereinabove, the Directory Server 106 is shown as being a centralized single server connected to the multicast capable IP network 102 in FIG. 1. The Directory Server could, alternatively, be a distributed algorithm on the network 102 that is executable by a client terminal desiring to create a conference and/or join a conference in accordance with the methods described above.
The above-described embodiment is illustrative of the principles of the present invention. Other embodiments could be devised by those skilled in the art without departing from the spirit and scope of the present invention.
Claims
Claims 1. In a multicast capable IP network in which during a conference at least one of a plurality of clients transmits packets on a socket for multicast transmission of those packets to at least some of the plurality of clients in the conference, each socket comprising a multicast IP address and a port number, a method comprising: assigning to each client in the conference a socket having a different unique multicast IP address on which to transmit packets.
2. The method of claim 1 wherein the conference is a multimedia conference in which packets of plural media types are transmitted by the at least one client, the step of assigning comprising assigning a socket having a different unique multicast IP address to each client in the conference for each media type transmitted.
3. The method of claim 2 wherein the plural media types are at least one of audio, video and/or data.
4. The method of claim 2 further comprising the step of routing to the at least one client packets transmitted on sockets by those clients selected by the at least one client from the plurality of clients on the conference.
5. The method of claim 1 wherein the multicast IP addresses of the sockets assigned to the clients on the conference are from a group of multicast IP addresses allocated to the conference.
6. The method of claim 5 wherein the group of multicast IP addresses allocated to the conference has a size that is a power of two.
7. The method of claim 6 wherein the multicast IP address of the socket assigned to the at least one client is incremented by a positive or negative integer of least one from the multicast IP address associated with the socket previously assigned to another client on the conference.
8. A method on a multicast capable IP network for a client to join a conference with at least one other client comprising the steps of: assigning to the client as it joins the conference a socket on which to transmit packets, the socket comprising a multicast IP address and a port number, the multicast IP address of the assigned socket being different than the multicast IP address of a socket assigned to any other client on the conference, the multicast IP address of the socket assigned to each one of the any other clients on the conference being different than the multicast IP address of any other assigned socket; receiving from the joining client an indication of which clients on the conference it selects to receive transmitted packets from; and routing to the joining client packets transmitted on those sockets associated with the selected clients.
9. The method of claim 8 wherein the conference is a multimedia conference in which packets of plural media types are transmitted by the joining client and the at least one other client, the step of assigning a socket to the joining client comprising assigning a socket with a different unique multicast IP address to each media type transmitted by the joining client.
10. The method of claim 9 wherein the plural media types are at least one of audio, video and/or data.
11. The method of claim 9 wherein the step of receiving comprises receiving from the joining client an indication of from which clients and on which media types it selects to receive transmitted packets, and the step of routing comprises routing to the joining client packets transmitted on those sockets associated with the selected clients and media types.
12. The method of claim 8 wherein the multicast IP address of the socket assigned to the joining client as it joins the conference is from a group of multicast IP addresses allocated to the conference.
13. The method of claim 12 wherein the group of multicast IP addresses assigned to the conference has a size that is a power of two.
14. The method of claim 13 wherein the multicast IP address of the socket assigned to the joining client as is joins the conference incremented by a positive or negative integer of at least one from the multicast IP address of the socket previously assigned to any other client on the conference.
15. The method of claim 12 further comprising the step of marking as unavailable for assignment to another client joining the conference the multicast IP address assigned to the joining client from the group of multicast IP addresses allocated to the conference.
16. The method of claim 15 further comprising the step of marking as available for assignment to another client in the group of multicast IP addresses allocated to the conference the multicast IP address assigned to the joining client if and when the joining client exits the conference.
17. A method of establishing a conference on a multicast capable IP network comprising the steps of: receiving from an originating client a request to establish the conference; allocating a plurality of separate and unique multicast IP addresses for each of a plurality of clients for a maximum number of clients that will be participants in the conference, the maximum number of clients being provided by the originating client.
18. The method of claim 17 wherein the conference is a multimedia conference in which packets of plural media types are transmitted by at least some of the clients that are participants in the conference, and the step of allocating allocates a separate and unique multicast IP address for each of the plural media types transmitted by the maximum number of clients that will be participants in the conference.
19. The method of claim 18 wherein the plural media types are at least one of audio, video, and/or data.
20. The method of claim 17 wherein the number of multimedia IP addresses allocated to the conference is a power of two.
21. Apparatus associated with a multicast capable IP network for establishing and running a conference on which at least one of a plurality of clients connected to the network transmits packets for multicast transmission to at least some of the plurality of clients on the conference on a socket that comprises a multicast IP address and a port number, the apparatus comprising: means for receiving a request to join the conference from one of the clients; and means for assigning to the one of the clients a socket with a unique multicast IP address on which to transmit packets which is different than the multicast IP address of a socket assigned to any other client on the conference, the multicast IP address of the socket assigned to each one of the any other clients on the conference being different than the multicast IP address of any other assigned socket.
22. The apparatus of claim 21 further comprising means responsive to a request to establish the conference by a conference originator for allocating a plurality of separate and unique multicast IP addresses for a maximum number of participants in the conference, the maximum number being provided by the conference originator.
23. The apparatus of claim 22 wherein the number of multicast IP addresses allocated to the conference is a power of two.
24. The apparatus of claim 23 wherein the assigning means assigns to the one of the clients a socket having a multicast IP address that is incremented by a positive or negative integer of at least one from than the multicast IP address of the socket previously assigned to another client on the conference.
25. The apparatus of claim 21 wherein the conference is a multimedia conference in which packets of plural media types are transmitted by the one of the clients and at least one of the other clients, the assigning means assigning a socket with a unique multicast IP address to each media type transmitted by the one of the clients.
26. The apparatus of claim 25 wherein the plural media types are at least one of audio, video and/or data.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/848,456 US6011782A (en) | 1997-05-08 | 1997-05-08 | Method for managing multicast addresses for transmitting and receiving multimedia conferencing information on an internet protocol (IP) network |
US08/848,456 | 1997-05-08 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO1998051040A1 true WO1998051040A1 (en) | 1998-11-12 |
Family
ID=25303323
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1998/006447 WO1998051040A1 (en) | 1997-05-08 | 1998-04-01 | Method for managing multicast addresses in an internet protocol (ip) network |
Country Status (2)
Country | Link |
---|---|
US (1) | US6011782A (en) |
WO (1) | WO1998051040A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1024647A1 (en) * | 1999-01-29 | 2000-08-02 | International Business Machines Corporation | Conferencing system |
EP1315377A1 (en) * | 2000-08-31 | 2003-05-28 | Sony Corporation | Content distribution reservation method, content distribution method, reservation management device, and program |
WO2016202172A1 (en) * | 2015-06-17 | 2016-12-22 | 华为技术有限公司 | Method and apparatus for allocating internet protocol (ip) addresses |
Families Citing this family (87)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5694546A (en) | 1994-05-31 | 1997-12-02 | Reisman; Richard R. | System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list |
US6873627B1 (en) * | 1995-01-19 | 2005-03-29 | The Fantastic Corporation | System and method for sending packets over a computer network |
ES2290986T3 (en) | 1997-03-12 | 2008-02-16 | Nomadix, Inc. | NAME TRANSMITTER OR ROUTER. |
US8458756B2 (en) * | 1997-05-16 | 2013-06-04 | Arturo A. Rodriguez | Videophone over cable networks |
US6189043B1 (en) * | 1997-06-09 | 2001-02-13 | At&T Corp | Dynamic cache replication in a internet environment through routers and servers utilizing a reverse tree generation |
US6963905B1 (en) * | 1997-09-29 | 2005-11-08 | Emc Corporation | System and method including a communication interface for transferring information between at least two processes |
US6108652A (en) * | 1997-12-01 | 2000-08-22 | At&T Corp. | Multicast probability-base grouping of nodes in switched network for improved broadcast search |
EP1040645B1 (en) * | 1997-12-16 | 2018-03-28 | Nokia Solutions and Networks GmbH & Co. KG | Method and apparatus for receiving full-motion digital video multi-casts, interactive data and interactive voice via a dsl circuit |
US6353614B1 (en) | 1998-03-05 | 2002-03-05 | 3Com Corporation | Method and protocol for distributed network address translation |
US7450560B1 (en) | 1998-03-05 | 2008-11-11 | 3Com Corporation | Method for address mapping in a network access system and a network access device for use therewith |
US7032242B1 (en) | 1998-03-05 | 2006-04-18 | 3Com Corporation | Method and system for distributed network address translation with network security features |
US6621514B1 (en) * | 1998-03-12 | 2003-09-16 | Intel Corporation | Video conferencing system |
US6181697B1 (en) * | 1998-03-31 | 2001-01-30 | At&T Corp. | Method for a unicast endpoint client to access a multicast internet protocol (IP) session and to serve as a redistributor of such session |
US6418141B1 (en) * | 1998-06-01 | 2002-07-09 | Lucent Technologies, Inc. | Multi-cast enabled web server |
US6512776B1 (en) * | 1998-06-15 | 2003-01-28 | Motorola, Inc. | Method and apparatus for transparently multicasting identical data streams originating from different or common sources |
US6249813B1 (en) * | 1998-08-06 | 2001-06-19 | Mci Communications Corporation | Automated method of and apparatus for internet address management |
AU6258499A (en) * | 1998-09-22 | 2000-04-10 | Science Applications International Corporation | User-defined dynamic collaborative environments |
US6226684B1 (en) * | 1998-10-26 | 2001-05-01 | Pointcast, Inc. | Method and apparatus for reestablishing network connections in a multi-router network |
US6262979B1 (en) * | 1998-12-01 | 2001-07-17 | 3Com Corporation | Telecommunication conferencing system and method |
US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
US6564380B1 (en) | 1999-01-26 | 2003-05-13 | Pixelworld Networks, Inc. | System and method for sending live video on the internet |
US6738382B1 (en) * | 1999-02-24 | 2004-05-18 | Stsn General Holdings, Inc. | Methods and apparatus for providing high speed connectivity to a hotel environment |
GB2348570B (en) * | 1999-03-31 | 2003-03-05 | Ericsson Telefon Ab L M | Mobile internet access |
WO2000060809A1 (en) * | 1999-04-01 | 2000-10-12 | Multitude, Inc. | Apparatus and method for establishing an audio conference in a networked environment |
US6731642B1 (en) | 1999-05-03 | 2004-05-04 | 3Com Corporation | Internet telephony using network address translation |
US6757259B1 (en) * | 1999-08-12 | 2004-06-29 | Intel Corporation | Control of internet based video conferencing |
WO2001031885A2 (en) | 1999-10-22 | 2001-05-03 | Nomadix, Inc. | Gateway device having an xml interface and associated method |
US6768743B1 (en) | 1999-10-26 | 2004-07-27 | 3Com Corporation | Method and system for address server redirection for multiple address networks |
US6781982B1 (en) | 1999-10-26 | 2004-08-24 | 3Com Corporation | Method and system for allocating persistent private network addresses between private networks |
US6708219B1 (en) | 1999-10-26 | 2004-03-16 | 3Com Corporation | Method and system for dual-network address utilization |
US6996621B1 (en) | 1999-12-07 | 2006-02-07 | 3Com Corporation | Method for supporting secondary address delivery on remote access servers |
US7660849B1 (en) * | 1999-12-14 | 2010-02-09 | Cisco Technology, Inc. | Extending camp-on capabilities to invitees to an ongoing converence call |
US20020054205A1 (en) * | 2000-02-22 | 2002-05-09 | Magnuski Henry S. | Videoconferencing terminal |
US7280492B2 (en) * | 2000-02-22 | 2007-10-09 | Ncast Corporation | Videoconferencing system |
US7171492B1 (en) | 2000-02-24 | 2007-01-30 | Utstarcom, Inc. | Method and application programming interface for assigning multiple network addresses |
US6477150B1 (en) * | 2000-03-03 | 2002-11-05 | Qualcomm, Inc. | System and method for providing group communication services in an existing communication system |
US6948074B1 (en) | 2000-03-09 | 2005-09-20 | 3Com Corporation | Method and system for distributed generation of unique random numbers for digital tokens |
EP1287677A2 (en) * | 2000-03-13 | 2003-03-05 | Comnet Media Corporation | Video data management, transmission, and control system and method employing distributed video segments microcasting |
US6353891B1 (en) | 2000-03-20 | 2002-03-05 | 3Com Corporation | Control channel security for realm specific internet protocol |
US6826159B1 (en) * | 2000-05-24 | 2004-11-30 | Cisco Technology, Inc. | System and method for providing speaker identification in a conference call |
EP1158731A3 (en) * | 2000-05-25 | 2003-08-13 | Roke Manor Research Limited | Improvements in or relating to packet switches |
US7487112B2 (en) * | 2000-06-29 | 2009-02-03 | Barnes Jr Melvin L | System, method, and computer program product for providing location based services and mobile e-commerce |
US7133837B1 (en) * | 2000-06-29 | 2006-11-07 | Barnes Jr Melvin L | Method and apparatus for providing communication transmissions |
US20030065720A1 (en) * | 2000-09-29 | 2003-04-03 | Chafer Charles M. | System and method for on-line participation in memorial services for space burials and the like |
US7454484B1 (en) * | 2000-11-16 | 2008-11-18 | Nortel Networks Limited | Method and apparatus for producing a multicast tree |
JP2002164889A (en) * | 2000-11-24 | 2002-06-07 | Matsushita Electric Ind Co Ltd | Multicast conference method by multiple terminals, and conference terminal used therefor, and conference system |
US7158534B2 (en) * | 2000-11-30 | 2007-01-02 | Imajet Communications, Inc. | Unified distributed architecture for a multi-point video conference and interactive broadcast systems |
US6993050B2 (en) | 2001-03-14 | 2006-01-31 | At&T Corp. | Transmit and receive system for cable data service |
DE10117679B4 (en) * | 2001-04-09 | 2006-04-27 | Siemens Ag | A method of exchanging messages and information during a telephone conference |
US7266609B2 (en) * | 2001-04-30 | 2007-09-04 | Aol Llc | Generating multiple data streams from a single data source |
US7237033B2 (en) | 2001-04-30 | 2007-06-26 | Aol Llc | Duplicating switch for streaming data units to a terminal |
US7430609B2 (en) | 2001-04-30 | 2008-09-30 | Aol Llc, A Delaware Limited Liability Company | Managing access to streams hosted on duplicating switches |
US8572278B2 (en) * | 2001-04-30 | 2013-10-29 | Facebook, Inc. | Generating multiple data streams from a single data source |
US7124166B2 (en) * | 2001-04-30 | 2006-10-17 | Aol Llc | Duplicating digital streams for digital conferencing using switching technologies |
WO2003105006A1 (en) * | 2001-04-30 | 2003-12-18 | America Online, Inc. | Load balancing with direct terminal response |
US7231423B1 (en) | 2001-05-23 | 2007-06-12 | Jens Horstmann | Interactive wireless device communication system for meetings and conferences |
US7590692B2 (en) * | 2001-07-09 | 2009-09-15 | Dialogic Corporation | Conferencing architecture employing media servers and enhanced session initiation protocol |
EP1283652A1 (en) * | 2001-08-07 | 2003-02-12 | Siemens Aktiengesellschaft | Method, transceiver unit and communications system for transmitting data from one transmitter to multiple receivers |
US7103011B2 (en) * | 2001-08-30 | 2006-09-05 | Motorola, Inc. | Use of IP-multicast technology for 2-party calls in mobile communication networks |
US6697349B2 (en) * | 2001-08-30 | 2004-02-24 | Motorola, Inc. | System and methods for distributed connection and mobility processing in a multicast IP network incorporating multi-cell location areas |
EP1440550B8 (en) * | 2001-10-24 | 2018-04-11 | Rateze Remote Mgmt. L.L.C. | Methods for multicasting content |
EP1324560B1 (en) * | 2001-12-28 | 2008-01-16 | Motorola, Inc. | Communication over a selected part of a network |
US20040128693A1 (en) | 2002-12-27 | 2004-07-01 | Weigand Gilbert G. | System and method for enabling access to content through a personal channel |
US8611919B2 (en) * | 2002-05-23 | 2013-12-17 | Wounder Gmbh., Llc | System, method, and computer program product for providing location based services and mobile e-commerce |
US10489449B2 (en) | 2002-05-23 | 2019-11-26 | Gula Consulting Limited Liability Company | Computer accepting voice input and/or generating audible output |
US8028092B2 (en) | 2002-06-28 | 2011-09-27 | Aol Inc. | Inserting advertising content |
US7289500B1 (en) * | 2003-07-17 | 2007-10-30 | Novell, Inc. | Method and system for reliable multicast data transmission |
US7197071B1 (en) | 2002-09-09 | 2007-03-27 | Warner Bros. Entertainment Inc. | Film resource manager |
US7376183B2 (en) | 2002-09-09 | 2008-05-20 | Warner Bros. Entertainment, Inc. | Post-production processing |
US8411594B2 (en) * | 2002-09-20 | 2013-04-02 | Qualcomm Incorporated | Communication manager for providing multimedia in a group communication network |
US7130282B2 (en) * | 2002-09-20 | 2006-10-31 | Qualcomm Inc | Communication device for providing multimedia in a group communication network |
US7278920B1 (en) | 2002-12-31 | 2007-10-09 | Warner Bros. Entertainment, Inc. | Theater-based gaming system enabling a multi-player game throughout a system of the theaters |
US7864939B1 (en) * | 2003-04-30 | 2011-01-04 | At&T Intellectual Property Ii, L.P. | Call arrangement and connection using messaging |
KR100580173B1 (en) * | 2003-07-15 | 2006-05-15 | 삼성전자주식회사 | Network scanning method and apparatus, and packet format therefor |
KR20060120019A (en) * | 2003-10-07 | 2006-11-24 | 톰슨 라이센싱 | Multicast over unicast in a network |
JP2005244521A (en) * | 2004-02-25 | 2005-09-08 | Pioneer Electronic Corp | Network conference system, management server, conference terminal and method of managing information transmission authority |
US7664058B1 (en) * | 2005-02-02 | 2010-02-16 | At&T Corp. | Method and apparatus for providing spontaneous multi-way telephone conversation with inserted messaging |
AU2007240562A1 (en) * | 2006-04-26 | 2007-11-01 | Upl Ip Holding, Ltd. | System for presentation of live video and audio compilations on TV using the internet |
US20080072292A1 (en) * | 2006-09-01 | 2008-03-20 | Narjala Ranjit S | Secure device introduction with capabilities assessment |
US8953486B2 (en) * | 2007-11-09 | 2015-02-10 | Cisco Technology, Inc. | Global auto-configuration of network devices connected to multipoint virtual connections |
US8667095B2 (en) * | 2007-11-09 | 2014-03-04 | Cisco Technology, Inc. | Local auto-configuration of network devices connected to multipoint virtual connections |
US20100005497A1 (en) * | 2008-07-01 | 2010-01-07 | Michael Maresca | Duplex enhanced quality video transmission over internet |
US8867539B2 (en) | 2009-09-18 | 2014-10-21 | At&T Intellectual Property I, L.P. | Multicast-unicast protocol converter |
US8150993B2 (en) * | 2009-10-29 | 2012-04-03 | At&T Intellectual Property I, Lp | Synchronization of clients to maximize multicast opportunities |
US8456509B2 (en) * | 2010-01-08 | 2013-06-04 | Lifesize Communications, Inc. | Providing presentations in a videoconference |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5674003A (en) * | 1995-04-28 | 1997-10-07 | Andersen; David B. | Mechanisms for accessing unique features of telephony networks from a protocol-Independent data transport interface |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5835723A (en) * | 1995-12-28 | 1998-11-10 | Intel Corporation | Dynamic assignment of multicast addresses |
US5812552A (en) * | 1996-03-19 | 1998-09-22 | At & T Corp | Method and apparatus for dynamically forming multimedia emulated local area networks |
US5841976A (en) * | 1996-03-29 | 1998-11-24 | Intel Corporation | Method and apparatus for supporting multipoint communications in a protocol-independent manner |
-
1997
- 1997-05-08 US US08/848,456 patent/US6011782A/en not_active Expired - Lifetime
-
1998
- 1998-04-01 WO PCT/US1998/006447 patent/WO1998051040A1/en active Application Filing
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5674003A (en) * | 1995-04-28 | 1997-10-07 | Andersen; David B. | Mechanisms for accessing unique features of telephony networks from a protocol-Independent data transport interface |
Non-Patent Citations (2)
Title |
---|
AHAMAD M ET AL: "MULTICAST COMMUNICATION IN UNIX 4.2BSD", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTIN SYSTEMS, DENVER, COLORADO, MAY 13 - 17, 1985, vol. C, no. ONF. 5, 13 May 1985 (1985-05-13), INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 80 - 87, XP000673844 * |
WILLEBEEK-LEMAIR M H ET AL: "Distributed video conferencing systems", COMPUTER COMMUNICATIONS, vol. 20, no. 3, May 1997 (1997-05-01), pages 157-168, XP004081675 * |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1024647A1 (en) * | 1999-01-29 | 2000-08-02 | International Business Machines Corporation | Conferencing system |
US6509925B1 (en) | 1999-01-29 | 2003-01-21 | International Business Machines Corporation | Conferencing system |
EP1315377A1 (en) * | 2000-08-31 | 2003-05-28 | Sony Corporation | Content distribution reservation method, content distribution method, reservation management device, and program |
EP1315377A4 (en) * | 2000-08-31 | 2009-02-25 | Sony Corp | Content distribution reservation method, content distribution method, reservation management device, and program |
WO2016202172A1 (en) * | 2015-06-17 | 2016-12-22 | 华为技术有限公司 | Method and apparatus for allocating internet protocol (ip) addresses |
Also Published As
Publication number | Publication date |
---|---|
US6011782A (en) | 2000-01-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6011782A (en) | Method for managing multicast addresses for transmitting and receiving multimedia conferencing information on an internet protocol (IP) network | |
US6138144A (en) | Method for managing multicast addresses for transmitting and receiving multimedia conferencing information on an internet protocol (IP) network implemented over an ATM network | |
US6181697B1 (en) | Method for a unicast endpoint client to access a multicast internet protocol (IP) session and to serve as a redistributor of such session | |
Schulzrinne | Personal mobility for multimedia services in the Internet | |
US5812552A (en) | Method and apparatus for dynamically forming multimedia emulated local area networks | |
US7783704B2 (en) | System and apparatus for geographically distributed VoIP conference service with enhanced QoS | |
EP0902569B1 (en) | Method and system for a unicast endpoint client to access a multicast internet protocol (ip) session | |
US6438111B1 (en) | Dynamically scaleable conference system | |
EP2241091B1 (en) | Combining locally addressed devices and wide area network (wan) addressed devices on a single network | |
US7936696B2 (en) | Efficient transmission of data to multiple network nodes | |
AU6973798A (en) | Multicast switching | |
US8621083B2 (en) | System and method for multicasting through a localized computer network | |
Pejhan et al. | Distributed multicast address management in the global internet | |
JP3720026B2 (en) | Device identification method supporting MCAP on the same network and multicast communication method using the same | |
CN1610349B (en) | Real-time information transmitting method | |
RU2240657C1 (en) | Method and device for conducting video conferences | |
KR100565186B1 (en) | Video Conferencing Method Using Multicast_ | |
KR100280825B1 (en) | How to Manage Session Membership in Internet Multicast Applications | |
EP2066073A1 (en) | Access system and method for multicast management | |
Jia et al. | Topology-aware optimal subgrouping and subscheduling for generalized explicit multicasting on Internet | |
KR100562145B1 (en) | Information Transmitting Method By Network Grouping | |
KR20000027471A (en) | Method for transmitting session data of a multicast router | |
Kreibich | The MBONE: the Internet's other backbone | |
KR100527200B1 (en) | method and apparatus for offer conference service in exchange switch | |
KR20070108968A (en) | Multicast group subscriber management method by xdsl device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): CA |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
122 | Ep: pct application non-entry in european phase | ||
NENP | Non-entry into the national phase |
Ref country code: CA |