Call processing method, device and system

Abstract

An embodiment of the present application discloses a call processing method, device and system, which includes: a media server receives a call request, negotiates video media resources with a first terminal, and based on the negotiation result of the video media resource negotiation with the first terminal, sends a real-time transport protocol RTP stream to the first terminal, the RTP stream including a first RTP message of the first video media and a second RTP message of the second video media, the first RTP message including a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP message including an SSRC identifier of the RTP stream and an SSRC identifier of the second video media. Without splicing the first video media and the second video media in advance, the media server can instruct the first terminal to play the first video media and the second video media on the screen simultaneously through the RTP stream, which is conducive to saving computing resources required for video splicing.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a call processing method, device and system. Background Art

[0002] With the deployment of 4th-generation (4G) and 5th-generation (5G) wireless communication systems, wireless communication systems can provide high-definition voice and video calls, as well as customized media services such as video ringback tone and video ringback tone. With the increase in network bandwidth, users have new requirements for the video experience during mobile communications. For example, when playing video ringback tone or advertisements, multiple sub-screens can be displayed simultaneously, showing different video content, to increase the content content and expand user selection.

[0003] To enable multi-screen CRBT video playback, existing technology combines the called user's multiple sub-videos into a single video file during video source creation. After the calling user initiates a SIP call, the calling and called domains conduct media negotiation, achieving the same playback resolution as the spliced ​​video file. After media negotiation, the called domain's MRS encapsulates the spliced ​​video file into an RTP stream frame by frame and sends it to the calling user's terminal. The calling user's terminal receives the video media RTP packets, parses the video stream, and displays the spliced ​​video stream in the video playback window. This allows the calling user to view the video on multiple screens.

[0004] However, videos for the calling user to watch on multiple screens need to be spliced ​​and produced in advance. Splicing involves transcoding operations, and transcoding is a computationally intensive service. If there is a lot of video material, a large number of CPUs are required for parallel processing, resulting in high computing resource costs. Summary of the Invention

[0005] The embodiments of the present application provide a call processing method, device, and system, which enable the network to instruct the calling terminal or the called terminal to play the first video media and the second video media simultaneously on the screen without having to splice the first video media and the second video media in advance. This is beneficial to saving the computing resources required for video splicing and is conducive to the development of multi-screen video media playback services.

[0006] In the first aspect, an embodiment of the present application provides a call processing method, which includes the following contents. A media server receives a call request, wherein the call request is used by a calling terminal to initiate a call to a called terminal. Afterwards, the media server negotiates video media resources with the calling terminal or the called terminal. For ease of description, the embodiment of the present application refers to the negotiation object of the media server as the first terminal. After the media server and the first terminal complete the video media resource negotiation, the media server sends a real-time transport protocol RTP stream to the first terminal based on the negotiation result of the video media resource negotiation, and the RTP stream includes RTP messages of at least two video media. For ease of description, the embodiment of the present application is illustrated by taking the RTP stream including a first RTP message of the first video media and a second RTP message of the second video media as an example. The first RTP message includes a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP message includes an SSRC identifier of the RTP stream and an SSRC identifier of the second video media.

[0007] In the above method, after the first terminal receives the RTP stream, the SSRC identifier of the RTP stream indicates that the first RTP message and the second RTP message are RTP messages in the RTP stream, the SSRC identifier of the first video media indicates that the first RTP message is a message of the first video media, and the SSRC identifier of the second video media indicates that the second RTP message is a message of the second video media. The first terminal can then determine the first RTP message of the first video media from the RTP stream based on the SSRC identifier of the first video media, and determine the second RTP message of the second video media from the RTP stream based on the SSRC identifier of the second video media. After the first terminal parses and decodes the first RTP message, it can play the first video media; after the first terminal parses and decodes the second RTP message, it can play the second video media. Therefore, the network does not need to splice the first video media and the second video media in advance. By carrying the RTP messages of the first video media and the second video media in the same RTP stream, the first terminal is instructed to play the first video media and the second video media on the screen at the same time, which is conducive to saving the computing resources required for video splicing and is conducive to the development of multi-screen video media playback services.

[0008] In the prior art, the RTP stream only includes an RTP message of one video media, and the RTP message in the RTP stream only includes the SSRC identifier of the RTP stream; in the embodiment of the present application, the RTP stream includes the RTP message of at least two video media, and the RTP message in the RTP stream includes the SSRC identifier of the RTP stream and the SSRC identifier of the video media. In order to facilitate the distinction between the RTP stream involved in the embodiment of the present application and the existing RTP stream, the existing RTP stream is referred to as an RTP stream with a single SSRC identifier, and the RTP stream involved in the embodiment of the present application is referred to as an RTP stream with multiple SSRC identifiers. Supporting the sending or receiving of RTP streams with multiple SSRC identifiers, and / or supporting video media resource negotiation for RTP streams with multiple SSRC identifiers is referred to as supporting a multiple SSRC identifier mechanism.

[0009] In one possible design, the video media resource negotiation between the media server and the first terminal specifically includes the following contents. The media server sends an update message to the first terminal, and the update message indicates that the media server supports the multi-SSRC identification mechanism. Afterwards, the media server receives a response message from the first terminal. Optionally, the response message carries the negotiation result of the video media resource negotiation, which can also be called the media capability information of the first terminal. The response message indicates whether the first terminal supports the multi-SSRC identification mechanism, so that the media server can determine whether the first terminal supports the multi-SSRC identification mechanism based on the response message, thereby facilitating the media server to send the RTP stream with multiple SSRC identifications to the first terminal based on the first terminal supporting the multi-SSRC identification mechanism, thereby avoiding the failure of the first terminal to play multiple video media.

[0010] In one possible design, the update message carries media capability information of the media server (such as the SDP information of the media server). In one possible design, the update message includes first indication information, and the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media. The first terminal can determine the information of the RTP stream to be received based on the first indication information, such as the number of video media in the RTP stream and the SSRC identifier of each video media, so that the first terminal can determine the RTP message of each video media from the received RTP stream, thereby facilitating the first terminal to correctly play the first video media and the second video media according to the RTP stream.

[0011] In one possible design, the first indication information corresponds to the same video m line in the update message. By negotiating the first video media and the second video media in the same video m line of the update message, it can be compatible with the existing scenario of negotiating a single video media, which is easy to promote.

[0012] In one possible design, the first indication information also indicates the playback parameters of the first video media and the playback parameters of the second video media. After the first terminal receives the update message, it can determine the playback parameters of the first video media based on the SSRC identifier of the first video media. After the first terminal receives the RTP stream, it can determine the first RTP message of the first video media based on the SSRC identifier of the first video media. Afterwards, the first terminal can parse and decode the first RTP message, and play the first video media according to the playback parameters of the first video media. Similarly, after the first terminal receives the update message, it can determine the playback parameters of the second video media based on the SSRC identifier of the second video media. After the first terminal receives the RTP stream, it can determine the second RTP message of the second video media based on the SSRC identifier of the second video media. Afterwards, the first terminal can parse and decode the second RTP message, and play the second video media according to the playback parameters of the second video media.

[0013] The first indication information in the update message can transmit the playback parameters of each video media to the first terminal, so as to facilitate the control of the playback parameters of each video media on the first terminal, improve the richness of multi-video media playback, and enhance user experience.

[0014] In one possible design, the playback parameter of the first video media indicates the display position of the first video media on the first terminal.

[0015] In one possible design, the first RTP message also includes a first sequence identifier, which indicates the order of the first RTP message in the first video media, facilitating the first terminal to determine whether the first video media has been lost. Similarly, the second RTP message also includes a first sequence identifier, which indicates the order of the second RTP message in the second video media, facilitating the first terminal to determine whether the second video media has been lost.

[0016] In one possible design, after the media server sends the RTP stream to the first terminal, the media server receives a switching request from the first terminal, where the switching request is used to request switching of the first video media. Afterwards, the media server stops sending the first RTP message of the first video media to the first terminal, and sends a third RTP message of the third video media to the first terminal, where the third RTP message includes the SSRC identifier of the RTP stream and the SSRC identifier of the third video media. The SSRC identifier of the third video media is the same as the SSRC identifier of the first video media, so that the first terminal can continue to determine the third RTP message of the third video media from the RTP stream based on the SSRC identifier of the first video media, parse and decode it, and continue to play the third video media based on the playback parameters of the first video media, thereby switching the first video media to the third video media on the first terminal, increasing the user's selectivity of video media, and improving the user experience.

[0017] In a second aspect, embodiments of the present application provide a call processing method, which is applied to a calling terminal or a called terminal. For simplicity of description, the terminal to which the method is applied is referred to as a first terminal. The method comprises: if the first terminal is a calling terminal, the first terminal sends a call request to a media server. If the first terminal is a called terminal, the first terminal receives a call request from the media server. The call request is used by the calling terminal to initiate a call to the called terminal. The first terminal negotiates video media resources with the media server. After the first terminal and the media server complete the video media resource negotiation, based on the negotiation results, the first terminal receives an RTP stream from the media server. The RTP stream includes RTP packets for at least two video media. For ease of description, embodiments of the present application illustrate an RTP stream including a first RTP packet for a first video media and a second RTP packet for a second video media. The first RTP packet includes a synchronization source SSRC identifier for the RTP stream and an SSRC identifier for the first video media, and the second RTP packet includes the SSRC identifier for the RTP stream and an SSRC identifier for the second video media.

[0018] After the first terminal receives the RTP stream, it plays the first video media and the second video media respectively according to the RTP stream. For example, the first terminal determines that the first RTP message and the second RTP message are RTP messages in the RTP stream based on the SSRC identifier of the RTP stream. The first terminal determines the first RTP message of the first video media from the RTP stream based on the SSRC identifier of the first video media, parses and decodes the first RTP message, and then plays the first video media. The first terminal determines the second RTP message of the second video media from the RTP stream based on the SSRC identifier of the second video media, parses and decodes the second RTP message, and then plays the second video media.

[0019] In the above method, the network does not need to splice the first video media and the second video media in advance. By carrying the RTP messages of the first video media and the second video media in the same RTP stream, the first terminal can play the first video media and the second video media on the screen at the same time, which is conducive to saving the computing resources required for video splicing and is conducive to the development of multi-screen video media playback services.

[0020] In the prior art, the RTP stream only includes an RTP message of one video media, and the RTP message in the RTP stream only includes the SSRC identifier of the RTP stream; in the embodiment of the present application, the RTP stream includes the RTP message of at least two video media, and the RTP message in the RTP stream includes the SSRC identifier of the RTP stream and the SSRC identifier of the video media. In order to facilitate the distinction between the RTP stream involved in the embodiment of the present application and the existing RTP stream, the existing RTP stream is referred to as an RTP stream with a single SSRC identifier, and the RTP stream involved in the embodiment of the present application is referred to as an RTP stream with multiple SSRC identifiers. Supporting the sending or receiving of RTP streams with multiple SSRC identifiers, and / or supporting video media resource negotiation for RTP streams with multiple SSRC identifiers is referred to as supporting a multiple SSRC identifier mechanism.

