CN113132120B - Monitoring method for multicast mode unicast group in 3GPP pre-established mode - Google Patents

Monitoring method for multicast mode unicast group in 3GPP pre-established mode Download PDF

Info

Publication number
CN113132120B
CN113132120B CN201911390880.7A CN201911390880A CN113132120B CN 113132120 B CN113132120 B CN 113132120B CN 201911390880 A CN201911390880 A CN 201911390880A CN 113132120 B CN113132120 B CN 113132120B
Authority
CN
China
Prior art keywords
terminal
player
message
group
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911390880.7A
Other languages
Chinese (zh)
Other versions
CN113132120A (en
Inventor
黄晋飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Chengdu TD Tech Ltd
Original Assignee
Chengdu TD Tech Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Chengdu TD Tech Ltd filed Critical Chengdu TD Tech Ltd
Priority to CN201911390880.7A priority Critical patent/CN113132120B/en
Publication of CN113132120A publication Critical patent/CN113132120A/en
Application granted granted Critical
Publication of CN113132120B publication Critical patent/CN113132120B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)

Abstract

The application discloses a monitoring method of a multicast mode unicast group in a 3GPP pre-established mode, after a server agrees that a terminal joins a group, a SIP 200OK message is fed back to the terminal through a SOCKET, and a CONNECT message is fed back to the terminal through a pre-established unicast RTCP channel; after receiving the SIP 200OK message, the terminal opens a PLAYER PLAYER; after receiving the CONNECT message and when determining that the PLAYER is opened, sending an ACK message to the server; and the terminal receives the voice data uploaded by the group talkback and sent by the server on a unicast RTCP channel and plays the voice data. By applying the method and the device, the first word can be avoided being lost, and the monitoring performance is improved.

Description

