Multicast videoconferencing

Abstract

In one embodiment, the invention is a method of transferring data. The method includes receiving a first video data stream at a first machine. The method also includes multicasting the first video data stream in uncompressed and raw form through a network. The method further includes receiving the first video data stream at a second machine. The method also includes playing the first video data stream on the second machine.

Description

S_i=PacketSize/IPG_i
IPG_i+1=IPG_i*C/(IPG_i+C)
α=S_i+1−S_i=PacketSize/C  [5]

When there is no packet loss then [5] is carried out. When it has been determined that packets have been lost, then [6] is carried out.
S_i+1=β*S_i
IPG_i+1=IPG_i/β
β=0.5  [6]
Where IPG is the inter-packet gap or packet loss and C is an equation that determines the number of packets sent during each step and increased by K every step.

The decision frequency is used to determine how often to change the rate. It is suggested that rate-based schemes modify their rates no more than once per RTT (Round Trip Time) using the most recent value Smoother RTT (SRTT). The decision frequency should not change too much as it may result in oscillation but not changing enough may result in unresponsive behaviour. The decision frequency preferably adjusts the Inter-Packet Gap (IPG) once every Round Trip Time (RTT) using the most recent value of Smoothed RTT (SRTT). In a steady state, the number of packets transmitted per step is increased by one and C is adjusted accordingly. If IPG is updated once every T seconds and C is determined to be T/K, then the number of packets sent during each step is increased by K every step. Here, RAP uses K=1 to emulate the TCP window adjustment.

The purpose of fine grain rate adaptation is to make RAP more stable and responsive to congestion while performing the AIMD algorithm at a coarser granularity. As shown in FIG. 12, the simulation result of the transmission rate of a single RAP flow without fine grain rate adaptation is significantly higher per unit time than the transmission rate of a single flow with fine grain rate adaptation. Binomial algorithms allow for the increase and decrease in windows size. Wt is the window size at time t.
I:ω_t+R←ω_t+α/ω_t^k; α>0  [7]
D:ω_t+δt←ω_t−βω_t^l0<β<1  [8]

When α>0, then [7] is performed and increases the window as a result of receipt of one window ACK in an RTT. But when β<1, the windows size is decreased due to the detection if a loss by the sender. When any 1<1 in [8], then it has a decrease that is, in general, less than a multiplicative decrease. [7] and [8] are TCP friendly if and ONLY if K+1=1 and 1<=1 for suitable α and β. An equilibrium state is accomplished when all involved algorithms meet the following requirements;
K>=0
l>=0
k+1>0

Research collected through experimentation yielded FIG. 13. This figure demonstrates fairness to TCP vs. K for different values of K. The values of K are 0.5, 1.0 and 1.5.

Multicast

The packet loss of transmitting raw audio/video packets in forward direction multicast is about 12% in one embodiment. As the stream, containing the combined raw video and audio data, is received by the destination client computer, the destination client computer sends back a signal to the various checksum points requesting the missing data packets, e.g., the data packets that were not delivered to the destination client computer. It takes a fraction of a nano-second to check each checksum value along the way. For purposes of the following explanation client computer is client #1 and the destination client computer is client #2.

For sending data from client #2 back to the source client computer, the process is reversed (return direction). See FIG. 14. In other words, client #2 computer now behaves in the manner that client #1 computer previously behaved and sends data to client #1.

During the reverse process, the packet loss becomes negligible, in contrast to the 12% error rate in the forward direction. According to certain embodiments of the invention, on the return direction, the error rate is about +−1.08%.

The method for a one-to-many bilateral communication can and also be applied to a one-to-many unilateral net meeting (video conferencing). Recall, there was packet loss in a first pass (forward direction) for a particular stream of packets and the loss disappeared on the return direction. See FIG. 14. The rate at which data packets travel is based on the various computer equipment requirements or the maximum the hardware can handle. As an example, 36 MB of combined raw audio/video data can be sent over the network in approximately ten seconds. This goes form the source client computer through the USB port, through the network and then to the destination client computer, and then back to the source client computer.

Furthermore, the rate of input of input devices and the rate of output of output devices may adjust the rate at which the data packets travel. For example, an input camera has the ability to send input at approximately fifteen frames per second (15 frames/sec) and the USB port only transmits five (5) Mega hertz/sec from the camera to the computer. Therefore, the rate at which the packets are traveling can be adjusted based on technological advances of input device speed and camera speed.

