Conference content acquisition method, conference content transmission method, conference system and equipment

Abstract

The invention discloses a conference content acquisition method, a conference content transmission method, a conference system and equipment, and belongs to the technical field of communication. The method comprises the following steps: sending a first session request message to a session initiation protocol (SIP) focus, wherein the first session request message is used for requesting to join a first session and acquiring first historical session content of the first session; and under the condition that a first data channel and a second data channel are respectively established between the SIP focus and the terminal, receiving the real-time session content of the first session through the first data channel, and receiving the first historical session content of the first session through the second data channel.

Description

Technical Field

[0001] This application belongs to the field of communication technology, specifically relating to a method for acquiring conference content, a method for transmitting conference content, a conference system, and equipment. Background Technology

[0002] With the development of technology, remote conferencing has become the mainstream method of cross-regional collaboration. Current remote conferencing systems mainly rely on the Internet Protocol Multimedia Subsystem (IMS). IMS can transmit the content of the meeting to the mobile phones, computers and other terminal devices of the participants in real time through the network, and supports new participants to join the meeting at any time.

[0003] However, since current remote conferencing systems transmit meeting content in real time, when a new participant joins the meeting midway, the system can only transmit the meeting content after the new participant joins, resulting in incomplete information for the participant. Summary of the Invention

[0004] The purpose of this application is to provide a method for obtaining meeting content, a method for transmitting meeting content, a meeting system and equipment, which enables participants to obtain historical meeting information during the meeting.

[0005] In a first aspect, embodiments of this application provide a method for obtaining meeting content, executed by a terminal. The method includes: sending a first session request message to a Session Initiation Protocol (SIP) focus, the first session request message being used to request joining a first session and obtaining the first historical session content of the first session; and, in the case where a first data channel and a second data channel are established between the SIP focus and the terminal respectively, receiving the real-time session content of the first session through the first data channel and receiving the first historical session content of the first session through the second data channel.

[0006] Secondly, embodiments of this application provide a method for transmitting conference content, executed by a Call Session Control Function (CSCF). The method includes: receiving a first session request message sent by a terminal, the first session request message being used to request joining a first session and to obtain the first historical session content of the first session; forwarding the first session request message to a SIP focus, so that a first data channel and a second data channel are established between the SIP focus and the terminal respectively, the first data channel being used to transmit the real-time session content of the first session, and the second data channel being used to transmit the first historical session content of the first session.

[0007] Thirdly, embodiments of this application provide a method for transmitting conference content, executed by a conference SIP focus. The method includes: receiving a first session request message sent by a terminal, the first session request message being used to request joining a first session and to obtain the first historical session content of the first session; and, in the case where a first data channel and a second data channel are established between the SIP focus and the terminal respectively, sending the real-time session content of the first session to the terminal through the first data channel, and sending the first historical session content of the first session to the terminal through the second data channel.

[0008] Fourthly, embodiments of this application provide a conferencing system, which includes a terminal, a calling CSCF, and a SIP focus; the terminal sends a first session request message to the CSCF, the first session request message being used to request to join a first session and obtain the first historical session content of the first session; the CSCF forwards the first session request message to the SIP focus; when a first data channel and a second data channel are established between the SIP focus and the terminal respectively, the SIP focus sends the real-time session content of the first session to the terminal through the first data channel, and sends the first historical session content of the first session to the terminal through the second data channel.

[0009] Fifthly, embodiments of this application provide a terminal, comprising: a sending module and a receiving module. The sending module is configured to send a first session request message to a SIP focus, the first session request message being used to request joining a first session and to obtain first historical session content of the first session. The receiving module is configured to, when a first data channel and a second data channel are established between the SIP focus and the terminal respectively, receive real-time session content of the first session through the first data channel and first historical session content of the first session through the second data channel.

[0010] Sixthly, embodiments of this application provide a first network-side device, comprising a receiving module and a sending module. The receiving module is configured to receive a first session request message sent by a terminal, the first session request message being used to request joining a first session and to obtain first historical session content of the first session. The sending module is configured to forward the first session request message received by the receiving module to a SIP focus, thereby establishing a first data channel and a second data channel between the SIP focus and the terminal, respectively. The first data channel is used to transmit the real-time session content of the first session, and the second data channel is used to transmit the first historical session content of the first session.

[0011] In a seventh aspect, embodiments of this application provide a second network-side device, comprising: a receiving module and a sending module. The receiving module is configured to receive a first session request message sent by a terminal, the first session request message being used to request joining a first session and to obtain the first historical session content of the first session; the sending module is configured to, when a first data channel and a second data channel are established between the SIP focus and the terminal respectively, send the real-time session content of the first session to the terminal through the first data channel, and send the first historical session content of the first session to the terminal through the second data channel.

[0012] Eighthly, embodiments of this application provide a terminal including a processor and a memory, the memory storing programs or instructions executable on the processor, the programs or instructions, when executed by the processor, implementing the steps of the method described in the first aspect.

[0013] In a ninth aspect, embodiments of this application provide a network-side device, which includes a processor and a memory. The memory stores programs or instructions that can run on the processor. When the program or instructions are executed by the processor, they implement the steps of the method described in the second aspect, or the program or instructions, when executed by the processor, implement the steps of the method described in the third aspect.

[0014] In a tenth aspect, embodiments of this application provide a readable storage medium on which a program or instructions are stored. When the program or instructions are executed by a processor, they implement the steps of the method described in the first aspect; or, when the program or instructions are executed by a processor, they implement the steps of the method described in the second aspect; or, when the program or instructions are executed by a processor, they implement the steps of the method described in the third aspect.

[0015] Eleventhly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect, or to implement the method as described in the second aspect, or to implement the method as described in the third aspect.

[0016] In a twelfth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method as described in the first aspect, or the program product is executed by at least one processor to implement the method as described in the second aspect, or the program product is executed by at least one processor to implement the method as described in the third aspect.

[0017] In this embodiment, the terminal can send a first session request message to the SIP focus to request joining the first session and to obtain the first historical session content of the first session. Then, with a first data channel and a second data channel established between the SIP focus and the terminal, the terminal can receive the real-time session content of the first session through the first data channel and the first historical session content of the first session through the second data channel. In this solution, since the terminal can request to obtain the first historical session content of the first session through the first session request message when requesting to join the first session, it can trigger the SIP focus to establish a real-time data channel and a playback data channel in parallel. Simultaneously, while sending the real-time session content of the first session to the terminal through the real-time data channel, it also sends the first historical session content of the first session to the terminal through the playback data channel. That is, a new participant can obtain both the real-time session content and the first historical session content of the meeting after joining. Thus, this solution enables the remote conferencing system to transmit historical meeting information to participants midway through the meeting, allowing new participants to obtain the desired historical meeting content. Attached Figure Description

[0018] Figure 1 This is one of the IMS conferencing system architecture diagrams provided in the embodiments of this application;

[0019] Figure 2 This is the second IMS conferencing system architecture diagram provided in the embodiments of this application;

[0020] Figure 3 This is one of the flowcharts of the meeting content acquisition method provided in the embodiments of this application;

[0021] Figure 4 This is the second flowchart of the meeting content acquisition method provided in the embodiments of this application;

[0022] Figure 5 This is one of the flowcharts of the meeting content transmission method provided in the embodiments of this application;

[0023] Figure 6 This is the second flowchart of the meeting content transmission method provided in the embodiments of this application;

[0024] Figure 7 This is the third flowchart of the meeting content transmission method provided in the embodiments of this application;

[0025] Figure 8 This is one of the schematic diagrams illustrating the interaction process of the conference system provided in the embodiments of this application;

[0026] Figure 9 This is a second schematic diagram of the interaction process of the conference system provided in the embodiments of this application;

[0027] Figure 10 This is the third schematic diagram of the interaction process of the conference system provided in the embodiments of this application;

[0028] Figure 11 This is a schematic diagram illustrating the entire interaction process of the meeting content acquisition method and the meeting content transmission method provided in the embodiments of this application;

[0029] Figure 12 This is one of the schematic diagrams of the terminal provided in the embodiments of this application;

[0030] Figure 13 This is a second schematic diagram of the first network-side device provided in the embodiments of this application;

[0031] Figure 14 This is the third schematic diagram of the second network-side device provided in the embodiments of this application;

[0032] Figure 15 This is a schematic diagram of the terminal structure provided in the embodiments of this application;

[0033] Figure 16 This is a schematic diagram of the hardware structure of the terminal provided in the embodiments of this application;

[0034] Figure 17 This is a schematic diagram of the network-side device provided in an embodiment of this application;

[0035] Figure 18 This is a schematic diagram of the hardware structure of the network-side device provided in the embodiments of this application. Detailed Implementation

[0036] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0037] The terms "first," "second," etc., used in this application's specification are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, a first object can be one or more. Furthermore, in the specification, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects have an "or" relationship.

[0038] The terms "at least one," "at least one," etc., in this application refer to any one, any two, or a combination of two or more of the included objects. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more, and its meaning is similar to that of "at least one."