Monitoring method for multicast mode unicast group in 3GPP pre-established mode
Technical Field
The present application relates to a 3GPP pre-establishment mode technology, and in particular, to a method for monitoring a multicast mode unicast group in a 3GPP pre-establishment mode.
Background
Under the existing multicast mode pre-established by the private network terminal MCPTT, if the group to which the terminal belongs is not configured to be a multicast group, the terminal can also join the group, and receives and plays the talkback voice of the group through a unicast channel, namely, the unicast group monitoring of the multicast mode. The terminal may join the group a, which does not mean that the terminal becomes a member of the group, but needs to perform one step of operation before receiving and playing the talkback voice of the group a. Specifically, the unicast group listening process in the multicast mode may include:
1, after a group (namely a group which is not configured to be multicast) where a terminal is located is established, a server sends a group STATUS message (wherein a STATUS flag bit is active) to the terminal through a multicast channel;
2, after receiving the message, the terminal sends SIP REFER message for joining the group to the server through SOCKET;
3, after receiving the SIP REFER message of the joining group, the server replies an SIP 200OK message to the terminal through SOCKET under the condition that the terminal is allowed to join the group, and simultaneously sends a CONNECT message to the terminal through a pre-established unicast RTCP channel and opens a pre-established unicast RTP channel of the terminal;
and 4, processing in two paths, wherein the path a is as follows: after receiving the SIP 200OK message on the SOCKET, the terminal indicates that the group joining is successful, and opens the PLAYER; path b: after receiving the connection message of the server on the pre-established unicast RTCP channel, the terminal immediately replies ACK through the pre-established unicast RTCP channel, and after receiving the ACK on the pre-established unicast RTCP channel, the server sends the uplink voice data of the main speech to the terminal on the pre-established unicast RTP channel. And the terminal starts to play the uplink voice of the main speech when receiving the voice data on the pre-established unicast RTP channel under the condition that the PLAYER is opened.
In practical application, the monitoring method of the multicast mode unicast group has the problem of losing the first word, thereby influencing the monitoring performance.
Disclosure of Invention
The application provides a monitoring method of a multicast mode unicast group in a 3GPP pre-established mode, which can avoid losing the first character and improve the monitoring performance.
In order to achieve the purpose, the following technical scheme is adopted in the application:
a method for monitoring a multicast mode unicast group in a 3GPP pre-established mode comprises the following steps:
after the server agrees that the terminal joins the group, the server feeds back SIP 200OK information to the terminal through SOCKET and feeds back CONNECT information to the terminal through a pre-established unicast RTCP channel;
after receiving the SIP 200OK message, the terminal opens a PLAYER PLAYER; after receiving the CONNECT message and when determining that the PLAYER is opened, sending an ACK message to the server;
and the terminal receives the voice data uploaded by the group talkback and sent by the server on the unicast RTCP channel and plays the voice data.
Preferably, the method further comprises: after the terminal receives the CONNECT message, the state information received by the CONNECT message is saved; after the terminal opens the PLAYER, saving the opened state information of the PLAYER;
the determination mode that the connection message is received and the PLAYER is opened comprises the following steps:
after the terminal receives the SIP 200OK message and finishes opening the PLAYER, inquiring whether the state information received by the CONNECT message is stored or not, if so, determining that the CONNECT message is received and the PLAYER is opened; otherwise, after receiving the CONNECT message, when inquiring whether the state information that the PLAYER is opened is saved, if the state information that the PLAYER is opened is saved, determining that the CONNECT message is received and the PLAYER is opened.
According to the technical scheme, after the server agrees that the terminal joins the group, the server feeds back the SIP 200OK message to the terminal through the SOCKET and feeds back the CONNECT message to the terminal through the pre-established unicast RTCP channel; after receiving the SIP 200OK message, the terminal opens a PLAYER PLAYER; after receiving the CONNECT message and when determining that the PLAYER is opened, sending an ACK message to the server; and the terminal receives the voice data uploaded by the group talkback and sent by the server on a unicast RTCP channel and plays the voice data. By the mode, the PLEAER can be opened before the terminal receives the main speaking uplink voice data on the pre-established unicast RTP channel, so that the problem of losing first words can be avoided, and the monitoring performance is improved.
Drawings
FIG. 1 is a schematic diagram of a basic flow of the process of the present application;
fig. 2a and 2b are schematic views of specific processing according to an embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical means and advantages of the present application more apparent, the present application will be described in further detail with reference to the accompanying drawings.
The monitoring method for multicast mode unicast group described in the background art has the problem of losing the first character in practical application, and then the reason of the problem is specifically analyzed.
Specifically, in the multicast mode unicast group monitoring method described in the background art, after receiving the SIP REFER message for group join on the SOCKET, the server determines that the terminal is allowed to join the group, and then sends the SIP 200OK message to the terminal on the SOCKET and sends the CONNECT message to the terminal on the pre-established unicast RTCP channel at the same time, but the transmission delays of the SOCKET channel and the pre-established unicast RTCP/RTP channel of the SIP are different, and it takes time for the terminal to process the SIP 200OK message and complete opening of the playlist, which causes asynchronization of the terminal.
In more detail, the server in the a-path transmits a time-consuming SIP 200OK message to the terminal through the SOCKET T1_1, and the terminal receives the SIP 200OK message and then triggers and completes the opening of the PLAYER T1_ 2; the time T2_1 is consumed when the server in the b-path sends the CONNECT message to the terminal through the pre-established unicast RTCP, the time T2_2 is consumed when the terminal receives the message and recovers the ACK message, and the time T2_3 is consumed when the server receives the ACK message and then sends the main speaking uplink user data to the terminal on the pre-established unicast RTP channel. As can be seen, the total a-way consumption time is T1_1+ T1_2, and the total b-way consumption time is T2_1+ T2_2+ T2_ 3.
If T1_1+ T1_2> T2_1+ T2_2+ T2_3, that is, the terminal has received voice data on the pre-established unicast RTP channel in the case where the play has not completed opening, the voice data of the upstream speaker cannot be played out, resulting in missing first words until the play is opened.
Based on the above analysis, the present application provides a monitoring method for a multicast mode unicast group in a 3GPP pre-established mode, which can ensure that the plain is opened before the terminal receives the voice data of the main speaking uplink on the pre-established unicast RTP channel, so as to avoid the problem of losing the first character, thereby improving the monitoring performance.
Next, a specific processing method of the present application will be described in detail. FIG. 1 is a schematic diagram of the basic process of the method of the present application. As shown in fig. 1, the method includes:
step 101, after the server agrees to join the terminal group, the server feeds back a SIP 200OK message to the terminal through SOCKET, and feeds back a CONNECT message to the terminal through a pre-established unicast RTCP channel.
Wherein, the server agrees to the joining of the terminal group and the previous operation can be performed in the existing mode. For example, using the process described in the background: after the group is established, the server sends a GROUPSTATUS message (wherein the STATUS flag bit is active) to the terminal through a multicast channel; after receiving the message, the terminal sends SIP REFER message of group joining to the server through SOCKET; after receiving the SIP REFER message of group joining, the server judges that the terminal group joining is allowed.
After the server agrees to the joining of the terminal group, the server sends two messages to the terminal, one is to feed back the SIP 200OK message to the terminal through SOCKET, and the other is to feed back the CONNECT message to the terminal through a pre-established unicast RTCP channel.
And step 102, after receiving the SIP 200OK message, the terminal opens the PLAYER.
Step 103, judging whether the CONNECT message is received currently and the PLAYER is opened, if yes, executing step 104 and step 105, otherwise, waiting again and judging.
Specifically, whether the current state is that the CONNECT message is received and the layer is opened is determined, which may be performed according to actual conditions. An optimal judgment method is provided in the application:
after the terminal receives the CONNECT message, the state information received by the CONNECT message is stored; and after the terminal opens the PLAYER, saving the opened state information of the PLAYER. Based on this, after the terminal receives the SIP 200OK message and completes opening of the PLAYER, the terminal may query whether the state information that the CONNECT message has been received is saved, and if so, it is determined that the CONNECT message has been received and the PLAYER has been opened; otherwise, after receiving the CONNECT message, when inquiring whether the state information that the PLAYER is opened is stored, if the state information that the PLAYER is opened is stored, determining that the CONNECT message is received and the PLAYER is opened.
And step 104, the terminal sends an ACK message to the server.
And 105, the terminal receives the voice data uploaded by the group talkback sent by the server on a unicast RTCP channel and plays the voice data.
The processing of steps 104 and 105 can be performed in the conventional manner, and will not be described herein.
So far, the basic method flow in the present application ends. Through the processing of the method, the terminal is ensured to feed back the ACK message to the server after the PLAYER is in the open state and receives the CONNCET message, so that the PLAYER is ensured to be in the open state when the server sends the voice data, the loss of the first character is avoided, and the monitoring performance is improved.
The following describes a specific implementation of the basic method by means of a specific embodiment. The data analysis of multiple laboratories and the current network shows that the transmission delay of the SOCKET of the SIP is larger than the transmission delay of the pre-established unicast RTCP/RTP channel. The CONNECT message on the pre-established unicast RTCP/RTP channel is often received first. Based on this, the applicant adds a synchronization module in the terminal for the storage and query of the CONNECT received status and the PLAYER opened status. As shown in fig. 2, the terminal includes a provider module, a SIP SOCKET channel module, a pre-established unicast RTP/RTCP channel module, a multicast channel module, and a synchronization module. The server comprises an SIP SOCKET channel module, a pre-established unicast RTP/RTCP channel module and a multicast channel module. Although it can be seen from laboratory and current network data analysis that the transport delay of the SOCKET of the SIP is generally greater than that of the pre-established unicast RTCP/RTP channel, it is still possible that the program is already open when the terminal receives the CONNECT message, and thus two cases of having received the CONNECT message and not receiving the CONNECT message when the program is open are explained below with reference to fig. 2a and 2b, respectively.
In the process shown in fig. 2a, a multicast channel module of a server sends a group traffic message to a multicast channel module of a terminal, an SIP SOCKET channel module of the terminal sends an SIP REFER message to the SIP SOCKET module of the server, a pre-established unicast RTP/RCTP channel module of the server sends a CONNECT message to the pre-established unicast RTP/RCTP channel module of the terminal, and a status message received by the CONNECT is stored in a synchronization module; the SIP SOCKET channel module of the server sends SIP 200OK information to the SIP SOCKET channel module of the terminal, the PLAYER module opens the PLAYER function, after the PLAYER function is opened, whether the status information received by the CONNECT is stored or not is inquired in the synchronization module, and the status information of the opened PLAYER is stored in the synchronization module; when the state information received by the CONNECT information is inquired and stored in the synchronization module, the pre-established unicast RTP/RCTP channel module of the terminal sends an ACK (acknowledgement character) information to the pre-established unicast RTP/RCTP channel module of the server, the pre-established unicast RTP/RCTP channel module of the server sends voice data of the group talkback to the pre-established unicast RTP/RCTP channel module of the terminal, and the PLAYER module of the terminal plays the voice data received by the pre-established unicast RTP/RCTP channel module.
In the process shown in fig. 2b, a multicast channel module of the server sends a group traffic message to a multicast channel module of the terminal, an SIP SOCKET channel module of the terminal sends an SIP REFER message to the SIP SOCKET module of the server, and a pre-established unicast RTP/RCTP channel module of the server sends a CONNECT message to the pre-established unicast RTP/RCTP channel module of the terminal; the SIP SOCKET channel module of the server sends SIP 200OK information to the SIP SOCKET channel module of the terminal, the PLAYER module opens the PLAYER function, after the PLAYER function is opened, whether the status information received by the CONNECT is stored or not is inquired in the synchronization module, and the status information of the opened PLAYER is stored in the synchronization module; when the status message received by the CONNECT message is not inquired and stored in the synchronization module, the pre-established unicast RTP/RCTP channel module of the terminal continues to wait for receiving the CONNECT message, after the CONNECT message is received, whether the status information that the PLAYER is opened is stored in the synchronization module is inquired, after the corresponding status information is inquired, the pre-established unicast RTP/RCTP channel module of the terminal sends an ACK message to the pre-established unicast RTP/RCTP channel module of the server, the pre-established unicast RTP/RCTP channel module of the server sends the voice data of the group owner to the pre-established unicast RTP/RCTP channel module of the terminal, and the PLAYER module of the terminal plays the voice data received by the pre-established unicast/RCTP channel module.
As can be seen from the basic flow and specific implementation of the method in the present application, when the terminal receives the CONNECT on the pre-established unicast RTCP channel, it does not immediately reply with an ACK, and it needs to reply after the playlist is opened. Therefore, when the server sends the voice data, the PLAYER of the terminal is opened, the problem of losing the first word is avoided, and therefore the monitoring performance is improved. Simulation and field tests show that the problem that the first word is lost at the monitoring end can be thoroughly solved when the group is not configured into a multicast group, the monitoring performance is effectively improved, and the actual effect is very good.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims (2)

