Patent Grant
9270474
The present invention relates to a method for ad hoc endpoint initiation of a multipart conference.
There are a number of technological systems available for arranging meeting between participants located in different areas. These systems may include audio visual multipoint conferences or videoconferencing, web conferencing and audio conferencing.
The most realistic substitute of real meetings is high-end videoconferencing systems. Conventional videoconferencing systems comprise a number of end-points communicating real-time video, audio and/or data streams over and between various networks such as WAN, LAN and circuit switched networks. The end-points include one or more monitor(s), camera(s), microphone(s) and/or data capture device(s) and a codec. Said codec encodes and decodes outgoing and incoming streams, respectively.
Traditional Audio Visual Multipoint conferences have a central Multipoint Control Unit (MCU) with three or more endpoints connected. These MCU's perform switching functions to allow the audiovisual terminals to intercommunicate in a conference. The central function of an MCU is to link multiple video teleconferencing sites (EP-endpoints) together by receiving frames of digital signals from audiovisual terminals (EP), processing the received signals, and retransmitting the processed signals to appropriate audiovisual terminals (EP) as frames of digital signals. The digital signals may include audio, video, data and control information. Video signals from two or more audiovisual terminals (EP) can be spatially mixed to form a composite video signal for viewing by teleconference participants. One example of mixing and transcoding is converting four QCIF video streams into one CIF video stream.
When the different video streams have been mixed together into one single video stream the composed video stream is transmitted to the different parties of the video conference, where each transmitted video stream preferably follows a set scheme indicating who will receive what video stream. In general, the different users prefer to receive different video streams. This result in that the multi point control unit needs to perform a large amount, of video mixing, which in turn results in a large demand for processing power.
In order to form such a composed video stream, the conventional solution is to decode the separate incoming video streams from the respective parties, mix the video streams in accordance with the set schemes for the different users and then encode the composite images and transmit it to the respective users from the MCU. Thus, MCU's are provided with a set of encoders and decoders. One decoder is required for each incoming coded bit stream, whereas encoders usually can be shared among several outgoing bit streams. Hence, the required encoder resources in an MCU are usually less than the required decoder resources.
This requires a certain amount of processing power and inputs/outputs assigned to each conference, making the MCU unavailable for new conferences when ongoing conferences already occupies the resources in the MCU.
To provide multipart conferences without MCU, some video endpoints do have integrated MCU features. These are typically meeting room applications, and more expensive conferencing systems. There are also a set of conferencing bridges that enables video multi point conferencing. Both these solutions (Meeting Rooms, Conferencing Bridges) do require conference setup actions, prior to every meeting. This is typically to book a room, schedule the meeting in an administration interface, distribute information, notifying the conference number etc), which typically is done through a user interface of a Management System. This may make the process of hosting a multipoint conferencing event a time consuming task, and the threshold for using this technology to high.
In an environment where personal endpoints are widespread, the usual configuration is small video systems, incapable of hosting a multipoint conference. This does not mean that the need for multipoint visual conferencing is absent. According to prior art, is it not possible to utilize the personal single call video endpoints for multipoint video conferencing, without doing extra management and time consuming preparations.
It is an object of the present invention to provide a method that eliminates the drawbacks described above. The features defined in the independent claim enclosed characterize this method.
In particular, the present invention provides a method for establishing a conference between two or more multimedia terminals through a Multipoint Control Unit (MCU), comprising at least the steps of pre-assigning and storing in the MCU one or more conference numbers respectively associated with a user or a multimedia terminal, when a primary multimedia terminal initiates a first call by dialing a first conference number among said one or more conference numbers, then routing said call to the MCU, when the MCU receives said first call, then allocating primary MCU resources and establishing the multipart conference including said primary multimedia terminal, and when a secondary multimedia terminal initiates a succeeding call by dialing said first conference number, then routing said succeeding call to the MCU, allocating secondary resources and including said secondary multimedia terminal in the multipart conference.
In order to make the invention more readily understandable, the discussion that follows will refer to the accompanying drawings.
In the following, the present invention is described by means of one example embodiment. However, people skilled in the art will also realize other implementations and variations within the scope of the invention.
The main idea of the present invention is to utilize central video processing resources, in for example an MCU, to offer multipoint capabilities available for all users, without demanding setup schemes, booking and education of users. According to one embodiment of the invention, a number of users can be registered in an MCU, every registered user is then assigned a unique and personal static number in the MCU. This number is assigned to a person, and not a video system, making a multipoint call available at all times, from any kind of system. All personal numbers are stored in the MCU after being registered. The user may be allocated number for multiple protocols, so the personal multipoint call may serve as a protocol gateway as well (SIP, ISDN, H323). The personal conference number allows multiple user to have an own and unique conference number. When a user dial this number, there will automatically be allocated resources for a conference, into which other users will be connected by dialing the same number. The personal conference number is static, and can be compared to any other personal number such as cellular phone number, pager number etc. This makes this number easy distributable. The number of personal Conference number assigned can be much larger than the required capacity if all numbers personal conference numbers where in use simultaneously. This is due to the conventional traffic theory of the relationship between the number of potential users and the expected value of the number of simultaneous users.
However, the personal conference number is not to be confused with a phone number, as it is not used for reaching a certain terminal. The solution will utilize free capacity on the MCU in an ad-hoc fashion, and will allocate and de allocate resources dynamically.
When a user calls his/her personal conference number, the call will be routed to the MCU where the number is stored. This is accomplished by e.g. giving all personal conference numbers belonging to a certain MCU a common prefix number. When the call is received at the MCU, the MCU recognizes the number as a personal conference number, and is thereby pre-instructed to automatically set up a multipart call. In the first phase, this means that an encoder resource is set aside for the conference, but the personal conference number could also be associated with pre-settings e.g. defining that a certain amount of resources (e.g. encoders/decoders) should be booked and bit rates should be set as the call from the first participant is received at the MCU.
When the second call initiated by the same personal conference number is received at the MCU, a decoder resource for both the participants is allocated (if not already allocated) and a call between the two participants are established through the MCU in a conventional way. The same is the case for the next incoming calls using the number, but in this case also to establish required functionalities for a conference including more than two participants, such as Continuous Presence and Voice Switching.
The resources are consecutively released as the participants leave the conference, and when the last participant is leaving, the conference is shut down, and the personal conference number is ready for new conferences.
The present invention is further exemplified in the following. As already indicated, the idea is to utilize the video conferencing capacity from a central conferencing bridge, developed for connecting multiple video endpoints into video conferences. The implementation will also utilize a number range available on the video conferencing bridge. In addition to the embodiment of the present invention described above, an alternative implementation of the present invention may also support a single number dial in.
The result will be the same. The central conferencing bridge will allocate resource and start a conference run time. When the last endpoint disconnect form the video conferences, the video bridge will automatically release the resources, and hence make it available for a new conference.
This allocation is implemented to be fully automated, and the conferencing users do not need to do any kind of conference setup and management.
Now describing an example of a single number dial in, one common access point on the MCU must be configured. When a participant dials into this number, he is allowed to both create a personal pin code, and have a conference created, or to provide a given pin code to access an already created conference. If the conference is not created yet, the user is placed in a “waiting room” which is a hold state providing graphical information to the user allowing for DTMF inputs, until the correct conference, with the correct pin code is created. From the “waiting room”, the user may disconnect, try to re-dial the pin code or create an own conference at any time. The management for achieving this must be done by the video bridge administrator, setting up a number available for single number dial in, and by the conference host, distributing the conference pin codes.
As an example, the administrator makes the number MEET-8000 as the configured single number dial in number.
User A would like to host a conference with two other participants, User B and User C.
User A sends an e-mail to User B and User C, saying: “Please dial into my conference. It will be hosted 10.00 am, the number is MEET-8000, and the pin code is 1976”.
Then, User C dials ‘MEET-8000’ at 09.55 am. He will be asked weather to create- or access a conference. User C chooses to access an already created conference, and provides the given pin code. Since User A has not yet started the conference, User C is told to wait until the conference is created. User C is placed in a waiting room.
User A dials ‘MEET-8000’, and chose to create a conference, at 09.58 am. User A is asked to provide a pin code for the conference, and User A enters ‘1976’. A conference is started dynamically. User C will now also dynamically be collected from the waiting room into the conference.
When User B dials ‘MEET-8000’ and provides the correct conference pin, all three are present in the conference, ready for multipoint conferencing.
A similar example when utilizing a personal conference number could be as follows.
User A has been assigned the number ‘USERA.meeting’. He may now at any time dial this number when he needs a multipart video conference. He can also distribute this number at any time, to anyone, since this is a static and personal number. When USER A will start a meeting with USER B and USER C, he distributes his personal number to them, and dials into ‘USERA.meeting’. No need for booking, setup and administration.
The idea of the concept is to use the potential number range on a conferencing bridge, to enable endpoints to automatically setup and connect to a multipart conferencing. This is facilitated by using simple interfaces as one system wide number, or a personal conference number.
The main advantage of the present invention is the increased availability of multipart conferencing, without the need of management, booking and administration. Now, simple endpoints may easily spawn a multipoint conference on the conferencing bridge, by dialing into a known number.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20060861 | Feb 2006 | NO | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 6272214 | Jonsson | Aug 2001 | B1 |
| 8296361 | Shaffer et al. | Oct 2012 | B1 |
| 20020159394 | Decker et al. | Oct 2002 | A1 |
| 20040114031 | Roundy et al. | Jun 2004 | A1 |
| 20040137887 | Niemi | Jul 2004 | A1 |
| 20050277409 | Etelapera | Dec 2005 | A1 |
| 20060171337 | Shaffer et al. | Aug 2006 | A1 |
| 20060233120 | Eshel et al. | Oct 2006 | A1 |
| 20070126858 | Bain et al. | Jun 2007 | A1 |
| 20080013706 | Kelley et al. | Jan 2008 | A1 |
| 20080069012 | Decker et al. | Mar 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| 1 517 506 | Mar 2005 | EP |
| WO 9857485 | Dec 1998 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20070223674 A1 | Sep 2007 | US |