[0021] In one possible design, the video media resource negotiation between the first terminal and the media server specifically includes the following contents. The first terminal receives an update message from the media server, and the update message indicates that the media server supports the multi-SSRC identification mechanism. Afterwards, the first terminal sends a response message to the media server. Optionally, the response message carries the negotiation result of the video media resource negotiation, which can also be called the media capability information of the first terminal, and also indicates that the first terminal supports the multi-SSRC identification mechanism, so that the media server can determine whether the first terminal supports the multi-SSRC identification mechanism based on the response message, thereby facilitating the media server to send the RTP stream with multiple SSRC identifications to the first terminal based on the first terminal supporting the multi-SSRC identification mechanism, thereby avoiding the failure of the first terminal to play multiple video media.

[0022] In one possible design, the update message carries media capability information of the media server, such as session description protocol (SDP) information of the media server. In one possible design, the update message includes first indication information, and the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media. On the premise that the first terminal supports a multi-SSRC identification mechanism, the first terminal is advantageously able to determine in advance information of the RTP stream to be received, such as the number of video media in the RTP stream and the SSRC identifier of each video media, based on the first indication information, so that the first terminal can determine the RTP message of each video media from the received RTP stream, thereby facilitating the first terminal to correctly play the first video media and the second video media according to the RTP stream.

[0023] In one possible design, the first indication information corresponds to the same video m line in the update message. By negotiating the first video media and the second video media in the same video m line of the update message, it can be compatible with the existing scenario of negotiating a single video media, which is easy to promote.

[0024] In one possible design, the first indication information also indicates the playback parameters of the first video media and the playback parameters of the second video media. The playback parameters of the first video media indicate the display position of the first video media on the first terminal. After the first terminal receives the update message, it can determine the playback parameters of the first video media based on the SSRC identifier of the first video media. After the first terminal receives the RTP stream, it can determine the first RTP message of the first video media based on the SSRC identifier of the first video media. Afterwards, the first terminal can parse and decode the first RTP message, and play the first video media according to the playback parameters of the first video media. Similarly, after the first terminal receives the update message, it can determine the playback parameters of the second video media based on the SSRC identifier of the second video media. After the first terminal receives the RTP stream, it can determine the second RTP message of the second video media based on the SSRC identifier of the second video media. Afterwards, the first terminal can parse and decode the second RTP message, and play the second video media according to the playback parameters of the second video media.

[0025] The first indication information in the update message can transmit the playback parameters of each video media to the first terminal, so as to facilitate the control of the playback parameters of each video media on the first terminal, improve the richness of multi-video media playback, and enhance user experience.

[0026] In one possible design, the playback parameters of the first video media are used to indicate the display position of the first video media on the first terminal.

[0027] In one possible design, the first RTP message also includes a first sequence identifier, which is used to indicate the order of the first RTP message in the first video media, facilitating the first terminal to determine whether the first video media has been lost. Similarly, the second RTP message also includes a first sequence identifier, which is used to indicate the order of the second RTP message in the second video media, facilitating the first terminal to determine whether the second video media has been lost.

[0028] In one possible design, after the first terminal plays the first video media and the second video media respectively according to the RTP stream, the first terminal sends a switching request to the media server, and the switching request is used to request switching of the first video media. Afterwards, the first terminal receives a third RTP message of the third video media from the media server, and the third RTP message includes the SSRC identifier of the RTP stream and the SSRC identifier of the third video media, and then plays the third video media according to the third RTP message. The SSRC identifier of the third video media is the same as the SSRC identifier of the first video media, which facilitates the first terminal to continue to determine the third RTP message of the third video media from the RTP stream according to the SSRC identifier of the first video media, and parse and decode it, and continue to play the third video media according to the playback parameters of the first video media, so as to switch the first video media to the third video media on the first terminal, increase the user's selectivity of video media, and improve the user experience.

[0029] In a third aspect, an embodiment of the present application provides a call processing method, including: a media resource server (MRS) receives a first playback request from an application server (AS), and then sends a real-time transport protocol RTP stream to a first terminal according to the first playback request, wherein the RTP stream includes a first RTP message of a first video media and a second RTP message of a second video media, the first RTP message includes a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP message includes an SSRC identifier of the RTP stream and an SSRC identifier of the second video media.

[0030] In the above method, the network does not need to splice the first video media and the second video media in advance. By carrying the RTP messages of the first video media and the second video media in the same RTP stream, the first terminal is instructed to play the first video media and the second video media on the screen. This is beneficial to saving the computing resources required for video splicing and is beneficial to the development of multi-screen video media playback services.

[0031] In one possible design, before the MRS receives the first play request from the AS, the MRS negotiates video media resources with the first terminal through the AS. The MRS sends a real-time transport protocol (RTP) stream to the first terminal based on the first play request, including: the MRS sends the RTP stream to the first terminal based on a negotiation result of the video media resource negotiation and the first play request.

[0032] In a possible design, the video media resource negotiation between the MRS and the first terminal through the AS specifically includes the following contents. The MRS sends an update message to the first terminal through the AS, and the update message indicates that the MRS and / or the AS supports the multiple SSRC identification mechanism. Afterwards, the MRS receives a response message from the first terminal through the AS, and the response message indicates that the first terminal supports the multiple SSRC identification mechanism. This facilitates the MRS to send the RTP stream with multiple SSRC identifiers to the first terminal based on the fact that the first terminal supports the multiple SSRC identification mechanism, thereby avoiding the failure of video media playback due to the MRS sending the RTP stream with multiple SSRC identifiers to the first terminal when the first terminal does not support the multiple SSRC identification mechanism. Optionally, the update message carries the media capability information of the MRS; the response message carries the negotiation result of the video media resource negotiation, which can also be called the media capability information of the first terminal.

[0033] In one possible design, before the MRS negotiates video media resources with the first terminal through the AS, the MRS receives a request message from the AS. The request message is sent by the AS in response to a received call request, where the calling terminal initiates a call to the called terminal. The request message indicates that the calling user or the called user has subscribed to the multi-video media playback service. As an optional method, the request message specifically instructs the MRS to use a multi-SSRC mechanism to negotiate video media resources with the first terminal.

[0034] In one possible design, the update message carries the media capability information of the MRS (such as the SDP information of the MRS). In one possible design, the update message includes first indication information, and the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media. Thus, the first terminal determines the information of the RTP stream to be received based on the first indication information, such as the number of video media in the RTP stream and the SSRC identifier of each video media, so that the first terminal can determine the RTP message of each video media from the received RTP stream, thereby facilitating the first terminal to correctly play the first video media and the second video media according to the RTP stream.

[0035] In one possible design, the first indication information corresponds to the same video m line in the update message. By negotiating the first video media and the second video media in the same video m line of the update message, it can be compatible with the existing scenario of negotiating a single video media, which is easy to promote.

[0036] In one possible design, the first indication information also indicates the playback parameters of the first video media and the playback parameters of the second video media. After the first terminal receives the update message, it can determine the playback parameters of the first video media based on the SSRC identifier of the first video media. After the first terminal receives the RTP stream, it can determine the first RTP message of the first video media based on the SSRC identifier of the first video media. Afterwards, the first terminal can parse and decode the first RTP message, and play the first video media according to the playback parameters of the first video media. Similarly, after the first terminal receives the update message, it can determine the playback parameters of the second video media based on the SSRC identifier of the second video media. After the first terminal receives the RTP stream, it can determine the second RTP message of the second video media based on the SSRC identifier of the second video media. Afterwards, the first terminal can parse and decode the second RTP message, and play the second video media according to the playback parameters of the second video media.

[0037] The first indication information in the update message can transmit the playback parameters of each video media to the first terminal, so as to facilitate the control of the playback parameters of each video media on the first terminal, improve the richness of multi-video media playback, and enhance user experience.

[0038] In one possible design, the playback parameters of the first video media are used to indicate the display position of the first video media on the first terminal.

[0039] In one possible design, the first RTP message also includes a first sequence identifier, which is used to indicate the order of the first RTP message in the first video media, facilitating the first terminal to determine whether the first video media has been lost. Similarly, the second RTP message also includes a first sequence identifier, which is used to indicate the order of the second RTP message in the second video media, facilitating the first terminal to determine whether the second video media has been lost.

[0040] In one possible design, after the MRS sends the RTP stream to the first terminal, the MRS receives a stop play request and a second play request from the AS. The stop play request instructs to stop playing the first video media, and the second play request instructs to play the third video media. The stop play request and the second play request can be the same message or two different messages. Furthermore, the MRS stops sending the first RTP message of the first video media to the first terminal based on the stop play request, and sends the third RTP message of the third video media to the first terminal based on the second play request. The third RTP message includes the SSRC identifier of the RTP stream and the SSRC identifier of the third video media. The SSRC identifier of the third video media is the same as the SSRC identifier of the first video media, which facilitates the first terminal to continue to determine the third RTP message of the third video media from the RTP stream based on the SSRC identifier of the first video media, parse and decode it, and continue to play the third video media based on the playback parameters of the first video media, thereby switching the first video media to the third video media on the first terminal, increasing the user's selectivity of video media, and improving the user experience.

[0041] In a fourth aspect, embodiments of the present application provide a media server having the functionality to implement any one of the methods of the first aspect. This functionality can be implemented via hardware, or by hardware executing corresponding software implementations. The hardware or software includes one or more units corresponding to the aforementioned functionality, such as a storage unit, a sending unit, a receiving unit, or a processing unit.

[0042] In one possible design, the structure of the media server includes at least one processor and memory, the memory storing program code, and the processor calling the program code to execute some or all of the steps of any method of the first aspect. The media server may also include a communication interface for communicating with other devices.

[0043] In a fifth aspect, an embodiment of the present application provides a terminal having the function of implementing any one of the methods of the second aspect. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the above functions, such as a storage unit, a sending unit, a receiving unit, or a processing unit.

[0044] In one possible design, the terminal structure includes at least one processor and memory, the memory storing program code, and the processor calling the program code to execute some or all steps of any method of the second aspect. The terminal may also include a communication interface for communicating with other devices.

[0045] In a sixth aspect, an embodiment of the present application provides a media resource server (MRS) having the function of implementing any one of the methods of the third aspect. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the above functions, such as a storage unit, a sending unit, a receiving unit, or a processing unit.

[0046] In one possible design, the structure of the MRS includes at least one processor and a memory, wherein the memory stores program code, and the processor calls the program code to execute some or all steps of any method of the fourth aspect. The terminal may also include a communication interface for communicating with other devices.

