A method for sending HTTPS request based on pjsip framework

Abstract

This invention discloses a method for sending HTTPS requests based on the pjsip framework, belonging to the field of communication server and network transmission technology. The method includes: S1, extending the HTTP client component: adding an HTTPS protocol support layer, which identifies the URL and calls the SSL / TLS socket API of the pjproject library; S2, URL parsing and TCP connection establishment: when the HTTP client component receives a request carrying an HTTPS URL, it parses the URL through the HTTPS protocol support layer, identifies it as an HTTPS scheme, and creates a TCP connection to the HTTPS port of the target server; S3, upgrading to an SSL / TLS encrypted connection and configuring security policies: calling the SSL socket API of the pjproject library to upgrade the created TCP connection to an SSL / TLS encrypted connection, and configuring the SSL context according to a preset security configuration policy; S4, performing an SSL handshake; S5, encrypting communication; and S6, returning the result. This invention is entirely based on the existing APIs of the pjproject library, without requiring changes to the underlying network architecture or hardware devices, thus maximizing the protection of existing investments and possessing high engineering feasibility and commercialization value.

Description

Technical Field

[0001] This invention belongs to the field of communication server and network transmission technology, and in particular relates to a method for sending HTTPS requests based on the pjsip framework. Background Technology

[0002] The pjsip framework is an open-source SIP protocol stack based on the pjproject library, widely used in various communication server systems. The pjproject library, as its underlying support library, provides complete functional components including SIP protocol implementation, memory management, thread handling, and network transmission. Among them, the pjproject library's built-in HTTP client component can be used to send HTTP (Hypertext Transfer Protocol) requests, facilitating interface interaction between the SIP server and external business systems. However, the HTTP client component only supports HTTP requests by default and cannot achieve secure transmission of HTTPS (Hypertext Transfer Secure Protocol).

[0003] With increasing network security requirements, more and more business interfaces are requiring the use of HTTPS for communication. HTTPS is a secure transmission protocol that encrypts HTTP communication based on the SSL / TLS (Secure Sockets Layer / Transport Layer Security) protocol, effectively preventing data from being eavesdropped on or tampered with during transmission. However, the HTTP client components built into business systems based on the pjsip framework lack HTTPS support and cannot directly meet the requirements for HTTPS interface integration.

[0004] To address this technical issue, HTTPS support is typically implemented by introducing an external HTTP client library. While this approach allows for quick HTTPS implementation, it increases system dependency complexity. For example, architectural differences between external libraries and the pjproject library in terms of memory pool models and input / output event handling mechanisms can easily lead to compatibility issues and increase system maintenance costs.

[0005] Therefore, how to achieve HTTPS protocol support for b2bsip servers based on the pjsip framework without introducing external dependencies has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to overcome the technical shortcomings of the existing pjsip framework, such as the lack of HTTPS support in the HTTP client component and the complex system dependencies and poor architectural compatibility caused by introducing external libraries. This invention provides a method for sending HTTPS requests based on the pjsip framework. By adding an HTTPS protocol support layer inside the component and reusing the existing SSL / TLS socket capabilities of the pjproject library, support for the HTTPS protocol can be achieved.

[0007] The technical solution adopted in this invention is: A method for sending HTTPS requests based on the pjsip framework, applied to a b2bsip server including an upper-layer business call layer and an HTTP client component, is described, and includes the following steps: S1. Extend the HTTP client component: Add an HTTPS protocol support layer. The above HTTPS protocol support layer recognizes the URL and calls the SSL / TLS socket API of the pjproject library; S2. URL parsing and TCP connection establishment: When the HTTP client component receives a request carrying an HTTPS URL, it parses the URL through the HTTPS protocol support layer mentioned above, identifies it as an HTTPS scheme, and establishes a TCP connection to the HTTPS port of the target server. S3. Upgrade to SSL / TLS encrypted connection and configure security policy: Call the SSL socket API of the pjproject library to upgrade the created TCP connection to an SSL / TLS encrypted connection and configure the SSL context according to the preset security configuration policy; S4. Perform an SSL handshake: Perform an SSL handshake with the target server and determine whether to skip the certificate verification step based on the security configuration policy described above. S5. Encrypted Communication: After a successful handshake, HTTP request data is sent through the SSL / TLS encrypted connection mentioned above, and encrypted response data is received from the server. The encryption and decryption of the data is automatically completed by the SSL / TLS socket of the pjproject library. After decryption, plaintext HTTP response data is obtained. S6. Return result: The above HTTP client component performs HTTP protocol parsing on the above plaintext HTTP response data and returns the parsed response data to the above upper-layer business call layer.