1. A method for monitoring a multicast mode unicast group in a 3GPP pre-established mode is characterized by comprising the following steps:
after the server agrees that the terminal joins the group, the server feeds back SIP 200OK information to the terminal through SOCKET and feeds back CONNECT information to the terminal through a pre-established unicast RTCP channel;
after receiving the SIP 200OK message, the terminal opens a PLAYER PLAYER; after receiving the CONNECT message and when determining that the PLAYER is opened, sending an ACK message to the server;
and the terminal receives the voice data uploaded by the group talkback and sent by the server on the unicast RTCP channel and plays the voice data.
2. The method of claim 1, further comprising: after the terminal receives the CONNECT message, the state information received by the CONNECT message is stored; after the terminal opens the PLAYER, saving the opened state information of the PLAYER;
the determination that the CONNECT message is received and the layer is open includes:
after the terminal receives the SIP 200OK message and finishes opening the PLAYER, inquiring whether the state information received by the CONNECT message is stored or not, if so, determining that the CONNECT message is received and the PLAYER is opened; if the state information received by the CONNECT message is not saved, after the CONNECT message is received, whether the opened state information of the PLAYER is saved or not is inquired, and if the opened state information of the PLAYER is saved, the condition that the CONNECT message is received and the PLAYER is opened is determined.
CN201911390880.7A 2019-12-30 2019-12-30 Monitoring method for multicast mode unicast group in 3GPP pre-established mode Active CN113132120B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911390880.7A CN113132120B (en) 2019-12-30 2019-12-30 Monitoring method for multicast mode unicast group in 3GPP pre-established mode

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911390880.7A CN113132120B (en) 2019-12-30 2019-12-30 Monitoring method for multicast mode unicast group in 3GPP pre-established mode