[0047] In the seventh aspect, an embodiment of the present application provides a call processing system, including the media server of the fourth aspect and the terminal of the fifth aspect, which will not be repeated here.

[0048] In an eighth aspect, an embodiment of the present application provides a call processing system, comprising the terminal of the fifth aspect and the media resource server (MRS) of the sixth aspect, which will not be described in detail here. The system also includes an application server AS.

[0049] In a ninth aspect, an embodiment of the present application provides a computer storage medium storing a program code, wherein the program code includes instructions for executing part or all of the steps of any method of the first aspect, the second aspect, or the third aspect.

[0050] In the tenth aspect, an embodiment of the present application provides a computer program product, which, when executed on a computer, enables the computer to execute part or all of the steps of any method of the first aspect, the second aspect, or the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a system architecture diagram of an embodiment of the present application applied in a VoLTE network;

[0052] Figure 2 This is a schematic flow chart of a possible embodiment of the call processing method of the present application;

[0053] Figure 3A is a schematic flow chart of another possible embodiment of the call processing method of the present application;

[0054] Figure 3B This is a schematic diagram of the interface for the calling terminal to play the RTP stream;

[0055] Figure 3CThis is a schematic diagram of the interface of the calling terminal playing the RTP stream after switching;

[0056] Figure 4 is a schematic flow chart of another possible embodiment of the call processing method of the present application;

[0057] Figure 5 is a schematic flow chart of another possible embodiment of the call processing method of the present application;

[0058] Figure 6 This is a schematic diagram of a possible embodiment of the media server of the present application;

[0059] Figure 7 This is a schematic diagram of a possible embodiment of the terminal of the present application;

[0060] Figure 8 This is a schematic diagram of a possible embodiment of the MRS of the present application;

[0061] Figure 9 This is a schematic diagram of a possible embodiment of the computer device of the present application. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solutions and beneficial effects of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0063] The embodiments of the present application can be applied to the 4th generation (4G), 5th generation (5G) mobile communication network architecture or future networks. For ease of description, the system architecture and method flow of the solution are described below using the 4G network architecture as an example.

[0064] like Figure 1 As shown, this is a system architecture diagram of an embodiment of the present application applied in a VoLTE network, which includes: a calling terminal, a called terminal, a wireless access network, and Internet Protocol (IP) Multimedia Subsystem (IMS) domain networks on the calling side and the called side.

[0065] The IMS domain on the calling and called sides may include the IMS domain core network and the Evolved Packet Core (EPC). The IMS domain core network includes: serving-call session control function (S-CSCF), interrogating-call session control function (I-CSCF), proxy-call session control function (P-CSCF), home subscriber server (HSS), session border controller (SBC), etc. The I-CSCF and S-CSCF can be combined and can be referred to as "I / S-CSCF". The SBC and P-CSCF can be combined and can be referred to as "SBC / P-CSCF". The EPC may include a packet data network gateway (PGW), a serving gateway (SGW), and a mobile management entity (MME). The PGW and SGW can be combined and can be referred to as "S / P-GW".

[0066] The aforementioned network elements are all corresponding network elements in wireless communication networks in the prior art and will not be described in detail here, but only briefly explained. For example, the S-CSCF can be used for user registration, authentication control, session routing, service triggering control, and maintaining session state information. The I-CSCF can be used to assign and query the S-CSCF for user registration. The P-CSCF can be used for signaling and message proxying. The HSS can be used to store user subscription information and location information. The SBC can provide secure access and media processing. The MME is the core device of the EPC network. The SGW can be used to connect the IMS core network to the wireless network, and the PGW can be used to connect the IMS core network to the IP network.

[0067] The calling and called IMS domain core networks also include media servers. These servers provide video playback for the calling and / or called user. These media servers can include application servers (ASs) and media resource servers (MRSs). The ASs and MRSs can be co-located or deployed on separate physical devices. The ASs process signaling messages, while the MRSs provide video streams and video streams for the calling and / or called user.

[0068] The media server can specifically be a color ring back tone (CRB) server, which provides video media playback for the calling user. The CRB server can include a customized alerting tone (CAT) AS and MRS. The media server can also specifically be a color ring back tone (CRT) server, which provides video media playback for the called user. The CRT server can include a customized alerting signal (CRS) AS and MRS. Furthermore, the media server can provide video media playback for both the calling user and the called user, such as a combined CRB and CRT server serving as the media server.

[0069] Calling and called terminals are devices with wireless transceiver capabilities and can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; on water (such as ships); or in the air (such as airplanes, balloons, and satellites). Specifically, terminal devices can be terminal devices that can access mobile networks, mobile phones, tablets, computers with wireless transceiver capabilities, virtual reality (VR) terminals, augmented reality (AR) terminals, wireless terminals in industrial control, wireless terminals in self-driving cars, wireless terminals in remote medical care, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, and so on.

[0070] It should be noted that the above description does not constitute a limitation on the system architecture of the embodiment of the present application. The system architecture of the embodiment of the present application includes but is not limited to Figure 1 shown.

[0071] As an optional manner, the media server may not be located in the IMS domain core network of the calling party or the called party, but may be independent of the IMS domain core network of the calling party and the called party.

[0072] As an optional approach, the embodiment of the present application can also be a scenario of a user of a VoLTE network and a user of another network (such as an IMS network, a fixed network, a switched network, etc.). For example, in the embodiment of the present application, the calling or called user is a VoLTE user, and the opposite user is a user of another network.

[0073] The solution of the present application is described below in conjunction with specific embodiments. To simplify the description and facilitate understanding, some network elements through which signaling exchanges pass are not shown in the figure, such as S / P-GW, SBC / P-CSCF, I / S-CSCF, etc.

[0074] Figure 2 This is a schematic flow chart of a possible embodiment of the call processing method of the present application. The method can be applied to Figure 1 The system shown can also be applied to other communication scenarios, and the embodiment of the present application is not limited here. The media server in the embodiment of the present application can be in the calling domain or the called domain; the first terminal can refer to the calling terminal or the called terminal. Figure 2 The specific steps of the corresponding call processing method embodiment.

[0075] 201. A media server receives a call request from a first terminal, or forwards the call request to the first terminal.

[0076] The calling terminal initiates a call to the called terminal, which may be a video call or an audio call. The call request for initiating the call is, for example, an INVITE message.

[0077] The call request includes the Session Description Protocol (SDP) information of the calling terminal, including but not limited to the call type, media types and codecs supported by the calling party, etc. The call request is used for the calling terminal and the called terminal to negotiate the call media.

[0078] After the calling terminal sends a call request, the media server can receive the call request from the calling terminal and forward the call request to the called terminal. Figure 2 In the corresponding embodiment, the first terminal may refer to a calling terminal or a called terminal. When the first terminal refers to a calling terminal, step 201 specifically refers to the media server receiving a call request sent by the first terminal; when the first terminal refers to a called terminal, step 201 specifically refers to the media server forwarding the received call request to the first terminal.

[0079] 202. The media server negotiates video media resources with the first terminal.

[0080] The media server negotiates video media resources with the first terminal. The negotiation results of the video media resource negotiation include but are not limited to information such as the negotiated IP address, media format, port number, media transmission type and / or audio and video media encoding method. The negotiation result indicates the method by which the media server sends the RTP stream.

[0081] Regarding possible specific implementations of step 202, examples will be given below using steps 2021 and 2022.

[0082] 203. The media server sends the RTP stream to the first terminal.

[0083] Based on the negotiation results of the video media resource negotiation, the media server sends an RTP stream to the first terminal. The source IP address, source port, destination IP address, destination port, and transport layer protocol of any two RTP packets in the RTP stream are identical. It should be understood that information such as the IP address and port of the RTP stream is determined based on the negotiation results of the video media resource negotiation in step 202.

[0084] The RTP stream includes RTP packets of at least two video media. Exemplarily, the video media refers to a video ringback tone or a video advertisement, and the multiple video media may include a video ringback tone and / or a video advertisement, etc. For ease of description, the embodiment of the present application is illustrated by taking the example that the RTP stream includes a first RTP packet of a first video media and a second RTP packet of a second video media. The first RTP packet includes an SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP packet includes an SSRC identifier of the RTP stream and an SSRC identifier of the second video media.

[0085] The existing RTP message includes an SSRC identifier, namely, the SSRC identifier of the RTP stream. Therefore, the SSRC identifier of the RTP stream in the RTP message involved in the embodiment of the present application can be referred to as the SSRC identifier of the RTP message or the original SSRC identifier, and the SSRC identifier of the newly added video media can be referred to as the sub-SSRC identifier of the RTP message or the newly added SSRC identifier. For example, the SSRC identifier of the first video media is referred to as the sub-SSRC identifier of the first RTP message, and the SSRC identifier of the second video media is referred to as the sub-SSRC identifier of the second RTP message. For example, assume that the RTP stream includes the following messages: RTP1-a, RTP2-b, RTP2-c and RTP1-d, wherein the SSRC identifiers of RTP1-a, RTP2-b, RTP2-c and RTP1-d are the same, which are all SSRC identifiers of the RTP stream; the sub-SSRC identifiers of RTP1-a and RTP1-d are the same, which are both SSRC identifiers of the first video media; the sub-SSRC identifiers of RTP2-b and RTP2-c are the same, which are both SSRC identifiers of the second video media.

[0086] 204. The first terminal plays the first video media and the second video media respectively according to the RTP stream.

[0087] After receiving the RTP streams of the multiple video media, the first terminal plays the first video media and the second video media respectively according to the RTP streams.

[0088] As an optional method, the first terminal determines that the first RTP message and the second RTP message are RTP messages in the RTP stream based on the SSRC identifier of the RTP stream. The SSRC identifier of the first video media is different from the SSRC identifier of the second video media. The first terminal determines that the first RTP message corresponds to the first video media based on the SSRC identifier of the first video media in the first RTP message, and determines that the second RTP message corresponds to the second video media based on the SSRC identifier of the second video media in the second RTP message. Specifically, the first terminal determines the first RTP message of the first video media from the RTP stream based on the SSRC identifier of the first video media, and after parsing and decoding the first RTP message, the first video media can be played. The first terminal determines the second RTP message of the second video media from the RTP stream based on the SSRC identifier of the second video media, and after parsing and decoding the second RTP message, the second video media can be played. Thus, the user of the first terminal can watch the first video media and the second video at the same time through the first terminal.

[0089] In one possible implementation, the first RTP message also includes a first sequence identifier, and the first sequence identifier of the first RTP message indicates the order of the first RTP message in the first video media. After the first terminal identifies multiple RTP messages of the first video media according to the SSRC identifier of the first video media, it can determine whether the first video media has been lost according to the first sequence identifier of each RTP message in the multiple RTP messages, and can sort each RTP message in the multiple RTP messages. Similarly, the second RTP message also includes a first sequence identifier, and the first sequence identifier of the second RTP message indicates the order of the second RTP message in the second video media. After the first terminal identifies multiple RTP messages of the second video media according to the SSRC identifier of the second video media, it can determine whether the second video media has been lost according to the first sequence identifier of each RTP message in the multiple RTP messages, and can sort each RTP message in the multiple RTP messages.