[0008] Furthermore, step S3 upgrades the created TCP connection to an SSL / TLS encrypted connection, including: reusing the socket descriptor corresponding to the TCP connection created in step S2, calling the pj_ssl_sock_create function of the pjproject library to create an SSL socket object, and associating the socket descriptor of the aforementioned TCP connection with the aforementioned SSL socket object.

[0009] Furthermore, the security configuration strategy mentioned above in step S3 includes any one of the following: verification-free mode, mode determined by compile-time options, or mode dynamically set by runtime API.

[0010] Furthermore, when the above security configuration policy is configured to the verification-free mode, server certificate verification is disabled, and a security risk warning message is output.

[0011] Specifically, disabling server certificate verification involves setting the verify_peer and verify_peer_cert fields in the SSL socket parameter structure of the pjproject library to PJ_FALSE.

[0012] Furthermore, when the above security configuration policy is to determine the mode through compile-time options, the above compile-time options are used to configure whether server certificate verification is enabled.

[0013] Furthermore, when the above security configuration policy is set to dynamic setting via runtime API, the runtime API is used to dynamically set whether server certificate verification is enabled.

[0014] Furthermore, step S2, which involves creating a TCP connection to the target server's HTTPS port, also includes setting connection timeout control parameters. If the TCP connection cannot be established within a specified time, the connection attempt is terminated and a timeout error is returned.

[0015] More specifically, the connection timeout control parameters mentioned above include connection establishment timeout and SSL handshake timeout.

[0016] Furthermore, in step S5, when the SSL handshake fails, the corresponding error code is returned to the upper-layer business call layer.

[0017] Compared with the prior art, the present invention has the following advantages: This invention proposes a method for sending HTTPS requests based on the pjsip framework. By extending the HTTPS protocol support layer within the HTTP client component built into the pjproject library and reusing the existing SSL / TLSsocket capabilities of the pjproject library, it achieves an architectural optimization shift from relying on external libraries to reusing native capabilities. This solves the technical problems of high system complexity and poor compatibility caused by the introduction of external dependencies in existing technologies. The technical solution of this invention has the following outstanding advantages: First, this invention fundamentally solves the problem of external library dependencies, significantly reducing system complexity. Addressing the issues caused by existing technologies that introduce external HTTP client libraries to support HTTPS, this invention extends the HTTP client component built into the pjproject library, adding an HTTPS protocol support layer within the component and directly reusing the pjproject library's SSL / TLSsocket API. The solution of this invention is entirely based on the native capabilities of the pjproject library, requiring no external libraries. This avoids the increased compilation dependencies, version management, and security maintenance costs associated with third-party libraries, keeping the system architecture simple and controllable.

[0018] Secondly, this invention achieves perfect compatibility with the pjproject architecture, significantly improving system stability. Addressing the compatibility issues caused by architectural differences between external libraries and the pjproject library's memory pool model and input / output event handling mechanisms in existing technologies, this invention reuses the pjproject library's native SSL socket API and adopts a technical solution of first creating a TCP connection and then upgrading it to an SSL socket. This allows the HTTPS support layer to be fully integrated into the pjproject library's I / O event loop and memory management system. As shown in Embodiment 1, this invention achieves seamless integration with the pjproject architecture by reusing the TCP socket descriptor and calling the pj_ssl_sock_create function to create an SSL socket object, avoiding resource contention and state inconsistency issues caused by the coexistence of multiple event-driven mechanisms.

[0019] Third, this invention provides a unified HTTP / HTTPS client call interface, enabling seamless invocation of the upper-layer business call layer. Addressing the issue in existing technologies where HTTP and HTTPS require separate calls to different interfaces or libraries, the extended HTTP client component of this invention provides an API that is completely consistent with the native components of the pjproject library. As shown in the code example in Embodiment 1, the upper-layer business call layer only needs to pass in URLs with different schemes (http: / / or https: / / ) for seamless invocation, without needing to be aware of underlying encryption details or modify any business code. This significantly reduces the adaptation cost of the upper-layer business call layer, enabling existing application systems based on the pjsip framework to smoothly upgrade to HTTPS support.