The above is an explanation of a one-tone (1 to 1) audio/video communication. The use of RAM, processor time, and bandwidth is minimal. But there are a number of ratios that may be considered. It ranges from a one-to-one (1 to 1) communication and can expand to at least a one-to-one hundred twenty eight (1 to 128) communication ratio. FIG. 15 demonstrates the RAM, CPU and Operating System (OS) usage as a percentage in a unicast and multicast transmission for various groups.

The total system resources for each instance are shown as well. In a unicast transmission once you reach a one-to-three (1 to 3) communication the system resources are completely used.

According to certain embodiments of the invention, in a multicast situation, a one-to-three (1 to 3) communication total system resource usage is thirty-five percent (35%). This is the vortex point, you can then add as many members to the group as you wish and when you reach a group of one-to-one hundred twenty-eight (1 to 128) the total system resource usage is approximately thirty-five percent plus/minus seven percent (35%+/−7%).

For better results and transmitting better quality of data (i.e., audio/video or any kind of data) we can use three servers, namely: Login server, Profile server and Registry server. Each server is connected through a gateway to the network. For example, Windows 2000 and XP have built-in Internet Location Server (ILS) servers. Also there are hundreds of public ILS servers available worldwide. Note that the login server, profile server and registry server can reside in one server or more than one server.

According to certain embodiments of the invention, when there are more than 1000 users who wish to participate in a given video conference with one another, then at least three server devices are used for housing the login, profile and registry servers. In FIG. 16, three users are shown connected to the ILS. There is one multicast data connection (for data needed for connecting the users) between the users and the ILS.

The login server and the profile server, is each associated with a multicast queue. See FIG. 16. For example, when user #1 sends out a signal, the login server's queue comes to the gateway and pings client #1. The queue sends many signals. Thus, the queue lines up the signals from each user in the queue. As a result, the login server can process each user one at a time from the queue. For example, it may take the login server 2 to 3 seconds to process 1000 users who want to log in and who are queued up.

After the login server has completed its job, the login server sends a signal to the profile server. The profile server provides IDs to each user. In other words, the profile server checks to see if the user is who the user says he is. When the profile server is done checking out a particular user, the profile server signals the registry server with respect to the user who has just been checked. The registry server sends back information to the profile server regarding the user.

Note that the first time a new user creates a signature on the multicast network; the registry server comes into play. The new user then enters all his information (name, address, etc.).

Once a user is logged in and user has been checked against the information in the registry server, that particular user can join a given net meeting. The profile server sends back to the user who is on the same stream any messages, or tells the user if there are other users that are waiting to video conference with that user. The profile server also provides information on communication ports, IP numbers, and any other information that the user needs to know for establishing multicast connections.

With reference to FIG. 16, user #1, user #2, and user #3 are logged in and connected to the ILS. Further user #1 is online but is not video conferencing with any other user initially. User #1 waits to be invited by someone to video conference. User #3 invites user #1 to a video conference. User #3 sends a message out to the profile server inform that user #3 wants to invite user #1 to a video conference. Profile server then sends a message to user #1 informing user #1 of user #3's invitation. User #1 can agree to join the video conference by letting the ILS server know of user #1's desire to join. User #1 and user #3 are then connected to each other on the same stream. Each user (client computer) that is connected has an independent open port available to receive the multicast signal. There may be up to 9000 open multicast ports on each client (based on current technological limitations). Even though user #1 is connected to user #3, such a connection does not terminate the responsibility of the profile server. Periodically, both user #1 and user #3 will each create a second stream for sending to the profile server. For example, every 10 seconds both user #1 and user #3 will each create a second stream for sending to the profile server. However, the connection to the profile server, at this point, is not a constant steady link. The second stream will check for incoming messages, for example. The check lasts for about 2 seconds and then the connection to profile server breaks up. If, there is an incoming message to an appropriate user that has logged in, the profile server will respond by sending the message to the appropriate user. When any user sends out that second stream to the profile server but does not get an acknowledgment from the profile server, then it probably means that there is no multicast connection. For example, there will be no multicast connection if the profile server has crashed.