[0039] The methods, conferencing systems, and devices provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0040] The embodiments of this application can be applied to scenarios where new participants are added during a remote session.

[0041] The following uses some specific scenarios from the embodiments of this application as examples to illustrate the meeting content acquisition method provided in the embodiments of this application.

[0042] Scenario 1: Online Meeting

[0043] The company held an emergency online meeting, lasting 90 minutes. Due to the user being out of town, they were unable to join immediately and were only able to join after a 30-minute preparation period. The user needed to review the first 30 minutes of the meeting to fully understand its progress and participate in subsequent discussions.

[0044] Scenario 2: Online Courses

[0045] A university professor was giving a two-hour live-streamed lecture on "Data Structures." After the course began, one student was unable to log in due to a network problem and only entered the classroom 40 minutes later. This student needed to review the code demonstrations in the first 40 minutes and then continue listening to the subsequent live explanations to seamlessly continue learning and avoid missing any key points.

[0046] Scenario 3: Remote Consultation

[0047] The hospital organized a 60-minute joint consultation with multidisciplinary experts for the patient. Due to shift work for on-call doctors, one expert was only urgently added to the consultation after 20 minutes. Upon joining the consultation, this expert needed to immediately review the patient's medical history, image interpretation, and preliminary discussions from the previous 20 minutes in order to quickly provide supplementary opinions, shorten the decision-making time, and reduce the risk of misdiagnosis.

[0048] It should be noted that scenarios 1 to 3 above are merely exemplary examples of some scenarios that may be applied to the embodiments of this application. In actual implementation, the embodiments of this application can also be applied to more scenarios where new participants need to be added during remote sessions. The embodiments of this application are not limited here.

[0049] This application provides a method for acquiring and transmitting meeting content, a meeting system, and a device. When a terminal requests to join a first session via a SIP focus, it can request the first historical session content of the first session through a first session request message. This triggers the SIP focus to establish a real-time data channel and a playback data channel in parallel. Simultaneously, the real-time session content of the first session is sent to the terminal via the real-time data channel, while the first historical session content is sent to the terminal via the playback data channel. In other words, new participants can acquire both the real-time and historical session content upon joining the meeting. Thus, this solution enables the remote conferencing system to transmit historical meeting information to participants midway through the meeting, allowing new participants to access the complete meeting content.

[0050] The embodiments of this application can be applied to conference systems, such as... Figure 1 As shown, the conference system 19 includes a terminal 10, a CSCF 11, and a SIP focus 12. Wherein:

[0051] For example, the terminal 10 mentioned above is the terminal device of the user who needs to join the session, such as a smartphone, tablet or laptop.

[0052] For example, the CSCF11 described above is a core component in the IMS network, responsible for handling and controlling the establishment, modification, and termination of multimedia sessions. CSCF11 may include a proxy session control function entity, a service session control function entity, and an interrogation session control function entity.

[0053] For example, the SIP focus 12 mentioned above is a logical role in conference control, responsible for session management at the signaling layer, and one SIP focus corresponds to one conference.

[0054] Combination Figure 1 ,like Figure 2As shown, the aforementioned conference system 19 may further include a terminal 10, a proxy session control function entity 11, an inquiry session control function entity 12, a service session control function entity 13, a Media Resource Function Controller (MRFC) 14, a Media Resource Function Processor 15, a subscription data location function entity 16, a home subscriber server 17, and an application server (AS) 18. For example, the proxy session control function entity 11 may be an entry node in the IMS architecture, responsible for forwarding requests from user devices to other functional entities in the IMS network.

[0055] For example, the aforementioned session control function entity 12 can be a network element in the IMS network, used to receive the user's registration request and session request when the user accesses the IMS network, and to route the request to the corresponding service session control function entity according to the user's home network information.

[0056] For example, the aforementioned service session control function entity 13 may be a core control node in the IMS network, responsible for user registration, authentication, session establishment, maintenance and termination, and routing requests to appropriate application servers based on the user's subscription data to provide corresponding multimedia services.

[0057] For example, the media resource function controller 14 described above can be an entity that controls media resources, manages codecs and media processing functions, and operates the media resource function processor according to the instructions of the application server.

[0058] For example, the media resource function processor 15 described above can be an entity for performing actual media processing, including codecs and conference bridging resources.

[0059] For example, the aforementioned contract data location function entity 16 can locate the location of user contract data storage, helping other entities quickly find which home user server the user's contract information is stored on.

[0060] For example, the aforementioned home user server 17 may include a database that stores user subscription data, including user identity information, service permissions, etc., which can be queried by other entities when a user registers or requests services.

[0061] For example, the application server 18 can be an entity that provides specific application services, implement business logic such as video calls, instant messaging, etc., and process application-related requests.

[0062] In one example, the application server 18 mentioned above includes a session controller, which can also be called a conference control server. The session controller is a logical entity in the IMS network that manages conferences, responsible for handling conference joining, media stream control, and historical content playback. The session controller is an instance or independent module of the application server, including at least one session focus. The session focus is a logical role in conference control, responsible for session management at the signaling layer. Each session focus corresponds to one conference; that is, when multiple session focuses are included, the conference control server can handle multiple conferences simultaneously. For example, when using the SIP protocol, the session focus can be a SIP focus, meaning the conference control server can include at least one SIP focus.

[0063] The execution entity of the meeting content acquisition method provided in this application embodiment can be a terminal, or a functional module or functional entity in the terminal. The following uses a terminal as an example to illustrate the technical solution provided in this application embodiment.

[0064] Figure 3 A flowchart illustrating a method for acquiring meeting content according to an embodiment of this application is shown, executed by a terminal. Figure 3 As shown, the meeting content acquisition method provided in this application embodiment may include the following steps 201 and 202.

[0065] Step 201: The terminal sends a first session request message to the SIP focus.

[0066] In this embodiment, the terminal is a user-used terminal device for joining a meeting, such as a smartphone, tablet, or laptop.

[0067] In some embodiments of this application, the aforementioned first session request message is used to request SIP focus to join the first session and obtain the historical session content of the first session.

[0068] In some embodiments of this application, the aforementioned historical session content is an audio and video recording from the start of the meeting to the current moment, which may include recordings of voice, video, screen sharing, and other content during the meeting.

[0069] In some embodiments of this application, the first session request message includes a session join request and a specified historical session duration. The session join request is used to request to join the first session from SIP Focus, and the specified historical session duration is the duration of the historical session content of the first session requested from SIP Focus.

[0070] In this way, by carrying a specified historical session duration in a session request message, the content of a specified historical session duration in the first session of the meeting can be accurately obtained. This avoids redundant loading of all historical session content and also prevents the omission of key content due to insufficient loading. This allows new participants to obtain more comprehensive information from the historical session content, while improving the efficiency of information acquisition.

[0071] In some embodiments of this application, the session request message can be implemented based on different signaling protocols, such as SIP. When using the SIP protocol, the session request message can be SIP signaling, such as a SIP invitation (SIPINVITE). The specific protocol depends on the network architecture and application scenario, and this application does not impose any limitations.

[0072] In some embodiments of this application, the specified historical session duration can be used to specify the duration for obtaining historical session content from the first session.

[0073] It should be noted that the specified historical session duration can be the terminal's default or a user-defined duration. For example, the specified historical session duration can be 30 minutes, 50 minutes, 90 minutes, etc. The specific duration can be determined according to actual usage needs, and this application embodiment does not impose any restrictions.

[0074] It's important to note that IMS-based multi-party conferencing technology is a crucial component of modern communications. IMS's open architecture and standardized interfaces facilitate efficient and flexible multi-party audio and video conferencing. In multi-party conferencing, IMS uses SIP for user registration, authentication, and session management, and supports various multimedia services such as Voice over Internet Protocol (VoIP), video calls, and instant messaging through signaling control and media transmission. This technology boasts high scalability, excellent interoperability, and strong network adaptability, enabling different types of devices, such as smartphones, tablets, and computers, to participate in meetings and achieving reliable communication between different networks and terminals. This approach significantly improves communication efficiency, allowing team members to collaborate effectively even when geographically separated by tools such as remote audio and video calls, screen sharing, and real-time collaboration. Existing multi-party conferencing technologies not only improve internal enterprise communication efficiency and reduce operating costs but are also suitable for various application scenarios such as remote collaboration, online education, and customer support. However, for users joining a multi-party conferencing midway through the meeting, access to previous meeting minutes and timely understanding of the meeting's progress can be challenging, reducing participation efficiency. This application is based on IMS for multi-person conferencing, introducing new data channels and a conferencing content storage and playback module, enabling users to participate in discussions in real time and view past meeting records at the same time, thus enhancing the flexibility of the meeting and the user experience.

[0075] Step 202: With a first data channel and a second data channel established between the SIP focus and the terminal respectively, the terminal receives the real-time session content of the first session through the first data channel and receives the first historical session content of the first session through the second data channel.

[0076] In some embodiments of this application, the first data channel is a channel for transmitting real-time conference media streams between the terminal and the SIP focus, emphasizing low latency and high real-time performance. The second data channel is a channel for transmitting media streams of historical session content between the terminal and the SIP focus, emphasizing data reliability and integrity.