[0020] Fourth, this invention provides a flexible security configuration mechanism to adapt to the needs of different application scenarios. Addressing the issue that existing HTTPS client libraries typically enforce certificate verification and lack flexibility, this invention designs a multi-layered security configuration strategy. As shown in Examples 2 to 4, the system supports a verification-free mode (suitable for internal networks or test environments), a compile-time option configuration mode (suitable for scenarios with clear deployment expectations), and a runtime API dynamic setting mode (suitable for operation and maintenance management scenarios). This flexible configuration mechanism allows the system to achieve a balance between security and convenience according to actual needs, ensuring the security of the production environment while also considering the efficiency of the development and testing environments.

[0021] Fifth, this invention implements a comprehensive connection management and error handling mechanism, improving system reliability. To address various anomalies that may occur in network communication, this invention sets connection timeout control parameters (including connection establishment timeout and SSL handshake timeout) and returns explicit error codes when the SSL handshake fails. As shown in Example 5, the system can clearly distinguish between different types of failure reasons such as expired certificates, untrusted certificates, and connection timeouts, providing accurate error information for upper-layer services, facilitating problem localization and anomaly handling, and significantly improving the system's robustness and maintainability.

[0022] In summary, the method of this invention is entirely based on the existing API of the pjproject library, and its core operations such as SSL socket creation, parameter configuration, and socket association all conform to the standard programming model of pjproject. Therefore, the method of this invention can be directly implemented on existing b2bsip servers based on the pjsip framework by upgrading software modules, without modifying the underlying network architecture or hardware devices, thus maximizing the protection of existing investments and possessing extremely high engineering feasibility and commercialization value. Detailed Implementation

[0023] Various exemplary embodiments of the present invention will now be described in detail. This detailed description should not be considered as a limitation of the present invention, but rather as a more detailed description of certain aspects, features, and embodiments of the present invention.

[0024] It should be understood that the terminology used in this invention is merely for describing particular embodiments and is not intended to limit the invention. Furthermore, with respect to numerical ranges in this invention, it should be understood that each intermediate value between the upper and lower limits of the range is also specifically disclosed. Any stated value or intermediate value within a stated range, as well as each smaller range between any other stated value or intermediate value within said range, is also included in this invention. The upper and lower limits of these smaller ranges may be independently included or excluded from the range.

[0025] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. While only preferred methods and materials have been described herein, any methods and materials similar or equivalent to those described herein may be used in the implementation or testing of this invention. All references to this specification are incorporated by way of citation to disclose and describe methods and / or materials associated with those references. In the event of any conflict with any incorporated reference, the content of this specification shall prevail.

[0026] Various modifications and variations can be made to the specific embodiments described in this specification without departing from the scope or spirit of the invention, as will be apparent to those skilled in the art. Other embodiments derived from this specification will also be apparent to those skilled in the art. This specification and embodiments are merely exemplary.

[0027] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to. Example 1

[0028] This embodiment provides a method for sending HTTPS requests based on the pjsip framework. This method is applied to a b2bsip server that includes an upper-layer business call layer and an HTTP client component. By extending the HTTP client component provided by the pjproject library and utilizing the SSL / TLS socket capabilities of the pjproject library, support for the HTTPS protocol is achieved.

[0029] The method includes the following steps: S1. Extend HTTP client components: Based on the HTTP client component that comes with the pjproject library, an HTTPS protocol support layer is added. This HTTPS protocol support layer recognizes URLs (Uniform Resource Locators) and calls the SSL / TLS socket API (Application Programming Interface) of the pjproject library.

[0030] In actual business logic calls, the upper-level business call layer initiates requests through a unified interface, as shown in the following code: ``` / / Create an HTTP client pjsip_endpoint * endpoint = ...; pjsip_http_client * client; pjsip_http_client_create(endpoint,&client); / / Send an HTTPS request (supported after extension, no certificate verification required) pjsip_http_req * req = create_request("https: / / internal-api.example.com / n5"); pjsip_http_client_send_request(client, req, callback, user_data); / / Send an HTTP request (existing functionality remains unchanged) pjsip_http_req * req2 = create_request("http: / / internal.example.com"); pjsip_http_client_send_request(client, req2, callback2, user_data2); ``` As can be seen from the code above, the API provided by the extended HTTP client component is completely consistent with the native pjproject component. The upper-level business call layer only needs to pass in the URL with different schemes (http: / / or https: / / ) to make calls without any difference. There is no need to be aware of the underlying encryption details or modify any business code.

