WebRTC connection establishment method, terminal equipment and storage medium

Abstract

The invention is suitable for the field of data processing, and discloses a WebRTC connection establishment method, terminal equipment and a storage medium. The WebRTC connection establishment method comprises the following steps: determining browser environment information, wherein the browser environment information comprises a browser type, a browser version and a WebRTCAPI support condition; generating an adaptation strategy according to the browser environment information, wherein the adaptation strategy is used for indicating an SDP rewriting rule, an API proxy mode and an ICE candidate processing mechanism; performing standardization processing on the SDP according to the adaptation strategy to obtain a target SDP in a unified format; converting the differentiated APIs through an API proxy layer to obtain a target API; iCE candidate collection and filtering are optimized according to the adaptation strategy, and effective ICE candidates are obtained; and according to the target SDP, the converted API and the effective ICE candidate, establishing a WebRTC connection across browsers. According to the invention, the system complexity and delay are reduced.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of data processing, and particularly relates to a WebRTC connection establishment method, a terminal device and a storage medium. BACKGROUND

[0002] There are differences in the implementation of WebRTC standards by various browser manufacturers, which are manifested in inconsistent API naming, different SDP negotiation mechanisms, and different ICE candidate processing strategies, leading to difficulties in establishing WebRTC connections across browsers, and traditional solutions mostly rely on server transit, increasing system complexity and delay. A new technical means is needed to solve the above technical problems. SUMMARY

[0003] In view of this, the embodiments of the present application provide a WebRTC connection establishment method, a terminal device and a storage medium, which can solve the problem of increased system complexity and delay in the related art WebRTC connection establishment method.

[0004] The first aspect of the present application provides a WebRTC connection establishment method, comprising: determining browser environment information, the browser environment information comprising browser type, browser version and WebRTC API support situation; generating an adaptation strategy according to the browser environment information, the adaptation strategy being used to indicate SDP rewriting rules, API proxy mode and ICE candidate processing mechanism; standardizing the SDP according to the adaptation strategy to obtain a target SDP in a unified format; converting differentiated APIs through an API proxy layer to obtain target APIs; optimizing ICE candidate collection and filtering according to the adaptation strategy to obtain effective ICE candidates; establishing a cross-browser WebRTC connection according to the target SDP, the converted APIs and the effective ICE candidates.

[0005] Optionally, in the first implementation manner of the first aspect of the present application, the step of generating an adaptation strategy according to the browser environment information comprises: determining SDP syntax difference rules, API compatibility mode and ICE candidate processing priority according to the browser type and the browser version; determining differentiated APIs requiring proxy and conversion rules according to the WebRTC API support situation; generating the adaptation strategy according to the SDP syntax difference rules, the API compatibility mode, the ICE candidate processing priority, the differentiated APIs and the conversion rules.

[0006] Optionally, in a second implementation form of the first aspect of the present application, the step of standardizing the SDP according to the adaptation strategy comprises: performing line feed unification on the original SDP according to an SDP rewriting rule in the adaptation strategy; adjusting the order of audio and video codecs in the SDP according to a codec priority rule in the adaptation strategy; applying a corresponding repair rule for the SDP format defects of a specific browser.

[0007] Optionally, in a third implementation form of the first aspect of the present application, the step of converting the differential API through the API proxy layer comprises: identifying the target API with inconsistent functions in different browser environments according to the adaptation strategy; performing equivalent replacement processing on the target API with missing functions to generate a compatible interface; injecting a logic correction layer into the target API with different behaviors to standardize the input and output behaviors thereof; integrating the compatible interface and the standardized interface into the API proxy layer to complete the conversion of the differential API.

[0008] Optionally, in a fourth implementation form of the first aspect of the present application, the step of optimizing the ICE candidate collection and filtering according to the adaptation strategy to obtain the effective ICE candidate comprises: collecting the ICE candidate according to the adaptation strategy, and filtering the collected candidate to obtain a filtering result; determining the effective ICE candidate according to a preset collection time threshold and the filtering result.

[0009] Optionally, in a fifth implementation form of the first aspect of the present application, the step of establishing the cross-browser WebRTC connection according to the target SDP, the converted API and the effective ICE candidate comprises: completing the interaction and negotiation of the target SDP through the converted API, and performing connectivity detection according to the effective ICE candidate; after the detection confirms the reachability, establishing and maintaining the cross-browser WebRTC connection.