[0077] In some embodiments of this application, the aforementioned real-time session content is a media stream of the currently ongoing meeting, which may include the participants' voice, video, screen-sharing content, and other content.

[0078] In some embodiments of this application, the terminal can receive media streams of real-time session content sent via SIP focus through a first data channel, and decode and play these media streams. Simultaneously, the terminal can receive media streams of historical session content sent via SIP focus through a second data channel, and decode and play these media streams.

[0079] In some embodiments of this application, the SIP focus is located in the session controller, each session controller includes at least one SIP focus, each SIP focus corresponds to a conference, and the session controller can handle at least one conference simultaneously through at least one SIP focus.

[0080] In some embodiments of this application, the terminal can receive media streams of real-time session content sent by the session focus (i.e., the SIP focus) corresponding to the first session in the session controller via a first data channel, and decode and play these media streams. Simultaneously, the terminal can receive media streams of historical session content sent by the session focus (i.e., the SIP focus) corresponding to the first session in the session controller via a second data channel, and decode and play these media streams.

[0081] In some embodiments of this application, the terminal can play real-time session content and historical session content in two areas of a window respectively, or the terminal can play real-time session content and historical session content in two separate windows respectively.

[0082] In some embodiments of this application, after a user joins a meeting midway through a terminal and begins participating in a real-time meeting discussion, they can simultaneously view the replay content of the meeting within a specified past time period.

[0083] For example, the terminal can display a playback window, allowing users to view the replay content of the meeting within a specified time period. In one example, the playback window may include timeline adjustment controls, allowing users to quickly jump to specific time points, control playback speed, and mark time tags.

[0084] In some embodiments of this application, the terminal may be equipped with or download a client that supports playback functionality, such as an operator-customized IMS conferencing application or system application extension, which supports multi-window or split-screen display of real-time and historical session content. The historical session content is muted by default when playing, and the headphones can play conference audio in custom channels, for example, the left ear plays real-time audio and the right ear plays playback audio.

[0085] This application provides a method for obtaining meeting content. When a terminal requests to join a first session through a SIP focus, it can request the first historical session content of the first session via a first session request message. This triggers the SIP focus to establish a real-time data channel and a playback data channel in parallel. Simultaneously, the real-time session content of the first session is sent to the terminal via the real-time data channel, while the first historical session content is sent to the terminal via the playback data channel. In other words, a new participant can obtain both the real-time and historical session content after joining the meeting. Thus, this solution enables the remote conferencing system to transmit historical meeting information to participants midway through the meeting, allowing new participants to obtain the complete meeting content or the meeting content for a specified time period.

[0086] In some embodiments of this application, when a second data channel is established between the SIP focus and the terminal, the meeting content acquisition method provided in this application further includes the following steps 301 and 302.

[0087] Step 301: The terminal sends a second session request message to the SIP focus.

[0088] In some embodiments of this application, the aforementioned second session request message is used to request the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content.

[0089] In some embodiments of this application, when a second data channel is established between the SIP focus and the terminal, the user can operate the terminal to send a second session request message to the SIP focus to request the acquisition of second historical session content whose corresponding time is different from the time corresponding to the first historical session content. That is, if the terminal acquires first historical session content of a certain duration, and the user needs to acquire second historical session content of another duration, the user can operate the terminal to send a second session request message to the SIP focus to request the acquisition of the second historical session content.

[0090] Step 302: The terminal receives the second historical session content of the first session through the second data channel.

[0091] In some embodiments of this application, after sending a second session request message to the SIP focus, the terminal can receive the second historical session content sent by the SIP focus through the established second data channel.

[0092] In this way, the terminal can obtain the content of different historical time periods of the same meeting by sending a second session request message, which allows users to flexibly view the historical session content at any time and improves the flexibility of users to obtain historical session content.

[0093] In some embodiments of the application, combined with Figure 3 ,like Figure 4 As shown, after step 201 above, the meeting content acquisition method provided in this application embodiment further includes the following step 303.

[0094] Step 303: The terminal receives the confirmation information corresponding to the first session request message sent by the SIP focus.

[0095] In some embodiments of this application, the aforementioned confirmation information is a message sent by the SIP focus to the terminal to confirm that the terminal's request has been received and processed. For example, the confirmation information can be a response status code 200 OK.

[0096] In some embodiments of this application, the above confirmation information includes Session Description Protocol (SDP) information, which is used to confirm the negotiated media port and encoding method.

[0097] In this way, the terminal can promptly confirm that its session request has been successfully processed by the SIP focus, and can accurately establish a data channel based on the media port and encoding method, laying the foundation for subsequent transmission of session content.

[0098] The execution entity of the conference content transmission method provided in this application embodiment can be a CSCF, or a functional module or functional entity within the CSCF. The following uses a CSCF as an example to illustrate the technical solution provided in this application embodiment.

[0099] Figure 5 A flowchart illustrating a conference content transmission method provided in an embodiment of this application is shown, executed by CSCF. Figure 5 As shown, the meeting content transmission method provided in this application embodiment may include the following steps 401 and 402.

[0100] Step 401: The CSCF receives the first session request message sent by the terminal.

[0101] In some embodiments of this application, the first session request message is used to request to join the first session and to obtain the first historical session content of the first session.

[0102] In some embodiments of this application, the CSCF is a core component in the IMS network, primarily responsible for handling and controlling the establishment, modification, and termination of multimedia sessions. The CSCF mainly includes a proxy session control function entity, a service session control function entity, and an interrogation session control function entity.

[0103] It should be noted that the aforementioned CSCF is a functional entity, functional module, or functional device. The CSCF can also be referred to as a CSCF entity, CSCF module, or CSCF device.

[0104] In some embodiments of this application, the aforementioned proxy session control function entity can be a proxy-call session control function entity (P-CSCF). The P-CSCF can be the first network access point of the terminal in the IMS architecture, primarily responsible for access control, signaling security, and signaling compression functions. The following explanation uses the P-CSCF as an example.

[0105] In some embodiments of this application, the aforementioned service session control function entity can be a Serving-Call Session Control Function (S-CSCF), which can be a core network element in the IMS network responsible for session control and business logic, including functions such as user registration, authentication, permission verification, and session routing. The following explanation uses the S-CSCF as an example.

[0106] In this embodiment of the application, the aforementioned Interrogating Call Session Control Function (I-CSCF) entity can be used as an example. The following description uses I-CSCF as an example.

[0107] In some embodiments of this application, the terminal may send a first session request message to the service session control function entity via the proxy session control function entity.

[0108] In some embodiments of this application, the terminal can send a first session request message to the P-CSCF, the P-CSCF can decrypt the first session request message and verify its integrity, and then the P-CSCF can forward the first session request message to the S-CSCF.

[0109] In this way, by sending the first session request message to the P-CSCF, the P-CSCF can first verify the first session request message, thereby intercepting malicious or malformed requests, protecting the internal network from attacks and invalid traffic, reducing the burden on the core network element S-CSCF, and improving the efficiency and reliability of network operation.

[0110] In some embodiments of this application, the S-CSCF can receive a first session request message from the terminal forwarded by the P-CSCF. Since the first session request message received by the S-CSCF is verified by the P-CSCF, the security of the first session request message received by the S-CSCF is guaranteed, thereby protecting the internal network from attacks and invalid traffic, reducing the burden on the core network element S-CSCF, and improving the efficiency and reliability of network operation.

[0111] In some embodiments of this application, the first session request message includes a session join request and a specified historical session duration. The session join request is used to request to join the first session from SIP Focus, and the specified historical session duration is the duration of the historical session content of the first session requested from SIP Focus.

[0112] In some embodiments of this application, the phrase "allowing the terminal to obtain the historical session content of the first session" means that the terminal has the right to participate in the current meeting and that there are meeting records of a specified historical session duration available for viewing.

[0113] In this way, the service session control function entity will only send the first session request message if it is determined that the terminal has the permission to obtain the historical session content of the first session, thus ensuring the data security of the meeting.

[0114] Step 402: The CSCF forwards the first session request message to the SIP focus, so that the SIP focus and the terminal establish the first data channel and the second data channel respectively.

[0115] In some embodiments of this application, the first data channel is used to transmit the real-time session content of the first session, and the second data channel is used to transmit the first historical session content of the first session.

[0116] In some embodiments of this application, after receiving the first session request message, the S-CSCF can verify the identity and access permissions of the terminal to confirm whether the terminal is allowed to obtain the historical session content of a specified historical session duration of the first session.

[0117] In some embodiments of this application, the S-CSCF may send a first session request message to the SIP focus if it confirms that the terminal is allowed to obtain the historical session content of a specified historical session duration of the first session.

[0118] Optionally, in some embodiments of this application, when it is determined that the terminal is allowed to obtain the historical session content of the first session, the Service Session Control Function entity will determine that the terminal is entitled to participate in the current meeting and can view the meeting records of a specified historical session duration. In this case, the S-CSCF can route the session request to the I-CSCF of the IMS network.