[0031] S2, URL parsing and TCP (Transmission Control Protocol) connection establishment: When an HTTP client component receives a request carrying an HTTPS URL, it first parses the URL through the HTTPS protocol support layer. During the parsing process, the HTTPS protocol support layer extracts the protocol identifier at the beginning of the URL, identifies it as an HTTPS scheme, and thus determines that an encrypted transmission method is required. Subsequently, the HTTP client component creates a TCP connection to the target server's HTTPS port (the default port is 443, but other ports can be specified via the URL). To ensure system reliability, this step also sets connection timeout control parameters. If a TCP connection cannot be established within the specified time, the connection attempt will be terminated and a timeout error will be returned. The connection timeout control parameters include connection establishment timeout and SSL handshake timeout.

[0032] S3, upgrade to SSL / TLS encrypted connection and configure security policies: After the TCP connection is successfully established, the HTTP client component calls the SSL socket API of the pjproject library to upgrade the ordinary TCP connection to an SSL / TLS encrypted connection. The specific implementation process is as follows: First, the socket descriptor corresponding to the TCP connection created in step S2 is reused. The pj_ssl_sock_create function of the pjproject library is called to create an SSL socket object, and the socket descriptor of the TCP connection is associated with the SSL socket object. The core code is as follows: ``` / / Create SSL context pj_ssl_sock_param ssl_param; pj_ssl_sock_param_default(&ssl_param); / / Configure the SSL context according to the security configuration policy / / (The specific configuration of the security policy here will be detailed in step S4); / / Create SSL socket pj_ssl_sock * ssl_sock; pj_status_t status = pj_ssl_sock_create(pool,&ssl_param,&ssl_sock); / / Associate the SSL socket with the HTTP client transport layer ``` During the above process, the HTTP client component configures the SSL context according to the preset security configuration policy, providing a variety of flexible configuration methods to adapt to the needs of different application scenarios.

[0033] S4. Perform an SSL handshake: After the SSL socket is created, the HTTP client component performs an SSL handshake with the target server. The certificate verification behavior during the handshake process depends on the security policy configured in step S3.

[0034] In this embodiment, the security configuration strategy includes the following three modes: Mode 1: Verification-free mode When the security configuration policy is configured to authentication-free mode (applicable to internal networks or test environments), the HTTP client component disables server certificate verification during the SSL handshake process and outputs security risk warning information. Disabling server certificate verification specifically involves setting the `verify_peer` and `verify_peer_cert` fields in the SSL socket parameter structure of the pjproject library to `PJ_FALSE`, as shown in the following code: ``` / / Disable certificate verification ssl_param.verify_peer = PJ_FALSE; ssl_param.verify_peer_cert = PJ_FALSE; ``` Mode 2: Compile-time option configuration mode This embodiment provides compile-time options for configuring whether server certificate verification is enabled; When the compile-time option is set to enable verification, the standard certificate verification process will be performed during the SSL handshake. When verification is disabled, the above-mentioned verification-free mode will be used.

[0035] This configuration method is suitable for scenarios where there are clear expectations for the deployment environment.

[0036] Mode 3: Runtime API Dynamic Setting Mode This embodiment provides a runtime API for dynamically setting whether server certificate verification is enabled during service operation; System administrators can switch verification modes without restarting the service, greatly improving deployment flexibility.

[0037] S5, Encrypted Communication: After a successful handshake, the HTTP client component obtains an encrypted communication channel; Subsequent HTTP communication will take place over this encrypted channel: When sending an HTTP request, the data is automatically encrypted via an SSL / TLS encrypted connection before being sent. When receiving the response from the server, the encrypted data is automatically decrypted by the SSL / TLS socket to obtain the plaintext HTTP response data.

[0038] If the SSL handshake fails (such as due to network error or protocol mismatch), the component returns the corresponding error code to the upper-layer business call layer so that the upper-layer business call layer can perform the appropriate exception handling.

[0039] S6. Return the result: The HTTP client component performs HTTP protocol parsing on the decrypted plaintext HTTP response data, extracts structured information such as the status line, response headers, and response body, and returns the parsed response data to the upper-layer business call layer, completing the entire HTTPS request sending and response processing. Example 2

[0040] This embodiment provides an application scenario based on the method of the embodiment, in order to explain in detail the implementation process and technical effects of the present invention.

[0041] In an internal development and testing environment of a company, an internal business system based on a b2bsip server was deployed. This system needs to interface with multiple internal HTTPS interfaces. Since all communication takes place within the company's internal network, and the interface servers use self-signed certificates, strict certificate verification can lead to handshake failures, impacting development and testing efficiency.