[0010] Optionally, in a sixth implementation form of the first aspect of the present application, the adaptation strategy comprises an SDP binding repair rule for Safari browser, an ICE candidate filtering rule for Firefox browser and / or a codec priority rule for Chrome browser.

[0011] Optionally, in a seventh implementation form of the first aspect of the present application, the step of determining the browser environment information comprises: parsing navigator.userAgent to obtain the browser type and the browser version; determining whether the UnifiedPlan mode is supported by detecting RTCRtpTransceiver; determining the API support condition by detecting whether the addTrack method exists in RTCPeerConnection.prototype; taking the browser type, the browser version, whether the UnifiedPlan mode is supported, and the API support condition as the browser information.

[0012] In a second aspect, the embodiments of the present application provide a terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the method for establishing a WebRTC connection when executing the computer program.

[0013] In a third aspect, the embodiments of the present application provide a computer readable storage medium, which stores a computer program, and the computer program is executable by a processor to implement the steps of the method for establishing a WebRTC connection.

[0014] In a fourth aspect, the embodiments of the present application provide a computer program product, which, when executed on a terminal device, causes the terminal device to perform the method for establishing a WebRTC connection.

[0015] Compared with the prior art, the embodiments of the present application have the beneficial effects that by determining the browser environment information and generating an adaptation strategy, the SDP is standardized, the differential API is converted, and the ICE candidate is optimized, which can effectively eliminate the differences in WebRTC implementation of different browsers, does not need to rely on server relay, realizes pure front-end cross-browser WebRTC connection establishment, improves the compatibility and efficiency of cross-browser connection, and reduces the system complexity and delay. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0017] Figure 1 FIG. 1 is a schematic diagram of an embodiment of the method for establishing a WebRTC connection in the embodiments of the present application. Figure 2 FIG. 1 is a schematic diagram of one embodiment of step S102 of the method for establishing a WebRTC connection in the embodiment of the present application; Figure 3 FIG. 1 is a schematic diagram of one embodiment of step S102 of the method for establishing a WebRTC connection in the embodiment of the present application; Figure 4 FIG. 1 is a schematic diagram of one embodiment of step S102 of the method for establishing a WebRTC connection in the embodiment of the present application; Figure 5 FIG. 1 is a schematic diagram of one embodiment of step S102 of the method for establishing a WebRTC connection in the embodiment of the present application; DETAILED DESCRIPTION

[0018] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present application and not to limit the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative efforts fall within the scope of the present application.

[0019] It should be noted that the terms "comprise", "contain", and "have" in the specification and claims of the present application and the above-mentioned drawings are intended to cover non-exclusive inclusion. For example, a process, method, terminal, product or device comprising a series of steps or units is not limited to the listed steps or units, but can optionally further comprise steps or units not listed, or can optionally further comprise other steps or units inherent to the process, method, product or device. In the claims, specification and drawings of the present application, the relationship terms such as "first" and "second" are merely used to distinguish one entity / operation / object from another entity / operation / object, and do not necessarily require or imply any such real-time relationship or sequence between the entities / operations / objects.

[0020] Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase that the phrase in the specification in various places does not necessarily all refer to the same embodiment, or necessarily refer to different or alternative embodiments. It is explicitly and implicitly understood that the embodiments described herein can be combined.

[0021] Different browser manufacturers have different implementations of the WebRTC standard, which is manifested in inconsistent API naming, different SDP negotiation mechanisms, and different ICE candidate processing strategies, resulting in difficulties in establishing WebRTC connections across browsers, and traditional solutions rely on server mediation, increasing system complexity and delay. A new technical means is needed to solve the above technical problems.

[0022] In view of this, the embodiment of the application provides a WebRTC connection establishment method, a terminal device and a storage medium, by determining browser environment information and generating an adaptation strategy, the SDP is standardized, the differentiated API is converted, and the ICE candidate is optimized, which can effectively eliminate the differences in WebRTC implementation of different browsers, without relying on server mediation, realizing pure front-end WebRTC connection establishment across browsers, improving the compatibility and efficiency of cross-browser connection, and reducing system complexity and delay.

[0023] In order to illustrate the technical scheme of the application, specific embodiments will be described below.