[0090] In one possible implementation, the first RTP message further includes a second sequence identifier, and the second sequence identifier of the first RTP message indicates the order of the first RTP message in the RTP stream. Similarly, the second RTP message further includes a second sequence identifier, and the second sequence identifier of the second RTP message indicates the order of the second RTP message in the RTP stream. The first terminal determines whether the RTP stream has packet loss based on the second sequence identifier of each RTP message in the RTP stream.

[0091] Existing RTP messages generally include a sequence identifier, namely the above-mentioned second sequence identifier. The first sequence identifier is a sequence identifier newly added to the RTP message in the embodiment of the present application. Therefore, the second sequence identifier in the RTP message can also be referred to as the sequence identifier or original sequence identifier of the RTP message, etc., and the first sequence identifier in the RTP message can be referred to as the sub-sequence identifier or newly added sequence identifier of the RTP message, etc. For example, based on the above example, it is assumed that the RTP messages in the RTP stream are, in the order of sending, RTP1-a, RTP2-b, RTP2-c, and RTP1-d, wherein the second sequence identifiers (or sequence identifiers) of RTP1-a, RTP2-b, RTP2-c, and RTP1-d are 1, 2, 3, and 4, respectively, and the first sequence identifiers (or sub-sequence identifiers) of RTP1-a, RTP2-b, RTP2-c, and RTP1-d are 1, 1, 2, and 2, respectively.

[0092] In an embodiment of the present application, the network does not need to splice the first video media and the second video media in advance, and the first terminal can play the first video media and the second video media simultaneously on the screen according to the RTP stream, which is conducive to saving the computing resources required for video splicing, and is conducive to the development of multi-screen video media playback services.

[0093] Furthermore, since the embodiment of the present application carries the first RTP message of the first video media and the second RTP message of the second video media through one RTP stream, and the receiving port of the same RTP stream is the same, the embodiment of the present application transmits at least two video media through one RTP stream, which is beneficial to reducing the processing complexity of video transmission and saving port resources.

[0094] An existing single RTP stream corresponds to a single video media, and the RTP message in the single RTP stream includes only one SSRC identifier, and the SSRC identifier of each RTP message is the same. However, the single RTP stream involved in the embodiments of the present application corresponds to multiple video media, and the RTP message in the single RTP stream includes two SSRC identifiers. The SSRC identifier of the RTP stream can be understood with reference to the SSRC identifier in the existing RTP stream; the SSRC identifier of the video media is used to indicate the video media corresponding to the RTP message. And because a single RTP stream corresponds to multiple video media (for example, n video media), the single RTP stream includes the SSRC identifiers of multiple video media (for example, the SSRC identifiers of n video media). For ease of distinction, the existing RTP stream is referred to as an RTP stream with a single SSRC identifier, and the RTP stream involved in the embodiments of the present application is referred to as an RTP stream with multiple SSRC identifiers. Supporting the sending or receiving of RTP streams with multiple SSRC identifiers, and / or supporting video media resource negotiation for RTP streams with multiple SSRC identifiers is referred to as supporting a multiple SSRC identifier mechanism.

[0095] In the above step 202, the media server negotiates the video media resource with the first terminal. As an optional method, the media server can negotiate with the first terminal whether to support the multi-SSRC identification mechanism during this process. Figure 2 , step 202 specifically includes step 2021 and step 2022.

[0096] 2021. The media server sends an update message to the first terminal.

[0097] After receiving the call request, the media server sends an update message to the first terminal. The update message carries the media capability information of the media server (such as the SDP information of the media server). The update message also indicates that the media server supports the multiple SSRC identification mechanism.

[0098] 2022. The first terminal sends a response message to the media server.

[0099] After receiving the update message, the first terminal determines the negotiation result of the video media resource negotiation based on the media server's media capability information carried in the update message and its own capabilities. It should be understood that the negotiation result of the video media resource negotiation can also be referred to as the first terminal's media capability information. Consequently, the first terminal sends a response message to the media server, which carries the negotiation result of the video media resource negotiation.

[0100] Optionally, the response message indicates that the first terminal supports a multiple SSRC identification mechanism, so that the media server can determine that the first terminal supports the multiple SSRC identification mechanism based on the response message, thereby facilitating the media server to further send an RTP stream with multiple SSRC identifications to the first terminal.

[0101] Exemplarily, the update message includes a field "multi-pack-mode = 1," which indicates that the media server supports the multiple SSRC identification mechanism, so that the first terminal determines that the media server supports the multiple SSRC identification mechanism based on this field. If the first terminal supports the multiple SSRC identification mechanism, the response message includes a field "multi-pack-mode = 1," which indicates that the first terminal supports the multiple SSRC identification mechanism. After receiving the response message, the media server determines that the first terminal supports the multiple SSRC identification mechanism based on this field in the response message, and further executes step 203 to send an RTP stream with multiple SSRC identifications to the first terminal.

[0102] If the first terminal does not support the multi-SSRC identification mechanism, the response message indicates that the first terminal does not support the multi-SSRC identification mechanism. Exemplarily, the response message includes "multi-pack-mode = 0" or does not include the relevant field of "multi-pack-mode". To avoid playback errors or inability to play after the first terminal receives the RTP streams of multiple video media, the media server does not perform step 203 based on "multi-pack-mode = 0" in the response message. As an optional method, the media server sends the RTP stream encapsulated according to the single SSRC identification mechanism to the first terminal based on the response message, for example, sending the RTP stream of the first video media.

[0103] It can be seen that the method of the embodiment of the present application facilitates the media server to determine whether the first terminal supports the multi-SSRC identification mechanism based on the response message by executing steps 2021 and 2022, thereby facilitating the media server to send the RTP stream with multiple SSRC identifiers to the first terminal based on the first terminal supporting the multi-SSRC identification mechanism, thereby avoiding the failure of the first terminal to play multiple video media, which is beneficial to improving the success rate of playing multiple video media and improving the user experience.

[0104] Furthermore, as an optional method, the SDP information carried in the update message involved in step 2021 includes first indication information, where the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media. If the first terminal supports a multiple SSRC identifier mechanism, the first terminal can determine information about the RTP stream to be received, such as the number of video media in the RTP stream and the SSRC identifier of each video media, based on the first indication information. This facilitates the first terminal to determine the RTP message of each video media from the received RTP stream in step 204, thereby facilitating the first terminal to correctly play the first video media and the second video media based on the RTP stream.

[0105] Optionally, the first indication information also indicates the playback parameters of the first video media and the playback parameters of the second video media. The playback parameters of the first video media indicate the display position of the first video media on the first terminal. After receiving the update message, the first terminal can determine the corresponding playback parameters of the first video media based on the SSRC identifier of the first video media. After receiving the RTP stream, the first terminal can determine the first RTP message of the first video media based on the SSRC identifier of the first video media. Thereafter, the first terminal can parse and decode the first RTP message and play the first video media according to the playback parameters of the first video media. Similarly, after receiving the update message, the first terminal can determine the corresponding playback parameters of the second video media based on the SSRC identifier of the second video media. After receiving the RTP stream, the first terminal can determine the second RTP message of the second video media based on the SSRC identifier of the second video media. Thereafter, the first terminal can parse and decode the second RTP message and play the second video media according to the playback parameters of the second video media. In one possible design, the playback parameters of the first video media are used to indicate the display position of the first video media on the first terminal.

[0106] The first indication information in the update message can transmit the playback parameters of each video media to the first terminal, thereby facilitating control of the playback parameters of each video media on the first terminal, improving the richness and flexibility of multi-video media playback, and enhancing user experience.

[0107] As an optional manner, the first indication information corresponds to the same video m line in the SDP information.

[0108] As an optional method, the first indication information is also used to indicate that the media server supports a multiple SSRC identification mechanism. Exemplarily, the SDP information carried by the update message includes the following content:

[0109] m=audio 20100RTP / AVP 120

[0110] a=rtpmap:120amr_wb / 16000

[0111] m=video 20102RTP / AVP 97

[0112] a=rtpmap:97H264 / 90000

[0113] a=fmtp:97profile_level_id=42C01E

[0114] a=multi_SSRC:12345showmode=2*1location=1:1

[0115] a=multi_SSRC:12346showmode=2*1location=2:1.

[0116] Among them, "m=audio 20100RTP / AVP 120" is the audio line m, "m=audio 20100RTP / AVP 120" is the video line m, "a=rtpmap:120amr_wb / 16000" corresponds to the audio line m "m=audio 20100RTP / AVP120", and the content after "m=video 20102RTP / AVP 97" corresponds to the same video line m, that is, both correspond to "m=audio 20100RTP / AVP 120".

[0117] The first indication information includes: "a=multi_SSRC:12345showmode=2*1location=1:1; a=multi_SSRC:12346showmode=2*1location=2:1". After receiving the update message, the first terminal determines the information of the RTP stream with multiple SSRC identifiers to be sent according to the first indication information. Specifically, the RTP stream carries RTP packets of two video media, and the first terminal plays these two video media respectively in two different upper and lower windows in the same column on the screen. The SSRC identifier of one of the two video media (called video media 1) is 12345, and the first terminal plays video media 1 in the upper window; the SSRC identifier of the other video media (called video media 2) is 12346, and the first terminal needs to play video media 2 in the lower window.

[0118] As an optional manner, the SDP information also includes "multi-pack-mode=1." For example, this field is located after "m=video 20102RTP / AVP 97," corresponding to the video m line, indicating that the media server supports the multiple SSRC identification mechanism. The first terminal determines that the media server supports the multiple SSRC identification mechanism based on "multi-pack-mode=1" in the SDP information.

[0119] The video media resource negotiation process was introduced above. Based on the existing SDP negotiation framework, the SDP content is expanded. By negotiating multiple video media in the same video m-line, it can be compatible with the existing scenario of negotiating a single video media. From the negotiation perspective, the extension mechanism adopted by this application is simple and effective. If multiple video m-lines are negotiated, the network elements that transmit SDP information need to be upgraded to support multiple video m-line negotiations. Compared with the solution provided by the embodiment of this application and the negotiation through multiple video m-lines, the SDP scale used in the video media resource negotiation process is small, and the negotiation process only involves the modification of the media server and the first terminal, and the other network elements are transparently transmitted, which is simple to implement and requires less modification of the network elements.

[0120] To improve user flexibility in viewing video ringback rings, based on the aforementioned solution, this application provides a video media switching solution. This solution allows users to switch between video media playback options while viewing multiple video ringback rings on a first terminal. As an optional method, after step 204, steps 205 through 207 are also included.

[0121] 205. The first terminal sends a switching request to the media server.

