Patent Application
20210176287
The present invention relates to the field of videoconferencing, and in particular to a technique for integrating conferencing systems of two different types.
Enterprises can schedule online conferences using Skype® For Business (formerly known as Lync®) services. (LYNC and SKYPE are registered trademarks of Microsoft Corp.) Some non-Skype videoconferencing systems can connect non-Skype videoconferences with Skype video conferences, but the connection has had limitations. Both Skype endpoints and non-Skype endpoints see content and video from endpoints of the other type as a cascaded videoconference in which the endpoints of the non-Skype videoconference appear in a single segment of a Skype screen layout and endpoints of the Skype videoconference appear in a single segment of a non-Skype screen layout, with a single stream passing between the Skype system and the non-Skype system. This presents a less than optimal user experience.
In addition, current approaches have used a separate server for handling content streams which use its own signaling, resulting in the Skype conference seeing the content as another caller in the Skype conference, which happens to use only content but no audio or video. Thus a single caller from a non-Skype endpoint ends up looking like two callers in the Skype conference.
A better approach to integrating Skype conferences and non-Skype conferences would be desirable.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an implementation of apparatus and methods consistent with the present invention and, together with the detailed description, serve to explain advantages and principles consistent with the invention. In the drawings,
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without these specific details. In other instances, structure and devices are shown in block diagram form in order to avoid obscuring the invention. References to numbers without subscripts or suffixes are understood to reference all instance of subscripts and suffixes corresponding to the referenced number. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the invention, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.
The terms “a,” “an,” and “the” are not intended to refer to a singular entity unless explicitly so defined, but include the general class of which a specific example may be used for illustration. The use of the terms “a” or “an” may therefore mean any number that is at least one, including “one,” “one or more,” “at least one,” and “one or more than one.”
The term “or” means any of the alternatives and any combination of the alternatives, including all of the alternatives, unless the alternatives are explicitly indicated as mutually exclusive.
The phrase “at least one of” when combined with a list of items, means a single item from the list or any combination of items in the list. The phrase does not require all of the listed items unless explicitly so defined.
As used herein, the term “a computer system” can refer to a single computer or a plurality of computers working together to perform the function described as being performed on or by a computer system.
As used herein, the term “processing element” can refer to a single hardware processing element or a plurality of hardware processing elements that together may be programmed to perform the indicated actions. The hardware processing elements may be implemented as virtual hardware processing elements of a virtual programmable device hosted on a physical hardware device. Instructions that when executed program the processing element to perform an action may program any or all of the processing elements to perform the indicated action. Where the processing element is one or more multi-core processors, instructions that when executed program the processing element to perform an action may program any or all of the multiple cores to perform the indicated action.
As used herein, the term “medium” can refer to a single physical medium or a plurality of media that together store the information described as being stored on the medium.
As used herein, the term “memory” can refer to a single memory device or a plurality of memory devices that together store the information described as being stored on the medium. The memory may be any type of storage device, including random access memory, read-only memory, optical and electromechanical disk drives, etc.
Although described herein as a technique for connecting between a Skype conference and non-Skype endpoints, the techniques described below are not so limited, and similar techniques can be used to allow endpoints associated with one type conferencing system to connect to a conference of another type of conferencing system with both media and content in the same conferencing session.
As disclosed herein, the user uses the Microsoft Skype software as the user is accustomed to use it, without any plugins. A user typically schedules an online meeting using the Microsoft Outlook® email software's built-in Skype meeting button. (OUTLOOK is a registered trademark of Microsoft Corporation.) Skype users can join the meeting by clicking the hyperlink they receive in the invitation and be connected to the Microsoft Skype multipoint control unit (MCU), sometimes referred to as an audio video MCU (AVMCU). All that is standard Microsoft flow. Participants with video or audio equipment that cannot dial in to the Skype MCU (referred to herein as a non-Skype endpoint) can dial the conference ID that was sent with the meeting invitation and join a conference on a non-Skype MCU. The non-Skype MCU and a call server enable dialing into the Skype MCU to join the Skype conference. Both Skype endpoints and non-Skype endpoints may see a continuous presence of endpoints that may include Skype endpoints and non-Skype endpoints, as determined by the Skype MCU. Thus, both integration between Skype and non-Skype conferencing systems is provided without requiring installation of a plugin in the non-Skype endpoints.
A non-Skype call server 150, such as a DMA® call server provided by Polycom, Inc. provides a dial rule using an identification such as “Dial by Skype conference ID.” (DMA is a registered trademark of Polycom, Inc.) In this example, endpoint 110C does not support the Skype protocol and is registered to the call server 150, using Session Initiation Protocol (SIP), H.323, or any other Media IP protocol. Details of one embodiment for allowing the non-Skype endpoints 110C to dial in to the conference managed by Skype MCU 120 can be found in U.S. Pat. Pub. No. 20160269687, “Integration of Scheduled Meetings with Audio-Video Solutions,” U.S. application Ser. No. 15/066,498, published Mar. 10, 2016, which is incorporated by reference in its entirety for all purposes. Other techniques may be used to allow non-Skype endpoints to dial in to Skype conferences.
In one embodiment, non-Skype video participants can see one or more Skype participants in a continuous presence layout. In some scenarios, each Skype participant is visible in their own segment of the layout. Likewise, Skype participants may be able to see a presentation of one or more non-Skype participants. In some scenarios, each non-Skype participant is visible in their own segment of the layout. As used herein, a Skype participant refers to an endpoint, such as Skype endpoints 110A and 110B of
In the example scenario of
In the discussion below, a signaling adapter merges the audio/video call from MCU 140 with its corresponding content call from a content server (CSS) 170 into a single call from the Skype MCU 130's point of view.
A Skype call consists of multiple SIP dialogs:
(1) A Centralized Conference Control Protocol (CCCP) dialog that is used to add and remove the call from the conference;
(2) A conference info dialog that is used to get info about the conference, its state, its participants and their states;
(3) An audio/video dialog that is used to establish bidirectional flows of audio and video; and
(4) A content dialog that is used to establish a flow of shared content.
Not all 4 dialogs exist at all times. For example, if no content is being shared the content dialog may not exist. In another example, when a participant is waiting in the lobby to be admitted into the conference no audio/video dialog may have been created yet.
Call merging happens on 2 different levels. The 2 logical calls (from MCU 140 and the CSS 170) get merged into one call going to Skype servers and some SIP dialogs get merged into one as well.
In
In the example scenario of
In some embodiments, MCU 140 may act as a media relay MCU and instead of composing streams received from Skype MCU 120 into a composite continuous presence stream, may relay the separate streams to endpoints 110C, along with layout-related information, allowing endpoint 110C to build composite images from the relayed streams.
To Skype MCU 120, signaling adapter 160 and MCU 140 are effectively invisible and Skype MCU 120 acts as if it communicates directly with non-Skype endpoint 110C, treating it as a Skype endpoint. In some embodiments, Skype MCU 120 may be unable to detect that non-Skype endpoints are connected to the conference, and may see all endpoints as Skype endpoints, regardless of their true nature.
Endpoint 110C is illustrated in
MCU 140 may provide transcoding, compositing, and scaling when acting as an MCU on the incoming streams received from the Skype MCU 120. Transcoding, compositing, and scaling are well known in the art and need no further description herein.
Signaling adapter 160 effectively merges the call for the content and the call for the media generated by endpoint 110C through the CSS 170 and MCU 140 into a single call, so that Skype MCU 120 and Skype endpoints 110A and 110B see only a single caller, with both content and media.
In block 210, MCU 140 creates a CCCP dialog, and adds endpoint 110C as a participant in the Skype conference. In block 220, signaling adapter 160 intercepts communication between MCU 140 and Skype MCU 120. Signaling adapter 160 forwards requests from MCU 140 to Skype MCU 120 and forwards responses from Skype MCU 120 to MCU 140. Similarly requests from Skype MCU 120 are forwarded by signaling adapter 160 to MCU 140 and responses from MCU 140 are forwarded to Skype MCU 120. This procedure is unchanged from the procedure that would be used without signaling adapter 160.
In block 230, CSS 170 creates a CCCP dialog and adds endpoint 110C as a participant in the Skype conference. Normally, this would create a second caller in the Skype conference. But now, in block 240, signaling adapter 160 intercepts the CSS CCCP dialog. Requests from CSS 170 are not forwarded to Skype MCU 120, but are dropped. Responses that were sent to MCU 140 for adding endpoint 110C as a participant are also forwarded by signaling adapter 160 to CSS 170. Thus, although CSS 170 and MCU 140 both see a CCCP dialog with Skype MCU 120, Skype MCU 120 only sees a single CCCP dialog and thus only a single caller session is created in the conference.
In block 250, session refreshes flow between MCU 140 and Skype MCU 120, but instead of forwarding session refreshes from CSS 170, signaling adapter 160 responds to the session refresh.
In block 260, dialog termination is handled similarly to session refreshes. Dialog termination flows between MCU 140 and Skype MCU 120 via signaling adapter 160. But dialog termination requests from CSS 170 are intercepted and responded to by signaling adapter 160, without being forwarded to Skype MCU 120. Because the content call from CSS 170 terminates as soon as the media call from MCU 140 does, signaling adapter 160 may terminate the CCCP dialog for MCU 140 with Skype MCU 120, since signaling adapter 160 knows CSS 170 terminates its CCCP dialog soon afterwards. Otherwise, signaling adapter 160 could not terminate the CCCP dialog with Skype MCU 120 until CSS 170 terminates its CCCP dialog.
In an alternate embodiment, signaling adapter 160 may store the full conference info obtained in response to the conference info dialog initiated by MCU 140, store the conference info contained in the response. Instead of modifying the CSS 170 conference dialog request to appear as if the request was coming from MCU 140, signaling adapter 160 may drop the request from CSS 170 and forward the stored conference info response back to CSS 170 as if the stored conference info were coming from Skype MCU 120. However, the previous embodiment is somewhat simpler.
Conference notifications sent by Skype MCU 120 in block 350 are intercepted by signaling adapter 160 and forked to both CSS 170 and MCU 140. Thus, both CSS 170 and MCU 140 get all conference notifications.
In one embodiment, when MCU 140 wants to refresh its conference info dialog, MCU 140 does not send a refresh request, but terminates the original dialog and starts a new conference info dialog. In such an embodiment, because CSS 170 conference info dialog is effectively embedded into MCU 140's conference info dialog, signaling adapter 160 may move CSS 170's conference info dialog from the original MCU 140 conference dialog, so that CSS 170 may continue to receive conference notifications.
In one embodiment, signaling adapter 160 may merge and fork the Session Description Protocol (SDP) messages received from and sent to MCU 140 and CSS 170. The merging may be done on the SDP media line level, adding and removing the SDP media lines associated with CSS 170.
However, in another embodiment, signaling adapter 160 does not need to merge dialogs for audio/video and content, because Skype MCU 120 uses two separate dialogs for media and content. Because CSS 170 passes on only content streams, CSS 170 generates no audio/video dialog. Similarly, because MCU 140 passes on only media streams, MCU 140 generates only an audio/video dialog, not a content dialog. Thus, signaling adapter 160 only needs to make sure that the content dialog generated by CSS 170 is a part of the same logical call from MCU 140 that employs an audio/video dialog.
One of skill in the art will recognize that other elements or components of an MCU that are not illustrated for clarity in
System unit 510 may be programmed to perform methods in accordance with this disclosure. System unit 510 comprises a processing element (PU) 520, input-output (I/O) interface 550 and memory 530. Processing element 520 may include any programmable controller device including one or more members of the processor families in common use in computers, including multi-core processors. Memory 530 may include one or more memory modules and comprise any type of memory, including, but not limited to, random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid-state memory. One of ordinary skill in the art will also recognize that PU 520 may also include some internal memory including, for example, cache memory. Program storage device 580 has stored on it instructions that when executed cause the programmable device 500 to perform its function.
Because prior approaches to integrating non-Skype endpoints into a Skype conference resulted in separate calls appearing for content and media from a non-Skype endpoint, the content and media from a non-Skype participant in the Skype conference could not recognized as connected by Skype MCU 120. Advantageously in embodiments described above, each non-Skype participant appears with media and content linked, and can be controlled as a single caller, instead of two separate callers.
Embodiments may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine readable storage medium, which may be read and executed by at least one processing element to perform the operations described herein. A machine readable storage medium may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine readable storage device may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media.
Embodiments, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules may be hardware, software, or firmware communicatively coupled to one or more processing elements in order to carry out the operations described herein. Modules may be hardware modules, and as such, modules may be considered tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. Circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. The whole or part of one or more programmable devices (e.g., a standalone client or server computer system) or one or more hardware processing elements may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. The software may reside on a computer readable medium. The software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. Accordingly, the term hardware module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Where modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processing element configured using software; the general-purpose hardware processing element may be configured as respective different modules at different times. Software may accordingly program a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. Modules may also be software or firmware modules, which operate to perform the methodologies described herein.
It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
This application is a continuation of U.S. Ser. No. 15/939,517, filed Mar. 29, 2018, which claims priority from U.S. Provisional Application No. 62/479,290, filed Mar. 30, 2017, the contents of which are incorporated herein in their entirety by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62479290 | Mar 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15939517 | Mar 2018 | US |
| Child | 17180184 | US |