[0024] Figure 1 A WebRTC connection establishment method implementation flowchart provided by an embodiment of the application is shown, and the method can be applied to a terminal device. The terminal device can be a mobile phone, a tablet computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, etc.

[0025] Specifically, the above-mentioned WebRTC connection establishment method can include the following steps S101 to S103.

[0026] Step S101, determine the browser environment information, the browser environment information includes the browser type, the browser version and the WebRTC API support situation.

[0027] In the embodiment of the application, the terminal device collects the browser environment information.

[0028] Optionally, the navigator.userAgent is parsed to obtain the browser type and the browser version; whether the UnifiedPlan mode is supported is determined by detecting RTCRtpTransceiver; the API support situation is determined by detecting whether the addTrack method exists in RTCPeerConnection.prototype; the browser type, the browser version, whether the UnifiedPlan mode is supported, and the API support situation are used as the browser information.

[0029] Specifically, the browser type and specific version are identified by analyzing the navigator.userAgent information of the browser; meanwhile, the WebRTC API supported by the browser is detected to determine whether it supports key APIs such as addTrack, and the information is integrated into the browser environment information.

[0030] In step S102, an adaptation strategy is generated according to the browser environment information, and the adaptation strategy is used to indicate the SDP rewriting rule, API proxy mode, and ICE candidate processing mechanism.

[0031] In the embodiment of the application, the terminal device generates an adaptation strategy based on the browser environment information.

[0032] Optionally, the adaptation strategy includes an SDP binding repair rule for the Safari browser, an ICE candidate filtering rule for the Firefox browser, and / or a codec priority rule for the Chrome browser.

[0033] Specifically, the adaptation strategy specifies the SDP rewriting rule (such as line feed processing and codec adjustment) for the current browser environment, the API proxy mode (such as conversion logic for differential APIs), and the ICE candidate processing mechanism (such as collection strategy and filtering rule) to adapt to the implementation differences of different browsers.

[0034] In step S103, the SDP is standardized according to the adaptation strategy, and a target SDP in a unified format is obtained.

[0035] In the embodiment of the application, the terminal device performs standardized processing on the original SDP according to the generated adaptation strategy. Specifically, the format of the original SDP is adjusted according to the SDP rewriting rule in the adaptation strategy, and the SDP syntax differences between different browsers are eliminated, and finally a target SDP in a unified format is obtained.

[0036] Optionally, specific SDP format defects (such as the mid binding problem of Safari) are repaired according to the browser type.

[0037] In step S104, the differential API is converted through the API proxy layer, and a target API is obtained.

[0038] In the embodiment of the application, the API (such as addTrack and addStream) with inconsistent functions or behaviors in the current browser environment is identified according to the adaptation strategy, and the differential API is converted and processed through the API proxy layer, for example, an equivalent replacement operation is performed on the API with missing functions, and logic correction is injected into the API with behavior differences, and finally a standardized target API is obtained.

[0039] Step S105, according to the adaptive strategy optimization ICE candidate collection and filtering, get effective ICE candidate.

[0040] In the embodiment of the application, the ICE candidate collection is started, and the collected candidates are screened according to the filtering rules in the adaptive strategy, and invalid candidates (such as the multi-host invalid candidate of Firefox) are removed; and in combination with the preset collection time threshold, the final effective ICE candidate is determined on the premise of ensuring sufficient candidate collection.

[0041] Optionally, the filtering rules or the time threshold are adjusted according to the network environment.

[0042] Step S106, according to the target SDP, the converted API and the effective ICE candidate, a cross-browser WebRTC connection is established.

[0043] In the embodiment of the application, according to the obtained target SDP, the converted API and the effective ICE candidate, a cross-browser WebRTC connection is established. The interaction and negotiation of the target SDP are completed through the converted API, and the connectivity detection is performed based on the effective ICE candidate, and after confirming the connection reachability, the cross-browser WebRTC connection is successfully established and maintained.

[0044] Compared with the prior art, the embodiment of the application has the beneficial effects that by determining the browser environment information and generating the adaptive strategy, the SDP is standardized, the differentiated API is converted, and the ICE candidate is optimized, the differences of different browsers in the implementation of WebRTC can be effectively eliminated, the server relay is not needed, the pure front-end cross-browser WebRTC connection establishment is realized, the compatibility and efficiency of the cross-browser connection are improved, and the system complexity and delay are reduced.