[0122] While a user of a first terminal is watching multiple video media being played on the first terminal, they can trigger the first terminal to switch to a certain video media by operating the first terminal. For example, they can trigger the first terminal to switch to the first video media by clicking on the display location of the first video media on the screen or sliding on the display location of the first video media on the screen. After detecting the above operation by the user, the first terminal sends a request to the media server to switch to the first video media. The switching request indicates switching to the first video media and can carry information about the first video media, such as the SSRC identifier and / or playback parameters of the first video media.

[0123] 206. The media server sends a third RTP packet of the third video media to the first terminal.

[0124] After receiving the switching request for the first video media, the media server determines the SSRC identifier of the first video media, stops sending the first RTP message of the first video media, and sends a third RTP message of the third video media to the first terminal, wherein the third RTP message includes the SSRC identifier of the RTP stream and the SSRC identifier of the third video media, and the SSRC identifier of the third video media is the same as the SSRC identifier of the first video media.

[0125] 207. The first terminal plays the third video media according to the third RTP message.

[0126] After receiving the RTP stream, the first terminal determines the third RTP message of the third video media from the RTP stream based on the SSRC identifier of the third video media. After parsing and decoding the third RTP message, the third video media frame is obtained, and the third video media is played. Because the SSRC identifier of the third video media is the same as the SSRC identifier of the first video media, the first terminal can play the third video media according to the playback parameters of the first video media. For example, the third video media is played in the upper window of the first terminal.

[0127] Figure 3A It is a schematic flow chart of another possible embodiment of the call processing method of the present application. Figure 3A The method of the present application is described with exemplary signaling. Figure 3A The method shown is Figure 2 An example of the method shown, thus Figure 3A Some explanation of the methods shown can be found in Figure 2 The following takes the video media as an example to introduce the method of video ringback tone. Figure 3A The specific steps of the corresponding call processing method embodiment.

[0128] 301-302. The calling terminal sends a call request (SDPo1) to the called terminal.

[0129] Specifically, the media server receives the call request sent by the calling terminal, and forwards the call request to the called terminal.

[0130] The call request carries the SDP information of the calling terminal (such as SDPo1), which is used for the calling terminal and the called terminal to negotiate the call media. The call request is specifically an INVITE message.

[0131] 303-304. The called terminal sends a call response (SDPa1) to the calling terminal.

[0132] Specifically, the media server receives the call response sent by the called terminal, and forwards the call response to the calling terminal.

[0133] The call response carries the SDP negotiation result (such as SDPa1) between the called terminal and the calling terminal, which can also be called the SDP information of the called terminal. The SDP information is used by the called terminal and the calling terminal to negotiate the call media.

[0134] Specifically, the call response may be a 183 message, indicating that the called terminal has received the call request.

[0135] If the call media negotiation adopts a resource reservation mechanism, steps 305 to 308 are also included. It should be understood that if the call media negotiation does not adopt a resource reservation mechanism, steps 305 to 308 may not be included.

[0136] 305-306. The calling terminal sends UPDATE (SDPo2) to the called terminal.

[0137] Specifically, the media server receives the update message sent by the calling terminal, and forwards the update message to the called terminal.

[0138] The update message carries the SDP information of the calling terminal (such as SDPo2), indicating that the calling terminal has completed resource reservation. For example, the update message is UPDATE (SDPo2).

[0139] 307-308. The called terminal sends 200 ok (SDPa2) to the calling terminal.

[0140] Specifically, the media server receives the 200 ok (SDPa2) message sent by the called terminal and forwards it to the calling terminal. The 200 ok message indicates that the called terminal has completed resource reservation.

[0141] 309. The called terminal sends a 180 (ALERTING) message to the media server.

[0142] Among them, 180 (ALERTING) is a ringing message, indicating that the called terminal is ringing.

[0143] 310. The media server sends an UPDATE (SDPo3) to the calling terminal.

[0144] The update message (UPDATE(SDPo3)) carries the media server's SDP information (SDPo3), which is used to negotiate video media resources between the media server and the calling terminal. This update message indicates that the media server supports the multiple SSRC identifier mechanism. The SDPo3 includes first indication information, which indicates the SSRC identifiers of multiple video ringback tone (RBT). For details about the update message (UPDATE(SDPo3)), see step 2021. Assume that the first indication information indicates that the SSRC identifier for video ringback tone 1 is "12345" and the SSRC identifier for video ringback tone 2 is "12346."

[0145] 311. The calling terminal sends a 200 (SDPa3) message to the media server.

[0146] The response message (200(SDPa3)) carries the calling terminal's SDP information (SDPo3), i.e., the result of the video media resource negotiation between the calling terminal and the media server. The response message also indicates that the calling terminal supports the multi-SSRC identification mechanism. For an explanation of the response message (200(SDPa3)), see step 2022. Exemplarily, the SDPa3 includes the field "multi-pack-mode = 1."

[0147] 312. The media server sends a 180 (ALERTING) message to the calling terminal through the I / S-CSCF.

[0148] The 180 message is a ringing message, indicating that the called terminal is ringing.

[0149] 313. The media server sends the RTP stream to the calling terminal.

[0150] The media server starts playing the video ring back tone, encapsulates the video frames of the multiple video ring back tone into an RTP stream, and sends the RTP stream to the calling terminal. For details, refer to step 203.

[0151] The embodiment of the present application is described by taking the example of playing a video after receiving a ringing message. It should be understood that the present application is also applicable to other scenarios such as opening in seconds, for example, step 313 is executed before step 312.

[0152] As an optional method, the video ring back tone in the RTP message is identified by using an RTP extension header in the RTP message. Exemplarily, the RTP message header of the RTP message in the RTP stream includes the content shown in Table 1.

[0153] Table 1

[0154]

[0155] The following describes the meaning of each field in the RTP message header.

[0156] "V" indicates the version number of the RTP protocol, and the length of this field is 2 bits (bit). "P" refers to the padding bit, and the length of this field is 1 bit. Generally, there is no padding, that is, generally P = 0. "X" refers to the extension bit, and the length of this field is 1 bit. If there is an extension header before the payload in the RTP message, then this field is set to 1. In the embodiment of the present application, the RTP message has an extension header before the payload, so this field is set to 1. "CC" is the counter of special cells (CSRC count), which indicates the number of CSCR identifiers. The length of this field is 4 bits. "M" refers to the flag bit, and the length of this field is 1 bit. If the current message is the last message of the video frame, then M = 1, and in other cases M = 0. "PT" refers to the payload type (payload type), and the length of this field is 7 bits, which is used to indicate the codec type. "Sequence number" refers to the sequence number of the current message. The length of this field is 16 bits. The value of this field increases by 1 each time a message is sent. The receiver can not only use this sequence number to detect message loss, but also to sort messages. Figure 2 The second sequence identifier of the first RTP message in the corresponding embodiment is understood. "Timestamp" indicates the sampling time of the first sampling point of the audio and video frame. The length of this field is 32 bits. "SSRC identifier" refers to the RTP stream synchronization source identifier, which is used to identify an RTP stream. The length of this field is 32 bits. "SSRC identifier" can be referred to Figure 2 The corresponding embodiment is understood as the SSRC identifier of the RTP stream. "CSRC list" identifies all sources that contribute to the payload in the current message.

[0157] The following describes the contents of the RTP extension header of the RTP message in the RTP stream, which is exemplified as shown in Table 2 below.

[0158] Table 2

[0159]

[0160] The following describes the meaning of each field in the RTP extension header.

[0161] "Defined of profile" is used to identify the extension header. The length of this field is 16 bits. "Length" refers to the length of the extension header. The length of this field is 16 bits. "P", "M", "PT", and "Reserve" have the same meanings as the corresponding fields in Table 1 and are not repeated here. "Sub-Sequence number" is the sub-sequence number, which refers to the sequence number of the current message in the video media. The length of this field is 16 bits. The sub-sequence number of each video media is counted separately. Figure 2The first sequence identifier in the corresponding embodiment can be understood. "Sub-Timestamp" represents the timestamp information of the RTP message. Its meaning can be understood by referring to "Timestamp" in Table 1. The length of this field is 32 bits. "Sub-SSRC identifier" refers to the synchronization source identifier of the video media, which is used to uniquely identify the video media. The length of this field is 32 bits. The video media to which the message belongs can be determined by this value. "Sub-SSRC identifier" can be referred to Figure 2 In the corresponding embodiment, the SSRC identifier of the video media (such as the SSRC identifier of the first video media and the SSRC identifier of the second video media) is understood.

[0162] Referring to Tables 1 and 2, RTP packets in an RTP stream are annotated with the SSRC identifier of the RTP stream and the SSRC identifier of each video ringback tone negotiated in step 310. Each RTP packet header in an RTP stream uses a "Sequence Number" to facilitate determining packet loss in the RTP stream. The RTP extension header uses a "Sub-Sequence Number" to facilitate accurate playback of individual video media. Assume that, according to the negotiation results in step 310, the "Sub-SSRC Identifier" in the RTP packet for video ringback tone 1 is 12345.

[0163] The encapsulated RTP stream has the following characteristics: the "Sequence number" of the RTP message header is globally continuous, and the content of this field can be used to determine whether the RTP stream has packet loss. The "SSRC identifier" of the RTP message header is used to identify that the RTP message belongs to the same RTP stream. Other fields in the RTP message header (such as "M", "P" and "Timestamp") are invalid; the "sub-Sequence number" in the RTP extension header is continuous in the same video media, the "sub-SSRC identifier" in the RTP extension header is used to determine the RTP message in the same video media, the "M" in the RTP extension header is used to determine the end of the video frame, the "P" in the RTP extension header is used to determine whether there is a supplementary bit, and the "Timestamp" in the RTP extension header marks the timestamp of the video frame.

[0164] 314. The calling terminal plays video ringback tone 1 and video ringback tone 2.

[0165] After receiving the RTP stream, the calling terminal first parses the RTP header, determines whether there has been packet loss based on the "Sequence number," and determines whether the received RTP message belongs to the same RTP stream based on the "SSRC identifier." It then parses the RTP extension header, identifies the RTP message for the same video ringtone based on the "Sub-SSRC identifier," determines the order of the RTP messages within the video media based on the "Sub-Sequence number," calculates the frame rate based on the "Sub-Timestamp," and retrieves a complete frame based on "M." After determining multiple RTP messages for the same video media, the message is sorted based on the "Sub-Sequence number." The calling terminal plays each video media based on the display position of the corresponding SSRC identifier carried in the SDP information in step 314. Specifically, the calling terminal parses the RTP payload and determines video characteristics, such as profile, level, resolution, and frame rate, from the Picture Parameter Set (PPS) and Sequence Parameter Set (SPS) frames. It then parses the I, P, and B frame types and content. I frames are intra-coded frames, P frames are forward-predicted frames, and B frames are bidirectionally interpolated frames. The calling terminal then decodes the RTP payload for each video media, extracting the original image information. The decoder then displays the obtained image information based on the display position of the corresponding SSRC identifier carried in the SDP information in step 314.