[0119] In some embodiments of this application, after the S-CSCF routes the session request to the I-CSCF of the IMS network, the I-CSCF can process the session request entering the IMS network, that is, parse the target conference Uniform Resource Identifier (URI) from the session request, so as to subsequently determine the address of the SIP focus or conference control server to which the URI belongs.

[0120] In some embodiments of this application, when multiple independently addressable Home Subscriber Servers (HSSs) are deployed in the IMS network, the I-CSCF can determine the HSS that stores the terminal information through the Subscription Locator Function (SLF). Then, the I-CSCF can send a query request to the HSS that stores the target user information based on the address returned by the SLF. The request includes the identifier of the target user and the meeting URI, which is used to query how to route the request to the destination.

[0121] It should be noted that the above SLF is used to maintain the mapping relationship between users and HSS, and can return the address of the HSS that stores the user information based on the user identifier.

[0122] In some embodiments of this application, the I-CSCF can obtain the address of the HSS for terminal information through the SLF.

[0123] In some embodiments of this application, after receiving a query request from the I-CSCF, the HSS queries the address of the SIP focus based on the user's subscription information and the meeting URI and returns it to the I-CSCF. Then, the I-CSCF determines whether to modify the original request header of the first session request message based on the SIP focus address returned by the HSS. The information returned by the HSS includes fields such as whether topology hiding is enabled (i.e., whether to hide the internal structure of the operator's network) and the target server address type. Next, if the I-CSCF determines that topology hiding is enabled, it can modify the original request header; otherwise, it retains it. Finally, the I-CSCF can forward the first session request message to the specific SIP focus in the session controller based on the SIP focus address.

[0124] In this way, the S-CSCF can send the first session request message to the SIP focus via the I-CSCF, thereby avoiding the S-CSCF directly exposing the internal conference focus address. Furthermore, by utilizing the I-CSCF's SLF / HSS lookup mechanism, the correct SIP focus can be accurately located based on the conference URI in multi-HSS scenarios, thus improving the security and accuracy of the entire network.

[0125] In some embodiments of this application, the S-CSCF may send a first query message to the MRFC.

[0126] In some embodiments of this application, the first query message is used to query whether the terminal is allowed to obtain the historical session content of a specified historical session duration of the first session.

[0127] In some embodiments of this application, the first query message includes the meeting URI and the specified duration of the historical session to be traced back.

[0128] In some embodiments of this application, the aforementioned meeting URI is used to identify the target meeting, locate the corresponding historical content storage location, and then determine whether there are sufficient resources to satisfy the historical session content request for a specified duration.

[0129] In some embodiments of this application, when the terminal is allowed to obtain historical session content, the S-CSCF can send a first query message to the MRFC. The MRFC can then query the meeting content storage and playback module to see if there is historical session content of a specified historical session duration based on the meeting URI.

[0130] In some embodiments of this application, the above-mentioned meeting content storage and playback module is used to record and save the audio and video data of the meeting, and can extract meeting records for a specified time period according to a request.

[0131] In some embodiments of this application, the S-CSCF can receive an acknowledgment message from the MRFC.

[0132] In some embodiments of this application, the above confirmation message is used to confirm that the terminal is allowed to obtain the historical session content of a specified historical session duration of the first session.

[0133] In some embodiments of this application, if there is historical session content with a specified historical session duration, the MRFC can return a response to the S-CSCF, that is, send an acknowledgment message to the S-CSCF so that the S-CSCF confirms that the terminal is allowed to obtain the historical session content of the specified historical session duration of the first session.

[0134] Thus, when the AS allows terminals to access historical session content, the S-CSCF can first use a first query message to verify with the MRFC whether historical content for a specified duration exists and whether resources are available. If the verification is successful, dual channels can then be established. This allows the process to be terminated early when resources are insufficient, avoiding unnecessary signaling when resources are unavailable and improving the overall network processing efficiency.

[0135] In some embodiments of this application, the S-CSCF can send a second query message to the HSS.

[0136] In some embodiments of this application, the second query message is used to query user information of the terminal.

[0137] In some embodiments of this application, the user information of the terminal is a user configuration file of the terminal. The user configuration file may include user authorization status, registration status, service domain, available service configuration, etc.

[0138] In some embodiments of this application, after receiving the first session request message, the S-CSCF can send a query request, i.e., the second query message, to the HSS to query the terminal's identity and registration information, such as the public user identity (IMS Public User Identity, IMPU) and the private user identity (IMS Private User Identity, IMPI).

[0139] In some embodiments of this application, the S-CSCF can receive user information from the terminal of the HSS.

[0140] In some embodiments of this application, after receiving a query request sent by the S-CSCF, the HSS can return a user profile to the S-CSCF. The S-CSCF can receive the user profile sent by the HSS and determine whether to allow the terminal to obtain historical session content based on the user profile.

[0141] In some embodiments of this application, the HSS determines whether to allow the terminal to access historical session content based on the terminal's user information.

[0142] In some embodiments of this application, the aforementioned "allowing the terminal to obtain historical session content" means that the terminal has the permission to join the meeting and access the history record, and can obtain historical session content from the meeting content storage and playback module.

[0143] In some embodiments of this application, after receiving the user profile returned by the HSS, the S-CSCF can verify the registration status of the terminal based on the user profile, that is, check whether the terminal has been registered through the P-CSCF and is in a valid registration state in the IMS network.

[0144] In some embodiments of this application, if a terminal fails to register or is not authenticated, the S-CSCF may reject the meeting join request and send an error response to the terminal, returning an error code of 403 Forbidden or 401 Unauthorized.

[0145] In some embodiments of this application, when the terminal's user authentication is successful, i.e., it is in a valid registration state, the S-CSCF can verify whether the terminal has the permission to join the meeting and access historical records. Specifically, the S-CSCF can determine whether the terminal has subscribed to the "multi-party conferencing service" and "history playback" function modules based on the user profile returned by the HSS.

[0146] In some embodiments of this application, when the terminal has subscribed to the "multi-party conferencing service" and "history playback" function modules, the S-CSCF extracts the meeting URI from the first session request message and sends the meeting URI to the AS. The AS checks the meeting permission rules, such as the list of inviters, meeting password, role permissions, etc., based on the meeting URI to determine whether the terminal is a user allowed to join midway.

[0147] In some embodiments of this application, when the AS allows the terminal to join the conference, the AS can send a notification message to the S-CSCF to inform the S-CSCF that the terminal is allowed to join the conference. Thus, the S-CSCF can determine that the terminal has the permission to join the conference and access the history records, and can obtain the historical session content, that is, allow the terminal to obtain the historical session content.

[0148] In this way, S-CSCF can verify the identity, permissions, and subscription status of the terminal by sending a second query message to the home user server. If the verification is successful, the connection is immediately allowed and the subsequent dual-channel establishment continues. If not allowed, the connection is directly rejected. This avoids invalid signaling from continuing to occupy network resources and ensures that only legitimate users can retrieve historical content, thereby improving network security and processing efficiency.

[0149] The execution entity of the conference content transmission method provided in this application embodiment can be a SIP focus, or a session controller containing the SIP focus. The following uses SIP focus as an example to illustrate the technical solution provided in this application embodiment.

[0150] Figure 6 A flowchart illustrating a conference content transmission method provided in an embodiment of this application is shown, executed by SIP focus. Figure 6 As shown, the meeting content transmission method provided in this application embodiment may include the following steps 501 and 502.

[0151] Step 501: The SIP focus receives the first session request message sent by the terminal.

[0152] In some embodiments of this application, the first session request message is used to request to join the first session and to obtain the first historical session content of the first session.

[0153] In some embodiments of this application, the first session request message carries session description protocol information, which is used to indicate the establishment of a data channel for receiving real-time session content and a data channel for receiving historical session content.

[0154] In some embodiments of this application, the SIP focus can receive a first session request message sent by the terminal through the session controller where it resides. Since the first session request message usually carries the address of the SIP focus, the session controller can receive the first session request message through the SIP focus corresponding to the address of the SIP focus, thereby realizing the forwarding of the first session request message to the SIP focus corresponding to the first session.

[0155] In some embodiments of this application, the SIP focus in the session controller corresponding to the first session can receive the first session request message from the S-CSCF forwarded via the I-CSCF.

[0156] In this way, the SIP focus can receive the first session request message from the S-CSCF via the I-CSCF, thereby avoiding the S-CSCF directly exposing the internal conference focus address. Furthermore, by utilizing the I-CSCF's SLF / HSS lookup mechanism, the correct SIP focus can be accurately located based on the conference URI in multi-HSS scenarios, thereby improving the security and accuracy of the entire network.

[0157] Step 502: With a first data channel and a second data channel established between the SIP focus and the terminal respectively, the SIP focus sends the real-time session content of the first session to the terminal through the first data channel, and sends the first historical session content of the first session to the terminal through the second data channel.

[0158] In some embodiments of this application, after the SIP focus receives the first session request message, it can verify the first session request message. If the verification is successful, the SIP focus can issue a resource allocation instruction to the Media Resource Function Processor (MRFP). The resource allocation instruction is used to instruct the MRFP to reserve the required media resources for the calling user.