[0045] In the conventional method, the specific differences of the browser type, version and API support condition are not fully combined when the WebRTC adaptive strategy is generated, the strategy lacks pertinence, it is difficult to effectively cope with the differences of different browsers in the SDP syntax, API behavior and ICE candidate processing, and the adaptive effect of the cross-browser connection is affected. Based on this, an optional embodiment is provided. Figure 2 , Figure 2 This is a specific embodiment diagram of step S102 of the WebRTC connection establishment method in the embodiment of the application. Step S102 further includes the following specific implementation.

[0046] Step S1021, according to the browser type and the browser version, the SDP syntax difference rule, the API compatibility mode and the ICE candidate processing priority are determined.

[0047] In the embodiments of the present application, according to the determined browser type and browser version, corresponding SDP syntax difference rules, API compatibility modes and ICE candidate processing priorities are determined. In this step, the terminal device will determine the differentiated rules and priorities to be followed in the SDP format, API calling mode and ICE candidate processing based on the inherent differences in the WebRTC implementation of different browsers (such as Chrome, Firefox, Safari, etc.) and their versions.

[0048] Optionally, for the Safari browser, the SDP syntax difference rules related to the a=group:BUNDLE field are determined, and for the Firefox browser, the processing priorities related to the ICE candidate filtering are determined.

[0049] In step S1022, the differentiated API to be proxied and the conversion rule are determined according to the WebRTC API support condition.

[0050] In the embodiments of the present application, the differentiated API to be proxied and the corresponding conversion rule are determined according to the detected WebRTC API support condition. The API (such as addTrack and addStream) with missing functions or inconsistent behaviors in the current browser is identified, and the specific logic for proxying and converting these APIs is determined, for example, for the browser that does not support addTrack, the conversion rule of using addStream to replace is determined.

[0051] In step S1023, the adaptation strategy is generated according to the SDP syntax difference rules, API compatibility modes, ICE candidate processing priorities, differentiated API and conversion rule.

[0052] In the embodiments of the present application, the determined SDP syntax difference rules, API compatibility modes, ICE candidate processing priorities, differentiated API to be proxied and conversion rule are integrated to generate the adaptation strategy. The adaptation strategy can comprehensively cover the adaptation requirements of SDP processing, API calling and ICE candidate processing in the current browser environment.

[0053] In the embodiments of the present application, by combining the browser type, version and API support condition, the components of the adaptation strategy are determined and integrated to generate, which can make the adaptation strategy more suitable for the specific implementation differences of different browsers, and improve the pertinence and effectiveness of the adaptation strategy.

[0054] Different browsers have different implementations of SDP format, such as inconsistent line break format, different codec order, and format defects of specific fields (such as a=group:BUNDLE of Safari), which lead to SDP negotiation failure and affect the establishment of WebRTC connection. Based on this, an optional embodiment is provided in the present application. Referring to Figure 3 , Figure 3 is a specific embodiment of step S102 of the method for establishing a WebRTC connection in the embodiment of the present application, and step S103 further includes the following specific implementation.

[0055] In step S1031, the original SDP is uniformly processed in terms of line break according to the SDP rewriting rule in the adaptation strategy.

[0056] In the embodiment of the present application, the original SDP is uniformly processed in terms of line break according to the SDP rewriting rule in the adaptation strategy. The terminal device scans the line break in the original SDP, and converts all forms of line break (such as \r\n, \n\r, \n, etc.) into the CRLF format required by the RFC standard.

[0057] In step S1032, the order of audio and video codecs in the SDP is adjusted according to the codec priority rule in the adaptation strategy.

[0058] In the embodiment of the present application, the order of audio and video codecs in the SDP is adjusted according to the codec priority rule in the adaptation strategy. For example, the audio codec such as Opus that is preferentially supported can be adjusted to a front position, so as to ensure that different browsers preferentially select compatible codecs during negotiation.

[0059] Optionally, for the audio codec, Opus is forced to be set as the highest priority, so as to improve the compatibility of cross-browser audio transmission.

[0060] In step S1033, a corresponding repair rule is applied to the SDP format defect of a specific browser.