[0166] The embodiment of the present application is illustrated by taking an RTP stream carrying RTP messages of video ringback tone 1 and video ringback tone 2 as an example. Figure 3B This is a schematic diagram of an interface for playing an RTP stream to a calling terminal. The display content in this diagram (such as the information displayed on the screen, the location and order of the information, etc.) is only illustrative and does not limit the actual display content on the screen.

[0167] 315. The calling terminal sends a handover request to the media server.

[0168] The switching request may specifically be an INFO notification message, and the INFO notification message indicates switching of the video ringback tone.

[0169] When the user of the calling terminal is watching multiple video ringback rings, the calling terminal can trigger the calling terminal to send a switching request to the media server by operating the calling terminal (such as clicking or sliding). Figure 3BFor example, suppose a user slides the screen at the display location of video ringback tone 1. After the calling terminal detects this operation, it generates a switching request for switching to video ringback tone 1. This switching request can be implemented using the Media Server Markup Language (MSML), as shown in the following example:

[0170]

[0171] In this example, the "switchlocation="1:1"" field instructs the media server to switch the video ringback tone displayed in the first row and first column. Alternatively, the "switchlocation="1:1"" field in the above example can be changed to "switchSSRC="12345" to instruct the media server to switch the video ringback tone 1 with the SSRC identifier "12345".

[0172] 316. The media server sends a response message to the calling terminal regarding the handover request.

[0173] The response message may specifically be a 200 OK (INFO) message, indicating that the handover is successful.

[0174] After receiving the switching instruction, the media server stops playing video ringback tone 1, starts playing video ringback tone 3, and sends a 200 OK (INFO) message to the calling terminal to notify the calling terminal that the switching is successful.

[0175] 317. The media server sends the RTP message of video ringback tone 3 to the calling terminal.

[0176] The media server encapsulates the video frame of video RBT 3 using the SSRC of the RTP stream and the SSRC of video RBT 1 according to the multi-SSRC identification mechanism, obtains the RTP message of video RBT 3, and sends the RTP message of video RBT 4 in the RTP stream.

[0177] Optionally, step 317 may be performed before step 316, or step 316 and step 317 may be performed simultaneously, and no timing limitation is made here.

[0178] 318. The calling terminal plays video ringback tone 3 according to the playback parameters of video ringback tone 1.

[0179] The calling terminal plays video ringback tone 3 according to the playback parameters of video ringback tone 1, and plays video ringback tone 2 according to the playback parameters of video ringback tone 2. Figure 3C Schematic diagram of the interface for playing the switched RTP stream for the calling terminal.

[0180] Above through Figure 2 and Figure 3AThe corresponding embodiment introduces the interaction process between the media server and the first terminal. The following example introduces the interaction process between the AS and the MRS in a communication scenario where the AS and the MRS are separately provided. Figure 4 This is a schematic flow chart of another possible embodiment of the call processing method of the present application. Figure 1 The system shown can also be applied to other communication scenarios, and the embodiment of the present application is not limited here. In the embodiment of the present application, AS and MRS are set separately. AS and MRS can be in the calling domain or the called domain; the first terminal can refer to the calling terminal or the called terminal. Figure 4 The specific steps of the corresponding call processing method embodiment.

[0181] 401. An AS receives a call request from a first terminal, or forwards the call request to the first terminal.

[0182] Step 401 can be understood with reference to step 201 and will not be described in detail here.

[0183] 402. The AS sends a request message to the MRS.

[0184] After receiving the call request, the AS sends a request message to the MRS, indicating that the calling or called user has subscribed to the multi-video media playback service. Optionally, the request message specifically instructs the MRS to use a multi-SSRC mechanism to negotiate video media resources with the first terminal. For example, if the called user has subscribed to the service, the AS sends a request message to the MRS, illustratively by extending the SIP X-header field to notify the MRS to use a multi-SSRC mechanism to negotiate video media resources with the first terminal. An example of an X-header extension is as follows:

[0185] X-SUPPORT-MULTI-SSRC flag: showmode=n*m.

[0186] Among them, "X-SUPPORT-MULTI-SSRC flag" indicates that multiple SSRC flags are negotiated, and "showmode=n*m" indicates that the number of negotiated SSRC flags is n*m.

[0187] 403. The MRS negotiates video media resources with the first terminal through the AS.

[0188] 404. The AS sends a first play request to the MRS.

[0189] The first play request instructs the MRS to send an RTP stream with multiple SSRC identifiers to the first terminal.

[0190] 405. The MRS sends the RTP stream to the first terminal according to the first play request.

[0191] 406. The first terminal plays the first video media and the second video media according to the received RTP stream.

[0192] Step 405 and step 406 can be understood with reference to step 203 and step 204 respectively, and will not be described in detail here.

[0193] Steps 401 to 403 are optional steps, and the present embodiment does not limit the execution of steps 401 to 403 before step 404. If step 403 is executed, optionally, in step 405, the MRS sends an RTP stream to the first terminal according to the result of the video media resource negotiation and the first play request.

[0194] In the above step 403, the MRS negotiates video media resources with the first terminal through the AS. As an optional method, refer to Figure 4 , step 403 specifically includes steps 4031 to 4035.

[0195] 4031-4032. The MRS sends an update message to the first terminal through the AS.

[0196] The update message indicates that the MRS supports the multi-SSRC identification mechanism. For details, please refer to the relevant introduction about the update message in step 2021, which will not be repeated here.

[0197] 4033-4034. The first terminal sends a response message to the MRS through the AS.

[0198] After receiving the update message, the first terminal sends a response message to the update message to the MRS through the AS according to its own capabilities. For details of the response message, please refer to the relevant introduction about the response message in step 2022, which will not be repeated here.

[0199] As an optional manner, after step 404, steps 407 to 414 are further included.

[0200] 407. The first terminal sends a switching request for the first video media to the AS.

[0201] Step 407 can be understood with reference to step 205 and will not be described in detail here.

[0202] 408. The AS sends a stop playback request to the MRS.

[0203] The stop playing request is used to instruct the MRS to stop playing the first video media.

[0204] 409. The MRS stops sending the RTP message of the first video media to the first terminal.

[0205] 410. The MRS sends a response message to the AS regarding the request to stop playing.

[0206] The response message to the stop playback request is used to notify the AS that playback of the first video media has stopped.

[0207] 411. The AS sends a second play request to the MRS.

[0208] The second play request is used to instruct the MRS to play the third video media.

[0209] 412. The MRS sends a response message to the AS regarding the second play request.

[0210] The response message to the second play request is used to notify the AS that the third video media is ready to be played.

[0211] 413. The AS sends a response message to the first terminal regarding the handover request.

[0212] The response message to the switching request is used to notify the first terminal that it is ready to switch the first video medium.

[0213] 414. The MRS sends a third RTP packet of the third video media to the first terminal.

[0214] 415. The first terminal plays the third video media according to the third RTP message.

[0215] Step 414 and step 415 can be understood with reference to step 206 and step 207, and will not be repeated here.

[0216] Optionally, step 412 may be performed after step 414 , or step 412 and step 414 may be performed simultaneously.

[0217] In the embodiment of the present application, step 10, step 412 and step 413 are optional steps.

[0218] Figure 5 It is a schematic flow chart of another possible embodiment of the call processing method of the present application. Figure 5 The method of the present application is described with exemplary signaling, and Figure 5 The AS and MRS in the media server are set separately as an example, so this method can be applied to Figure 1 The present invention is a system for demonstrating the present invention, and of course it can also be applied in other communication scenarios, and the embodiments of the present application are not limited here. Figure 5 The method shown is Figure 4 An example of the method shown, thus Figure 5 Some explanation of the methods shown can be found in Figure 4 The following takes the video media as an example to introduce the method of video ringback tone. Figure 5 The specific steps of the corresponding call processing method embodiment.

[0219] 501-502. The calling terminal sends a call request, such as INVITE (SDPo1), to the called terminal through the AS.

[0220] 503-504. The called terminal sends 183 (SDPa1) to the calling terminal through the AS.

[0221] 505-506. The calling terminal sends UPDATE (SDPo2) to the called terminal via the AS.

[0222] 507-508. The called terminal sends UPDATE (SDPa2) to the calling terminal via the AS.

[0223] 509. The called terminal sends a 180 (ALERTING) message to the AS.

[0224] In step 501 to step 509 , the interaction process between the AS and the calling terminal and the called terminal may refer to the interaction process between the media server and the calling terminal and the called terminal in step 301 to step 309 , which will not be repeated here.

[0225] 510. The AS sends a request message, such as an INVITE, to the MRS.

[0226] The AS determines whether the called user has subscribed to the multi-video ringback tone service. If so, it sends an INVITE message to the MRS. This INVITE message does not carry SDP and notifies the MRS to use multi-SSRC identifier negotiation by extending the SIP X header field. An example of the X header field extension is as follows:

[0227] X-SUPPORT-MULTI-SSRC flag: showmode = 3*1.

[0228] 511. MRS sends 200 (SDPa3) to AS.

[0229] The MRS determines whether the current SIP call is a video negotiation and whether the called user has subscribed to the multi-video ringback tone service. If so, the MRS generates three SSRC identifiers, such as "12345, 12346, and 12347," and sends a 200 message carrying SDP information, namely, 200 (SDPa3), to the AS. This SDP information can be referenced from step 310.

[0230] 512. The AS sends an update message, such as UPDATE (SDPa3), to the calling terminal.

[0231] The update message carries the SDP information in the 200 message in step 511 .

[0232] 513. The calling terminal sends a response message to the AS, for example, 200 (SDPo3).

[0233] Step 513 can be understood with reference to step 311 and will not be described again here.

[0234] 514. AS sends ACK (SDPo3) to MRS.

[0235] The ACK (SDPo3) carries the SDP information in the response message in step 513. The MRS determines whether the calling terminal supports receiving the RTP stream encapsulated by the multiple SSRC identifier mechanism according to the SDP information.

[0236] 515. The AS sends an INFO message to the MRS.

[0237] After receiving the response message, if the AS determines that the calling terminal supports receiving multiple SSRC identifier streams based on the message, the AS sends an INFO message to the MRS. The INFO message is used to control the MRS to play multiple video ringback tones.

[0238] The INFO message can support multiple protocols to control media operations, such as the MSML implementation example:

[0239]

[0240] 516: The AS sends a 180 (ALERTING) message to the calling terminal.

[0241] The 180 message carries the ringing information (ALERTING), which is used to indicate that the called terminal is ringing.

[0242] 517. MRS sends 200 (response) to AS.

