Patent Application
20100332598
The present invention relates generally to conferencing and, more specifically, to a system and method for routing videoconferencing signals based on network configurations.
Videoconferencing may be used to allow two or more participants at remote locations to communicate using both video and audio. Each participant location may include a videoconferencing system for video/audio communication with other participants. Each videoconferencing system may include a camera and microphone to collect video and audio from a first or local participant to send to another (remote) participant. Each videoconferencing system may also include a display and speaker to reproduce video and audio received from one or more remote participants. Each videoconferencing system may also be coupled to (or comprise) a general purpose computer system to allow additional functionality into the videoconference. For example, additional functionality may include data conferencing (including displaying and/or modifying a document for both participants during the conference).
Currently, some networks include servers which allow an endpoint to communicate to another endpoint outside of the network. In such networks, all network traffic of a videoconference may be routed through the server system. However, such routing may be inefficient. Correspondingly, improvements in videoconferencing are desired.
Various embodiments are presented of a method for routing videoconferencing signals based on network configurations.
In a first embodiment, the method may be performed by a server. More specifically, a server system may detect a videoconference (e.g., a H.460 protocol videoconference) between a first endpoint and a second endpoint. For example, the server system may receive a request to establish the videoconference between the first endpoint and the second endpoint (e.g., from the first endpoint). The first endpoint and the second endpoint may be on the same network and the server system may be configured to provide videoconference communication external to the network for the first endpoint and the second endpoint. Thus, in this embodiment, the server may be used for (e.g., dedicated to) providing videoconference communication to external endpoints, but may not be appropriate since the first and second endpoints are within the same network.
Accordingly, the server system may determine that the first endpoint and the second endpoint are within the same network and may provide an indication to the first endpoint to provide videoconferencing signals of the videoconference to the second endpoint without utilizing the server system. Thus, after providing the indication, the first endpoint may provide the videoconferencing signals of the videoconference to the second endpoint (e.g., directly) without using the server system.
The determination that the first endpoint and the second endpoint are within the same network may be performed in an automatic fashion by the server system based on an IP address of the first endpoint and an IP address of the second endpoint. In one embodiment, a configuration file(s) (e.g., stored by the server system) may define a range of IP addresses that are common to the same network. Accordingly, the IP address of the first endpoint and the IP address of the second endpoint fall within the range of IP addresses when they are on the same network. Accordingly, the server system may determine that the two endpoints are on the same network by comparing the IP addresses of the two endpoints with the IP addresses stored in the configuration file. In order to perform this determination, the server system may receive the range of IP addresses in an automatic fashion or based on user input, as desired.
In a second embodiment, the method may be performed by an endpoint. For example, a first endpoint may receive a request to establish the videoconference (e.g., which may use an H.460 protocol). The request may include an address (e.g., an IP address) of a second endpoint that is to participate in the videoconference.
The method (e.g., the first endpoint) may determine whether the second endpoint is within the same network as the first endpoint based on the address of the second endpoint. For example, the method may compare the address of the second endpoint with a known list of addresses that are on the same network. More specifically, a configuration file may be used which defines a range of addresses that are common to the same network and the determination may be performed by determining whether address of the second endpoint falls within the range of IP addresses. This range of IP addresses may be determine automatically (e.g., by the first endpoint) or may be defined manually, e.g., by an administrator.
The videoconference may then be established (e.g., by the first endpoint) with the second endpoint based on this determination. More particularly, the conference may be established using an external communication server if the second endpoint is not within the same network as the first endpoint or the conference may be established without using (bypassing) the external communication server if the second endpoint is within the same network as the first endpoint.
A better understanding of the present invention may be obtained when the following detailed description is considered in conjunction with the following drawings, in which:
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. Note that the headings are for organizational purposes only and are not meant to be used to limit or interpret the description or claims. Furthermore, note that the word “may” is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not a mandatory sense (i.e., must). The term “include”, and derivations thereof, mean “including, but not limited to”. The term “coupled” means “directly or indirectly connected”.
U.S. patent application titled “Video Conferencing System Transcoder”, Ser. No. 11/252,238, which was filed Oct. 17, 2005, whose inventors are Michael L. Kenoyer and Michael V. Jenkins, is hereby incorporated by reference in its entirety as though fully and completely set forth herein.
In some embodiments, the participant location may include camera 104 (e.g., an HD camera) for acquiring images (e.g., of participant 114) of the participant location. Other cameras are also contemplated. The participant location may also include display 101 (e.g., an HDTV display). Images acquired by the camera 104 may be displayed locally on the display 101 and/or may be encoded and transmitted to other participant locations in the videoconference.
The participant location may also include a sound system 161. The sound system 161 may include multiple speakers including left speakers 171, center speaker 173, and right speakers 175. Other numbers of speakers and other speaker configurations may also be used. The videoconferencing system 103 may also use one or more speakerphones 105/107 which may be daisy chained together.
In some embodiments, the videoconferencing system components (e.g., the camera 104, display 101, sound system 161, and speakerphones 105/107) may be coupled to a system codec 109. The system codec 109 may be placed on a desk or on a floor. Other placements are also contemplated. The system codec 109 may receive audio and/or video data from a network, such as a LAN (local area network) or the Internet. The system codec 109 may send the audio to the speakerphone 105/107 and/or sound system 161 and the video to the display 101. The received video may be HD video that is displayed on the HD display. The system codec 109 may also receive video data from the camera 104 and audio data from the speakerphones 105/107 and transmit the video and/or audio data over the network to another conferencing system. The conferencing system may be controlled by a participant or user through the user input components (e.g., buttons) on the speakerphones 105/107 and/or remote control 150. Other system interfaces may also be used.
In various embodiments, a codec may implement a real time transmission protocol. In some embodiments, a codec (which may be short for “compressor/decompressor”) may comprise any system and/or method for encoding and/or decoding (e.g., compressing and decompressing) data (e.g., audio and/or video data). For example, communication applications may use codecs for encoding video and audio for transmission across networks, including compression and packetization. Codecs may also be used to convert an analog signal to a digital signal for transmitting over various digital networks (e.g., network, PSTN, the Internet, etc.) and to convert a received digital signal to an analog signal. In various embodiments, codecs may be implemented in software, hardware, or a combination of both. Some codecs for computer video and/or audio may include MPEG, Indeo™, and Cinepak™, among others.
In some embodiments, the videoconferencing system 103 may be designed to operate with normal display or high definition (HD) display capabilities. The videoconferencing system 103 may operate with a network infrastructures that support T1 capabilities or less, e.g., 1.5 mega-bits per second or less in one embodiment, and 2 mega-bits per second in other embodiments.
Note that the videoconferencing system(s) described herein may be dedicated videoconferencing systems (i.e., whose purpose is to provide videoconferencing) or general purpose computers (e.g., IBM-compatible PC, Mac, etc.) executing videoconferencing software (e.g., a general purpose computer for using user applications, one of which performs videoconferencing). A dedicated videoconferencing system may be designed specifically for videoconferencing, and is not used as a general purpose computing platform; for example, the dedicated videoconferencing system may execute an operating system which may be typically streamlined (or “locked down”) to run one or more applications to provide videoconferencing, e.g., for a conference room of a company. In other embodiments, the videoconferencing system may be a general use computer (e.g., a typical computer system which may be used by the general public or a high end computer system used by corporations) which can execute a plurality of third party applications, one of which provides videoconferencing capabilities. Videoconferencing systems may be complex (such as the videoconferencing system shown in
The videoconferencing system 103 may execute various videoconferencing application software that presents a graphical user interface (GUI) on the display 101. The GUI may be used to present an address book, contact list, list of previous callees (call list) and/or other information indicating other videoconferencing systems that the user may desire to call to conduct a videoconference.
Note that the videoconferencing system shown in
The server system may solve the NAT/Firewall traversal problem for local networks (e.g., enterprise networks). In some embodiments, the server system may be deployed on the public side of the enterprise network (e.g., the wide area network's side of the local area network 275). The network 275 endpoints may be registered to the server system. The signaling and media between the private network endpoints (e.g., conferencing units 220C and 220D) and a public network endpoint (e.g., conferencing unit 220A or 220B) may be routed through the server system. The server system may solve the NAT/Firewall issue using H.323/H.460 and SIP based protocols.
In 302, network locality for videoconferencing units (referred to herein as “endpoints”) may be determined. As used herein, the “network locality” of a device refers to the network(s) to which the device belongs. Thus, the method may determine the network of each of a plurality of endpoints. For example, a server system, such as the transit server described above, may store the addresses (e.g., IP addresses) for the endpoints in a configuration file. The addresses may be used to determine network locality (e.g., common networks) among the endpoints. For example, two endpoints may be on a same or common network if they each have an address within a same range of addresses. In some embodiments, the server system may be local to a network for which it provides external communication of videoconferences. Thus, in one embodiment, each endpoint on the network may register itself with the server system, thereby specifying its address as being local to the network with the server system.
In various embodiments, the addresses may be determined in an automatic fashion or may be determined based on input received from a user. Alternatively or additionally, the method may include specifying (e.g., by a user) a range of addresses as being local to a network (e.g., the local network of the server system). For example, an administrator may specify that all addresses in 192.168.x.x (or specify a range within 192.168.x.x) are local to the network. Accordingly, in one embodiment, the server system may use the start and end address in the range of addresses to build a map of the local network. However, in some embodiments, there may be more than one range of addresses that are local to the network. For example, a plurality of sub-private networks may form a larger private network (e.g., the local network described herein). Thus, a plurality of different ranges may be specified as being local to the network.
Alternatively, or additionally, the server system may automatically determine the range of addresses (or sets of ranges of addresses) that are local to the network, e.g., by discovering devices (and/or addresses of devices) coupled to the network. Upon discovery, a topology or configuration of the network may be determined for future routing of videoconference packets, as described in 306 below. In one embodiment, the addresses may be automatically determined based on standard configured private networks (e.g., RFC 1918).
In 304, a videoconference may be requested or otherwise detected between a first endpoint and a second endpoint. The detection may be performed by the server system described above, although other systems are envisioned. In some embodiments, the detection may be performed based on packets received from the first endpoint and/or the second endpoint by the server system. The packets may be for initializing the videoconference or they may be data packets of the videoconference (e.g., RTP packets). In one embodiment, the server system may receive signaling packets, e.g., H.225 signaling packets, from the first and/or the second endpoint, which may be usable in the determination in 306.
In 306, the method may determine that the first endpoint and the second endpoint are within the same network (e.g., the local network described above). For example, as indicated above, the server system may receive signaling packets, e.g., H.225 signaling packets, which may include an address of the originating endpoint and/or the participating endpoints (e.g., the first and/or second endpoint). Thus, the server system may determine the address (e.g., the IP address) of the first and/or the second endpoint by examining the signaling packets. This method of determination may be referred to as a source mechanism, although other embodiments are envisioned. For example, the server system may utilize a stun mechanism. With the stun mechanism, the server system may use ICE/STUN (session traversal utilities for NAT, IETF standard) in conjunction with the session initiation protocol (SIP) to determine the first and/or second endpoint address. Thus, in some embodiments, this mechanism may be used in conjunction with H.323 to determine the address of the first and/or second endpoint, as desired.
The server system may determine that the addresses (e.g., the IP addresses) are within the configuration file or range of IP addresses previously determined and stored in 302 above. Thus, an endpoint whose address falls within the range of the start and end address of the range(s) may be considered a private address or part of the local network. Accordingly, if the first endpoint and the second endpoint are both within the same local network (e.g., the same address range or space), then the server system may determine that the first endpoint and the second endpoint are within the same network. Thus, the determination may be performed automatically and may be based on the address of the first endpoint and the second endpoint.
However, it should be noted that the determination that the endpoints are in the same local network may be performed dynamically at the time that the videoconference is detected or requested in 304, rather than before. In other words, 302 may be performed before the detection or may be performed in a dynamic fashion upon each determination of a videoconference, as desired.
In 308, the first endpoint and the second endpoint may not utilize the server system to transmit videoconference data of the videoconference between each other. For example, the first endpoint and the second endpoint may communicate directly via the local network rather than using the external server system or sending data outside of the local network. In some embodiments, this may be performed in response to an indication provided by the server system that the two endpoints (the first and second endpoints) are on the same server and that they should communicate with each other without using the server system. Thus, the first endpoint and the second endpoint may transmit videoconference data (e.g., using a real-time transport protocol (RTP) for audio and visual data of the videoconference) in a more efficient manner based on the determination in 306.
Note that the above method may be applied to videoconferences which include more than two endpoints. For example, the method may apply to any number of endpoints.
In 402, a first endpoint may receive a request to initiate a videoconference with a second endpoint. According to various embodiments, the first endpoint may receive the request from a user (e.g., selecting the second endpoint and selecting a “call” button using software executing on the first endpoint) or from another device or system (e.g., an external computer system, such as a scheduling system, or from the second endpoint, which may be initiating the videoconference). The request of the initiation of the videoconference may include an address (e.g., an IP address) of the first and/or the second endpoint.
In 404, the first endpoint may determine whether the second endpoint is within a same network as the first endpoint. 404 may be performed similar to the methods described above in
In 406, the videoconference may be initiated and/or performed based on the determination in 404. More specifically, if the second endpoint is not within the same network, the endpoint (e.g., software executing on the endpoint) may use a server system, such as the server system described above). As already indicated, the server system may provide H.323 or H.460 services for calling a public endpoint. However, if the second endpoint is within the same network as the first endpoint, the first endpoint may not use the server system, but may instead communicate with the second endpoint within the network (e.g., in a direct fashion, without using a server system or routing traffic outside of the local network).
Similar to above, the method of
FIGS. 5-8—Exemplary Screen Shots According to the Method of
As shown in
In a first example of the system shown in
In a second example, endpoint A may initiate a multipoint videoconference by calling endpoint B and endpoint C. The videoconference data may be passed within the MPLS network and may not use the transit server, similar to the first example of
In a first example, endpoint A may establish a videoconference with endpoint B. Since both of these endpoints are within the same network, the transit server may not be used.
In a second example, endpoint A may establish a videoconference with endpoint D. Since these endpoints are not within the same network, the transit server may be used.
In a third example, endpoint A may establish a videoconference with endpoint B and endpoint D. In this case, communication between A and B may not use the transit server, but any communication with D may use the transit server.
In a first example, endpoint A may establish a videoconference with endpoint C and the transit server may not be used since they are both local to the MPLS network.
In a second example, endpoint A may establish a videoconference with endpoints B and C. In this case, the transit server may not be used since all three are local to the MPLS network. However, upon adding endpoint 1 to the videoconference, any data to/from 1 may use the transit client(s) and server, but any data between endpoints A-C may not use the transit server.
In a first example, endpoint A may establish a videoconference with endpoint B. Since both of these endpoints are within the same network, the transit client and server may not be used.
In a second example, endpoint A may establish a videoconference with endpoint D. Since these endpoints are not within the same network, the transit clients and server may be used.
In a third example, endpoint A may establish a videoconference with endpoint B and endpoint D. In this case, communication between A and B may not use the transit client and server, but any communication with D may use the transit clients and server.
The above described methods may have advantages over prior systems, such as those indicated in the Background section above. For example, current H.460 specifications may require RTP streams to be routed through an H.460 server. By performing the methods above, use cases where the RTP stream is sent to an externally placed H.460 server for calls between endpoints in the same private address space may be avoided. Thus, the RTP stream, using the methods described above, may not be sent external to the private network and then routed back in, and may instead take a direct path between the two (or more) endpoints. Thus, network resources may be used more efficiently in such cases by avoiding the use of a server system (e.g., the transit server) described above and by decreasing external network use and routing associated therewith.
Embodiments of a subset or all (and portions or all) of the above may be implemented by program instructions stored in a memory medium or carrier medium and executed by a processor. A memory medium may include any of various types of memory devices or storage devices. The term “memory medium” is intended to include an installation medium, e.g., a Compact Disc Read Only Memory (CD-ROM), floppy disks, or tape device; a computer system memory or random access memory such as Dynamic Random Access Memory (DRAM), Double Data Rate Random Access Memory (DDR RAM), Static Random Access Memory (SRAM), Extended Data Out Random Access Memory (EDO RAM), Rambus Random Access Memory (RAM), etc.; or a non-volatile memory such as a magnetic media, e.g., a hard drive, or optical storage. The memory medium may comprise other types of memory as well, or combinations thereof. In addition, the memory medium may be located in a first computer in which the programs are executed, or may be located in a second different computer that connects to the first computer over a network, such as the Internet. In the latter instance, the second computer may provide program instructions to the first computer for execution. The term “memory medium” may include two or more memory mediums that may reside in different locations, e.g., in different computers that are connected over a network.
In some embodiments, a computer system at a respective participant location may include a memory medium(s) on which one or more computer programs or software components according to one embodiment of the present invention may be stored. For example, the memory medium may store one or more programs that are executable to perform the methods described herein. The memory medium may also store operating system software, as well as other software for operation of the computer system.
Further modifications and alternative embodiments of various aspects of the invention may be apparent to those skilled in the art in view of this description. Accordingly, this description is to be construed as illustrative only and is for the purpose of teaching those skilled in the art the general manner of carrying out the invention. It is to be understood that the forms of the invention shown and described herein are to be taken as embodiments. Elements and materials may be substituted for those illustrated and described herein, parts and processes may be reversed, and certain features of the invention may be utilized independently, all as would be apparent to one skilled in the art after having the benefit of this description of the invention. Changes may be made in the elements described herein without departing from the spirit and scope of the invention as described in the following claims.
This application claims benefit of priority of U.S. provisional application Ser. No. 61/220,345 titled “Routing Videoconference Signals Based on Network Configurations” filed Jun. 25, 2009, whose inventors were Ashish Goyal and Prithvi Ranganath, which is hereby incorporated by reference in its entirety as though fully and completely set forth herein.
| Number | Date | Country | |
|---|---|---|---|
| 61220345 | Jun 2009 | US |