[0042] To address the above scenario, the system adopts the method of Implementation Example 1 and configures the security configuration policy to authentication-free mode. In this embodiment, the following parameters are set for the SSL context in the system configuration file: ``` ssl_param.verify_peer = PJ_FALSE; ssl_param.verify_peer_cert = PJ_FALSE; ``` When the upper-layer business call layer calls the pjsip_http_client_send_request interface and passes in https: / / internal-api.example.com / n5, the system processes it according to steps S1 to S6 in Example 1.

[0043] During the SSL handshake process in step S4, due to the configuration of the certificate-free mode, the system skips the certificate verification step, completes the handshake directly, successfully sends the HTTPS request and receives the response; at the same time, the system outputs a security risk warning message in the log: "Currently in certificate-free mode, only applicable to internal test environment".

[0044] This embodiment allows developers to quickly perform interface integration testing without having to handle the installation and trust configuration of self-signed certificates, significantly improving development efficiency. Example 3

[0045] This embodiment provides an application scenario based on the method of the embodiment, in order to explain in detail the implementation process and technical effects of the present invention.

[0046] An equipment manufacturer needs to deliver a communication system based on a b2bsip server to a customer. The system needs to support two deployment scenarios: one is the customer's internal test environment (certificate verification needs to be disabled for quick verification), and the other is the production environment (certificate verification must be enabled to ensure security).

[0047] To meet the needs of different scenarios, the method of Implementation Example 1 is adopted, and the compile-time option MCX_HTTPS_VERIFY is provided during the system compilation phase to configure certificate verification behavior. The build script of this embodiment includes the following conditional compilation logic: ``` #ifdef MCX_HTTPS_VERIFY_ENABLE ssl_param.verify_peer = PJ_TRUE; ssl_param.verify_peer_cert = PJ_TRUE; #else ssl_param.verify_peer = PJ_FALSE; ssl_param.verify_peer_cert = PJ_FALSE; #endif ``` When compiling a version for a customer's internal testing environment, execute the compilation command `make MCX_HTTPS_VERIFY_ENABLE = 0`, setting the compilation option to disable verification, and the system will use a verification-free mode. When compiling a version for a customer's production environment, execute the compilation command `make MCX_HTTPS_VERIFY_ENABLE=1`, with the compilation option set to enable verification, and the system uses the standard certificate verification mode.

[0048] Through this embodiment, the same set of source code can be flexibly adapted to different deployment environments through compile-time options without modifying the code logic, which ensures the security of the production environment while taking into account the convenience of the testing environment. Example 4

[0049] This embodiment provides an application scenario based on the method of the embodiment, in order to explain in detail the implementation process and technical effects of the present invention.

[0050] In a large enterprise's B2B SIP server production environment, operations and maintenance personnel needed to perform connectivity tests on a newly added third-party HTTPS interface. This interface used a certificate issued by a Certificate Authority (CA) not pre-installed within the enterprise. Enabling strict verification directly in the production environment could lead to service interruptions, while recompiling the system was too cumbersome.

[0051] For the above scenario, this embodiment adopts the method described in Embodiment 1 and provides the runtime API pjsip_http_client_set_verify_mode() for dynamically setting the certificate verification mode.

[0052] Operations and maintenance personnel can call this API through the management interface to temporarily set the verification mode to "disabled". The core call example is as follows: ``` / / Temporarily disable certificate verification pjsip_http_client_set_verify_mode(client, PJ_FALSE, PJ_FALSE); / / Send a test HTTPS request pjsip_http_req * test_req = create_request("https: / / new-external-api.example.com / test"); pjsip_http_client_send_request(client, test_req, test_callback,NULL); / / Resume certificate verification after testing. pjsip_http_client_set_verify_mode(client, PJ_TRUE, PJ_TRUE); ``` During the temporary closure of verification, a handshake communication with the third-party interface was successfully completed, verifying the interface reachability.

[0053] After the test is completed, the operations and maintenance personnel call the API again to restore the certificate verification mode. The whole process does not require restarting the service and does not affect the normal operation of other services.

[0054] As can be seen, this embodiment provides flexible runtime configuration capabilities, enabling maintenance personnel to cope with various temporary debugging needs without interrupting services, and significantly improving the maintainability of the system. Example 5

[0055] This embodiment provides an application scenario based on the method of the embodiment, in order to explain in detail the implementation process and technical effects of the present invention.