If there is a one-to-many video conferencing, the ILS establishes a stream (connection) from the outermost point in the network. See FIG. 17. User 6 (Hong Kong) is the outermost user. In FIG. 17, all the other users will also connect to that connection. If any user drops off, for example Hong Kong, then user 5 (Hawaii) becomes the outermost point. At this point, the ILS server seamlessly drops Hong Kong (without crashing the conference) and connects Hawaii as the outermost point. The Hong Kong zone (video) gets frozen, this process is known as pruning. The 5 remaining users continue video conferencing with one another. The conference will continue until the very last user drops off. When the very last user drops off, the connection shuts down. FIG. 18 illustrates an intranet connection for a net meeting in certain embodiments of the invention. For purposes of simplicity, only 2 client computers are shown as participants of the net meeting. However, at least 128 participants can be included. With reference to FIG. 18, the following operations are:

• • Operation 1: Online list sent to each client (the login server send out to every gateway, i.e., to each client informing of who is online.)
  • Operation 2: Client #1 starts conference by connecting ILS server to request start of conference.
  • Operation 3: The ILS creates a multicast stream containing specific information about the conference to client #1.
  • Operation 4: Client #1 invites client #2 to join the net meeting (video conference) and conference name is sent to client #2.
  • Operation 5: If client #2 agrees to join then client #2 will inform the ILS of its desire to join. Client #2 requests the multicast stream containing specific information about the conference.
  • Operation 6: The multicast stream containing specific information about the conference is sent to client #2.
  • Operation 7: The conference is connected.

According to certain embodiments of the invention, the rate of sending raw video/audio data using multicast needs to match the biggest bandwidth among the participants for a T1 capacity connection. Typically, the capacity of each participant for receiving data is known.

In the case of a one-to-many unilateral net meeting, multicast GL (Global listener) is used in a double loop. See FIG. 19. For example, in FIG. 19, the source client sends combined raw video/audio data to destination client D1, the D1 sends the same data to D2. D2 sends the data back to D1. This is the double loop, which gets rid of packet loss. Thus, the double loop applies for D1 through D5. Note that D1 through D5 are receiving the same data from the source because the data is unilaterally broadcast from the source client. Each destination client checks with the adjacent client. FIG. 20 and FIG. 21 illustrate a system for a one-to-many bilateral net meeting. According to certain embodiments of the invention, FIG. 22 illustrates the multicast characteristics of a one-to-many bilateral net meeting.

E-Mail:

According to certain embodiments of the invention, the method for sending combined raw video/audio data through the network as described herein can apply to e-mail systems as well. When video is sent through e-mail, the common problems are (with respect to SMTP)

• • A. Size of the files: The files are usually too big too be opened by an e-mail application. The average video is 15 megaB, and the application usually can't open more than 5 megaB.
  • B. Intensity of the network: How many hops (routers) to get from source to destination.
  • C. Traffic on the network: How many users on the system.
  • D. Time: The time it takes for recipients to receive their email.

In FIG. 23, e-mail containing raw audio/video content from client #1 is converted using multicast GL and sent through SMTP to client #2. Then, the data is converted back to a regular email message when the data gets to client #2.

For example, in FIG. 24, client #1 sends 40 second commercial video to client #2 using SMTP. There may be about 10 to 15 routers between client #1 and client #2 for example. The raw video/audio data of about 5 megaB is stretched as a file into a 2 Kb stream. Such a process is herein referred to as a RICH Media E-Mail Response (RMER). In an RMER process, the multimedia data stream goes through an expedited traversal of the routers between the client computers as long as the routers are multicast enabled. The first multicast enabled router that gets the multicast stream will look at the IP address of the destination client and will fire the stream to the destination IP address.

In certain embodiments of the invention, if a modem does not accept multicast transmission, then the multicast is sent in the guise of unicast transmission through the modem and onto the first multicast enabled router. In other words the multicast transmission masquerades as a unicast transmission.

FIG. 24 displays the initial P/See user interface. When the executable is selected for P/See Suite the illustrated application displays. Here the chat box is displayed but when the actual application opens one must select the chat button in order for it to come into view.

P/SEE Suite

An embodiment of the invention is herein referred to as P/SEE Suite and for convenience is described, but not limited to, six (6) participants in a net meeting using the P/SEE Suite application. The number of participants may vary but potentially thousands of participants can participate at one time. Moreover, another present implementation of P/SEE Suite uses eight (8) participants.