[0159] In some embodiments of this application, when a terminal initiates a SIP INVITE request, it carries SDP information in the SIP INVITE request. SDP information is used to define the parameters of the new data channel, including media type, transmission protocol, codec format, bandwidth, etc. The terminal actively carries SDP information in the SIP INVITE request, indicating that in addition to wanting to join the real-time conference audio and video stream, it also needs an additional channel for receiving historical session content.

[0160] In some embodiments of this application, after issuing a resource allocation instruction to the MRFP, the SIP focus can establish a conference connection with the terminal, adding the terminal to the current audio and video stream of the real-time conference. That is, the terminal connects to the audio and video stream of the real-time conference, enabling it to receive and send real-time audio and video data, thereby participating in the current conference. Simultaneously, the SIP focus adds an SDP message to the 200 OK response status code returned to the terminal to confirm the negotiated media port and encoding method. At the same time, the SIP focus notifies the conference content storage and playback module to prepare the corresponding historical session content. The SIP focus uses the newly added data channel to carry the historical session content.

[0161] In some embodiments of this application, the SIP focus can send a media stream of real-time session content to the terminal through a first data channel, and simultaneously send a media stream of historical session content to the terminal through a second data channel.

[0162] In some embodiments of this application, SIP Focus can transmit meeting playback to the user device in various formats, such as audio / video with subtitles or text, depending on network conditions. Based on the new data channel, key information in the meeting can be detected in real time and alerted to the user.

[0163] In some embodiments of this application, when the meeting ends and all aspects are disconnected, the meeting content storage and playback module can save historical meeting records.

[0164] This application provides a method for transmitting conference content. Since the SIP focus receives a first session request message requesting to join the first session and simultaneously requesting to obtain the historical session content of the first session, the SIP focus establishes a real-time data channel and a playback data channel in parallel. This allows the terminal to receive the real-time session content of the first session sent by the SIP focus through the real-time data channel, while simultaneously receiving the historical session content of the first session sent by the SIP focus through the playback data channel. In other words, new participants can obtain both the real-time session content and the historical session content of the meeting for playback viewing after joining the meeting.

[0165] In some embodiments of this application, when a second data channel is established between the SIP focus and the terminal, the conference content transmission method provided in this application further includes the following steps 601 and 602.

[0166] Step 601: The SIP focus receives the second session request message sent by the terminal.

[0167] In some embodiments of this application, the aforementioned second session request message is used to request the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content.

[0168] In some embodiments of this application, when a second data channel is established between the SIP focus and the terminal, the SIP focus can receive a second session request message from the terminal to request second historical session content. That is, if the terminal has obtained a first historical session content of a certain duration, and the user needs to obtain a second historical session content of another duration, the user can operate the terminal to send a second session request message to the SIP focus to request the second historical session content.

[0169] Step 602: SIP Focus sends the second historical session content of the first session to the terminal through the second data channel.

[0170] In some embodiments of this application, after the SIP focus receives the second session request message sent by the terminal, the SIP focus can send the second historical session content to the terminal through the established second data channel.

[0171] In this way, the terminal can obtain the content of different historical time periods of the same meeting by sending a second session request message, which allows users to flexibly view the historical session content at any time and improves the flexibility of users to obtain historical session content.

[0172] In some embodiments of this application, combined with Figure 6 ,like Figure 7 As shown, after step 501 above, the meeting content transmission method provided in this application embodiment further includes the following steps 603 and 604.

[0173] Step 603: SIP Focus verifies the first session request message.

[0174] In some embodiments of this application, the above resource allocation instructions are used to instruct the MRFP to inform the Session Content Storage and Playback Entity that it needs to extract session records for a specified duration.

[0175] In some embodiments of this application, after the SIP focus receives the first session request message, the first session request message can be verified, including:

[0176] (1) Check whether the From header field in the first session request message is consistent with the user information returned by HSS.

[0177] (2) Check whether the SIP-specific extension header field P-Asserted-Identity is consistent with the user information returned by HSS.

[0178] Step 604: If the verification is successful, the SIP focus sends an acknowledgment message corresponding to the first session request message to the terminal, and sends a resource allocation instruction message to the MRFP.

[0179] In some embodiments of this application, the above-mentioned resource allocation instruction information is used to instruct the MRFP to reserve resources for the terminal.

[0180] In some embodiments of this application, the aforementioned resource allocation instruction information includes media path parameters of the terminal, which include at least one of the following: media type, codec format, bandwidth, and conference identity document (ID).

[0181] (1) Media type: refers to the content format of the media, such as audio, video, etc. In a conferencing system, the media type determines the type of media data to be transmitted and processed.

[0182] (2) Codec format: refers to the encoding and decoding methods of media data. Common audio codec formats include G.711, G.729, and AAC, while video codec formats include H.264, H.265, and VP8. Different codec formats have different compression efficiencies and media quality. In a conferencing system, the selection should be based on a comprehensive consideration of factors such as network bandwidth and equipment capabilities.

[0183] (3) Bandwidth: refers to the amount of data that can be transmitted per unit of time, usually measured in bits per second (bps). In a conferencing system, bandwidth determines the speed and quality of media stream transmission. Sufficient bandwidth can ensure smooth transmission of media data and avoid problems such as stuttering and delays.

[0184] (4) Meeting ID: A meeting ID is an identifier used to uniquely identify a meeting. It can be a number, a letter, or a combination of both, used to distinguish different meetings in a meeting system. Through the meeting ID, users can join specific meetings, and the meeting system can also manage and allocate resources to different meetings based on the meeting ID.

[0185] In some embodiments of this application, if the verification is successful, the SIP focus can send a response message to the terminal, i.e., an acknowledgment message corresponding to the first session request message, indicating that the request has been successful. Furthermore, the SIP focus sends a resource allocation instruction to the MRFP via the SIP protocol, including media type, codec format, bandwidth, conference ID, etc., and specifies the media path parameters of the newly joined user terminal.

[0186] In some embodiments of this application, after receiving a resource allocation instruction, the MRFP can reserve the necessary media resources, such as codecs and mixers, for the calling user according to the instruction, and instruct the conference content storage and playback module to extract historical session content for a specified historical session duration.

[0187] In this way, the SIP focus can issue resource allocation instructions to the MRFP through the SIP focus corresponding to the first session, and can simultaneously reserve real-time ports and playback channels, ensuring that the terminal can seamlessly receive current audio and video and historical content after access, thus improving the efficiency of the terminal joining the first session.

[0188] In some embodiments of this application, by extending and improving existing multi-person conferencing systems, the problems of poor user experience for mid-meeting participants and insufficient integration of real-time and historical data are solved, thereby improving user experience and participation in meetings. By introducing new data channels and meeting content storage and playback modules into the IMS architecture, users can choose to view past meeting records while participating in real-time meetings. For users joining a meeting mid-meeting, they can understand the progress of the meeting in a timely and comprehensive manner, ensuring that all users have complete meeting background information when joining the meeting. At the same time, based on the playback of the meeting, it is beneficial for participants to conduct more in-depth discussions on specific content, meeting the needs of modern enterprises and organizations for efficient collaboration and rapid information access.

[0189] This application provides a conferencing system, which includes a terminal, a CSCF (Conference Service Container Registry), and a SIP (Search Engine Utility) focus. For example... Figure 8 As shown, the interaction process of the terminal, CSCF and SIP focus in the conference system provided in this application embodiment may include the following steps 701 to 703.

[0190] Step 701: The terminal sends a first session request message to the CSCF.

[0191] In some embodiments of this application, the first session request message is used to request to join the first session and to obtain the first historical session content of the first session.

[0192] It should be noted that the terminal, CSCF, first session request message, and SIP focus, as well as their related implementation schemes, can be found in the descriptions in the above embodiments, and will not be repeated here.

[0193] Step 702: The CSCF forwards the first session request message to the SIP focus.

[0194] It should be noted that the CSCF, the first session request message, and SIP focus, as well as their related implementation schemes, can be found in the descriptions in the above embodiments, and will not be repeated here.

[0195] Step 703: With a first data channel and a second data channel established between the SIP focus and the terminal respectively, the SIP focus sends the real-time session content of the first session to the terminal through the first data channel, and sends the first historical session content of the first session to the terminal through the second data channel.

[0196] It should be noted that the SIP focus, terminal, first data channel and second data channel, and their related implementation schemes can be found in the descriptions in the above embodiments, and will not be repeated here.

[0197] In some embodiments of this application, combined with Figure 8 ,like Figure 9 As shown, when a second data channel is established between the SIP focus and the terminal, the interaction process between the terminal, CSCF, and SIP focus in the conferencing system provided in this application embodiment may further include the following steps 801 and 802.

[0198] Step 801: The terminal sends a second session request message to the SIP focus.

[0199] In some embodiments of this application, the aforementioned second session request message is used to request the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content.

[0200] It should be noted that the descriptions of the terminal, SIP focus, and second session request messages, as well as their related implementation schemes, can be found in the above embodiments and will not be repeated here.

[0201] Step 802: SIP Focus sends the second historical session content of the first session to the terminal through the second data channel.