[0061] In the embodiment of the present application, a corresponding repair rule is applied to the SDP format defect of a specific browser. For example, for the a=group:BUNDLE field binding problem of Safari browser, the field content can be replaced to repair, so that the SDP format meets the parsing requirements of the browser.

[0062] In the embodiment of the present application, the standardization of SDP format is realized by unifying line breaks, adjusting the order of codecs, and repairing the format defects of specific browsers, and the differences in SDP syntax between different browsers are effectively eliminated.

[0063] Different browser manufacturers have different implementations of WebRTC API, such as the functional substitution relationship of addTrack and addStream, the inconsistent option behavior of createOffer, etc., which leads to different results of the same API call in different browsers, and affects the normal establishment of cross-browser WebRTC connection. Based on this, an optional embodiment is provided. Figure 4 , Figure 4 is a specific embodiment of step S102 of the method for establishing a WebRTC connection in the embodiment of the application, and step S104 further includes the following specific implementation.

[0064] In step S1041, a target API with inconsistent functions in different browser environments is identified according to an adaptation strategy.

[0065] In the embodiment of the application, a target API with inconsistent functions or behaviors in different browser environments is identified according to an adaptation strategy. The terminal device locates the WebRTC API with differences in different browsers, such as addTrack and addStream, createOffer, etc., based on the determined browser type, version and API support condition.

[0066] In step S1042, an equivalent substitution process is performed on the target API with missing functions to generate a compatibility interface.

[0067] In the embodiment of the application, an equivalent substitution process is performed on the identified target API with missing functions to generate a compatibility interface. For example, if it is detected that the browser does not support the addTrack method, the addTrack call can be converted into a call to the addStream method through the proxy layer to realize equivalent functions.

[0068] Optionally, for the browser that does not support the UnifiedPlan mode, the corresponding API call is converted into an operation compatible with the PlanB mode by injecting adaptation logic.

[0069] In step S1043, a logic correction layer is injected into the target API with different behaviors to standardize the input and output behaviors thereof.

[0070] In the embodiment of the application, a logic correction layer is injected into the target API with different behaviors to standardize the input and output behaviors thereof. For example, for the difference in the SDP format returned by the createOffer method in different browsers, processing logic can be added in the proxy layer to unify the generation rules of the SDP, so that the output of createOffer conforms to the preset standardized format in any browser environment.

[0071] Step S1044, integrating the compatibility interface and the standardized interface to the API proxy layer to complete the conversion of the differentiated API.

[0072] In the embodiments of the present application, the generated compatibility interface and standardized interface are integrated into the API proxy layer to form a unified API calling entry to complete the conversion of the differentiated API. The API calling request is received through the proxy layer, and the corresponding compatibility or correction logic is automatically matched according to the browser environment to realize the transparent conversion of the differentiated API.

[0073] In the embodiments of the present application, by identifying the differential API, generating the compatibility interface, injecting the logic correction layer and integrating it into the proxy layer, the functional and behavioral differences of the WebRTC API in different browsers can be automatically eliminated, the standardization of API calling is realized, the consistency of API interaction under cross-browser environment is ensured, and the compatibility of WebRTC connection establishment is improved.

[0074] The ICE candidate collection strategies of different browsers are different (such as too many invalid candidates caused by the multi-host problem of Firefox, and incomplete candidate collection of Safari), and there is lack of unified filtering and timeout processing mechanism, which causes low quality or incomplete collection of ICE candidates, and affects the normal establishment of WebRTC connection. Based on this, an optional embodiment is proposed in the present application. Step S105 further includes the following specific embodiments.

[0075] Step S1051, collecting ICE candidates according to the adaptation strategy, and filtering the collected candidates to obtain a filtering result.

[0076] In the embodiments of the present application, the terminal device will screen the collected ICE candidates according to the ICE candidate processing rules for different browsers in the adaptation strategy (such as the multi-host problem of Firefox browser), retain valid candidates (such as candidates containing host or srflx type), and eliminate invalid or redundant candidates to form a filtering result.

[0077] Optionally, the preliminary filtering of valid candidates is realized by detecting whether the candidate field contains identifiers such as "host", "srflx" and the like.

[0078] Step S1052, determining the valid ICE candidate according to the preset collection time threshold and the filtering result.