Using six (6) participants for convenience, the user interface (See FIG. 24. for user interface of P/See Suite) of P/SEE Suite has six windows for video conferencing, with each having the ability to support one unicast or multicast user at a time. Potentially, an individual selects a group he/she wants to video conference with. Accordingly, a message is then sent to each individual of the group (in this example five (5) individuals). Each individual must accept the “invitation” to become part of the video conference in order to be added to the group.

P/SEE Suite offers instant access to video conference with any willing participant in a state of the art video conference workstation. This application offers internet users the ability to live real-time video conference with at least five (5) other family members or friends in a many-to-many multicast environment. This means that P/SEE Suite allows for the sending and receiving of audio, video and text messages, in real time, to and from anyone in the world via a direct connect, local area network and the internet.

P/SEE Suite also offers the ability to do multi-client web browsing, implying that a group of participants can surf the web together. Located at the top of the browser there is a lock icon. This icon allows the initiator (the participant that selected the icon) to lock the web sites of the entire group of participants. This essentially allows a multi-client browsing method with the initiator controlling the viewed web pages of the other participants locked into the multi-client browsing.

The text chat option (See FIG. 24 to view the Text Chat section) was added in case someone that was added to the friends list does not have audio/video. Messages can be sent to one individual on the friends list or it can be sent to the group of online users, making this application a client/server based, multi-user chat session.

P/SEE Suite has three main sections: the Video Conferencing Form, the Control Panel, and the drop down Text Based Chat. See FIG. 24 to view the user interface of P/SEE Suite. Each section will be discussed in succession. See FIG. 24 for user interface containing the three (3) sections. The Video Conferencing Form contains six (6) blocks which displays the live video feed from the six (6) participants involved in the video conference. Below these windows are four buttons: Chat, Control, Surfer, All/None.

The Chat button allows the user to hide or show the text chat section so he/she can send instant messages to one or more of the list of online friends or hide the options if the user wishes not to use it at that time. The Control button allows the user to display the control panel out of the right-hand side of the application or hide it behind the video conferencing form. The Surfer button is a quick launch web browser for individual web browsing. In order for a multi-client web browsing to be initiated a group must be selected and a confirmation request would be sent to each user.

If both or one of the control panel and chat windows are hidden then when the All button is clicked, the Control Panel and the Text Chat become visible and the button that said All now says None. When both, the Control Panel and Chat boxes, are displayed then the None button is displayed and selection of that button will hide both windows.

The Control Panel is automatically displayed to the right of the main form (Video Conferencing form) and can be hidden as described above.

The Control Panel has two boxes. One box contains a list of friends that are currently online with the P/SEE Suite application and the other box gives a list of friends that are not currently on-line. The user can select up to five (5) friends from the online list box to video conference with. A request message is then sent to each selected friend. The selected on-line friend does not have the option to decline the request to video conference.

There are several buttons on the Control Panel that the user can select. They are as follows: ILS Info, Delete, Help, About, Profile, Services, Search and Conditions. These buttons will be described in succession.

The ILS (Internet Locator Server) Info button allows the user to choose the ILS he/she wishes to use. It also gives the user the ability to use one that is in the list by highlighting it and selecting the button that says Use Selected. The user can create a new ILS by selecting new or delete one already in the list by highlighting one and then select delete from list. The Cancel buttons closes the window and disregards the changes. See FIG. 25 for window that displays when this button is selected.

FIG. 25 displays consequences of the ILS button. The ILS (Internet Server Locator) button displays the illustrated window. This allows the user to use the selected ILS, create a new one, delete one from the list, and cancel the option.

The Delete button allows the user to delete a friend from the friend list. The friend is selected in the list and when the delete button is pressed the user is removed from the friend list. If one tries to delete a friend when one has yet to add any one will receive a message stating so. The Help button brings up a window containing a list of topics in which the user can select any topic and read up on how to accomplish what they want using the application.

The About button uses one scrolling window that covers the Video Conferencing Form and displays the details of who created the application, the requirements for the program to run, and the company that created the application.

When selecting the Profile button, the user is presented with a window that shows all of the information that was entered when it was first entered. This window also allows one to change any information and also hide information from other users. Whenever a change has been to this windows and the apply button has been selected then the changes will take affect and be reflected in the application. See FIG. 26 for window that displays when this button is selected.