[0202] It should be noted that the SIP focus, the second data channel, and the terminal, as well as their related implementation schemes, can be found in the descriptions in the above embodiments, and will not be repeated here.

[0203] In some embodiments of this application, such as Figure 10 As shown, after step 702 above, the conference system provided in this application embodiment further includes the following steps 901 and 902.

[0204] Step 901: SIP Focus verifies the first session request message.

[0205] It should be noted that the SIP focus and first session request message, as well as their related implementation schemes, can be found in the descriptions in the above embodiments, and will not be repeated here.

[0206] Step 902: If the verification is successful, the SIP focus sends an acknowledgment message corresponding to the first session request message to the terminal and sends a resource allocation instruction message to the MRFP.

[0207] In some embodiments of this application, the above-mentioned resource allocation instruction information is used to instruct the MRFP to reserve resources for the terminal.

[0208] It should be noted that the descriptions of SIP focus, terminal, and MRFP, as well as their related implementation schemes, can be found in the above embodiments and will not be repeated here.

[0209] This application provides a conferencing system where, when a terminal requests to join a first session via a SIP focus, it can request the historical session content of the first session through a first session request message. This triggers the SIP focus to establish a real-time data channel and a playback data channel in parallel. Simultaneously, the system sends the real-time session content of the first session to the terminal via the real-time data channel and the historical session content of the first session to the terminal via the playback data channel. In other words, new participants can access both the real-time and historical session content upon joining the meeting. Thus, this solution enables the remote conferencing system to transmit historical meeting information to participants midway through the meeting, allowing new participants to access the complete meeting content.

[0210] For example, the following describes the entire interaction process of the conference content acquisition method and conference content transmission method provided in the embodiments of this application, taking UE#B as the terminal, P-CSCF as the proxy session control function entity, S-CSCF as the service session control function entity, and I-CSCF as the query session control function entity.

[0211] Figure 11 This is a schematic diagram illustrating the entire interaction process of the meeting content acquisition method and the meeting content transmission method provided in the embodiments of this application. Figure 11 As shown, the entire interaction process of the meeting content acquisition method and the meeting content transmission method provided in this application embodiment may include the following steps 10 to 18.

[0212] Step 10: UE#B sends a SIP INVITE signaling message to P-CSCF, which includes a session join request and a specified history duration.

[0213] In some embodiments of this application, if UE#B wishes to join an ongoing meeting midway, it can send a SIP INVITE signaling message to P-CSCF containing a session join request and a specified history duration.

[0214] Step 11: After receiving the session join request sent by UE#B, P-CSCF forwards the session join request to S-CSCF.

[0215] In some embodiments of this application, after receiving a request from UE#B, the P-CSCF forwards the request to the S-CSCF.

[0216] Step 12: After receiving the session join request, the S-CSCF verifies the identity and access permissions of UE#B.

[0217] In some embodiments of this application, after receiving a request, the S-CSCF first queries the HSS for the identity and registration information of UE#B, such as public user identifier, private identifier, IMPU, IMPI, etc. The HSS returns information including user authorization status, registration status, service domain, and available service configuration. Next, the S-CSCF verifies the registration status, checking whether UE#B has registered through the P-CSCF and is in a valid registration state in the IMS network. If registration fails or authentication fails, the S-CSCF rejects the meeting join request, returning 403 Forbidden or 401 Unauthorized. After successful user authentication, the S-CSCF verifies whether the user has the permission to join the meeting and access historical records. Based on the user profile returned by the HSS, it determines whether the user has subscribed to the "Multi-Party Meeting Service" and "Historical Recording Playback" function modules. The S-CSCF interacts with the application server via the meeting URI, checks meeting permission rules such as the inviter list, meeting password, and role permissions, determines whether UE#B is a user allowed to join mid-meeting, and interacts with the MRFC to determine whether access to meeting content from the past X minutes (i.e., the specified historical session duration) is possible.

[0218] Step 13: Once it is confirmed that UE#B is authorized to participate in the current meeting and view the meeting records of the specified past minutes, the S-CSCF will route the session join request to the I-CSCF.

[0219] In some embodiments of this application, after confirming that the user is authorized to participate in the current meeting and view the meeting records of the specified past minutes, the S-CSCF will route the request to the I-CSCF of the meeting network. The I-CSCF then processes the call request and the route query request entering the IMS network. The request contains the target meeting URI. The task of the I-CSCF is to determine the SIP focus or meeting control server address to which the URI belongs.

[0220] Step 14: The I-CSCF determines the SIP focus corresponding to the session join request and forwards the session join request to that SIP focus.

[0221] In some embodiments of this application, if the network deploys multiple independently addressable HSSs, the I-CSCF first accesses the SLF to determine which HSS stores the user's information. The I-CSCF then consults the HSS storing the user's information on how to route the request to the destination. The HSS then informs the I-CSCF of the address of the SIP focus. Based on the information returned by the HSS, the I-CSCF modifies or retains the original request header and forwards the SIP INVITE to the specific SIP focus.

[0222] Step 15: If the session join request passes the SIP focus verification, the SIP focus sends a resource allocation instruction to the MRFP via the SIP protocol.

[0223] In some embodiments of this application, after receiving a request, the SIP focus performs verification, checking whether the standard From header field and the SIP-specific extended header field P-Asserted-Identity field in the INVITE request are consistent with the verification information from the previous HSS. Upon successful verification, the SIP focus replies to the user with "OK," and simultaneously sends a resource allocation instruction to the MRFP via the SIP protocol, including media type, codec format, bandwidth, conference ID, etc., specifying the media path parameters of the newly added user UE#B. The MRFP reserves resources for the calling user according to the instruction and informs the conference content storage and playback module that it needs to retrieve conference records of a specified duration.

[0224] Step 16: The SIP focus establishes a conference connection with UE#B, adds UE#B to the current audio and video stream of the real-time conference, and uses the newly added data channel to carry the conference playback record.

[0225] In some embodiments of this application, the SIP focus can establish a conference connection with UE#B, adding UE#B to the current audio and video stream of the real-time conference, and using a newly added data channel to carry the conference playback record. The newly added data channel is the SDP information actively carried by UE#B when initiating the SIPIVITE request, indicating that in addition to wanting to join the real-time conference audio and video stream, an additional channel is needed to receive historical playback content. The SIP focus returns the SDP in a 200 OK response, confirming the negotiated media port and encoding method, and simultaneously notifying the playback module to prepare the corresponding content. UE#B needs to be equipped with or download a client that supports this function, such as an operator-customized IMS conferencing application or system application extension, supporting multi-window or split-screen display of real-time audio and video conferences and conference playback records. The conference playback record is muted by default, and custom channel playback of conference audio is supported via headphones, such as playing real-time audio in the left ear and playback audio in the right ear.

[0226] Step 17: UE#B begins participating in the real-time meeting discussion and views the meeting replay content from the specified time period in the past.

[0227] In some embodiments of this application, UE#B can start participating in real-time conference discussions and view the replay content of the conference within a specified time period in the past. The replay window provides a timeline controller, allowing users to quickly jump to time points, control playback speed, and mark time tags, etc.

[0228] Step 18: After the meeting ends, the meeting content storage and playback module saves the historical meeting records.

[0229] In some embodiments of this application, when the meeting ends, all aspects are disconnected, and the meeting content storage and playback module saves the historical meeting records.

[0230] This application provides an IMS-based real-time history display system for multi-person meetings. By adding a data channel and a meeting content storage and playback module, it ensures that all users can obtain complete meeting information when joining the meeting, improves the experience and participation of users who join midway through the meeting, enriches the ways in which participants obtain information, and meets the needs of modern enterprises for efficient collaboration and rapid information acquisition.

[0231] In some embodiments of this application, the multi-person conference real-time history display system mainly introduces a new data channel and a conference content storage and playback module on the basis of the IMS architecture. It uses the original audio and video channel to carry the real-time conference and uses the new data channel to carry the conference playback record, so that users can participate in the discussion in real time and view the past conference records at the same time.

[0232] Each of the above-described method embodiments, or various possible implementations of each method embodiment, can be executed individually or in combination of any two or more. The specific implementation can be determined according to actual usage requirements, and this application does not impose any restrictions on this.

[0233] The meeting content acquisition method provided in this application can be executed by a meeting content acquisition device or a terminal. This application uses a terminal executing the meeting content acquisition method as an example to illustrate the terminal provided in this application embodiment.

[0234] The meeting content acquisition device in this application embodiment can be a terminal or a component within the terminal, such as an integrated circuit or a chip. For example, the terminal can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a network attached storage (NAS), personal computer (PC), television set (TV), ATM, or self-service machine, etc. This application embodiment does not impose specific limitations.

[0235] The meeting content acquisition device in this application embodiment can be a device with an operating system, and the terminal in this application embodiment can be a device with an operating system. The operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0236] Figure 12 A schematic diagram of a possible structure of a terminal involved in some embodiments of this application is shown. For example... Figure 12 As shown, the terminal 70 may include a transmitting module 71 and a receiving module 72.