[0243] After receiving the INFO message, the MRS sends a 200 message to the AS. The 200 message carries response information, indicating that the MRS has received the INFO message.

[0244] 518. The MRS sends the RTP stream to the calling terminal.

[0245] 519. The calling terminal plays multiple video media according to the RTP stream.

[0246] Step 518 and step 519 are understood with reference to step 313 and step 314 and are not described again here.

[0247] 520. The calling terminal sends a switching instruction, such as INFO (switching), to the AS.

[0248] INFO (switch) can be implemented by extending MSML, as shown below:

[0249]

[0250] In this example, the "switchlocation="1:1"" field is used to instruct the media server to switch the video ringback tone displayed in the first row and first column.

[0251] Step 520 can be understood with reference to step 315 and will not be described in detail here.

[0252] 521. The AS sends a stop playback request to the MRS, such as INFO (stop).

[0253] Among them, INFO (stop) is used to indicate to stop playing the video ringback tone displayed in the first row and the first column. The extended MSML example is as follows:

[0254]

[0255] In the example, <subvideostop><showmode="3*1"stoplocation="1:1" / >" field, instructing the media server to stop playing the video ringback tone displayed in the first row and first column, that is, video ringback tone 1.

[0256] 522. The MRS stops sending the RTP message of the video ringback tone 1 to the calling terminal.

[0257] 523. The MRS sends a response message to the AS regarding the request to stop playing, such as 200 (Stop).

[0258] Among them, 200 (Stop) is used to notify the AS that the video media 1 has stopped playing.

[0259] 524. The AS sends a play request to the MRS, such as INFO (play);

[0260] Among them, INFO (play) is used to instruct the MRS to play other video ringback rings except video ringback ring 1. An example of INFO (play) is as follows:

[0261]

[0262]

[0263] In the example, <subvideoplay><showmode="3*1"filepath="y: / video / 202001 / sub-6.3gp"location="1:1" / >" field, instructing MRS to play the video ringback tone with the path "y: / video / 202001 / sub-6.3gp" in the first row and first column. For the convenience of description, this video ringback tone is called video ringback tone 4.

[0264] 525. The MRS sends a response message to the AS for the play request, for example, 200 (Play).

[0265] Among them, 200 (play) is used to notify the AS that the video media 3 is ready to be played.

[0266] 526. The AS sends a handover success response message, such as 200 (INFO), to the calling terminal.

[0267] Among them, 200 (INFO) is used to notify the calling terminal that it is ready to switch to video ringback tone 1.

[0268] 527. The MRS sends a third RTP message of the video ringback tone 3 to the calling terminal.

[0269] 528. The first terminal plays the video ringback tone 3 according to the third RTP message.

[0270] Steps 527 to 528 may refer to steps 316 to 318 and will not be repeated here.

[0271] The call processing method provided in the embodiment of the present application has been introduced above. The device provided in the embodiment of the present application is introduced below. Figure 6 This is a possible embodiment diagram of the media server of this application. Figure 6 , the media server includes a call processing unit 601, a media negotiation unit 602 and a media sending unit 603. Among them, the call processing unit 601 is used to receive a call request, and the call request is used for the calling terminal to initiate a call to the called terminal. The media negotiation unit 602 is used to negotiate video media resources with the first terminal, and the first terminal is the calling terminal or the called terminal. The media sending unit 603 is used to send a real-time transport protocol RTP stream to the first terminal based on the negotiation result of the video media resource negotiation between the media negotiation unit and the first terminal. The RTP stream includes a first RTP message of the first video media and a second RTP message of the second video media, the first RTP message includes the synchronization source SSRC identifier of the RTP stream and the SSRC identifier of the first video media, and the second RTP message includes the SSRC identifier of the RTP stream and the SSRC identifier of the second video media. These units can also be used to implement the aforementioned Figure 2 and Figure 3A The relevant functions in any embodiment will not be repeated here.

[0272] As an optional manner, the media negotiation unit 602 is specifically used to: send an update message to the first terminal, where the update message indicates that the media server supports a multiple SSRC identification mechanism; and receive a response message from the first terminal, where the response message indicates that the first terminal supports the multiple SSRC identification mechanism.

[0273] As an optional manner, the update message includes first indication information, where the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media.

[0274] As an optional manner, the first indication information corresponds to the same video m lines in the update message.

[0275] As an optional manner, the first RTP packet further includes a first sequence identifier, and the first sequence identifier of the first RTP packet indicates the order of the first RTP packet in the first video media.

[0276] As an optional method, the media server also includes a media switching unit 604, which is used to: after the media sending unit 603 sends the RTP stream to the first terminal, receive a switching request from the first terminal, and the switching request is used to request switching of the first video media; send a third RTP message of the third video media to the first terminal, and the third RTP message includes the SSRC identifier of the RTP stream and the SSRC identifier of the third video media, and the SSRC identifier of the third video media is the same as the SSRC identifier of the first video media.

[0277] The embodiment of the present application also provides a terminal, Figure 7 This is a possible embodiment diagram of the terminal of this application. Figure 7 The terminal includes a call processing unit 701, a media negotiation unit 702, a media receiving unit 703 and a media playing unit 704. The call processing unit 701 is used to send a call request to the media server, or receive a call request from the media server, and the call request is used by the calling terminal to initiate a call to the called terminal. The media negotiation unit 702 is used to negotiate video media resources with the media server. The media receiving unit 703 is used to receive an RTP stream from the media server based on the negotiation result of the video media resource negotiation with the media server, the RTP stream including a first RTP message of a first video media and a second RTP message of a second video media, the first RTP message including a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, the second RTP message including an SSRC identifier of the RTP stream and an SSRC identifier of the second video media. The media playing unit 704 is used to play the first video media and the second video media respectively according to the RTP stream.

[0278] As an optional manner, the media negotiation unit 702 is specifically configured to: receive an update message from the media server, where the update message indicates that the media server supports a multiple SSRC identification mechanism; and send a response message to the media server, where the response message indicates that the first terminal supports the multiple SSRC identification mechanism.

[0279] As an optional manner, the update message includes first indication information, where the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media.

[0280] As an optional manner, the media playing unit 704 is specifically configured to play the first video media according to the playing parameters corresponding to the SSRC identifier of the first video media, and play the second video media according to the playing parameters corresponding to the SSRC identifier of the second video media.

[0281] As an optional manner, the first indication information corresponds to the same video m lines in the update message.

[0282] As an optional manner, the first RTP packet further includes a first sequence identifier, where the first sequence identifier indicates the sequence of the first RTP packet in the first video medium.

[0283] As an optional method, the terminal also includes a media switching unit 705, which is used to: after the media playback unit 704 plays the first video media and the second video media respectively, send a switching request to the media server, and the switching request is used to request switching of the first video media; receive a third RTP message of the third video media from the media server, and the third RTP message includes the SSRC identifier of the RTP stream and the SSRC identifier of the third video media, and the SSRC identifier of the third video media is the same as the SSRC identifier of the first video media; and play the third video media according to the third RTP message.

[0284] These units implement the aforementioned Figure 2 Related functions of the first terminal in the embodiment, or implementation Figure 3A The related functions of the calling terminal in the embodiment will not be described in detail here.

[0285] The present application embodiment also provides an MRS, Figure 8 This is a possible embodiment diagram of the MRS of this application. Figure 8 , the MRS includes a receiving unit 801 and a media sending unit 802. The receiving unit 801 is used to receive a first play request from the AS. The media sending unit 802 is used to send an RTP stream to the first terminal. The first terminal is a calling terminal or a called terminal. The RTP stream includes a first RTP message of a first video media and a second RTP message of a second video media, the first RTP message includes a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP message includes an SSRC identifier of the RTP stream and an SSRC identifier of the second video media.

[0286] As an optional embodiment, the MRS further includes a media negotiation unit 803, which performs video media resource negotiation with the first terminal through the AS before the receiving unit 801 receives the playback request from the AS. The media sending unit 802 is specifically configured to send an RTP stream to the first terminal based on the negotiation result of the video media resource negotiation and the first playback request.

[0287] As an optional manner, the media negotiation unit 803 is specifically configured to: the MRS sends an update message to the first terminal through the AS, the update message indicating that the MRS and / or the AS supports the multiple SSRC identification mechanism. Thereafter, the MRS receives a response message from the first terminal through the AS, the response message indicating that the first terminal supports the multiple SSRC identification mechanism.

[0288] Optionally, the receiving unit 801 is further configured to receive a request message from the AS before the media negotiation unit 803 negotiates video media resources with the first terminal through the AS. The request message is sent by the AS in response to a call request for the calling terminal to initiate a call to the called terminal. The request message indicates that the calling user or the called user has subscribed to the multi-video media playback service. Optionally, the request message specifically instructs the MRS to use a multi-SSRC mechanism to negotiate video media resources with the first terminal.

[0289] As an optional manner, the update message carries the media capability information of the MRS (such as the SDP information of the MRS). In one possible design, the update message includes first indication information, and the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media.

[0290] As an optional manner, the first indication information corresponds to the same video m lines in the update message.

[0291] As an optional manner, the first indication information further indicates the playback parameters of the first video medium and the playback parameters of the second video medium.

[0292] As an optional manner, the playback parameter of the first video medium is used to indicate the display position of the first video medium on the first terminal.

[0293] As an optional manner, the first RTP message further includes a first sequence identifier, and the first sequence identifier of the first RTP message is used to indicate the order of the first RTP message in the first video medium.

[0294] As an optional method, the MRS further includes a media switching unit 804, which is configured to receive a stop play request and a second play request from the AS after the media sending unit 802 sends the RTP stream to the first terminal. The stop play request indicates to stop playing the first video media, and the second play request indicates to play the third video media. The media switching unit 804 then stops sending the first RTP message of the first video media to the first terminal according to the stop play request, and sends a third RTP message of the third video media to the first terminal according to the second play request. The third RTP message includes the SSRC identifier of the RTP stream and the SSRC identifier of the third video media. The SSRC identifier of the third video media is the same as the SSRC identifier of the first video media.

[0295] These units implement the aforementioned Figure 4 or Figure 5 The relevant functions of the MRS in the embodiment will not be described in detail here.

[0296] In the embodiments of the present application, the media server and terminal are presented as functional units. "Units" herein may refer to ASICs, circuits, processors and memories executing one or more software or firmware programs, integrated logic circuits, and / or other devices capable of providing the aforementioned functionality. In a simple embodiment, those skilled in the art will appreciate that the media server and terminal may be implemented using a processor, memory, and a communication interface.

[0297] The media server or terminal of the embodiment of the present application can also Figure 9 It is implemented by means of a computer device (or system) in the computer system. Figure 9 FIG2 is a schematic diagram of a computer device according to an embodiment of the present application, wherein the computer device includes at least one processor 901 , a communication bus 902 , and a memory 903 , and may further include at least one communication interface 904 and an I / O interface 905 .