FIG. 26 displays consequences of the profile button. The Profile button displays the illustrated window. It details the user's information and gives the user the ability to change/update the information. Here the user also has the option to hide personal details from other users. Any changes to the page will be saved.

When the user selects the services button a window displays of the service and links. This windows has eight possible choices for the user that are essentially quick launches to that default browser (depends on what button is selected) displaying the appropriate web page. See FIG. 27 for the window that displays when this button is selected.

FIG. 27 displays consequences of the services button. When the Services button is selected the illustrated window displays. It allows the user to select one of the quick launch buttons and thereby display the home page of the selected web site in the browser.

When the Search button is selected another interface appears containing a search option to find a friend/user. The window has three text boxes that allow the user to search for someone using their first name, last name or their nick name. The results display in a box below and by clicking on the person's name one is able to add them to one's friend list. See FIG. 28 for window that displays when this button is selected.

FIG. 28 displays consequences of the search button. When the search button is selected the illustrated window is displayed. Here the user has the ability to search for a friend via first name, last name, and/or nickname. When the search is complete, clicking on the friend's name adds them to the list.

The Conditions button allows the user to view the current settings of the servers and friend's user list. When the window comes into view there are three tabs across the top. The Startup Tab allows the user to change password, auto login and set his/her current status (available/unavailable). There is also a box that contains the system information. See FIG. 29 for window that displays when this button is selected.

FIG. 29: The figure displays consequences of the conditions button. When the button is selected the illustrated window appears with the startup tab already selected. Here the user is able to select an auto login (No password required), change their current status (Available/unavailable), and to view system information.

The next tab is the friends tab. This shows a list of friends that a user has selected and added to the user's friend's list. If an individual's name is highlighted, then the three checkboxes at the top may become checked if it applies to that specific user. A user can be either able to send video, audio or chat or any combination thereof. See FIG. 30 for window that displays when this button is selected.

FIG. 30: The figure displays consequences of the conditions button with the friends tab selected. When the conditions button is selected and the friends tab is selected the illustrated form displays. This allows the user to view what conditions/restrictions, if any, their friends have. Conditions/Restrictions may include: able to (send and/or receive) video, audio, or chat.

The final tab on this screen is the Blocked tab. This tab contains a list of users that have been added as a friend but the user has decided to block them. If the user wishes to unblock a user, then the friend's name is highlighted and the removed button is selected. See FIG. 31 for window that displays when this button is selected.

FIG. 31: The figure displays consequences of the conditions button with the block tab selected. The conditions buttons displays the interface with the block tab selected. Here the user is able to unblock a previous user that was selected as a friend. Also, here a new user can be created or change users.

On each of these tabs there is an option to add a new user or change user. There is also an apply button to save any changes that have been made to any of the screens.

The final section is the Chat Section of the application. As described before the Chat section can be hidden or displayed by either selecting the Chat button or the All/None button on the Video Conferencing Form. This form is available in case someone in the friends list does not have the ability to interact using audio/video. See FIG. 24 for window that displays when the user wishes to have the chat box in view.

On this form there are three main text boxes and three buttons. The text box with the drop down option allows the user to select a friend, which he/she wants to send a message, that is on-line or all the friends that are on-line. The white text box is where the user types what he/she wants to say. In order to send the message, the send button must be selected. When the message is sent it displays the information in the grey text box to view the current conversation. If the user wants the information cleared then he/she selects the clear button and everything is erased from the screen. If the user desires to save the chat then simply selecting the save button does so. If a friend is not selected in the drop down menu then no message can be sent.

According to certain embodiments of the invention, several servers must be utilized in order for the application to work.

The Login server connects to clients via TCP Winsock connections, all the information sent is encrypted. The login server has several characteristics: The transaction is processed and the information is send to the login queue in folder. The login server checks the login out folder for a response, which is processed and sent back to the user. The TCP connection is set back to a listen state. The Login Queue also has several characteristics: The login queue checks the in folder for any new additional registrations and logins. If it is a registration, then the information is added to the login database. If the user is already registered, the login queue verifies login, adds IP to the database and send the transaction to the profile in folder. If a logoff is requested, then the client's IP is deleted from the database and sends the transaction to the profile in folder. Like the Login server, the Profile server connects to the clients via TCP Winsock connections and the information is encrypted. This server also has its own characteristics: Profile information is processed and the transaction is sent to the profile queue in folder. Profile server checks the profile out folder for response; this is processed and sent back to the client. Then the TCP connection is set back to a listen state. The Profile queue has the following characteristics: The queue checks the profile in folder for transactions (the transactions can be for a friend list, add a friend, and delete a friend) The response transaction is sent to the out folder with the information about the processed transaction.