[0079] In the embodiment of the present application, the terminal device monitors the collection duration of the ICE candidate, and when the preset time threshold is reached, judges whether sufficient valid candidates have been collected in combination with the filtering result; if yes, the filtered candidates are taken as valid ICE candidates; if not, the terminal device can actively trigger a signal of candidate collection completion to ensure that the subsequent connection establishment is not affected by incomplete candidate collection.

[0080] In the embodiment of the present application, the invalid ICE candidates are filtered according to the adaptation strategy, and the time threshold is combined to ensure sufficient candidate collection, so that high-quality valid ICE candidates can be obtained, and the problem of strategy difference in ICE candidate collection of different browsers is solved.

[0081] The SDP negotiation mechanism and ICE candidate connectivity detection logic of each browser for WebRTC are different, which leads to the problems that the negotiation fails when the SDP is interacted across browsers, or the reachable path cannot be detected due to invalid ICE candidates, and finally it is difficult to establish the WebRTC connection. Based on this, an optional embodiment is proposed in the present application. The step S106 further includes the following specific implementation.

[0082] In step S1061, the target SDP is interacted and negotiated through the converted API, and the connectivity is detected according to the valid ICE candidate.

[0083] In the embodiment of the present application, the standardized API (such as the converted createOffer, addTrack, etc.) is used to interact and deliver the standardized target SDP between different browsers, so as to realize the SDP negotiation process; at the same time, the connectivity detection is initiated based on the valid ICE candidate obtained after optimization, to verify the feasibility of establishing the connection between different browsers through the candidate address.

[0084] Optionally, in the SDP negotiation process, if the first negotiation is not successful, the retry mechanism can be triggered through the converted API to re-deliver the target SDP for negotiation.

[0085] In step S1062, after the connectivity is detected and confirmed to be reachable, the WebRTC connection across browsers is established and maintained.

[0086] In the embodiment of the present application, after the connectivity is detected and confirmed to be reachable, the WebRTC connection across browsers is established and maintained. When the connectivity detection result shows that the reachability between browsers can be achieved through the valid ICE candidate, the terminal device establishes the WebRTC connection based on the target SDP agreed in negotiation and the converted API, and continuously monitors the connection state to maintain the stability of the connection.

[0087] In the embodiment of the present application, the effective negotiation of the target SDP is realized through the standardized API, and the connectivity detection is completed based on the effective ICE candidate, so that the smooth establishment and stable maintenance of the WebRTC connection in the cross-browser environment are ensured, and the connection negotiation failure or unreachable problem caused by the browser difference is solved.

[0088] As shown in Figure 5 FIG. 1 is a schematic diagram of a terminal device provided by an embodiment of the present application. The terminal device 500 can include a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501, for example, a WebRTC connection establishment program. The processor 501 implements the steps in the above-mentioned various embodiments of the establishment of the WebRTC connection when executing the computer program 503.

[0089] The computer program can be divided into one or more modules / units, one or more modules / units are stored in the memory 502 and executed by the processor 501 to complete the present application. One or more modules / units can be a series of computer program instruction segments capable of completing a specific function, which is used to describe the execution process of the computer program in the terminal device.

[0090] The terminal device can include, but is not limited to, the processor 501 and the memory 502. Those skilled in the art can understand that Figure 5 The terminal device is only an example and does not constitute a limitation on the terminal device, and can include more or fewer components than the diagram, or combine certain components, or different components, for example, the terminal device can also include an input / output device, a network access device, a bus, etc.

[0091] The processor 501 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0092] The memory 502 can be an internal storage unit of the terminal device, for example, a hard disk or a memory of the terminal device. The memory 502 can also be an external storage device of the terminal device, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the terminal device. Further, the memory 502 can include both the internal storage unit and the external storage device of the terminal device. The memory 502 is used to store computer programs and other programs and data required by the terminal device. The memory 502 can also be used to temporarily store data that has been output or will be output.

[0093] It should be noted that, for the convenience and brevity of description, the structure of the terminal device described above can also refer to the specific description of the structure in the method embodiments, which will not be described here.

[0094] The embodiment of the present application also provides a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by a processor to realize the steps in the method for establishing a WebRTC connection.

[0095] The embodiment of the present application provides a computer program product, when the computer program product is run on a mobile terminal, so that the mobile terminal executes the steps in the method for establishing a WebRTC connection.

