Method for sending an audio stream from a terminal participating in a conference session involving multiple other third-party terminals
Patent Information
- Application Number
- FR2022011518
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-11-04
- Publication Date
- 2025-03-21
- Estimated Expiration
- 2042-11-04
Smart Images

Figure 00000011_0000 
Figure 00000012_0000 
Figure 00000013_0000
Abstract
Description
Title of the invention: Method for sending an audio stream from a terminal participating in a conference session involving a plurality of other third-party terminals Technical field
[0001] The present disclosure relates to the field of data exchanges transiting via networks using internet protocols in the context of audio and / or video type conferences. Prior art
[0002] Data exchanges via networks using internet protocols are widely used in the context of audio and / or video conferences between remote participants. In particular, several applications make it possible to hold conferences including numerous participants, who connect and participate in the conference via a suitable electronic device, or terminal.
[0003] An audio and / or video conference between several participants is generally managed, from the point of view of bandwidth and the different audio / video data streams to be processed and transmitted to the different participants, by a session server which centralizes all the processing and transmission of the data streams.
[0004] Managing conferences and processing video and audio streams requires a lot of computing resources from the session server's processor. The higher the number of participants, the greater the resources required.
[0005] The present disclosure improves this situation. Summary
[0006] In this regard, a method is proposed, implemented by a terminal, for sending an audio stream from said terminal participating in a conference session in which a plurality of third-party terminals also participate; wherein the data packets of the audio streams emitted by said terminal and said third-party terminals are encapsulated according to an internet protocol, and wherein an audio stream emitted by each of said terminal and said third-party terminals is sent to a session server which distributes the audio stream to the other terminals participating in the conference, the method comprising: determine at least one audio parameter of the audio stream acquired by said terminal, send or not send the audio stream to the session server depending on a value of the at least one audio parameter.
[0007] Optionally, at least one of the at least one audio parameter corresponds to a sound volume of the audio stream acquired by the terminal, and in which the audio stream is sent to the session server only when the volume of the acquired audio stream is above a determined volume threshold.
[0008] Optionally, the audio stream is sent to the session server and the method further comprises transmitting a value of the sound volume of the audio stream.
[0009] Optionally, the method further comprises receiving a volume value of the audio stream received from the session server, and the volume threshold is determined to be equal to the volume value received from the session server.
[0010] Optionally, at least one of the at least one audio parameter corresponds to a frequency of the audio stream acquired by said terminal, and in which the audio stream is sent to the session server only when the audio stream contains a frequency included in a predetermined frequency range.
[0011] Optionally, the predetermined frequency range corresponds to a frequency range of the human voice.
[0012] Optionally, the predetermined frequency range extends from 30 to 3000 Hz.
[0013] The method according to the present disclosure therefore makes it possible to save computing resources of the session server 3 ensuring the distribution of the data streams of the conference session by cleverly using the computing resources of the terminal to discriminate the audio streams upstream of the data exchanges between terminal and server. In this way, the session server does not have to decode, possibly decrypt, all of the audio streams acquired by the terminals in real time. The filtering, that is to say the selection of the streams, is implemented at least in part at the level of the transmitting terminals.
[0014] The application also relates to a terminal configured to implement any of the methods presented by the present disclosure.
[0015] The application further relates to a computer program product comprising instructions for implementing any of the methods presented by the present disclosure when this program is executed by a processor.
[0016] Finally, the application relates to a non-transitory recording medium readable by a computer on which is recorded a program for implementing any of the methods presented by the present disclosure when this program is executed by a processor. Brief description of the drawings
[0017] Other characteristics, details and advantages will appear on reading the detailed description below, and on analyzing the attached drawings, in which: Fig.l
[0018] [Fig.l] schematically represents an example of communication architecture wherein a method of sending an audio data stream from a terminal participating in a conference session to a session server can be implemented. Fig. 2
[0019] [Fig.2] represents an example of a method for sending an audio stream from a terminal participating in a conference session to a session server. Fig. 3
[0020] [Fig.3] represents an example of a terminal. Description of the embodiments
[0021] An example of a communication architecture 1 is now described with reference to [Fig. 1] in which a method for sending an audio data stream from a terminal participating in a conference session to a session server can be implemented.
[0022] A data stream, or a stream, is defined in the present disclosure as corresponding to at least two successively acquired data packets. An audio data stream, or audio stream, is therefore defined as corresponding to at least two successively acquired audio data packets.
[0023] The communication architecture 1 comprises a terminal 2, a session server 3, and a plurality of third-party terminals 4. In this case, the terminal 2 and the third-party terminals 4 participate in a conference session managed at least in part by the session server 3. During this conference session, the terminal 2 and the plurality of third-party terminals 4 can exchange, in quasi-real time, audio data streams.
[0024] Thus, a data stream emitted by each of the terminal 2 and the third-party terminals 4 during the conference session is sent to the session server 3 which distributes, in real time, the data stream to the other terminals participating in the conference. The distribution of the data packets of the data streams between the session server and the terminals participating in the conference session can be direct or indirect. A distribution is said to be direct between the session server 3 and a terminal when the session server 3 directly sends the data packets of the data stream to this terminal. A distribution is said to be indirect between the session server 3 and a terminal when the session server 3 sends the data packets of the data stream to an intermediate device, for example another server, before the data packets of the data stream are sent to the terminal.
[0025] The terminal 2 is distinguished, in the present disclosure, from the third-party terminals 4 insofar as the method for sending an audio stream presented with reference to [Fig.2] is implemented at the level of the terminal 2. However, the method presented with reference to [Fig.2] and implemented by the terminal 2 can also be implemented by each of the third-party terminals 4 participating in the conference session.
[0026] The conference session can thus designate an audio conference in which the terminal 2 and the third-party terminals 4 can be led to exchange, in real time, audio streams via a session server 3.
[0027] In examples, the terminals of the conference session may be required to exchange, in real time and in addition to the audio data streams, video data streams. In these examples, the conference session may therefore designate a videoconference in which the terminal 2 and the third-party terminals 4 may be required to exchange, in real time, audio and video streams via a session server.
[0028] During the conference session, the data packets of the data streams sent by the terminal 2 and by the third-party terminals 4 are encapsulated according to an internet protocol. This protocol is notably defined in the RFC 791 standard.
[0029] In the example described here, the data streams exchanged by the terminal 2 and the third-party terminals 4 during the conference session are encapsulated according to an RTP (“Real-time Transport Protocol”) or SRTP (“Secure Real-time Transport Protocol”) protocol.
[0030] A data stream encapsulated according to an RTP protocol must be understood in the present application as a UDP (“User Datagram Protocol”) data stream arranged so as to comply with an RTP protocol, that is to say so as to comply with a protocol notably defined by the RFC 3550 standard. In particular, when an RTP data stream is encrypted so as to comply with an SRTP protocol, that is to say in accordance with the RFC 3711 standard, we speak of an SRTP data stream.
[0031] An audio stream emitted by a terminal during the conference session is also encoded by a codec implemented by the terminal.
[0032] Thus, when the terminal 2 transmits an audio stream during the conference session, the data packets of this audio stream are encapsulated according to an internet protocol, are encoded by a codec, are possibly encrypted by an encryption key and then are sent to the session server 3 which distributes them to the third-party terminals 4 participating in the conference session.
[0033] A terminal may correspond to a fixed or mobile communication device.
[0034] An example of terminal 2 is notably represented in [Fig.3].
[0035] In examples and as illustrated by [Fig. 3], the terminal 2 may comprise a microphone 21 for acquiring an audio stream. It may, alternatively, be connected to a camera as a peripheral.
[0036] In examples and as illustrated by [Fig. 3], the terminal 2 may comprise a camera 22 for acquiring a video stream. It may, alternatively, be connected to a microphone as a peripheral.
[0037] In examples, the terminal 2 may comprise a computer 23 configured to
[0038]
[0039]
[0040]
[0041]
[0042]
[0043]
[0044]
[0045] order the execution of the processes presented here. As explained above, at least any one of the third-party terminals 4 participating in the conference session may correspond to the terminal example 2 described with reference to [Fig. 3]. In this sense, at least any one of the third-party terminals 4 may comprise a microphone 21, a camera 22 and a computer 23. A session 3 server can, for example, correspond to a multimedia server (known as a “media server”). There is now presented, with reference to [Fig. 2], an example of a method 200 for sending an audio stream from a terminal 2 participating in a conference session in which a plurality of third-party terminals 4 also participate. The audio stream from the terminal 2 is sent to the session server 3. The method for sending the audio data stream from the terminal 2 to the session server 3 is implemented by the terminal 2. One of the objectives of the present disclosure is to reduce the computing resources required by the session server 3 in managing the conference session in which the terminal 2 and the third-party terminals 4 participate. As illustrated by block 210, method 200 comprises: - determine at least one audio parameter of the audio stream acquired by said terminal. In examples, at least one of the at least one audio parameter corresponds to the value of a sound volume of the audio stream acquired by the terminal. In examples, at least one of the at least one audio parameter corresponds to a frequency of the audio stream acquired by said terminal. As illustrated by block 220, method 200 comprises: - send or not send the audio stream to the session server depending on a value of at least one audio parameter. The method according to the present disclosure makes it possible to reduce the number of audio streams received and therefore processed by the session server 3 during the conference session by not sending some of the audio streams acquired by the terminal 2. Indeed, in the context of a real-time conference session involving a plurality of terminals, each of the terminals can transmit an audio stream in the same time interval. Consequently, transmitting to the participants each of the audio streams transmitted by the terminals in the same time interval could alter the sound quality of the conference session. Under these conditions, the session server 3 can filter and select only some of the audio streams that it receives in order to distribute them to the participants of the conference session according to audio parameters linked to these audio streams, for example according to a sound volume of the audio streams.Usually, to determine audio parameters of received audio streams, a session server must decode each of the audio streams, possibly decrypting these streams beforehand. when it comes to encrypted audio streams, in order to determine the audio parameters that allow it to perform processing based on said parameters. Therefore, not sending an audio stream to the session server saves at least one decoding operation and one operation of determining the audio parameters, and possibly saves one decryption operation at the session server 3 when the communications are encrypted. The method according to the present disclosure therefore saves computing resources of the session server by cleverly using the computing resources of the terminal 2 to discriminate the audio streams upstream, before they are transmitted to the session server.
[0046] In examples in which at least one of the at least one audio parameter corresponds to a sound volume of the audio stream, the audio stream is sent to the session server only when the sound volume of the acquired audio stream is greater than a determined sound volume threshold. These examples make it possible to avoid the session server 3 receiving and processing audio streams for which the sound volume is lower than the determined sound volume threshold. A sound volume may, for example, correspond to an average sound volume of a predetermined number of audio packets belonging to the audio stream. Since it is a real-time conference, it is appropriate to reduce as much as possible the latency between the acquisition of the audio stream by the terminal 2 and its sending to the session server 3. A compromise is therefore made between a precise determination of the sound volume of the audio stream and a delay in the transmission of this audio stream if necessary.The audio stream can therefore be temporarily stored at terminal 2 to determine its volume before being sent to the session server if its volume was determined to be higher than the volume threshold.
[0047] In examples, and as illustrated by block 215, the method may also comprise: - receive a sound volume value from the session server. In these examples, the volume threshold below which the audio stream from terminal 2 is not sent to session server 3 is determined to be equal to the volume value received from session server 3.
[0048] In embodiments, the session server 3 can determine, in real time and based on the audio streams distributed to the participants in the conference session, a sound volume below which the new audio streams received will not be processed. For example, the session server 3 can be configured to distribute to the participants in the conference session a predetermined maximum number of simultaneous audio streams. In such a case, the selection of the streams to be transmitted can be carried out by favoring the audio streams having the highest volumes among those received. The session server 3 can send to the terminal 2 a sound volume value cor corresponding to the volume of the lowest audio stream among the distributed audio streams. In this way, only an audio stream with sufficient volume to be distributed will be sent by terminal 2 to session server 3. Audio streams with a lower volume are filtered by the sending terminal itself rather than by session server 3.
[0049] In examples in which the audio stream is sent by the terminal 2 to the session server 3, and as illustrated by block 221, the method 200 may also comprise: - transmit a value of the sound volume of the audio stream sent to the session server 3. These examples allow the session server 3 to have access to the sound volume of the audio stream sent by the terminal 2 without decoding the audio stream itself, and without possibly decrypting it when this audio stream was encrypted. In particular, when the session server 3 distributes only a predetermined number of audio streams corresponding to the audio streams having the highest volumes among the audio streams that it receives, it is no longer necessary for the session server 3 to decode, possibly decrypt, this audio stream to be able to determine its sound volume and therefore to be able to determine whether this audio stream must be distributed or not.
[0050] In examples in which at least one of the at least one audio parameter corresponds to a frequency of the audio stream acquired by the terminal 2, the audio stream is sent to the session server 3 only when the audio stream contains a frequency included in a predetermined frequency range. Thus, when the terminal 2 acquires audio streams which do not include a frequency belonging to the predetermined frequency range, these audio streams are not sent to the session server 3. They are filtered by the terminal 2.
[0051] In examples, the predetermined frequency range may correspond to a frequency range of the human voice. Thus, when an audio stream acquired by the terminal 2 does not contain a frequency belonging to a frequency range of the human voice, the audio stream acquired by the terminal 2 is not sent to the session server 3. This makes it possible to avoid sending audio streams to the session server 3 comprising only parasitic noise accidentally acquired by the terminal 2.
[0052] In examples, the predetermined frequency range may, for example, correspond to a first frequency range extending from 30 to 3000 Hz or to a second frequency range extending from 60 to 500 Hz. The first frequency range includes all the frequencies of the human voice, in particular that of sopranos and altos when they sing. The second frequency range covers all the frequencies of the human voice when it is spoken but not necessarily when it is sung.
[0053] The present disclosure also presents a terminal configured to implement any of the methods presented by the present disclosure.
[0054] The method according to the present disclosure therefore makes it possible to save computing resources of the session server 3 ensuring the distribution of the data streams of the conference session by cleverly using the computing resources of the terminal 2 to discriminate the audio streams upstream of the data exchanges between terminal and server. In this way, the session server 3 does not have to decode, possibly decrypt, all of the audio streams acquired by the terminals in real time. The filtering, that is to say the selection of the streams, is implemented at least in part at the level of the transmitting terminals.
Claims
Claims
1. A method, implemented by a terminal, of sending an audio stream from said terminal participating in a conference session in which a plurality of third-party terminals also participate; wherein the data packets of the audio streams emitted by said terminal and said third-party terminals are encapsulated according to an internet protocol, and wherein an audio stream emitted by each of said terminal and said third-party terminals is sent to a session server which distributes the audio stream to the other terminals participating in the conference, the method comprising: determining (210) at least one audio parameter of the audio stream acquired by said terminal, at least one of the at least one audio parameter corresponding to a frequency of the audio stream acquired by said terminal;sending (220) or not sending the audio stream to the session server depending on a value of the at least one audio parameter, the audio stream being sent to the session server only when the audio stream contains a frequency included in a predetermined frequency range.;
2. Method according to the preceding claim, in which at least one of the at least one audio parameter corresponds to a sound volume of the audio stream acquired by the terminal, and in which the audio stream is sent to the session server only when the sound volume of the acquired audio stream is greater than a determined sound volume threshold.
3. Method according to claim 2 wherein, when the audio stream is sent to the session server, the method further comprises: - transmitting (221) a value of the sound volume of the audio stream.
4. The method of claim 2 or 3, wherein the method further comprises: receiving (215) a volume value of the audio stream received from the session server, and wherein the volume threshold is determined to be equal to the volume value received from the session server.
5. A method according to any preceding claim, wherein the predetermined frequency range corresponds to a frequency range of the human voice.
6. A method according to any preceding claim, wherein the predetermined frequency range is from 30 to 3000 Hz.
7. Terminal configured to implement any one of the methods according to one of claims 1 to 6.
8. Terminal according to the preceding claim, wherein the terminal corresponds to a mobile telephone or a computer.
9. Computer program product comprising instructions for implementing the method according to one of claims 1 to 6 when this program is executed by a processor.