[0237] The sending module 71 is used to send a first session request message to the SIP focus. The first session request message is used to request to join the first session and obtain the first historical session content of the first session.

[0238] The receiving module 72 is used to receive the real-time session content of the first session through the first data channel and the first historical session content of the first session through the second data channel when a first data channel and a second data channel are established between the SIP focus and the terminal, respectively.

[0239] In one possible implementation, the sending module 71 is further configured to send a second session request message to the SIP focus when a second data channel is established between the SIP focus and the terminal. This second session request message requests access to the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content. The receiving module 72 is further configured to receive the second historical session content of the first session through the second data channel.

[0240] In one possible implementation, the receiving module 72 is further configured to receive confirmation information corresponding to the first session request message sent by the SIP focus after the sending module 71 sends the first session request message to the SIP focus.

[0241] This application provides a terminal that, when requesting to join a first session via a SIP focus, can request the first historical session content of the first session from the SIP focus through a first session request message. This triggers the SIP focus to establish a real-time data channel and a playback data channel in parallel. Simultaneously, the real-time session content of the first session is sent to the terminal via the real-time data channel, while the first historical session content of the first session is sent to the terminal via the playback data channel. In other words, new participants can obtain both the real-time and historical session content of the meeting after joining. Thus, this solution enables the remote conferencing system to transmit complete information to participants midway through the meeting, allowing new participants to obtain the complete meeting content.

[0242] The meeting content acquisition device or terminal provided in this application embodiment can implement the various processes implemented in the above method embodiments, and will not be repeated here to avoid repetition.

[0243] The meeting content transmission method provided in this application can be executed by a meeting content transmission device or a network-side device. This application uses a first network-side device to illustrate the meeting content transmission method as an example.

[0244] In some embodiments of this application, the network-side device may be a CSCF, a session controller, etc., and the embodiments of this application do not specifically limit it. For example, a CSCF may include at least one of the following: P-CSCF, S-CSCF, and I-CSCF.

[0245] For example, the first network-side device described above may be the CSCF in the above embodiments.

[0246] Figure 13 A schematic diagram of a possible structure of a first network-side device involved in some embodiments of this application is shown. For example... Figure 13 As shown, the first network-side device 73 may include a receiving module 74 and a transmitting module 75.

[0247] The receiving module 74 is used to receive a first session request message sent by the terminal. The first session request message is used to request to join the first session and obtain the first historical session content of the first session.

[0248] The aforementioned sending module 75 is used to forward the first session request message to the SIP focus, so that a first data channel and a second data channel are established between the SIP focus and the terminal respectively. The first data channel is used to transmit the real-time session content of the first session, and the second data channel is used to transmit the first historical session content of the first session.

[0249] This application provides a first network-side device. After receiving a first session request message, the first network-side device can verify whether the terminal is allowed to obtain the historical session content of the first session through authentication. If allowed, the first session request message is sent, thereby enabling the SIP focus to establish a real-time data channel and a playback data channel in parallel. This allows the terminal to receive the real-time session content of the first session through the real-time data channel and the first historical session content of the first session through the playback data channel. In other words, new participants can obtain both the real-time session content and the historical session content of the meeting for playback after joining the meeting.

[0250] The conference content transmission device or the first network-side device provided in this application embodiment can implement the various processes implemented in the above method embodiments. To avoid repetition, they will not be described again here.

[0251] The meeting content transmission method provided in this application can be executed by a meeting content transmission device or a network-side device. This application uses a second network-side device as an example to illustrate the second network-side device provided in this application embodiment.

[0252] For example, the second network-side device described above may be the SIP focus or session controller in the above embodiments.

[0253] Figure 14 A schematic diagram of a possible structure of a second network-side device involved in some embodiments of this application is shown. For example... Figure 14 As shown, the second network-side device 76 may include a receiving module 77 and a transmitting module 78.

[0254] The receiving module 77 is used to receive a first session request message sent by the terminal. The first session request message is used to request to join the first session and obtain the first historical session content of the first session.

[0255] The aforementioned sending module 78 is used to send the real-time session content of the first session to the terminal through the first data channel, and to send the first historical session content of the first session to the terminal through the second data channel, when a first data channel and a second data channel are established between the SIP focus and the terminal respectively.

[0256] In one possible implementation, the receiving module 77 is further configured to receive a second session request message sent by the terminal when a second data channel is established between the SIP focus and the terminal. This second session request message requests access to the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content. The sending module 78 is further configured to send the second historical session content of the first session to the terminal via the second data channel.

[0257] In one possible implementation, the second network-side device 76 provided in this application embodiment further includes: a verification module. This verification module is configured to verify the first session request message after receiving it from the terminal. The aforementioned sending module 78 is further configured to, if the verification is successful, send confirmation information corresponding to the first session request message to the terminal, and send resource allocation instruction information to the MRFP, the resource allocation instruction information being used to instruct the MRFP to reserve resources for the terminal.

[0258] In one possible implementation, the aforementioned resource allocation instruction information includes media path parameters of the terminal, which include at least one of the following: media type, codec format, bandwidth, and conference ID.

[0259] This application provides a second network-side device. Since the second network-side device receives a first session request message requesting to join the first session and simultaneously requests to obtain the historical session content of the first session, the second network-side device establishes a real-time data channel and a playback data channel in parallel. This allows the terminal to receive the real-time session content of the first session sent by the second network-side device through the real-time data channel, while simultaneously receiving the first historical session content of the first session sent by the second network-side device through the playback data channel. In other words, new participants can obtain both the real-time session content and the historical session content of the meeting for playback viewing after joining the meeting.

[0260] The conference content transmission device or the second network-side device provided in this application embodiment can implement the various processes implemented in the above method embodiments. To avoid repetition, they will not be described again here.

[0261] Optionally, such as Figure 15 As shown, this application embodiment also provides a terminal 1000, including a processor 1001 and a memory 1002. The memory 1002 stores a program or instructions that can run on the processor 1001. When the program or instructions are executed by the processor 1001, they implement the various steps of the above-described meeting content acquisition method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0262] Figure 16A schematic diagram of the hardware structure of a terminal to implement an embodiment of this application.

[0263] The terminal 100 includes, but is not limited to, components such as: radio frequency unit 101, network module 102, audio output unit 103, input unit 104, sensor 105, display unit 106, user input unit 107, interface unit 108, memory 109, and processor 110.

[0264] Those skilled in the art will understand that the terminal 100 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 110 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 16 The terminal structure shown does not constitute a limitation on the terminal. The terminal may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0265] The radio frequency unit 101 is used to send a first session request message to the SIP focus. The first session request message is used to request to join the first session and obtain the first historical session content of the first session.

[0266] The radio frequency unit 101 is also used to receive the real-time session content of the first session through the first data channel and the first historical session content of the first session through the second data channel when a first data channel and a second data channel are established between the SIP focus and the terminal, respectively.

[0267] Optionally, the aforementioned radio frequency unit 101 is further configured to send a second session request message to the SIP focus when a second data channel is established between the SIP focus and the terminal. This second session request message requests access to the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content. The aforementioned radio frequency unit 101 is also configured to receive the second historical session content of the first session through the second data channel.

[0268] Optionally, the radio frequency unit 101 is further configured to receive confirmation information corresponding to the first session request message sent by the SIP focus after sending the first session request message to the SIP focus.

[0269] This application provides a terminal that, when requesting to join a first session via a SIP focus, can request the first historical session content of the first session from the SIP focus through a first session request message. This triggers the SIP focus to establish a real-time data channel and a playback data channel in parallel. Simultaneously, the real-time session content of the first session is sent to the terminal via the real-time data channel, while the first historical session content of the first session is sent to the terminal via the playback data channel. In other words, new participants can obtain both the real-time and historical session content of the meeting after joining. Thus, this solution enables the remote conferencing system to transmit complete information to participants midway through the meeting, allowing new participants to obtain the complete meeting content.

[0270] The terminal provided in this application embodiment can implement all the processes implemented in the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here. For the beneficial effects of the various implementation methods in this embodiment, please refer to the beneficial effects of the corresponding implementation methods in the above method embodiments. To avoid repetition, it will not be described again here.

[0271] It should be understood that, in this embodiment, the input unit 104 may include a graphics processing unit (GPU) 1041 and a microphone 1042. The GPU 1041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 106 may include a display panel 1061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 107 includes at least one of a touch panel 1071 and other input devices 1072. The touch panel 1071 is also called a touch screen. The touch panel 1071 may include a touch detection device and a touch controller. Other input devices 1072 may include, but are not limited to, a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a trackball, a mouse, and a joystick, which will not be described in detail here.

[0272] The memory 109 can be used to store software programs and various data. The memory 109 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 109 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 109 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0273] Processor 110 may include one or more processing units; optionally, processor 110 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 110.

[0274] Optionally, such as Figure 17 As shown, this application embodiment also provides a network-side device 1200, including a processor 1201 and a memory 1202. The memory 1202 stores a program or instructions that can run on the processor 1201. When the program or instructions are executed by the processor 1201, they implement the various steps of the above-described conference content transmission method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0275] This application also provides a network-side device. For example... Figure 18 As shown, the network-side device 1100 includes: a processor 1101, a network interface 1102, and a memory 1103. This network-side device can be... Figure 13 or Figure 14 The conference content transmission device shown. The network interface 1102 is, for example, a common public radio interface (CPRI).