When someone wants to register, the Registration server connects to the client via TCP Winsock connection and all information is encrypted. The client gets connected to the server via two (2) connections. The first connection carries registration information from the client to the Registration server while the other connection carries photo information from client to Registration server. Connection two (2) is only made when a photo is supplied.

The server then verifies if there is a duplicate entry and if there is a message is sent back to the user. If it is not duplicate information, then the server creates a unique serial number or identifier which is then sent back to the client which will be used as a unique password for logging onto the system. Then a transaction is sent to the login and profile queues with new registration information.

When doing searches or adding a friend to the friend list, a query is sent to the registration server via a TCP Winsock connection. The registration database is queried and the results are sent back to the client.

P/See suite is an excellent video conferencing tool. It allows a user of the application to video conference with five (5) friends on their friends list, text chat with one or all of the people that are on-line with P/See Suite, and revolutionize the idea of browsing the net with a friend through its ability to lock friends into a web browsing session. All of this is achieved through a multicast environment.

P/See Podium

P/See podium is a video conferencing tool that allows real time audio/video that is multicast from one-to-many and also receiving audio from many upon request. P/See podium is aimed at long distance education over the net.

In order to accomplish this, participants would be given a time and date on when the conference lecture would begin. The students/participants would then log onto the TCP/IP server and their IP information would be forwarded to the podium host. The lecture is received by the students that have IP addresses forwarded to the server. The lecture is broadcast in real time and the participants are able to reply with feedback or questions.

Frame rates of 15-32 fps according to P/See podium—based on a video window of one quarter (¼) screen on a 600*800 screen resolution, video is h-323 and h-324 compliant and can be received by non-podium viewers if the viewers is multicast enabled, audio is compliant with G-711 and can be extracted by the non-podium viewer this may be achieved using a fifty-six (56) K modem, ISDN, xDSL, Cable and satellite up to full motion video—the frame rates mentioned are all approximates due to the nature of the internet. Reception rates can be affected by the internet time of day, local net traffic, number of clients, quality of phone line, for example. The transmission should stay steady. Cable connections have a disadvantage of bandwidth sharing in their local area. With a modem dial up connections, a 56K modem may connect at a lower speed due to line conditions (if there is a lot of static on the lines) or if the dial-up ISP does not allow high-speed connections. In most areas the fastest a 56K modem can connect is 53K.

Due to the size of digital data, email is limited as to what can be emailed across the internet because of available bandwidth. As a result of this limitation, the sending of video or real time visual data used for the purposes of multiple conferences calling or advertising is prohibitive. Without the need for data compression technology, RMER (Rich Media Email Response) overcomes these limitations.

The flow of video data can be transmitted at a size of approximately 2 Kb using RMER over the internet. This is not a new form of compression, but by reconstituting the present information into a format that is more efficiently sized for transmission.

With this, individuals may send video data, with the use of the internet and wireless network, directly to new generation cell phones for face-to-face conversations. Businesses may direct email their advertisements to users with a particular interest. Therefore, RMER allows the movement of visual information that promotes endless possibilities for the communications and advertising industries. This can be accomplished through every level of receiving mediums, whether it is wireless phones, a personal computer, or some device yet to be developed.

RMER allows the possibility of multi conference calling, which now can only be accomplished via wider area network (WAN) within a controlled environment. This is a benefit for all business that wants to reach a wider array of possible clients.

Altorete (Advanced Core of P/See Suite)

Altorete is the advanced flow of data-grams through a multicast system. The stream of data continuously flows/travels along the data pipe (satellite, fiber optic or twisted pair) in an endless circle once a stream has been created by the originating server. Connector points within the loop, the modem allow access to the data and to retrieve data for use on personal computers. The inner circle of the stream contains the core data where the out side contains the reference headers and index files. Error correction loops take place as the stream passes over a point in the loop. These error correction loops assure that the data has the correct datagram checksum. Since there is a need for continuous feed of data into the multicast cast stream, flow feeder servers are used.