[0056] In a real-world deployment scenario, a b2bsip server needs to connect to an external HTTPS interface, https: / / external-api.example.com / data. Because the SSL certificate of this interface server has expired and the system is configured in standard authentication mode (with certificate verification enabled), certificate verification fails during the SSL handshake process.

[0057] According to the method in Embodiment 1, when performing the SSL handshake in step S4, the SSL socket of the pjproject library detects that the certificate validity period has expired during the certificate verification process and returns the error code PJ_STATUS_FROM_SSL_ERR (PJ_SSL_ERR_CERT_EXPIRED).

[0058] After the system captures the error, it encapsulates the error code and returns it to the upper business call layer through a callback function, following the error handling logic in step S5.

[0059] Based on the received error code, the upper-layer business call layer can perform corresponding exception handling, such as recording error logs, triggering alarms, trying alternative interfaces, or directly returning a failure response to the upper-layer user.

[0060] In addition, if the handshake fails due to a timeout caused by network issues (such as the target server not responding within 5 seconds), the system returns a timeout error code PJ_ETIMEDOUT. The timeout threshold can be adjusted through the timeout control parameters set in Example 1 to adapt to the needs of different network environments.

[0061] Through this embodiment, the system can clearly distinguish the reasons for different types of handshake failures, providing accurate error information for upper-layer services, which facilitates problem localization and anomaly handling.

[0062] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for sending HTTPS requests based on the pjsip framework, the method being applied to a b2bsip server including an upper-layer business call layer and an HTTP client component, characterized in that, Includes the following steps: S1. Extend the HTTP client component: Add an HTTPS protocol support layer, which recognizes the URL and calls the SSL / TLS socket API of the pjproject library; S2. URL parsing and TCP connection establishment: When the HTTP client component receives a request carrying an HTTPS URL, it parses the URL through the HTTPS protocol support layer, identifies it as an HTTPS scheme, and establishes a TCP connection to the HTTPS port of the target server. S3. Upgrade to SSL / TLS encrypted connection and configure security policy: Call the SSL socket API of pjproject library to upgrade the created TCP connection to SSL / TLS encrypted connection and configure the SSL context according to the preset security configuration policy; S4. Perform SSL handshake: Perform an SSL handshake with the target server and determine whether to skip the certificate verification step based on the security configuration policy. S5. Encrypted Communication: After a successful handshake, HTTP request data is sent through the SSL / TLS encrypted connection, and encrypted response data is received from the server. The encryption and decryption of the data are automatically completed by the SSL / TLS socket of the pjproject library. After decryption, plaintext HTTP response data is obtained. S6. Return result: The HTTP client component performs HTTP protocol parsing on the plaintext HTTP response data and returns the parsed response data to the upper-layer business call layer.

2. The method according to claim 1, characterized in that, Step S3 upgrades the created TCP connection to an SSL / TLS encrypted connection, including: reusing the socket descriptor corresponding to the TCP connection created in step S2, calling the pj_ssl_sock_create function of the pjproject library to create an SSL socket object, and associating the socket descriptor of the TCP connection with the SSL socket object.

3. The method according to claim 1, characterized in that, The security configuration strategy described in step S3 includes any one of the following: verification-free mode, mode determined by compile-time options, or mode dynamically set by runtime API.

4. The method according to claim 3, characterized in that, When the security configuration policy is configured to the verification-free mode, server certificate verification is disabled, and a security risk warning message is output.

5. The method according to claim 4, characterized in that, The specific steps to disable server certificate verification are as follows: set the verify_peer and verify_peer_cert fields in the SSL socket parameter structure of the pjproject library to PJ_FALSE.

6. The method according to claim 3, characterized in that, When the security configuration policy is determined by compile-time options, the compile-time options are used to configure whether server certificate verification is enabled.

7. The method according to claim 3, characterized in that, When the security configuration policy is set to dynamic setting mode via runtime API, the runtime API is used to dynamically set whether server certificate verification is enabled.

8. The method according to claim 1, characterized in that, Step S2, which involves creating a TCP connection to the target server's HTTPS port, also includes setting connection timeout control parameters. If the TCP connection cannot be established within a specified time, the connection attempt is terminated and a timeout error is returned.

9. The method according to claim 8, characterized in that, The connection timeout control parameters include connection establishment timeout and SSL handshake timeout.

10. The method according to claim 1, characterized in that, In step S5, when the SSL handshake fails, the corresponding error code is returned to the upper-layer business call layer.