[0276] The network-side device 1100 provided in this application embodiment can be the first network-side device or the second network-side device in the above embodiments.

[0277] In one possible implementation, the network-side device 1100 is a first network-side device;

[0278] The network interface 1102 is used to receive a first session request message sent by the terminal. The first session request message is used to request to join the first session and to obtain the first historical session content of the first session.

[0279] The processor 1101 is used to forward the first session request message to the SIP focus, so that the SIP focus and the terminal establish a first data channel and a second data channel respectively. The first data channel is used to transmit the real-time session content of the first session, and the second data channel is used to transmit the first historical session content of the first session.

[0280] This application provides a network-side device. After receiving a session request message, the network-side device can verify whether the terminal is allowed to obtain the historical session content of the first session through authentication. If allowed, the network-side device sends the session request message, thereby enabling the SIP focus to establish a real-time data channel and a playback data channel in parallel. This allows the terminal to receive the real-time session content of the first session through the real-time data channel and the historical session content of the first session through the playback data channel. In other words, new participants can obtain both the real-time session content and the historical session content of the meeting for playback viewing after joining the meeting.

[0281] In one possible implementation, the network-side device 1100 is a second network-side device;

[0282] Among them, network interface 1202 is used to receive a first session request message sent by the terminal. The first session request message is used to request to join the first session and to obtain the first historical session content of the first session.

[0283] Network interface 1202 is used to send the real-time session content of the first session to the terminal through the first data channel and the first historical session content of the first session to the terminal through the second data channel, when a first data channel and a second data channel are established between the SIP focus and the terminal respectively.

[0284] Optionally, network interface 1202 is further configured to receive a second session request message sent by the terminal when a second data channel is established between the SIP focus and the terminal. This second session request message requests access to the second historical session content of the first session, wherein the time corresponding to the second historical session content differs from the time corresponding to the first historical session content. Network interface 1202 is also configured to send the second historical session content of the first session to the terminal via the second data channel.

[0285] Optionally, the processor 1201 is further configured to verify the first session request message after the network interface 1202 receives the first session request message sent by the terminal. The network interface 1202 is further configured to, if the verification is successful, send confirmation information corresponding to the first session request message to the terminal, and send resource allocation instruction information to the MRFP, which instructs the MRFP to reserve resources for the terminal.

[0286] Optionally, the aforementioned resource allocation instruction information includes the terminal's media path parameters, which include at least one of the following: media type, codec format, bandwidth, and conference ID.

[0287] This application provides a network-side device. Since the network-side device receives a first session request message requesting to join the first session and simultaneously requests to obtain the first historical session content of the first session, the network-side device establishes a real-time data channel and a playback data channel in parallel. This allows the terminal to receive the real-time session content of the first session sent by the network-side device through the real-time data channel, while simultaneously receiving the first historical session content of the first session sent by the network-side device through the playback data channel. In other words, new participants can obtain both the real-time session content and the historical session content of the meeting for playback viewing after joining the meeting.

[0288] Furthermore, the network-side device 1100 in this embodiment of the application also includes: a program or instructions stored in the memory 1103 and executable on the processor 1101, wherein the processor 1101 calls the program or instructions in the memory 1103 to execute. Figure 13 or Figure 14 The methods executed by each module shown achieve the same technical effect, and to avoid repetition, they will not be described in detail here.

[0289] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described meeting content acquisition method or meeting content transmission method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0290] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0291] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described meeting content acquisition method or meeting content transmission method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0292] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0293] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described meeting content acquisition method or meeting content transmission method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0294] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0295] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0296] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for acquiring meeting content, characterized in that, The method, executed by a terminal, includes: Send a first session request message to the SIP focus, the first session request message being used to request to join the first session and to obtain the first historical session content of the first session; When a first data channel and a second data channel are established between the SIP focus and the terminal respectively, the real-time session content of the first session is received through the first data channel, and the first historical session content of the first session is received through the second data channel.

2. The method according to claim 1, characterized in that, When the SIP focus establishes a second data channel with the terminal, the method further includes: Send a second session request message to the SIP focus. The second session request message is used to request the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content. The second historical session content of the first session is received through the second data channel.

3. The method according to claim 1, characterized in that, After sending the first session request message to the SIP focus, the method further includes: Receive the confirmation information sent by the SIP focus corresponding to the first session request message.

4. A method for transmitting conference content, characterized in that, Performed by the Call Session Control Function (CSCF), the method includes: The receiving terminal sends a first session request message, which is used to request to join a first session and obtain the first historical session content of the first session. The first session request message is forwarded to the Session Initiation Protocol (SIP) focus, so that the SIP focus and the terminal establish a first data channel and a second data channel respectively. The first data channel is used to transmit the real-time session content of the first session, and the second data channel is used to transmit the first historical session content of the first session.

5. A method for transmitting conference content, characterized in that, The method, executed by the Session Initiation Protocol (SIP) focus, includes: The receiving terminal sends a first session request message, which is used to request to join a first session and obtain the first historical session content of the first session. When a first data channel and a second data channel are established between the SIP focus and the terminal respectively, the real-time session content of the first session is sent to the terminal through the first data channel, and the first historical session content of the first session is sent to the terminal through the second data channel.

6. The method according to claim 5, characterized in that, When the SIP focus establishes a second data channel with the terminal, the method further includes: The terminal receives a second session request message, which requests the acquisition of the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content. The second historical session content of the first session is sent to the terminal through the second data channel.

7. The method according to claim 5, characterized in that, After the receiving terminal sends the first session request message, the method further includes: Verify the first session request message; If the verification is successful, an acknowledgment message corresponding to the first session request message is sent to the terminal, and a resource allocation instruction message is sent to the Media Resource Function Processor (MRFP). The resource allocation instruction message is used to instruct the MRFP to reserve resources for the terminal.

8. The method according to claim 7, characterized in that, The resource allocation instruction information includes the media path parameters of the terminal, which include at least one of the following: media type, codec format, bandwidth, and conference ID.

9. A conference system, characterized in that, The conferencing system includes a terminal, a Call Session Control Function (CSCF), and a Session Initiation Protocol (SIP) focus. The terminal sends a first session request message to the CSCF. The first session request message is used to request to join the first session and to obtain the first historical session content of the first session. The CSCF forwards the first session request message to the SIP focus; When a first data channel and a second data channel are established between the SIP focus and the terminal, the SIP focus sends the real-time session content of the first session to the terminal through the first data channel and sends the first historical session content of the first session to the terminal through the second data channel.

10. The conference system according to claim 9, characterized in that, When the SIP focus establishes a second data channel with the terminal The terminal sends a second session request message to the SIP focus. The second session request message is used to request the second historical session content of the first session, wherein the time corresponding to the second historical session content is different from the time corresponding to the first historical session content. The SIP focus sends the second historical session content of the first session to the terminal through the second data channel.

11. The conference system according to claim 9, characterized in that, After receiving the first session request message, the SIP focus verifies the first session request message; If the verification is successful, an acknowledgment message corresponding to the first session request message is sent to the terminal, and a resource allocation instruction message is sent to the Media Resource Function Processor (MRFP). The resource allocation instruction message is used to instruct the MRFP to reserve resources for the terminal.

12. A terminal, characterized in that, include: Sending module and receiving module; The sending module is used to send a first session request message to the Session Initiation Protocol (SIP) focus. The first session request message is used to request to join the first session and to obtain the first historical session content of the first session. The receiving module is configured to receive the real-time session content of the first session through the first data channel and the first historical session content of the first session through the second data channel, provided that a first data channel and a second data channel are established between the SIP focus and the terminal, respectively.

13. A first network-side device, characterized in that, include: Receive module and transmit module; The receiving module is used to receive a first session request message sent by the terminal. The first session request message is used to request to join a first session and to obtain the first historical session content of the first session. The sending module is used to forward the first session request message received by the receiving module to the Session Initiation Protocol (SIP) focus, so that the SIP focus and the terminal establish a first data channel and a second data channel respectively. The first data channel is used to transmit the real-time session content of the first session, and the second data channel is used to transmit the first historical session content of the first session.

14. A second network-side device, characterized in that, include: Receive module and transmit module; The receiving module is used to receive a first session request message sent by the terminal. The first session request message is used to request to join a first session and to obtain the first historical session content of the first session. The sending module is used to send the real-time session content of the first session to the terminal through the first data channel, and to send the first historical session content of the first session to the terminal through the second data channel, when a first data channel and a second data channel are established between the Session Initiation Protocol (SIP) focus and the terminal respectively.

15. A terminal, characterized in that, It includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the meeting content acquisition method as described in any one of claims 1 to 3.

16. A network-side device, characterized in that, It includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the conference content transmission method as described in claim 4, or to implement the steps of the conference content transmission method as described in any one of claims 5 to 8.

Images