U.S. patent application number 14/332597 was filed with the patent office on 2014-11-06 for method, system, and device for controlling a token for an auxiliary stream in a multi-point double-stream conference.
The applicant listed for this patent is Huawei Device Co., Ltd.. Invention is credited to Haifeng Wang.
Application Number | 20140327731 14/332597 |
Document ID | / |
Family ID | 40770403 |
Filed Date | 2014-11-06 |
United States Patent
Application |
20140327731 |
Kind Code |
A1 |
Wang; Haifeng |
November 6, 2014 |
Method, System, and Device for Controlling a Token for an Auxiliary
Stream in a Multi-Point Double-Stream Conference
Abstract
A method for controlling a token for an auxiliary stream in a
multi-point double-stream conference is provided. In the method, a
second conference terminal requests to deprive a token when the
token in the multi-point double-stream conference is occupied by a
first conference terminal and the auxiliary stream is sent. A
Multi-point Control Unit (MCU) receives a token depriving request
message sent by the second conference terminal or a chairman
conference terminal, judges whether to execute token depriving
according to an identifier (ID) carried in the token depriving
request message and sends the token depriving request message to
the first conference terminal that owns the token after the MCU
decides to deprive the token.
Inventors: |
Wang; Haifeng; (Shenzhen,
CN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Huawei Device Co., Ltd. |
Shenzhen |
|
CN |
|
|
Family ID: |
40770403 |
Appl. No.: |
14/332597 |
Filed: |
July 16, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12815052 |
Jun 14, 2010 |
8819133 |
|
|
14332597 |
|
|
|
|
PCT/CN2008/073452 |
Dec 11, 2008 |
|
|
|
12815052 |
|
|
|
|
Current U.S.
Class: |
348/14.09 |
Current CPC
Class: |
H04L 65/403 20130101;
H04M 3/567 20130101; H04N 7/15 20130101; H04N 7/152 20130101; H04N
19/30 20141101 |
Class at
Publication: |
348/14.09 |
International
Class: |
H04N 7/15 20060101
H04N007/15 |
Foreign Application Data
Date |
Code |
Application Number |
Dec 14, 2007 |
CN |
200710179568.4 |
Claims
1. A method for controlling a token for an auxiliary stream in a
multi-point double-stream conference, wherein a second conference
terminal requests depriving of a token when the token in the
multi-point double-stream conference is occupied by a first
conference terminal and the auxiliary stream is sent, comprising:
receiving, by a multi-point control unit (MCU), a token depriving
request message sent by the second conference terminal or a
chairman conference terminal; judging, by the MCU, whether to
execute token depriving according to an identifier (ID) carried in
the token depriving request message; and sending, by the MCU, the
token depriving request message to the first conference terminal
that owns the token after the MCU decides to deprive the token.
2. The method according to claim 1, wherein when the token
depriving request message is sent by the second conference
terminal, the method comprises: receiving, by the MCU, the token
depriving request message from the second conference terminal, the
message carrying an ID of the second conference terminal; judging,
by the MCU, whether to deprive the token from the first conference
terminal according to the ID of the second conference terminal and
an internal policy; and depriving the token from the first
conference terminal when the MCU decides to deprive the token.
3. The method according to claim 1, wherein when the token
depriving request message is sent by the second conference
terminal, the method comprises: receiving, by the MCU, the token
depriving request message from the second conference terminal, the
message carrying an ID that is equivalent to an ID of a chairman
conference terminal and can instruct the MCU to execute related
operation according to contents of the message; and judging, by the
MCU, whether to deprive the token from the first conference
terminal according to the ID that is equivalent to the ID of the
chairman conference terminal in the token depriving request
message.
4. The method according to claim 1, wherein when the token
depriving request message is sent by the chairman conference
terminal, the method further comprises: receiving, by the chairman
conference terminal, a token depriving request message carrying the
ID of the second conference terminal forwarded by the MCU; and
judging, by the chairman conference terminal, whether to deprive
the token from the first conference terminal according to the ID of
the second conference terminal and an internal policy, sending the
token depriving request message that carries the ID of the chairman
conference terminal to the MCU to notify the MCU of depriving the
token from the first conference terminal when the chairman
conference terminal decides to deprive the token, and ending the
token depriving when the chairman conference terminal decides not
to deprive the token.
5. The method according to claim 4, wherein receiving, by the
chairman conference terminal, the token depriving request message
forwarded by the MCU comprises: receiving, by the MCU, the token
depriving request message from the second conference terminal, the
message carrying the ID of the second conference terminal;
obtaining, by the MCU, the token from the first conference
terminal; and forwarding, by the MCU, the token depriving request
message to the chairman conference terminal when the MCU fails to
obtain the token.
6. The method according to claim 4, wherein receiving, by the
chairman conference terminal, the token depriving request message
forwarded by the MCU comprises receiving, by an auxiliary-stream
chairman conference terminal for auxiliary stream images, the token
depriving request message carrying the ID of the second conference
terminal forwarded by the MCU.
7. The method according to claim 5, further comprising the MCU
issuing the token to the second conference terminal and updating a
status of the token to idle when the MCU successfully obtains the
token from the first conference terminal.
8. The method according to claim 5, wherein obtaining the token
from the first conference terminal by the MCU comprises: sending a
token request message to the first conference terminal; and
obtaining successfully the token when the first conference terminal
agrees to release the token.
9. The method according to claim 1, further comprising sending, by
the MCU, a token response message to the second conference terminal
and updating a status of the token to idle.
10. The method according to claim 1, further comprising the MCU
issuing the token to a conference terminal with a highest priority
when multiple conference terminals request the token
simultaneously, wherein the priorities of the conference terminals
are set in advance.
11. The method according to claim 1, wherein when the token
depriving request message is sent by the chairman conference
terminal, the method comprises: receiving, by the MCU, the token
depriving request message that carries the ID of the chairman
conference terminal from the chairman conference terminal; judging,
by the MCU, whether to deprive the token from the first conference
terminal according to the ID of the chairman conference terminal;
and depriving the token from the first conference terminal when the
MCU decides to deprive the token.
12. A system for controlling a token for an auxiliary stream in a
multi-point double-stream conference, comprising: a multi-point
control unit (MCU); a first conference terminal; and a second
conference terminal, wherein the MCU is configured to: receive a
token depriving request message sent by the second conference
terminal or a chairman conference terminal in the multi-point
double-stream conference when the token is occupied by the first
conference terminal and the auxiliary stream is sent, and the
second conference terminal requests depriving of the token; judge
whether to execute the token depriving according to an identifier
(ID) carried in the token depriving request message; and deprive
the token from the first conference terminal by sending the token
depriving request message to the first conference terminal that
owns the token after deciding to execute the token depriving.
13. The system according to claim 12, further comprising the
chairman conference terminal, and wherein the chairman conference
terminal is configured to: receive the token depriving request
message; judge whether to execute the token depriving according to
the ID carried in the token request and an internal policy; and
send a token depriving request message carrying an ID of the
chairman conference terminal to the MCU when deciding to deprive
the token.
14. The system according to claim 13, wherein the MCU is further
configured to: receive the token depriving request message; obtain
the token from the first conference terminal according to the token
depriving request message; and forward the token request message to
the chairman conference terminal when failing to obtain the
token.
15. The system according to claim 13, wherein the MCU is further
configured to send a token depriving response message to the second
conference terminal that requests the token after successfully
depriving the token, and update a status of the token to idle.
16. The system according to claim 13, wherein the chairman
conference terminal is the chairman conference terminal for
controlling auxiliary stream images.
17. The system according to claim 12, wherein the MCU is configured
to: receive the token depriving request message carrying an ID of
the second conference terminal from the second conference terminal;
judge whether to deprive the token from the first conference
terminal according to the ID of the second conference terminal and
an internal policy; and deprive the token from the first conference
terminal when the MCU decides to deprive the token.
18. The system according to claim 12, wherein the MCU is configured
to: receive the token depriving request message carrying an ID that
is equivalent to an ID of a chairman conference terminal in from
the second conference terminal; judge whether to deprive the token
from the first conference terminal according to the ID that is
equivalent to the ID of the chairman conference terminal; and
deprive the token from the first conference terminal when the MCU
decides to deprive the token.
19. A multi-point control unit (MCU), comprising: a receiver
configured to receive token depriving request messages from
conference terminals in a multi-point double-stream conference sent
by a second conference terminal or a chairman conference terminal;
and a processor coupled to the receiver and a computer readable
medium having computer executable instructions stored thereon that,
when executed by the processor, cause the processor to: judge
whether to deprive a token from a first conference terminal
according to an identifier (ID) carried in the token depriving
request message; and deprive the token from the first conference
terminal by sending the token depriving request message to the
first conference terminal that owns the token after deciding to
execute the token depriving.
20. The MCU according to claim 19, further comprising a transmitter
configured to send a token depriving response message to the second
conference terminal that requests the token according to the token
depriving request response message.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 12/815,052, filed Jun. 14, 2010, which is a
continuation of International Application No. PCT/CN2008/073452,
filed on Dec. 11, 2008, which claims priority to Chinese Patent
Application No. 200710179568.4, filed on Dec. 14, 2007, all of
which are hereby incorporated by reference in their entireties.
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
[0002] Not applicable.
REFERENCE TO A MICROFICHE APPENDIX
[0003] Not applicable.
TECHNICAL FIELD
[0004] The present invention relates to the communication technical
field, and in particular, to a method, a system, and a device for
controlling a token for an auxiliary stream in a multi-point
double-stream conference.
BACKGROUND
[0005] In an H.323 protocol-based multi-point double-stream
video-conferencing system, a centralized conference mode exists.
This mode is the most widely used mode. In this mode, the video and
audio streams on each conference terminal in a conference are
controlled by a Multi-point Control Unit (MCU) in a centralized
way. All the conference terminals participating in the conference
set up calls with only the MCU, and send the code streams including
the main stream and auxiliary stream to the MCU. The MCU performs
necessary processing for the code streams, and selectively sends
the code streams to each conference terminal. In addition, the MCU
sends conference control signaling to each conference terminal and
controls the exchange and transmission of video and audio code
streams to implement the specific conference control function.
[0006] With the existing technology, the double-stream function of
the multi-point double-stream video-conferencing system is
implemented in compliance with the H.239 standard protocol. The
H.239 protocol describes how to control and indicate the auxiliary
stream through H.245 signaling and the capability exchange
mechanism in an H.323 protocol-based video-conferencing system. A
presentation type of auxiliary stream exists in the multi-point
double-stream video-conferencing system. The auxiliary stream is
controlled in the role management process. Specifically, for a
presentation type of auxiliary stream, the role management process
is based on the token mechanism. That is, a specific auxiliary
stream token must be obtained before the conference terminal in a
conference sends the local auxiliary stream. At any time, only one
conference terminal holds the token in a conference to send the
auxiliary stream.
[0007] As stipulated by the H.239 protocol, in a multi-point
double-stream conference system, the MCU controls the delivery of
the auxiliary stream token. That is, each conference terminal must
request an auxiliary stream token from the MCU before sending the
auxiliary stream. The MCU determines whether the token can be
delivered to the requesting conference terminal based on the
holding of the token in the current conference. After receiving a
token response from the MCU, the conference terminal can open the
auxiliary stream channel to send the auxiliary stream and
periodically send a message indicating the holding of the token to
the MCU. The MCU forwards the message to all the conference
terminals in the conference. When a conference terminal wants to
release the token without sending the auxiliary stream, the
terminal sends a token release indication to the MCU. After
receiving the indication, the MCU deems that the auxiliary stream
token in the current conference is in the idle state, and other
conference terminals can apply to the MCU for the token.
[0008] During the implementation of the present invention, the
inventor discovers the following disadvantages in the existing
technology:
[0009] In many actual application scenarios, the MCU needs to
forcibly deprive the token from a conference terminal in a
conference and then deliver the token to another conference
terminal, so that the conference terminal can obtain the auxiliary
stream token smoothly. For example, when a conference terminal in a
conference needs to present an important film image to
participants, but the auxiliary stream token in the current
conference is occupied by another conference terminal for a long
time and cannot be released instantly. As a result, the conference
terminal cannot obtain the right to send the auxiliary stream in
time, thus affecting the conference progress. In the H.239
protocol, token request and release mechanisms are regulated, but
no token depriving mechanism is described. In this case, the MCU as
the conference control center fails to control the release of an
auxiliary stream token in the conference and cannot fully control
the auxiliary stream token. In serious cases, for example, when an
exception occurs on the conference terminal with the token, a
conference has to be held again.
SUMMARY
[0010] In one embodiment, the disclosure includes a method for
controlling a token for an auxiliary stream in a multi-point
double-stream conference, wherein a second conference terminal
requests depriving of a token when the token in the multi-point
double-stream conference is occupied by a first conference terminal
and the auxiliary stream is sent. The method includes an MCU
receiving a token depriving request message sent by the second
conference terminal or a chairman conference terminal. The MCU
judges whether to execute token depriving according to an
identifier (ID) carried in the token depriving request message, and
the MCU sends the token depriving request message to the first
conference terminal that owns the token after the MCU decides to
deprive the token.
[0011] In another embodiment, the disclosure includes a system for
controlling a token for an auxiliary stream in a multi-point
double-stream conference. The system includes an MCU, a first
conference terminal, and a second conference terminal. The MCU is
configured to receive a token depriving request message sent by the
second conference terminal or a chairman conference terminal in the
multi-point double stream conference when the token is occupied by
the first conference terminal and the auxiliary stream is sent, and
the second conference terminal requests depriving the token. The
MCU is further configured to judge whether to execute the token
depriving according to an ID carried in the token depriving request
message and to deprive the token from the first conference terminal
by sending the token depriving request message to the first
conference terminal that owns the token after deciding to execute
the token depriving.
[0012] In yet another embodiment, the disclosure includes an MCU
comprising a receiver and a processor. The receiver is configured
to receive token depriving request messages from conference
terminals in a multi-point double-stream conference sent by a
second conference terminal or a chairman conference terminal. The
processor is coupled to the receiver and a computer readable medium
that has computer executable instructions stored thereon that, when
executed by the processor, cause the processor to judge whether to
deprive a token from a first conference terminal according to an ID
carried in the token depriving message, and deprive the token from
the first conference terminal by sending the token depriving
request message to the first conference terminal that owns the
token after deciding to execute the token depriving.
[0013] These and other features will be more clearly understood
from the following detailed description taken in conjunction with
the accompanying drawings and claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIG. 1 is a flowchart of a method for controlling a token
for an auxiliary stream provided in an embodiment of the present
invention;
[0015] FIG. 2 shows an application scenario of an implementation
mode provided in an embodiment of the present invention;
[0016] FIG. 3 is a flowchart for controlling a token for an
auxiliary stream provided in a second embodiment of the present
invention;
[0017] FIG. 4 is a flowchart for controlling a token for an
auxiliary stream provided in a fourth embodiment of the present
invention;
[0018] FIG. 5 shows a system module for controlling a token for an
auxiliary stream provided in a fifth embodiment of the present
invention; and
[0019] FIG. 6 shows a system module for controlling a token for an
auxiliary stream provided in a sixth embodiment of the present
invention.
DETAILED DESCRIPTION
[0020] The following section explicitly describes the complete
technical solution provided in the embodiments of the present
invention. Obviously, only certain embodiments of the present
invention are presented herein. All the other embodiments obtained
by those skilled in the art without creative work based on the
embodiments of the present invention are protected by the present
invention.
[0021] In the multimedia video-conferencing system, the
double-stream mode is more and more widely used. The double streams
indicate that all the conference terminals in a conference receive
and send two channels of video code streams at the same time. One
channel of code stream for moving picture people is called "main
stream" and is adapted to send the main video code stream of the
conference terminal. The other channel of code stream for contents
is called "auxiliary stream" and is adapted to send auxiliary
pictures or video images such as slides. Based on the H.239
protocol, the embodiments of the present invention are used in the
scenario where the first conference terminal holds a token and
sends auxiliary streams and the second conference terminal requests
a token in a multi-point double-stream conference. In the
embodiment of the present invention, the MCU executes the token
depriving. FIG. 1 is a flowchart of a method for controlling a
token for an auxiliary stream provided in an embodiment of the
present invention. The method includes: after the MCU receives a
token depriving request message (block 10), the MCU judges whether
to execute the token depriving according to an ID carried in the
token depriving request message (block 12), that is, whether to
release the token of the current conference terminal. The ID
carried in the token depriving request message may be an MCU
Terminal (MT) ID. When the MCU determines to execute the token
depriving, the MCU deprives the token of the first conference
terminal (block 14). Based on the token depriving request message,
the MCU is requested to deprive the auxiliary stream token of the
current conference terminal. That is, the token for the auxiliary
stream is requested from the MCU. The MT ID is the MT ID of the
conference terminal (the second conference terminal) sending the
token depriving request message. The MT ID is allocated uniformly
by the MCU to each conference terminal when the terminal
participates in the conference. The MT ID corresponds to a
conference terminal one by one and is used to uniquely identify a
conference terminal in the conference. Most conference control
functions of the MCU are specified to a relevant conference
terminal according to an MT ID.
[0022] The chairman conference terminal is preferably configured to
have the capability to implement some special conference control
functions, for example, broadcasting the conference terminal,
muting the conference terminal, and implementing roll call for
speech, through the MCU. When the chairman conference terminal
exists in a conference, the MCU executes the token depriving
according to the token depriving request message if the message
carries the MT ID of the chairman conference terminal; otherwise,
the MCU does not execute this operation.
[0023] If the MCU receives the release messages from multiple
conference terminals concurrently, the MCU decides to deliver the
deprived token to the conference terminal with the highest
priority. The priority of each conference terminal can be preset in
advance.
[0024] A method for controlling a token for an auxiliary stream in
a multi-point double-stream conference is provided in a first
embodiment of the present invention. In this embodiment, the
chairman conference terminal does not exist. The method is
described in detail as follows.
[0025] A conference terminal requesting the depriving of the token
sends a token depriving request message with the MT ID of the
conference terminal. After receiving this message, the MCU judges
whether to deprive the token of the current conference terminal
according to the MT ID of the conference terminal requesting a
token and the internal policy. If the MCU decides to deprive the
token, the MCU executes the token depriving; otherwise, the MCU
ends this operation. The internal policy for the MCU to judge
whether to deprive the token varies with MCUs. The policy can be,
but is not limited to, one of the following.
[0026] The MCU reports the MT ID of the conference terminal sending
a token depriving request message to the service processing layer.
This layer determines whether to execute the token depriving, such
as manual operation; or a pool of MT IDs with the permission to
deprive a token for an auxiliary stream can be set on the MCU in
advance. The MCU determines whether to execute the depriving
operation by judging whether the MT ID in the token depriving
request message exists in the pool.
[0027] The specific operation of the MCU to deprive the token can
be in, but is not limited to, one of the following modes.
[0028] Mode 1: The token depriving request message
presentationTokenRelease is sent to the current conference terminal
with the token, and then the token response message
presentationTokenResponse is sent to the conference terminal
currently requesting a token, and subsequently the holding state of
the token in the conference is updated to the non-holding
state.
[0029] Mode 2: A token request message is sent to the current
conference terminal with the token, and the symmetryBreaking field
in the message is set to 0. After the conference terminal with the
token receives this message, this terminal must release the token
because the symmetryBreaking field is set to 0. Subsequently, the
MCU sends a token response message to the conference terminal
currently requesting a token, and updates the holding state of the
token in the conference to the non-holding state.
[0030] If the MCU receives a request or release message from
multiple conference terminals concurrently, the MCU decides to
deliver the deprived token to the conference terminal with the
highest priority. That is, a token response message is sent to a
high-priority conference terminal.
[0031] In this embodiment, after receiving a token depriving
request message, the MCU determines whether to deprive a token
according to the MT ID of the conference terminal requesting a
token. The preceding solution effectively solves the problem that
the token is held by a conference terminal in a multi-point
double-stream conference for a long time and the sending of an
emergent and important auxiliary stream is disturbed, realizes the
absolute control of the token by the MCU, and meets the need of
user in the multi-point double-stream conference.
[0032] A method for controlling a token for an auxiliary stream in
a multi-point double-stream conference is provided in a second
embodiment of the present invention. In this embodiment, the
chairman conference terminal exists. The method is described in
detail as follows.
[0033] A conference terminal requesting the depriving of the token
sends a token request message with the MT ID of the conference
terminal. After receiving this message, the MCU obtains the token
from the conference terminal holding the token. When failing to
obtain the token, the MCU sends the request message to the chairman
conference terminal. The chairman conference terminal determines
whether to deprive the token of the current conference terminal or
to keep the existing token holding state unchanged according to the
MT ID of the conference terminal requesting a token and the
internal policy. When the chairman conference terminal decides to
deprive the token of the current conference terminal, the chairman
conference terminal sends a token depriving request message with
the MT ID of the chairman conference terminal to the MCU. After
receiving the token depriving request message, the MCU judges
whether the MT ID carried in the message is the MT ID of the
chairman conference terminal. If yes, the MCU executes the
subsequent token depriving according to the specific content of the
message; otherwise, the MCU does not execute this operation. In
addition to the mode specified in the first embodiment, the MCU can
deprive the token in the following mode: if the MCU determines that
the MT ID in the token depriving request message is the MT ID of
the chairman conference terminal in the current conference, and the
auxiliary stream token of the conference is held by a non-chairman
conference terminal, the MCU executes the subsequent depriving
operation.
[0034] After receiving a token request message, the MCU checks the
token holding condition of the current conference and executes the
operation of obtaining the token from the token holding terminal.
The specific operation includes: the MCU sends a token request
message to the token holding terminal. When the token holding
terminal agrees to release the token, the token holding terminal
sends a presentationTokenResponse message to the MCU. The MCU
updates the token holding condition in the conference and forwards
the response message to the conference terminal requesting a
terminal. When the token holding terminal has no response or
refuses to release the token, the MCU fails to obtain the token,
and the process proceeds to the subsequent token depriving.
[0035] The internal policy of the chairman conference terminal
varies with the chairman conference terminals. The policy can be as
follows: each chairman conference terminal notifies a terminal in
the chairman conference terminal of the received token request
message and the terminal in the chairman conference terminal
determines whether to execute the depriving operation.
[0036] FIG. 2 shows an application scenario provided in a specific
embodiment of the implementation mode. In this embodiment, an MCU
20 is connected to a Chairman conference terminal 22, a first
conference terminal 24, and a second conference terminal 26. While
connection to two conference terminals is depicted, it is to be
appreciated that connection of the MCU 20 to more than two
conference terminals is encompassed by the present invention. FIG.
3 shows an execution process. The token in the current conference
is held by the conference terminal 2 (26), which sends the
auxiliary stream. When the conference terminal 1 (24) wants to send
the auxiliary stream, the following blocks are performed:
[0037] Block 1: Conference terminal 1 (24) sends the token request
message presentationTokenRequest to the MCU 20.
[0038] Block 2: The MCU 20 checks the token holding condition of
the current conference, and forwards the request message to
conference terminal 2 (26) as the token holder. If conference
terminal 2 agrees to release the token, the process proceeds to
block 3. If conference terminal 2 has no response or refuses to
release the token, the process proceeds to block 4.
[0039] Block 3: Conference terminal 2 sends the response message
presentationTokenResponse to the MCU, and then the process proceeds
to block 6 where the MCU sends a token response message to
conference terminal 1.
[0040] Block 4: The MCU 20 forwards the token request message from
conference terminal 1 to the chairman conference terminal 22, and
the chairman conference terminal determines how to proceed. The
chairman conference terminal 22 can decide whether to execute token
depriving based on the MT ID of conference terminal 1 and the
internal policy. If the chairman conference terminal decides to
deprive the token of conference terminal 2, the process proceeds to
block 5.
[0041] Block 5: The chairman conference terminal 22 sends a token
depriving request message presentationTokenRelease to the MCU 20,
in which the carried MT ID is the MT ID of the chairman conference
terminal.
[0042] Block 6: Upon receiving the message, the MCU 20 judges that
the MT ID in the message is the MT ID of the chairman conference
terminal, which indicates that the chairman decides to deprive the
token of the current conference token owner (conference terminal
2), executes the token release operation, and sends the token
response message to conference terminal 1.
[0043] In this case, the MCU 20 has two modes to forcibly release
the token of conference terminal 2:
[0044] Mode 1: The MCU 20 sends a token depriving message
presentationTokenRelease to conference terminal 2 and a token
response message presentationTokenResponse to conference terminal
1, and updates the state of the token in the conference to
idle.
[0045] Mode 2: The MCU sends a token request message
presentationTokenRequest to conference terminal 2, and sets the
symmetryBreaking field in the message to 0. Then, the MCU sends a
token response message presentationTokenResponse to conference
terminal 1, and updates the state of the token in the conference to
idle.
[0046] After obtaining the response from the MCU, the conference
terminal 1 can open the auxiliary stream channel to send auxiliary
stream information to the conference, and periodically send the
token occupation indication presentationTokenlndicateOwner to the
MCU. The MCU broadcasts the message to other participating
terminals to state that the token is occupied by conference
terminal 1.
[0047] In this embodiment, a token request message is forwarded to
the chairman conference terminal 22, and the chairman conference
terminal decides whether to deprive the token. If the token needs
to be deprived, the chairman conference terminal 22 instructs the
MCU to execute token depriving. In this way, the problem that the
token in a multi-point double-stream conference is occupied by a
certain conference terminal for a long time and thus the emergent
and important auxiliary steams cannot be sent can be solved, and
the chairman conference terminal can fully control the token, thus
meeting the need of users in a multi-point double-stream
conference.
[0048] In the third embodiment of the present invention, a method
for controlling a token for an auxiliary stream in a multi-point
double-stream conference is provided. For a scenario where two
chairman conference terminals exist in a multi-point double-stream
conference in this embodiment, the two chairman conference
terminals are divided into a chairman conference terminal for
controlling the main stream images and a chairman conference
terminal for controlling the auxiliary stream images. The method
for controlling the token can be as follows: the conference
terminal requesting the depriving of the token sends a token
request message to the chairman conference terminal for auxiliary
streams. The chairman conference terminal for auxiliary streams
forwards this message to the MCU. The MCU obtains the token from
the token owner (in the same way as specified in the second
embodiment). If the MCU fails to obtain the token, the MCU forwards
the message to the chairman conference terminal for auxiliary
streams. The subsequent process is the same as that in the second
embodiment.
[0049] This embodiment applies to the scenario where two chairman
conference terminals exist. To distinguish between the conference
terminals in terms of main stream and auxiliary stream, in this
embodiment, the token request message is sent to the chairman
conference terminal for auxiliary steams, and the chairman
conference terminal for auxiliary streams forwards the message to
the MCU, so that the MCU knows that the auxiliary stream token
needs to be controlled. In this case, the token is fully
controlled, the requirement of users in a multi-point double-stream
conference is met, and the problem that the token in a multi-point
double-stream conference is occupied by a certain conference
terminal for a long time and thus the emergent and important
auxiliary steams cannot be sent is solved.
[0050] In the fourth embodiment of the present invention, a method
for controlling a token for an auxiliary steam in a multi-point
double-stream conference is provided. The method is described as
follows.
[0051] In a scenario where a chairman conference terminal exists,
and the conference terminal requesting a token knows the MT ID of
the chairman conference terminal, the conference terminal
requesting a token simulates the chairman conference terminal to
send a token depriving request message to the MCU. The message
contains the MT ID of the chairman conference terminal. Upon
receiving the message, the MCU deems that the conference terminal
wants to forcedly obtain the token, and then the MCU deprives the
token. The operation of depriving the token by the MCU is the same
as that stated in the first embodiment.
[0052] The preceding operation applies to the scenario where no
chairman conference terminal exists. In this case, a virtual MT ID
of the chairman conference terminal can be preset. This MT ID
equals to the MT ID of the chairman conference terminal, and can
instruct the MCU to execute related operations according to the
contents of this message. That is, the MCU deems that the message
that carries this MT ID is a message sent by the chairman
conference terminal, and then executes related operations according
to the contents of this message.
[0053] FIG. 2 shows an implementation mode of this embodiment. FIG.
4 is the flowchart of the implementation mode. In the current
conference, the token is held by conference terminal 2 that sends
auxiliary streams. When conference terminal 1 wants to send
auxiliary streams, the following blocks are performed.
[0054] Block 1: Conference terminal 1 simulates the chairman
conference terminal to send a token depriving request
presentationTokenRelease to the MCU, which carries the MT ID of the
chairman conference terminal.
[0055] Block 2: Upon receiving the message, the MCU deems that the
conference terminal wants to forcibly obtain the token and then
deprives the token of conference terminal 2 in the same way as that
stated in the first embodiment.
[0056] Block 3: The MCU sends a token response message to
conference terminal 1, and updates the status of the token in the
conference to idle.
[0057] Upon receiving the response from the MCU, conference
terminal 1 can open the auxiliary stream channel to send auxiliary
stream information to the conference, and periodically send the
token occupation indication presentationTokenIndicateOwner to the
MCU. The MCU broadcasts the message to other participating
terminals to state that the token is occupied by conference
terminal 1.
[0058] In this embodiment, the conference terminal requesting a
token simulates the chairman conference terminal to send a token
request message to the MCU. In this way, a solution is provided to
the problem of a token in a multi-point double-stream conference
being occupied by a certain conference terminal for an extended
time and inhibiting sending of the emergent and important auxiliary
steams, and the chairman conference terminal can fully control the
token, thus meeting the need of users in a multi-point
double-stream conference.
[0059] In the fifth embodiment of the present invention, a system
for controlling a token for an auxiliary stream in a multi-point
double-stream conference is provided, as shown in FIG. 5. The
system may include an MCU 50 and at least two conference terminals
(a first conference terminal 52 and a second conference terminal
54). In the multi-point double-stream conference, when the token is
held by the first conference terminal 52 and the auxiliary stream
is sent, the second conference terminal 54 requests the depriving
of the token, and the MCU 50 is adapted to receive a token
depriving request message, judge whether to execute the token
depriving according to an ID carried in the token depriving request
message, and deprive the token of the first conference terminal 52
when it is determined to execute the token depriving. The ID
carried in the token depriving request message may be an MT ID.
[0060] The MCU 50 may include a token depriving request message
receiving module 501, a token depriving judging module 502, a token
releasing module 503, and a token response message sending module
504. The token depriving request message receiving module 501 is
adapted to receive the token depriving request messages from the
conference terminals in the multi-point double-stream conference.
The token depriving judging module 502 is adapted to determine
whether to deprive the token from the first conference terminal 52
that owns the token according to the MT ID in the received token
depriving request message in the same way as stated in the first
embodiment. The token releasing module 503 is adapted to receive
the judgment result of the token depriving judging module 502,
execute token release in the same way as that stated in the first
embodiment when the MCU 50 decides to deprive the token and receive
the token depriving request response message of the conference
terminal that owns the token. The token response message sending
module 504 is adapted to send a token response message to the
second conference terminal 54 requesting the token according to the
token depriving request response message received by the token
releasing module 503.
[0061] In this embodiment, a token depriving judging module 502 is
set in the MCU 50 to allow the MCU 50 to deprive the current token
according to the actual user requirement, thus implementing full
control of the MCU 50 over the token, and meeting user
requirements.
[0062] In the sixth embodiment of the present invention, a system
for controlling a token for an auxiliary stream in a multi-point
double-stream conference is provided, as shown in FIG. 6. The
system may include an MCU 60, a chairman conference terminal 62,
and at least two conference terminals (a first conference terminal
64 and a second conference terminal 66). In the multi-point
double-stream conference, when the token is held by the first
conference terminal 64 and the auxiliary stream is sent, the second
conference terminal 66 requests the depriving of the token, the MCU
60 is adapted to receive the token depriving request message, judge
whether to execute the token depriving according to the MT ID
carried in the token depriving request message, and deprive the
token of the first conference terminal 64 when the MCU 60 decides
to execute the token depriving.
[0063] The MCU 60 may include a token depriving request message
receiving module 601, a token depriving judging module 602, a token
releasing module 603 and a token response message sending module
604. The token depriving request message receiving module 601 is
adapted to receive a token depriving request message that carries
an MT ID, which can be sent by a conference terminal or the
chairman conference terminal 62. The token depriving judging module
602 is adapted to determine whether to deprive the token from the
first conference terminal 64 that owns the token according to the
MT ID in the received token depriving request message in the same
way as stated in the first embodiment. The token releasing module
603 is adapted to receive the judgment result of the token
depriving judging module 602, execute token release when the MCU
decides to deprive the token and receive the token depriving
request response message of the conference terminal that owns the
token. The token response message sending module 604 is adapted to
send a token response message to the conference terminal requesting
the token according to the token depriving request response message
received by the token depriving request module.
[0064] If the token request message received by the MCU 60 is sent
by a conference terminal, the MCU 60 may further include: a token
request message receiving module 605 adapted to receive a token
request message from a conference terminal in a multi-point
double-stream conference; a token obtaining module 606 adapted to
obtain the token from the conference terminal that owns the token
according to the received token request message and sends the token
obtaining result; and a token request message forwarding module 607
adapted to receive the token obtaining result from the token
obtaining module 606 and forward the token request message to the
chairman conference terminal 62 when the MCU 60 fails to obtain the
token.
[0065] The chairman conference terminal 62 is adapted to receive
the token request message, and judge whether to execute token
depriving according to the MT ID in the token request message. When
it decides to deprive the token, the chairman conference terminal
62 sends the token depriving request message to the MCU 60. The
message carries the MT ID of the chairman conference terminal
62.
[0066] The chairman conference terminal 62 may include: a token
request message receiving and sending terminal 621 adapted to
receive a token request message that is sent by the MCU 60 or a
conference terminal, and send the token request message to the MCU
60 when the message is sent by a conference terminal; a token
depriving judging module 622 adapted to determine whether to
deprive the token of the conference terminal that owns the token
according to the MT ID carried in the received token request
message and send the judgment result; and a token depriving request
message sending module 623 adapted to receive the judgment result
of the token depriving judging module 622 and send the token
depriving request message that carries the MT ID of the chairman
conference terminal 62 to the MCU 60 when the token needs to be
deprived.
[0067] In a scenario where two chairman conference terminals exist
(not shown in the figure), the two chairman conference terminals
are divided into the chairman conference terminal for controlling
the main streams and the chairman conference terminal for
controlling the auxiliary streams. The preceding chairman
conference terminal is the chairman conference terminal for
controlling the auxiliary streams.
[0068] In this embodiment, the chairman conference terminal
determines whether to execute token depriving, and instructs the
MCU to execute token depriving when it decides that the token needs
to be deprived. In this way, the chairman conference terminal fully
controls the token, meeting the requirements of actual conference
users.
[0069] In conclusion, in the embodiment of the present invention,
the MCU executes token depriving according to the received token
depriving request or order, thus solving the problem that the
auxiliary stream token is held by a certain conference terminal for
a long time and the sending of an emergent and important auxiliary
stream is disturbed, realizing the absolute control of the
auxiliary stream token in a multi-point double-stream conference,
and meeting the need of users.
[0070] The foregoing sections describe the specific implementation
of the present invention. However, all the modifications or
replacements made by those skilled in the art in the technical
range disclosed by the present invention are protected by the
present invention. Therefore, the protection scope of the present
invention is subject to the protection scope in claims.
* * * * *