[0096] In the above embodiments, the description of each embodiment has its own focus, and the parts not described or recorded in a certain embodiment can be referred to the related description of other embodiments.

[0097] Those skilled in the art can appreciate that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0098] In the embodiments provided by the present application, it should be understood that the disclosed terminal device and method can be implemented by other ways. For example, the terminal device embodiments described above are only schematic. In addition, the mutual coupling or direct coupling or communication connection between the shown or discussed elements can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0099] The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, i.e. may be located in one place, or may be distributed to multiple network units. Part or all of the units may be selected according to actual needs to achieve the purpose of the embodiment.

[0100] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0101] The integrated module / unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on this understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. When the processor executes the computer program, the steps of each method embodiment can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable file or some intermediate form, etc. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0102] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements to part of the technical features. These modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for establishing a WebRTC connection, characterized in that, include: Determine browser environment information, including browser type, browser version, and WebRTC API support. An adaptation strategy is generated based on the browser environment information. The adaptation strategy is used to indicate the SDP rewrite rules, API proxy method, and ICE candidate processing mechanism. The SDP is standardized according to the adaptation strategy to obtain a target SDP in a unified format. The differentiated API is transformed through an API proxy layer to obtain the target API; The ICE candidate collection and filtering are optimized according to the adaptation strategy to obtain effective ICE candidates; Establish a cross-browser WebRTC connection based on the target SDP, the transformed API, and the valid ICE candidates.

2. The method for establishing a WebRTC connection as described in claim 1, characterized in that, The step of generating an adaptation strategy based on the browser environment information includes: Based on the browser type and browser version, determine the SDP syntax difference rules, API compatibility mode, and ICE candidate processing priority; Based on the WebRTC API support, determine the differentiated APIs that need to be proxied and the conversion rules; The adaptation strategy is generated based on the SDP syntax difference rules, the API compatibility mode, the ICE candidate processing priority, the differentiated API, and the conversion rules.

3. The method for establishing a WebRTC connection as described in claim 1, characterized in that, The steps for standardizing the SDP according to the adaptation strategy include: According to the SDP rewriting rules in the adaptation strategy, the original SDP is processed to unify the newline characters. Adjust the order of audio and video codecs in the SDP according to the codec priority rules in the adaptation strategy; For specific browser-specific SDP format defects, apply corresponding repair rules.

4. The method for establishing a WebRTC connection as described in claim 1, characterized in that, The step of converting differentiated APIs through the API proxy layer includes: Based on the adaptation strategy, target APIs with inconsistent functionality in different browser environments are identified. Perform equivalent replacement processing on target APIs with missing functions to generate compatible interfaces; Inject a logic correction layer into target APIs that exhibit different behaviors to standardize their input and output behaviors; The compatibility and standardized interfaces are integrated into the API proxy layer to complete the conversion of differentiated APIs.

5. The method for establishing a WebRTC connection as described in claim 1, characterized in that, The step of optimizing ICE candidate collection and filtering according to the adaptation strategy to obtain effective ICE candidates includes: ICE candidates are collected according to the adaptation strategy, and the collected candidates are filtered to obtain the filtering results. The effective ICE candidates are determined based on the preset collection time threshold and the filtering results.

6. The method for establishing a WebRTC connection as described in claim 1, characterized in that, The step of establishing a cross-browser WebRTC connection based on the target SDP, the converted API, and the valid ICE candidates includes: The target SDP is interacted and negotiated through the transformed API, and connectivity detection is performed based on the valid ICE candidates. Once reachability is confirmed, the WebRTC connection is established and maintained across browsers.

7. The method for establishing a WebRTC connection as described in claim 1, characterized in that, The adaptation strategy includes SDP binding fix rules for Safari, ICE candidate filtering rules for Firefox, and / or codec priority rules for Chrome.

8. The method for establishing a WebRTC connection as described in claim 1, characterized in that, The steps for determining browser environment information include: Parse navigator.userAgent to get the browser type and browser version; Determine whether UnifiedPlan mode is supported by detecting RTCRtpTransceiver; API support can be determined by checking if the addTrack method exists in RTCPeerConnection.prototype. The browser type, browser version, whether UnifiedPlan mode is supported, and API support status are used as the browser information.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the WebRTC connection establishment method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the WebRTC connection establishment method as described in any one of claims 1 to 8.

Images