[0298] The processor 901 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0299] The communication bus 902 may include a path for transmitting information between the aforementioned components. A communication interface, such as any transceiver, is used to communicate with other devices or communication networks, such as Ethernet, a radio access network (RAN), or a wireless local area network (WLAN).

[0300] The memory 903 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program codes in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory can be independent and connected to the processor via a bus. The memory can also be integrated with the processor.

[0301] The memory 903 is used to store application code for executing the solution of the present application, and the execution is controlled by the processor. The processor is used to execute the application code stored in the memory.

[0302] In a specific implementation, the processor 901 may include one or more CPUs, each of which may be a single-core processor or a multi-core processor. The processor 801 herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0303] In a specific implementation, as an embodiment, the computer device may further include an input / output (I / O) interface 905. For example, the output device may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device may be a mouse, a keyboard, a touch screen device, or a sensor device.

[0304] The computer device can be a general-purpose computer device or a dedicated computer device. In a specific implementation, the computer device can be a desktop computer, a portable computer, a network server, a PDA (Personal Digital Assistant), a mobile phone, a tablet computer, a wireless terminal device, a communication device, an embedded device or a computer with Figure 7 The embodiments of the present application do not limit the type of computer device.

[0305] like Figure 1 Each network element in can be Figure 9 The device shown has one or more software modules stored in the memory. The terminal or media server or AS or MRS can implement the software modules through the processor and the program code in the memory to complete the method executed by the corresponding device in the above embodiment.

[0306] The present application also provides a computer-readable storage medium for storing the above Figure 9 The computer software instructions used by the device (terminal or media server) shown include a program designed to execute the above method embodiment. The above method can be implemented by executing the stored program.

[0307] The embodiment of the present application also provides a call processing system, which includes a terminal and a media server, wherein the terminal can execute Figure 2 In the embodiment, the first terminal or Figure 3A In the embodiment, the calling terminal performs any steps; the media server may perform Figure 2 or Figure 3A Any steps performed by the media server in the embodiment will not be repeated in this embodiment of the application.

[0308] The embodiment of the present application also provides a call processing system, which includes a terminal, an AS and an MRS, wherein the terminal can execute Figure 4 In the embodiment, the first terminal or Figure 5 In the embodiment, any step performed by the calling terminal; AS and MRS can respectively perform Figure 4 or Figure 5 Any steps performed by the AS and MRS in the embodiment will not be described in detail in the embodiment of this application.

[0309] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple situations. A single processor or other module can implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0310] Those skilled in the art will appreciate that the functions described in conjunction with the various illustrative logic blocks, modules, and algorithm steps disclosed herein can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions described in the various illustrative logic blocks, modules, and steps can be stored or transmitted as one or more instructions or codes on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media can include computer-readable storage media, which corresponds to tangible media, such as data storage media, or communication media including any media that facilitates the transfer of computer programs from one place to another (e.g., according to a communication protocol). In this manner, computer-readable media can generally correspond to (1) non-transitory tangible computer-readable storage media, or (2) communication media, such as signals or carrier waves. Data storage media can be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in this application. A computer program product can include computer-readable media.

[0311] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Furthermore, any connection is properly referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are actually directed to non-transitory tangible storage media. As used herein, disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and Blu-ray disc, where disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0312] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Thus, the term "processor," as used herein, may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described by the various illustrative logical blocks, modules, and steps described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a combined codec. Furthermore, the techniques may be fully implemented in one or more circuits or logic elements.

[0313] The techniques of this application can be implemented in a variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs), or a set of ICs (e.g., a chipset). Various components, modules, or units are described herein to emphasize functional aspects of devices for performing the disclosed techniques, but they do not necessarily require implementation by different hardware units. In fact, as described above, the various units may be combined in a codec hardware unit in conjunction with appropriate software and / or firmware, or provided by interoperating hardware units (including one or more processors as described above).

[0314] The above description is merely an exemplary embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.< / subvideoplay> < / subvideostop>

Claims

1. A call processing method, characterized in that: Applicable to media servers, including: receiving a call request, where the call request is used by the calling terminal to initiate a call to the called terminal; Performing video media resource negotiation with a first terminal, where the first terminal is the calling terminal or the called terminal; Sending a real-time transport protocol RTP stream to the first terminal based on a negotiation result of the video media resource negotiation conducted with the first terminal, the RTP stream including a first RTP packet of the first video media and a second RTP packet of the second video media, the first RTP packet including a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP packet including the SSRC identifier of the RTP stream and the SSRC identifier of the second video media; receiving a switching request from the first terminal, the switching request being used to request switching of the first video medium; A third RTP message of a third video media is sent to the first terminal, where the third RTP message includes an SSRC identifier of the RTP stream and an SSRC identifier of the third video media, and the SSRC identifier of the third video media is the same as the SSRC identifier of the first video media.

2. The method according to claim 1, characterized in that The performing video media resource negotiation with the first terminal includes: Sending an update message to the first terminal, where the update message indicates that the media server supports a multiple SSRC identification mechanism; A response message is received from the first terminal, where the response message indicates that the first terminal supports the multiple SSRC identification mechanism.

3. The method according to claim 2, characterized in that The update message includes first indication information, where the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media.

4. The method according to claim 3, characterized in that The first indication information corresponds to the same video m lines in the update message.

5. The method according to any one of claims 1 to 4, characterized in that The first RTP packet further includes a first sequence identifier, and the first sequence identifier of the first RTP packet indicates the order of the first RTP packet in the first video medium.

6. A call processing method, characterized in that: Applied to a first terminal, where the first terminal is a calling terminal or a called terminal, including: Sending a call request to a media server, or receiving a call request from the media server, wherein the call request is used by the calling terminal to initiate a call to the called terminal; Performing video media resource negotiation with the media server; receiving, based on a negotiation result of the video media resource negotiation performed with the media server, an RTP stream from the media server, the RTP stream comprising a first RTP packet of a first video media and a second RTP packet of a second video media, the first RTP packet comprising a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP packet comprising the SSRC identifier of the RTP stream and an SSRC identifier of the second video media; Play the first video media and the second video media respectively according to the RTP stream; Sending a switching request to the media server, where the switching request is used to request switching of the first video media; receiving a third RTP packet of a third video media from the media server, where the third RTP packet includes an SSRC identifier of the RTP stream and an SSRC identifier of the third video media, where the SSRC identifier of the third video media is the same as the SSRC identifier of the first video media; The third video media is played according to the third RTP message.

7. The method according to claim 6, characterized in that The performing video media resource negotiation with the media server includes: receiving an update message from the media server, wherein the update message indicates that the media server supports a multiple SSRC identification mechanism; A response message is sent to the media server, where the response message indicates that the first terminal supports the multiple SSRC identification mechanism.

8. The method according to claim 7, characterized in that The update message includes first indication information, where the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media.

9. The method according to claim 8, characterized in that The first indication information corresponds to the same video m lines in the update message.

10. The method according to any one of claims 6 to 9, characterized in that The first RTP packet further includes a first sequence identifier, and the first sequence identifier indicates the sequence of the first RTP packet in the first video medium.

11. A media server, characterized in that: include: A call processing unit, configured to receive a call request, wherein the call request is used by a calling terminal to initiate a call to a called terminal; a media negotiation unit, configured to negotiate video media resources with a first terminal, where the first terminal is the calling terminal or the called terminal; a media sending unit, configured to send a real-time transport protocol RTP stream to the first terminal based on a negotiation result of the video media resource negotiation performed with the first terminal, the RTP stream including a first RTP packet of the first video media and a second RTP packet of the second video media, the first RTP packet including a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP packet including an SSRC identifier of the RTP stream and an SSRC identifier of the second video media; The media server further includes a media switching unit, which is configured to: After sending the RTP stream to the first terminal, receiving a switching request from the first terminal, the switching request being used to request switching of the first video media; A third RTP message of a third video media is sent to the first terminal, where the third RTP message includes an SSRC identifier of the RTP stream and an SSRC identifier of the third video media, and the SSRC identifier of the third video media is the same as the SSRC identifier of the first video media.

12. The media server according to claim 11, wherein The media negotiation unit is specifically configured to: Sending an update message to the first terminal, where the update message indicates that the media server supports a multiple SSRC identification mechanism; A response message is received from the first terminal, where the response message indicates that the first terminal supports the multiple SSRC identification mechanism.

13. The media server according to claim 12, wherein: The update message includes first indication information, where the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media.

14. The media server according to claim 13, wherein: The first indication information corresponds to the same video m lines in the update message.

15. The media server according to any one of claims 11 to 14, characterized in that The first RTP packet further includes a first sequence identifier, and the first sequence identifier of the first RTP packet indicates the order of the first RTP packet in the first video medium.

16. A terminal, wherein the terminal is a calling terminal or a called terminal, characterized in that: include: A call processing unit, configured to send a call request to a media server or receive a call request from the media server, wherein the call request is used by the calling terminal to initiate a call to the called terminal; A media negotiation unit, configured to negotiate video media resources with the media server; a media receiving unit, configured to receive an RTP stream from the media server based on a negotiation result of video media resource negotiation performed with the media server, the RTP stream comprising a first RTP packet of a first video media and a second RTP packet of a second video media, the first RTP packet comprising a synchronization source SSRC identifier of the RTP stream and an SSRC identifier of the first video media, and the second RTP packet comprising an SSRC identifier of the RTP stream and an SSRC identifier of the second video media; a media playing unit, configured to play the first video media and the second video media respectively according to the RTP stream; The terminal further includes a media switching unit, which is configured to: After playing the first video media and the second video media respectively according to the RTP stream, sending a switching request to the media server, wherein the switching request is used to request switching of the first video media; receiving a third RTP packet of a third video media from the media server, where the third RTP packet includes an SSRC identifier of the RTP stream and an SSRC identifier of the third video media, where the SSRC identifier of the third video media is the same as the SSRC identifier of the first video media; The third video media is played according to the third RTP message. The terminal according to claim 16 , wherein: The media negotiation unit is specifically configured to: receiving an update message from the media server, wherein the update message indicates that the media server supports a multiple SSRC identification mechanism; A response message is sent to the media server, where the response message indicates that the first terminal supports the multiple SSRC identification mechanism. The terminal according to claim 17 , wherein: The update message includes first indication information, where the first indication information indicates the SSRC identifier of the first video media and the SSRC identifier of the second video media.

19. The terminal according to claim 18, characterized in that The first indication information corresponds to the same video m lines in the update message.

20. The terminal according to any one of claims 16 to 19, characterized in that: The first RTP packet further includes a first sequence identifier, and the first sequence identifier indicates the sequence of the first RTP packet in the first video medium.

21. A call processing system, characterized in that: The method comprises the media server according to any one of claims 11 to 15 and the terminal according to any one of claims 16 to 20.

Images