Flow Feeder servers act similarly to Dynamic Name Servers (DNS). Data continuously travels along the pipe moving at speeds that are relative to the network speeds. Where fiber optic networks are involved, the data-grams can be pushed through the network at speeds that reflect high efficiency transmission and are only affected by termination points and modems. When it reaches the modem, the data is extracted from the stream and sent to the requesting computer along the stream. The data is then stored on the user's (or client) computer until it receives an action to be read. At this point it gets deleted leaving the Time to Live (TTL) at zero and the stream continues. Potentially, when data is accessed solely in a streaming manner, the data may effectively be stored within its transmission through the network, thereby eliminating the need for local storage (such as a hard drive) in a computer.

Video conferencing through multicast provides the client or end user with quality picture and sound. There is no time loss, delay or excessive use of bandwidth resulting in a more efficient and real time transfer of video. The transfer of raw audio/video data rather than the use of compression and decompression enable efficiency of transport over any network. The use of multicasting requires less system resources for a one-to-many relationship than unicast technology does. Video conferencing is accomplished by the sound card and video card dealing with the sound data and video data respectively; there is no need for special hardware.

It is expected that applications can be based on several components of the P/See Core. For example, some of these applications may relate to transmission of audio, video, web and/or data. Audio applications may encompass, but not be limited to, audio presentation, radio over the internet, and telephony. Video applications may encompass, but not be limited to, video conferencing systems, distance learning and video phones. Web applications may include, but not be limited to, technical support, text based chat, and live updates to sporting events (i.e. Nascar races). Data applications may consist of, but not be limited to, data streams for example. The working model of P/See Suite is one embodiment of a working core for video conferencing.

Claims

1. A method for multicasting data through a network in real-time, the method comprising the computer-implemented acts of:

multicasting said data through said network as a data stream having a specific rate using a bi-directional delivery protocol (BDP);

determining an available bandwidth of said network to connect to a first client; and

2. The method of claim 1, further comprising:

multicasting the data to a second client connected to said network.

3. The method of claim 2, further comprising:

using a multicast global listener (multicast GL) between the first and second clients to correct for packet loss;

wherein, the first client sends the data to the second client and the second client sends the data to the first client.

4. The method of claim 3, wherein, the multicast GL is implemented in, one or more of, TAPI 3 and IGMPv3.

5. The method of claim 2, further comprising

multicasting the data through the network from the second client; and

receiving the data at the first client.

6. The method of claim 2, further comprising:

performing a multi-client web browsing session;

wherein, a browser at the first client is locked to a browser at the second client and displays the same website as that displayed at the second client.

7. The method of claim 1, wherein, said determining of the available bandwidth is based on a source client connected to said network and configured to send the rate of data stream.

8. The method of claim 7, wherein said determining of the available bandwidth is performed, by the source client, through a process of increasing and decreasing the rate of the rate of data stream sent for delivery to the first client.

9. The method of claim 8, wherein the first client and a second client join a group configured to receive the rate of data stream, and wherein the rate of the rate of data stream corresponds to a receiving rate of the first client and the second client.

10. The method of claim 1, wherein, the data includes audio data.

11. The method of claim 10, wherein, the audio data is uncompressed.

12. The method of claim 1, wherein, to determine the available bandwidth, the first client receives a second rate of data stream.

13. The method of claim 12, wherein, the first client ceases to receive the second rate of data stream upon determination of insufficient available bandwidth.

14. The method of claim 1, wherein an increase in the available network bandwidth is achieved by filtering specific information from the rate of data stream multicast through the network.

15. The method of claim 14, wherein the specific information is selected from the group consisting of a frame type, layer, frequency, and codec.

16. The method of claim 1, wherein, the data comprises live updates to a sporting event.

17. The method of claim 1, further comprising:

receiving a checksum result at the first client; and

determining a list of data packets that are missing from the at least a portion of the data received at the first client using the checksum result.

18. The method of claim 1, wherein, the network is a local area network or wide area network.

19. The method of claim 1, wherein, the network is the internet or an intranet.

20. The method of claim 1, wherein, the network is a wireless network.

21. The method of claim 1, wherein, the first client is a wireless phone.

22. The method of claim 1, wherein the dynamic adjustment of the rate of data stream is based on modifying a tcp window size and modifying a compression rate of the data of the rate of data stream.

23. The method of claim 1, wherein the rate of data stream is directed through one or more routers located on the network, wherein the one or more routers are not actively enabled for multicasting.