Abstract:
Recording of sessions in a peer-to-peer (P2P) videoconference can be performed. In a first embodiment each participant provides a one-way audio and video stream to a recording server, the recording server cooperating with the signaling server to establish the media streams and to record the desired streams and place desired restrictions on the resulting stored file. In a second embodiment, a plurality of recording servers are present, with participants cooperating with one of the recording servers to record each participants audio and video stream. In a third embodiment a recording server is integrated with the participant endpoint, with that participant using the local recording server.

Description:
RELATED APPLICATIONS 
       [0001]    This application claims priority under 35 U.S.C. §119 to Indian Patent Application No. 201631 020157 filed on Jun. 13, 2016, the entire content of which is hereby incorporated by reference. 
       BACKGROUND 
       [0002]    In a traditional videoconference as shown in  FIG. 1 , recording the videoconference is easily performed. Each participant  102 ,  104 ,  106  in the videoconference provides signaling requests to a signaling server  108  and interacts with a multipoint control unit (MCU)  110  to exchange video and audio streams. The MCU  110  receives the audio and video stream from each participant  102 ,  104 ,  106  and composes them into an audio and video stream for each participant  102 ,  104 ,  106 . A recording server  112  is connected to the MCU  110  to record sessions. It is understood that the signaling server  108  and the MCU  110  could be in the same unit or could be separate as shown. When a participant  102 ,  104 , 106  elects to have the session recorded, the record request is provided to the signaling server  108 , which provides the request to the MCU  110 , which then provides the audio and video of the session to the recording server  112 . 
         [0003]    A full mesh peer-to-peer (P2P) videoconference is achieved by setting up independent audio/video real-time RTP streams between each participant of the conference. Setting up individual streams with each participant allows the videoconferencing clients the capability to independently compose the video or to select which participant it wants to send/receive the video. However, because a centralized device like the MCU is not present, recording a session is not readily performed. 
       SUMMARY 
       [0004]    In embodiments according to the present invention, recording of sessions in a P2P videoconference can be performed. In a first embodiment each participant provides a one-way audio and video stream to a recording server, the recording server cooperating with the signaling server to establish the media streams and to record the desired streams and place desired restrictions on the resulting stored file. In a second embodiment, a plurality of recording servers are present, with participants cooperating with one of the recording servers to record each participants audio and video stream. In a third embodiment a recording server is integrated with the participant endpoint, with that participant using the local recording server. 
     
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0005]    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. 
           [0006]      FIG. 1  is a block diagram illustrating connections and operations of a videoconferencing configuration according to the prior art. 
           [0007]      FIG. 2  is a block diagram illustrating connections and operations of a peer-to-peer videoconferencing configuration of a first embodiment according to the present invention. 
           [0008]      FIG. 3  is a block diagram illustrating connections and operations of a peer-to-peer videoconferencing configuration of a second embodiment according to the present invention. 
           [0009]      FIG. 4  is a block diagram illustrating connections and operations of a peer-to-peer videoconferencing configuration of a third embodiment according to the present invention. 
           [0010]      FIG. 5  is a flowchart of operations according to the present invention. 
           [0011]      FIG. 6  is a block diagram of an endpoint according to the present invention. 
           [0012]      FIG. 7  is a block diagram of signaling server according to the present invention. 
           [0013]      FIG. 8  is a block diagram of recording server according to the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0014]    Systems according to the present invention embody recording architectures where the recording server or servers are added as P2P participants in a full mesh conference. 
         [0015]    Referring to  FIG. 2 , a recording server  212  establishes a one-way (receive only) peer media channel with each of the participants (a.k.a. endpoints)  202 ,  204 ,  206  in the conference as requested/directed by a signaling server  208 . This enables the recording server  212  to receive media streams (audio and video) from each participant  202 ,  204 ,  206  separately, which it then records separately. 
         [0016]    The recording server  212  establishes and modifies in runtime the quality (video size, bitrates, frame rate, etc) of the media streams it receives and stores for each participant  202 ,  204 ,  206  in the conference, since the recording is always separate. For example, the recording server  212  might want to receive high bit-rate streams from actively speaking participants while receiving low bit-rate streams for all other participants. 
         [0017]    According to the present invention, each participant  202 ,  204 ,  206  has recording permissions, such as allow, deny or make private. This allows a participant to choose whether he or she agrees to be recorded. For example, if Participant  1   202  initiates a conference recording, Participant  2   204  can choose not to record his streams, while Participant  3   206  might choose to record his streams, but keep them private. The selection of each participant&#39;s recording status can be seen by other participants (for example, in the videoconference roster), so they are aware about which streams are being recorded and will be available for playback in the final recording. 
         [0018]    The signaling server  208  is responsible for setting up the media channels and managing permissions, as well as ensuring there are sufficient recording resources in the network to serve demand. 
         [0019]    Referring to  FIG. 5 , the flow is as follows: 
         [0020]    Participant  1   202  pushes the “Start Recording” button om his videoconference unit, which sends a request to the signaling server  208 . In step  502  the signaling server  208  receives the “Start Recording” request from the participants. 
         [0021]    In step  504  the signaling server  208  finds and allocates resources on a suitable recording server(s)  212 . 
         [0022]    In step  506  the signaling server  212  sends a recording permissions request to all the participants  202 ,  204 ,  206 . 
         [0023]    The participants  202 ,  204 ,  206  choose to allow the recording, deny the recording of their streams or make their stream recording private. 
         [0024]    The permission selection request is sent back from each participant to the signaling server, which are received by the signaling server  208  in step  508 . 
         [0025]    In step  510  the signaling server  208  initiates media stream setup for a one-way (participant to recording server) P2P stream between each participant  202 ,  204 ,  206  and the recording server(s)  212 . 
         [0026]    On completion of media stream setup, in step  512  each participant starts streaming their audio and video to the recording server  212 . 
         [0027]    In step  514  the recording server(s)  212  store the recording. It may optionally store a different file for each participant in the conference separately, with metadata used to indicate the session and the other participants, to allow the entire conference to be recreated if desired. 
         [0028]    This method of recording streams directly from the participant can be further optimized by distributing the recordings on multiple servers, as shown in  FIG. 3 . The signaling server  308  chooses to setup the recording media streams of participants  302 ,  304 ,  306  in a conference with more than one recording servers  312 A,  312 B. The choice of which recording server  312 A,  312 B to use for each participant  302 ,  304 ,  306  can be based on multiple conditions, such as geographic location (to co-locate the participant and the recording server), bandwidth uplink (from participant to the recording server) and/or cost. Each recording server  312 A,  312 B can include metadata to indicate the existence of recorded streams on the other recording server  312 B,  312 A in addition to the normal metadata, to again allow the entire conference to be recreated if desired. 
         [0029]    In an additional embodiment, a recording server  412 C (as a component) is bundled with the participant  402  (i.e. part of endpoint  414 ) and can record the participant&#39;s audio and video streams locally, as shown in  FIG. 4 , thus obviating the need to transmit one stream over the network. The signaling server  408 , participants  404 ,  406  and recording server  412 B are the same as in  FIG. 3 . From the perspective of signaling and user experience, everything above would be applicable for such a local recording server and would behave exactly the same. 
         [0030]    At the end of the conference, or when the recording is stopped, the signaling server requests the recording server(s) to stop the recordings. The recording server may transfer the recordings to a content delivery network (CDN). The signaling server may upload the metadata that ties the separate recordings into a single conference recording. Such metadata contains information such as the conference details, participant details, active speaker details etc., which is useful while playing back the recordings as discussed above. 
         [0031]      FIG. 6  is a block diagram of an exemplary endpoint used by participants in the videoconference. A processor  602  is the primary computing element which handles the user interface, provides the audio and video codec functions and communicates with the signaling server. A memory  604  having volatile and non-volatile portions is connected to the processor  602  to provide working memory and to store the programs which execute on the processor  602  to provide the indicated functions. An audio interface  606  coupled to the processor  602  is connected to microphones to receive audio and to a loudspeaker to provide audio output. A video interface  608  coupled to the processor  602  is connected to a camera to provide the video input and to a monitor or other display to show the other participants. A network interface  610  coupled to the processor  602  is used to communicate with the other participants and the signaling server over the network connecting the various devices. 
         [0032]      FIG. 7  is a block diagram of an exemplary signaling server. A processor  702  is the primary computing element which handles the management and connections of the videoconference and communicates with the participants and the recording server. A memory  704  having volatile and non-volatile portions is connected to the processor  702  to provide working memory and to store the programs which execute on the processor  702  to provide the indicated functions. A network interface  710  coupled to the processor  702  is used to communicate with the other participants and the recording server over the network connecting the various devices. 
         [0033]      FIG. 8  is a block diagram of an exemplary recording server. A processor  802  is the primary computing element which handles the storage of the sessions and communicates with the participants and the signaling server. A memory  804  having volatile and non-volatile portions is connected to the processor  802  to provide working memory and to store the programs which execute on the processor  802  to provide the indicated functions. A network interface  610  coupled to the processor  802  is used to communicate with the other participants and the signaling server over the network connecting the various devices. Session storage  812  provides the bulk storage for storing the recorded sessions. 
         [0034]    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 should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.”