Publications (2)

Publication Number Publication Date
CN113132120A CN113132120A (en) 2021-07-16
CN113132120B true CN113132120B (en) 2022-09-09

Family

ID=76767577

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911390880.7A Active CN113132120B (en) 2019-12-30 2019-12-30 Monitoring method for multicast mode unicast group in 3GPP pre-established mode

Country Status (1)

Country Link
CN (1) CN113132120B (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101129045A (en) * 2004-12-31 2008-02-20 索尼爱立信移动通讯股份有限公司 Method for remotely controlling media devices via a communication network
CN107567001A (en) * 2016-06-30 2018-01-09 中兴通讯股份有限公司 A kind of method, application server and system for realizing that calling is resident
CN110519710A (en) * 2018-05-21 2019-11-29 成都鼎桥通信技术有限公司 The method, apparatus and terminal of loss of data are avoided in group call

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101873762B1 (en) * 2012-08-01 2018-07-03 엘지전자 주식회사 Mobile terminal and method for controlling the same

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101129045A (en) * 2004-12-31 2008-02-20 索尼爱立信移动通讯股份有限公司 Method for remotely controlling media devices via a communication network
CN107567001A (en) * 2016-06-30 2018-01-09 中兴通讯股份有限公司 A kind of method, application server and system for realizing that calling is resident
CN110519710A (en) * 2018-05-21 2019-11-29 成都鼎桥通信技术有限公司 The method, apparatus and terminal of loss of data are avoided in group call

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ETSI TS 102 250-2 V1.3.4;3GPP;《3GPP tsg_sa\WG4_CODEC》;20051223;全文 *
一种TS OVER IP的流媒体播放器架构和实现;张祎;《中国优秀硕士学位论文全文数据库》;20061215;全文 *

Also Published As

Publication number Publication date
CN113132120A (en) 2021-07-16

Similar Documents

Publication Publication Date Title
CN101909196B (en) Channel-switching handling method, system and related equipment
CN101346929B (en) Method for converting between unicast sessions and a multicast session
US7453831B2 (en) Session control using a multicast address
CN101547144B (en) Method and device for improving data transmission quality
US20140050142A1 (en) Managing acknowledgment transmissions from multicast group members of a multicast group within a wireless communications network
CN1917674A (en) Method for processing information of voice in mobile dialogue service
US8803942B2 (en) Session processing method and system
KR20080049739A (en) Audio chat system based on peer-to-peer architecture
CN102651852A (en) Method and device for continuously receiving multimedia broadcast multicast service (MBMS)
US8095116B2 (en) Method for delivering multimedia files
CN113132120B (en) Monitoring method for multicast mode unicast group in 3GPP pre-established mode
CN113612759B (en) High-performance high-concurrency intelligent broadcasting system based on SIP protocol and implementation method
US20090080358A1 (en) Terminating a multicast session within a wireless communications network
US20220006660A1 (en) Rich communication services multicast system
US9143334B2 (en) Method and apparatus for transmitting group message in unicast network
CN103414836B (en) Access processing method and the device of IP-based videoconference
CN104518988A (en) Method and system for priority processing of messages
CN1937613B (en) Method for realizing real-time flow protocol control utilizing state machine
CN104394119B (en) RTP packet sending method, response method and device
WO2011116661A1 (en) User equipment and method for acquiring multicast control information
CN100440780C (en) Method for user joining multimedia broadcast/multicast service
CN116094934B (en) Butt joint linkage method, device and system for broadcasting system
CN104301551A (en) Method for music playing and equipment for music playing
CN113852856B (en) Method for fast switching channels
CN101090392B (en) Multi-service receiving method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant