Calling methods, apparatuses, devices, media, and products

Abstract

The application provides a call method, device, equipment, medium and product. A call request is received from a calling terminal, and the call request is used for calling a called terminal. If an address field is carried in the call request, and the address in the address field does not conform to a preset address rule, a session initiation protocol (SIP) response information is sent to the calling terminal. The preset address rule is used to indicate whether a real public internet protocol (IP) address of the calling terminal exists in the address field. If the calling terminal and the called terminal are not successfully connected, and the first real-time transport protocol (RTP) silence data sent by the calling terminal according to the SIP response information is received within a preset time, the first public IP address of the calling terminal is determined according to the first RTP silence data. The real public IP address of the calling terminal can be obtained without depending on the network environment of the calling terminal, and the security of the call is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a calling method, apparatus, device, medium and product. Background Technology

[0002] In current audio and video communication systems, call systems based on the Session Initiation Protocol (SIP) face the challenge of malicious call requests and registration requests from the public internet. To ensure system and application security, the system needs to filter and verify the real Internet Protocol (IP) address of the calling end. However, since most calling ends operate in a Network Address Translation (NAT) private network environment, the IP address in their SIP signaling messages is from a private network, making it impossible for backend services to directly obtain the calling end's real public IP address.

[0003] Currently, existing methods for obtaining public IP addresses either require additional support from the calling end or place high demands on network equipment. In practical applications, especially in home broadband network environments, due to the diversity and complexity of network devices, existing methods for obtaining public IP addresses are often difficult to fully apply. This makes it difficult for the backend services of audio and video communication systems to obtain the real public IP address of the calling end, thereby affecting the security of the system and the effectiveness of the call. Summary of the Invention

[0004] This application provides a calling method, apparatus, device, medium, and product that can obtain the real public IP address of the calling end without relying on the network environment of the calling end, thereby improving the security of the call.

[0005] In a first aspect, embodiments of this application provide a calling method applied to a backend service, the method comprising:

[0006] Receive call requests sent by the calling party; the call requests are used to call the called party.

[0007] If the address field in the call request does not conform to the preset address rule, a Session Initiation Protocol (SIP) response message is sent to the calling party. The preset address rule is used to indicate whether the address field contains the real public Internet Protocol (IP) address of the calling party that initiated the call.

[0008] If the caller and the called party fail to connect, and the caller receives first Real-Time Transport Protocol (RTP) silence data sent by the caller based on SIP response information within a preset time, the first public IP address of the caller that initiated the call is determined based on the first RTP silence data.

[0009] Secondly, embodiments of this application provide a calling method applied to a calling terminal, the method comprising:

[0010] The current public IP address in the current network environment will be stored in the address field;

[0011] The address field is stored in the call request, and the call request containing the address field is sent to the backend service. The call request is used to call the called party.

[0012] Upon receiving the SIP response information sent by the backend service in response to the call request, if the caller and the called party fail to connect successfully, the caller sends the first RTP silence data to the backend service based on the address information of the backend service in the SIP response information, so that the backend service can determine the first public IP address of the caller that initiated the call based on the first RTP silence data.

[0013] Thirdly, this application provides a calling device for backend services, the device comprising:

[0014] A receiving module is used to receive a call request sent by the calling end, the call request being used to call the called end;

[0015] The first sending module is used to send Session Initiation Protocol (SIP) response information to the calling end if the address in the address field does not conform to a preset address rule when the call request carries an address field. The preset address rule is used to indicate whether the address field contains the real public IP address of the calling end that initiated the call.

[0016] The determination module is configured to, when the calling end and the called end fail to connect successfully, if it receives first Real-Time Transport Protocol (RTP) silence data sent by the calling end according to the SIP response information within a preset time, determine the first public IP address of the calling end that initiated the call based on the first RTP silence data.

[0017] Fourthly, this application provides a calling device for use on a calling terminal, the device comprising:

[0018] The storage module is used to store the current public IP address in the address field under the current network environment;

[0019] The second sending module is used to store the address field in a call request and send the call request containing the address field to the backend service. The call request is used to call the called party.

[0020] The third sending module is used to send first RTP mute data to the backend service based on the address information of the backend service in the SIP response information if the calling end and the called end fail to connect successfully, upon receiving SIP response information sent by the backend service according to the call request, so that the backend service can determine the first public IP address of the calling end that initiated the call based on the first RTP mute data.

[0021] Fifthly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;

[0022] When the processor executes computer program instructions, it implements the calling method as described in any one of the embodiments of the first and second aspects.

[0023] Sixthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the calling method as described in any one of the embodiments of the first and second aspects.

[0024] In a seventh aspect, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a calling method as described in any of the embodiments of the first and second aspects above.

[0025] In a calling method, apparatus, device, medium, and product provided in this application embodiment, when a backend service receives a call request sent by a calling end, it first checks the address field in the call request. If the address in the address field does not conform to a preset address rule, i.e., it cannot be directly confirmed that this is the real public IP address of the calling end, the backend service sends SIP response information to the calling end to guide the calling end to perform further verification. Subsequently, if the call is not successfully connected, and if the backend service receives the first RTP silence data sent by the calling end according to the SIP response information within a preset time, it can accurately determine the real first public IP address of the calling end by analyzing the first RTP silence data. The advantage of this method is that it does not require any additional support from the calling end, nor does it require large-scale modification or upgrade of existing network equipment. It makes full use of the first RTP silence data generated during the call process, and can obtain the real first public IP address of the calling end by simply analyzing and processing the first RTP silence data. This not only improves system security, as the backend service can filter and verify calls based on the real public IP address, but also enhances call validity, as the backend service can more accurately determine the source and intent of the call, thus processing call requests more efficiently and improving call security. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a flowchart illustrating a calling method provided in one embodiment of this application;

[0028] Figure 2 This is a flowchart illustrating a calling method provided in another embodiment of this application;

[0029] Figure 3 This is a flowchart illustrating a calling method provided in another embodiment of this application;

[0030] Figure 4 This is a flowchart illustrating a calling method provided in another embodiment of this application;

[0031] Figure 5 This is a flowchart illustrating a calling method provided in another embodiment of this application;

[0032] Figure 6 This is a schematic diagram of the structure of a calling device provided in an embodiment of this application;

[0033] Figure 7 This is a schematic diagram of another calling device provided in an embodiment of this application;

[0034] Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0035] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0036] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0037] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0038] An audio / video calling system based on the SIP protocol, running on the public internet, receives numerous malicious call and registration requests daily, attempting to make unauthorized calls and launching Denial of Service (DoS) attacks. Considering system and application security, it's necessary to filter the real IP address of the incoming terminal device according to call security control rules before each call. IP addresses that meet the criteria (within the user-defined IP address range) can call the called party, while IP addresses that do not meet the criteria (outside the user-defined IP address range) are rejected. Calls from illegal IP addresses (such as SIP application probe calls from overseas IPs) should be blocked promptly. Therefore, for each call, it's crucial to obtain the real IP address information of the incoming terminal device as early as possible before reaching the called party.

[0039] Currently, most access terminal devices operate in a NAT private network environment (such as a home broadband network environment). NAT's function is to map public IP addresses and ports to private IP addresses and ports, operating at the transport layer. It only modifies the addresses and ports in the Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) packet headers. However, the signaling messages (SIP protocol) used by terminal devices to access audio and video communication systems embed private network IP addresses and port numbers. These addresses and ports are only visible at the application layer. Therefore, NAT does not modify the address information in these messages, resulting in the IP addresses and ports in the signaling messages not being the actual network IPs of the services accessed by the terminal devices. Furthermore, since the backend is based on an audio and video communication system, firewalls and load balancers such as F5 are deployed, operating at layers three or lower, to ensure security and system performance. Ultimately, this leads to the backend services of the audio and video communication system not receiving the actual public IP address from the terminal devices.

[0040] Since all NAT and firewalls (FW) process and filter at the TCP / IP layer and below, while SIP is an application layer control signaling protocol, SIP is independent of the underlying transport and network layer protocols. Therefore, other methods must be used to obtain the real public IP address of the NAT device. Currently, the main solutions are as follows: 1. Universal Plug and Play (UPnP); 2. Traversal Using Relay NAT (TURN); 3. Simple Traversal of UDP Through network Address Translators (STUN); 4. Application Layer Gateway (ALG).

[0041] The first three methods involve terminal devices (including User Agents (UAs) and proxies) obtaining their public IP address and port before INVITE (an INVITE is a request message in the SIP protocol used to invite one or more users to participate in a multimedia session) through some means or protocol. The basic idea behind the ALG (Alternate Gateway) technical solution is to add Protocol Awareness to NAT / FW, enabling NAT / FW to modify the address information in the SIP signaling message as it passes through. ALG modifies the SIP address and port in the SIP message, changing them to the public IP address and port mapped by NAT / FW.

[0042] The above-mentioned technical solutions have the following main drawbacks: The first three solutions require additional support from the terminal device and are not compatible with all NAT methods. The ALG solution does not require any additional support from the terminal device. It processes and modifies the application-layer SIP signaling to achieve transparent address translation, but it requires the terminal device's NAT device or the network device in front of the backend service to support ALG functionality. This places high demands on network equipment and requires modifications to existing network devices. If the network device does not support ALG functionality, it is also impossible to obtain the NATed IP address of the device from the signaling. A typical scenario is that the terminal device runs under a home broadband gateway network, and the backend audio / video communication system, due to security and system performance considerations, deploys firewalls and F5-type load balancers and other network devices running at Layer 3 or lower. In this network deployment environment, the backend service of the audio / video communication system cannot obtain the real public IP address called by the terminal device.

[0043] To address the problems existing in the prior art, embodiments of this application provide a calling method, apparatus, device, medium, and product.

[0044] This application provides a calling method, apparatus, device, medium, and product. The calling method provided in the first aspect of this application will be described first. Figure 1 As shown, this method is applied to backend services, and specifically includes the following steps:

[0045] S100, receive a call request sent by the calling end, the call request being used to call the called end.

[0046] Optionally, in one feasible implementation of this application, the calling end (which may be a mobile phone, landline, computer software, or other communication terminal device) first initiates a call request. This call request may include the called end's identification information (such as phone number, username, etc.) and possible call parameters (such as call type, priority, etc.). After the call request is initiated, it is transmitted to a backend service system responsible for handling such requests. This backend service system may be based on a cloud computing architecture, capable of handling a large number of concurrent requests and ensuring high availability and scalability of the service. Upon receiving the call request, the backend service first verifies and parses it to ensure the legality and validity of the request.

[0047] S200, if the address in the call request does not conform to the preset address rule, then a Session Initiation Protocol (SIP) response message is sent to the calling end. The preset address rule is used to indicate whether there is a real public Internet Protocol (IP) address in the address field that initiated the call by the calling end.

[0048] Optionally, in one feasible implementation of this application, address field verification in the call request is a crucial step in ensuring communication security and validity. When the calling party carries an address field in a SIP call request, the backend service needs to rigorously check these addresses to ensure they conform to preset address rules. These rules are used to verify whether the address field contains the real public IP address of the calling party initiating the call.

[0049] Specifically, first, the backend service parses the address field in the SIP request, which can be a string containing IP address information. Then, the server applies preset address rules to verify this address. These rules may include checking whether the IP address is formatted correctly (e.g., whether it conforms to Internet Protocol version 4 (IPv4) or IPv6 specifications), whether the IP address belongs to a known public address range, and whether the IP address matches information previously registered or authenticated by the calling end.

[0050] If the address in the address field does not conform to the preset address rules, the server will send an extended SIP response message to the calling end. This response message can use non-standard status codes from the 18X series (such as 189) to indicate a specific error or authentication failure. The extended SIP response message includes a special header field "P-Early-Media:sendrecv". This header field tells the terminal device that although the call is not yet fully established, it should begin preparing to send and receive media streams (in this case, the first RTP silence packet). The message body of the extended SIP response message (usually an SDP description) carries the public IP address information of the backend service. This information guides the calling end to use this public IP address as the destination address in subsequent media transmissions. After sending the SIP response message containing the public IP address, the backend service starts a short timer. This timer waits for the terminal device to send the first RTP silence packet.

[0051] S300, if the calling end and the called end fail to connect successfully, and if the calling end receives first Real-Time Transport Protocol (RTP) silence data sent by the calling end according to the SIP response information within a preset time, then the first public IP address of the calling end that initiated the call is determined based on the first RTP silence data.

[0052] Optionally, in one feasible implementation of this application, if the caller and the called party fail to connect successfully during call setup, the caller's terminal device receives an 18X SIP response message from the backend service. Upon receiving the 18X SIP response message, the caller's terminal device checks whether it supports processing such messages. If it does, the caller further parses the message content, specifically checking for the presence of a header field such as "P-Early-Media:sendrecv". This header field indicates that the caller needs to send the first RTP silence data before the call is established.

[0053] When the calling terminal device detects the "P-Early-Media:sendrecv" header field, it begins sending the first RTP silence packet to the IP address and port specified by the backend service in the Session Description Protocol (SDP). These packets contain key network information about the calling device, such as the source IP address and port number.

[0054] Meanwhile, after sending the 18X SIP response, the backend service starts a short timer (typically configured to be less than 300 milliseconds). Within the time specified by this timer, if the backend service receives the first RTP silence packet from the terminal device, it parses the packet header information, especially the source IP address and port number. This information represents the public IP address of the calling device, i.e., the first public IP address from which the calling device initiated the call.

[0055] This method allows the public IP address of the calling device to be obtained before the call is answered. This is crucial for subsequent network communication, troubleshooting, and log recording. If the terminal device does not support processing 18X messages, it will simply discard the message without any processing.

[0056] In a calling method, apparatus, device, medium, and product provided in this application embodiment, when a backend service receives a call request sent by a calling end, it first checks the address field in the call request. If the address in the address field does not conform to a preset address rule, i.e., it cannot be directly confirmed that this is the real public IP address of the calling end, the backend service sends SIP response information to the calling end to guide the calling end to perform further verification. Subsequently, if the call is not successfully connected, and if the backend service receives the first RTP silence data sent by the calling end according to the SIP response information within a preset time, it can accurately determine the real first public IP address of the calling end by analyzing the first RTP silence data. The advantage of this method is that it does not require any additional support from the calling end, nor does it require large-scale modification or upgrade of existing network equipment. It makes full use of the first RTP silence data generated during the call process, and can obtain the real first public IP address of the calling end by simply analyzing and processing the first RTP silence data. This not only improves system security, as the backend service can filter and verify calls based on the real public IP address, but also enhances call validity, as the backend service can more accurately determine the source and intent of the call, thus processing call requests more efficiently and improving call security.

[0057] In one embodiment, the method further includes:

[0058] If the first RTP mute data sent by the calling end according to the SIP response information is not received within the preset time, and if the callee responds to the connection information sent by the calling end, the address information of the backend service and the connection information are sent to the calling end. The connection information is used to indicate that the calling end and the callee have successfully communicated, and the address information is used to indicate the address of the backend service.

[0059] Receive the second RTP mute data sent by the calling terminal based on the address information during a call;

[0060] The second public IP address of the calling end is obtained by parsing the second RTP mute data.

[0061] Optionally, in one specific implementation of this application, if the first RTP silence packet based on SIP response information is not received from the calling end within a preset time, this usually means that the backend service failed to directly obtain the calling end's NAT address at the initial stage of call establishment. However, if the backend service subsequently receives a response (usually a 200 OK response) from the called end to the connection information sent by the calling end, indicating that the call has been successfully established, the backend service still needs a mechanism to identify the calling end's NAT address.

[0062] In this scenario, the backend service uses an indirect method to obtain the caller's NAT address. First, the backend service sends its own address information (including its public IP address and port) and the connection confirmation message from the called party to the caller. This address information will be used by the caller for subsequent media data transmission, while the connection confirmation message informs the caller that the call has been successfully established.

[0063] Once the call is established and in a call state, the calling party will begin sending a second RTP silence packet based on the address information provided by the backend service. This second RTP silence packet passes through a NAT device during transmission, thus including the calling party's NAT address information in its header. Upon receiving these RTP silence packets, the backend service will parse the packet header information to extract the calling party's second public IP address (actually, the address after NAT translation).

[0064] The advantage of this technical solution lies in its ability to indirectly obtain the caller's NAT address through the call setup process and subsequent media data transmission, even when the NAT address cannot be directly obtained at the initial stage of call setup. This not only ensures a smooth call but also provides necessary information to backend services for direct data interaction with the caller when needed. Furthermore, since RTP silent packets are used to indirectly obtain the NAT address, this method has no negative impact on call quality or the overall call experience.

[0065] In these alternative embodiments, a flexible and reliable method is provided to handle situations where the backend service fails to directly obtain the terminal device's NAT address during the initial call setup. By utilizing the called party's response information (such as 200 OK) and the backend service's SDP information during call setup, the backend service can successfully forward the call to the called party and maintain communication with the terminal device. Secondly, when the terminal device enters a call state and begins sending second RTP media data, the backend service can receive these packets and resolve the terminal device's NAT address from them. This indirect method of obtaining the NAT address is not only effective but also does not negatively impact call quality or user experience. Finally, successfully obtaining the IP information of the terminal device initiating the call is crucial for the backend service. It helps the backend service better understand and manage the call connection, providing necessary support and guarantees for subsequent communication. Simultaneously, this also provides the terminal device with a more stable and reliable communication service, enhancing the user experience.

[0066] In one embodiment, if the first RTP silence data sent by the calling end according to the SIP response information is not received within a preset time, and if a connection information sent by the calling end in response to the calling end is received, before sending the address information of the backend service and the connection information to the calling end, the method further includes:

[0067] If the address field is included in the call request, and the address field conforms to the preset address rule, then the third public IP address of the calling party that initiated the call is obtained from the address field.

[0068] After parsing the second RTP mute data to obtain the second public IP address of the calling end that initiated the call, the method further includes:

[0069] The second public IP address and the third public IP address are verified to obtain a verification result, which is used to indicate whether the second public IP address and the third public IP address are consistent.

[0070] Optionally, in one specific implementation of this application, the backend service checks whether the call request carries a field containing address information. If the call request does indeed contain such an address field, and the field conforms to preset address rules (e.g., a specific field name such as X-Auth-IP or meeting specific format requirements), the backend service extracts the third-party public IP address of the calling party from this address field. This step allows the backend service to obtain the NAT address of the calling party before the call is established.

[0071] After a call is successfully established, i.e., the called party responds to the caller's connection information, the backend service sends its own address information and connection information to the caller. As the call progresses, the caller sends second RTP media data (including silence packets) to the backend service. When the backend service receives these second RTP packets, it parses their header information to obtain the sender's (i.e., the caller's) second public IP address after NAT.

[0072] After obtaining the second public IP address, the backend service performs a crucial verification step: comparing it with the third public IP address extracted from the call request address field. This verification confirms that the two IP addresses match, thus verifying whether the NAT address reported by the terminal device in the call request is the same as the NAT address used during the actual call. If the two addresses match, the verification result indicates success, proving that the NAT address reported by the terminal device in the call request is accurate and was used during the actual call. If the addresses do not match, the verification result indicates failure, which may mean that the terminal device reported an incorrect NAT address in the call request or used a different NAT address during the actual call. This verification mechanism helps the backend service more accurately understand and manage call connections, ensuring the stability and reliability of communication.

[0073] In these alternative embodiments, during these steps, the backend service effectively obtains and verifies the NAT address of the calling end by cleverly combining the address field information in the call request with the second RTP data packet information during the subsequent call, ensuring that the NAT address of the calling end can still be obtained under certain circumstances.

[0074] Once the call is established, the backend service, after receiving the RTP media data from the calling end, can resolve the second public IP address. By verifying this address against the third public IP address previously obtained from the call request, the backend service can confirm that the two addresses are identical. This verification mechanism not only ensures the backend service's accurate identification of the calling end's NAT address but also helps detect potential address conflicts or errors, thereby improving the stability and reliability of communication. Furthermore, this approach enhances the backend service's ability to manage call connections, providing more reliable support for subsequent communication.

[0075] In one embodiment, determining the first public IP address of the calling end that initiated the call based on the first RTP silence data includes:

[0076] Obtain the target network address translation (NAT) address of the calling terminal from the first RTP mute data;

[0077] Obtain the first public IP address corresponding to the target NAT address from the preset mapping relationship, wherein the preset mapping relationship includes a one-to-one correspondence between multiple NAT addresses and multiple IP addresses.

[0078] Optionally, in one specific implementation of this application, such as Figure 2 and Figure 3 As shown, when the calling terminal device initiates a call, if the INVITE message (i.e., call request) does not carry "X-Auth-IP" or if "X-Auth-IP" is an internal network IP address, the backend service checks whether the "X-Auth-IP" field is missing or is an internal network IP address. It then proactively sends an extended 18X (e.g., an extended 189 SIP response message) SIP response message to the calling terminal device. The response message header field contains "P-Early-Media:sendrecv," and the SDP in the message body carries the public IP address of the backend service, instructing the calling terminal device to send the first RTP mute packet to the public IP address of the backend service. Simultaneously, a short timer is started to wait for this RTP mute packet.

[0079] Before the call is answered, after the calling terminal device receives the 18X response information from the server, if the calling terminal device supports processing 18X messages, it will check the "P-Early-Media:sendrecv" header field stored in the 18X response information and send the first RTP silence data to the IP and port specified by the SDP of the backend service; if the calling terminal device does not support processing 18X messages, it will discard the message without any processing.

[0080] After a short timer is started, the backend service receives the first RTP silence packet sent by the calling terminal device within a specified time (configurable, typically below 300 milliseconds). The backend service then parses the source address and port of the first RTP silence packet from the calling terminal device, which is the obtained NAT address of the calling terminal device. In this case, the public IP address information of the terminal device initiating the call is obtained before the call is answered.

[0081] If the backend service does not receive the first RTP silence packet from the calling terminal device within a specified time after the short timer starts, and fails to obtain the NAT address of the terminal device before forwarding the call to the called party, in this case, the NAT address of the calling terminal device is obtained through the call connection process, the call is sent to the called party, the called party responds with 200 OK to connect the call, the backend service forwards the 200 OK to the calling terminal device, and carries the public IP address and port of the backend service in the SDP;

[0082] After the called party answers the call, the calling party's terminal device is in a call state and sends second RTP media data (audio and video data) to the backend service. The backend service receives the second RTP silence data packet sent by the terminal device, parses it, and obtains the source IP address and port of the second RTP silence data packet, which is the obtained NAT address of the terminal device. In this case, after the call is answered, the IP information of the terminal device that initiated the call is successfully obtained.

[0083] Optionally, in the embodiments of this application, this application can adaptively adopt corresponding technical means (such as the device actively carrying IP reporting, the backend server actively probing through extended SIP protocol, and obtaining from the terminal device's RTP stream after connection) according to the support capabilities of the calling terminal device, to obtain the public IP address of the terminal device under the NAT network environment, thereby maximizing the support range of the device, minimizing the modification of existing network devices and network elements, and obtaining the public IP address of the device after NAT as early as possible at the beginning of the call (before the call is forwarded to the called party).

[0084] For the terminal device on the calling end, the solution supports carrying the public IP address after NAT in the SIP protocol (for example, extending the X-Auth-IP field, or other methods) and actively reporting it. At the same time, after the call is connected, the solution can verify the first public IP address reported by the calling end and the second public IP address of the calling end terminal device obtained from the second RTP stream address of the calling end terminal device after the call is connected.

[0085] For a calling terminal device that supports the early media functions of SIP in IP Multimedia Subsystem (IMS), before the call is sent to the called party, the backend service proactively sends an extended 18X response message, triggering the calling terminal device to proactively send a first RTP media silence packet to the backend service's IP and port. Through this packet, the backend service detects the IP address behind the NAT of the terminal device. For devices that do not support the first two technical solutions, the backend service forwards the call message to the called party. After the call is connected, the backend service obtains the public IP address behind the NAT of the terminal device from the second RTP media packet sent by the calling terminal device to the backend service's IP and port. Therefore, the technical solution of this application can obtain the NAT (NAT network, F5 network) address of the calling terminal device in various network environments, thereby obtaining the public IP address of the calling party.

[0086] The calling method provided by the second aspect of this application is described below. For example... Figure 4As shown, this method is applied to the calling end, and the method specifically includes the following steps:

[0087] S400 stores the current public IP address in the address field under the current network environment;

[0088] S500, the address field is stored in the call request, and the call request containing the address field is sent to the backend service. The call request is used to call the called party.

[0089] S600, upon receiving SIP response information sent by the backend service according to the call request, if the calling end and the called end fail to connect successfully, the backend service sends first RTP mute data to the backend service according to the address information of the backend service in the SIP response information, so that the backend service can determine the first public IP address of the calling end that initiated the call based on the first RTP mute data.

[0090] Optionally, in this embodiment, in step S400, the calling end first needs to determine the public IP address in the current network environment. This can be achieved by querying network configuration, using an API to call a specific service, or by sending special network packets and listening for responses. Once the public IP address is successfully obtained, it is stored in an address field, which can be part of a data structure used to store various information related to the call.

[0091] Next, in step S500, the system adds the address field containing the public IP address to the call request. The call request is a data packet containing various information used to notify the backend service that a call request has occurred and to request the establishment of a communication connection with the called party. In addition to the public IP address, this request may also include the caller's identifier, the called party's identifier, the call type (such as voice, video, etc.), and other relevant parameters. This call request is then sent to the backend service for further processing.

[0092] Finally, in step S600, the system waits for a response from the backend service. When the backend service receives the call request, it sends a SIP response message to the calling end. At this time, the calling end sends a first RTP silent packet to the backend service based on the backend service address information in this response message. Upon receiving this packet, the backend service parses the information within it and determines the public IP address of the calling end that sent the packet. This address can then be used for various purposes, such as logging call information, troubleshooting, or network optimization.

[0093] In these optional embodiments, the calling method provided by the second aspect of this application cleverly incorporates a mechanism for acquiring and transmitting public IP addresses during the calling process. Through steps S400 and S500, the calling end can capture its current public IP address in real time and store it as an address field in the call request, sending it to the backend service. This mechanism not only ensures the accuracy and real-time nature of the public IP address but also greatly simplifies the complex process of the backend service obtaining the calling end's public IP address when establishing a communication connection. If the call is not established, through step S600, the calling end can proactively send first RTP silence data to the backend service based on the SIP response information returned by the backend service. Through this data packet, the backend service can accurately determine the first public IP address used by the calling end when initiating the call. This not only helps the backend service troubleshoot and optimize the network but also provides the calling end with more reliable and efficient communication assurance.

[0094] In one embodiment, the method further includes:

[0095] If the calling end and the called end successfully connect, and the calling end receives connection information and address information sent by the backend service, then the calling end sends second RTP silence data to the backend service according to the address information, so that the backend service can determine the second public IP address of the calling end that initiated the call based on the second RTP silence data. The address information is used to indicate the address of the backend service, and the connection information is used to indicate that the calling end and the called end have successfully communicated.

[0096] Optionally, in one specific implementation of this application, such as Figure 5 As shown, the calling terminal actively detects its public IP address information under NAT and carries this public IP information in the extended field "X-Auth-IP" of the SIP call request INVITE. Carrying the calling terminal's NAT public IP address through the extended field "X-Auth-IP" is just one specific technical implementation method; this example is provided for ease of explanation. Through alternative methods, SIP can also be implemented with NAT public IP information (including cases where symmetric encryption is applied to the public IP information), which can also be included in the scheme of this application.

[0097] Subsequently, the backend service determines whether the INVITE message sent by the calling terminal device contains an "X-Auth-IP" field (in some cases, the terminal device may not support the extended "X-Auth-IP" field) or whether the "X-Auth-IP" field is a public IP address. If the IP information obtained from the "X-Auth-IP" field is a public IP address, the obtained IP address can be verified to determine whether it is the user's real public IP address or a forged IP address in the signaling. If the public IP address of the terminal device cannot be obtained from the "X-Auth-IP" field, the public IP address of the terminal device is probed and obtained through the SIP call process. For the specific process, please refer to the call method of the first aspect embodiment above, which will not be repeated here.

[0098] Optionally, in the embodiments of this application, by obtaining the NAT address of the terminal device initiating the SIP call through the technical solution of this application, it is possible to adapt to various network operating environments of the terminal device to the greatest extent and to maximize compatibility with the device's support capabilities. Based on the standard IMS SIP call process, the modification of existing terminal devices and network devices is minimized, which can effectively reduce modification costs and improve the security control of IP address-based calls.

[0099] Optionally, this application proposes a method to obtain the public IP address of the calling terminal device during the entire SIP call process (when the call comes in, before the call is forwarded to the called party, when the call is forwarded to the called party, and after the call is connected), depending on the capabilities supported by the calling terminal device and the actual network environment. This method employs various approaches, including the device actively reporting its IP address, the backend service actively probing via extended SIP protocol, and obtaining the public IP address from the second RTP stream of the calling terminal device after connection. The public IP address obtained through this application maximizes compatibility with various network operating environments of different terminal devices. Furthermore, the standard IMS-based SIP call process minimizes the need for modifications to existing terminal and network equipment, effectively reducing modification costs. Additionally, this application provides accurate public IP addresses of the calling terminal device, improving the accuracy and timeliness of IP address-based call security management and reducing misjudgments in call security management.

[0100] In these optional embodiments, in some SIP-based audio and video calling systems, considering system and application security, it is necessary to filter and block some illegal calls (such as SIP application probe calls from overseas IPs) by checking the real IP address of the calling terminal device before each call is initiated, according to call control security rules. Therefore, it is necessary to obtain the real public IP address information of the calling terminal device before each call. The calling terminal device and the SIP audio and video communication system are deployed in various network environments (NAT network environment, F5 network environment). Accurately and efficiently obtaining the real public IP address information of the calling terminal device helps improve the effectiveness and timeliness of call security control based on the calling terminal's IP address, enhances the security of the SIP-based audio and video calling system, and helps prevent and reduce telephone attack incidents.

[0101] Figure 6 A schematic diagram of the structure of a calling device provided in a third aspect embodiment of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0102] Reference Figure 6 The calling device is used in backend services and may include:

[0103] The receiving module 601 is used to receive a call request sent by the calling end, the call request being used to call the called end;

[0104] The first sending module 602 is used to send Session Initiation Protocol (SIP) response information to the calling end if the address in the address field does not conform to a preset address rule when the call request carries an address field. The preset address rule is used to indicate whether the address field contains the real public IP address of the calling end that initiated the call.

[0105] The determining module 603 is used to determine the first public IP address of the calling end that initiated the call if, within a preset time, it receives first Real-Time Transport Protocol (RTP) silence data sent by the calling end according to the SIP response information, when the calling end and the called end fail to connect successfully.

[0106] In one embodiment, the calling device may further include:

[0107] The fourth sending module is used to send the address information of the backend service and the connection information to the calling end if, in the case that the first RTP silence data sent by the calling end according to the SIP response information is not received within a preset time, the calling end receives the connection information sent by the calling end in response to the called end. The connection information is used to indicate that the calling end and the called end have successfully communicated, and the address information is used to indicate the address of the backend service.

[0108] The second receiving module is used to receive the second RTP mute data sent by the calling terminal according to the address information during a call.

[0109] The parsing module is used to parse the second RTP mute data to obtain the second public IP address of the calling end that initiated the call.

[0110] In one embodiment, the calling device may further include:

[0111] The first acquisition module is used to, when the call request carries the address field, if the address field conforms to the preset address rule, then obtain the third public IP address of the calling party that initiated the call from the address field.

[0112] In one embodiment, the calling device may further include:

[0113] The verification module is used to verify the second public IP address and the third public IP address to obtain a verification result, which is used to indicate whether the second public IP address and the third public IP address are consistent.

[0114] In one embodiment, the determining module may include:

[0115] The first acquisition submodule is used to acquire the target network address translation (NAT) address of the calling terminal from the first RTP mute data;

[0116] The second acquisition submodule is used to obtain the first public IP address corresponding to the target NAT address from a preset mapping relationship. The preset mapping relationship includes a one-to-one correspondence between multiple NAT addresses and multiple IP addresses.

[0117] Figure 7 A schematic diagram of the structure of a calling device provided in a fourth aspect embodiment of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0118] Reference Figure 7 The calling device is used at the calling end and may include:

[0119] Storage module 701 is used to store the current public IP address in the address field under the current network environment;

[0120] The second sending module 702 is used to store the address field in a call request and send the call request containing the address field to the backend service. The call request is used to call the called party.

[0121] The third sending module 703 is used to send first RTP mute data to the backend service based on the address information of the backend service in the SIP response information if the calling end and the called end fail to connect successfully when receiving SIP response information sent by the backend service according to the call request, so that the backend service can determine the first public IP address of the calling end that initiated the call based on the first RTP mute data.

[0122] In one embodiment, the calling device may further include:

[0123] The fifth sending module is used to, when the calling end and the called end have successfully connected, if it receives connection information and address information sent by the backend service, send second RTP silence data to the backend service according to the address information, so that the backend service can determine the second public IP address of the calling end that initiated the call based on the second RTP silence data. The address information is used to indicate the address of the backend service, and the connection information is used to indicate that the calling end and the called end have successfully communicated.

[0124] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. They are devices corresponding to the above-mentioned battery thermal runaway early warning method. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of this device. For details on its specific functions and the technical effects it brings, please refer to the method embodiment section. It will not be repeated here.

[0125] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0126] Figure 8 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0127] The device may include a processor 801 and a memory 802 storing program instructions.

[0128] When processor 801 executes the program, it implements the steps in any of the above method embodiments.

[0129] For example, the program can be divided into one or more modules / units, one or more of which are stored in memory 802 and executed by processor 801 to complete this application. The one or more modules / units can be a series of program instruction segments capable of performing a specific function, which describe the execution process of the program in the device.

[0130] Specifically, the processor 801 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0131] Memory 802 may include mass storage for data or instructions. For example, and not limitingly, memory 802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 802 may include removable or non-removable (or fixed) media. Where appropriate, memory 802 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 802 is non-volatile solid-state memory.

[0132] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0133] The processor 801 implements any of the methods described in the above embodiments by reading and executing program instructions stored in the memory 802.

[0134] In one example, the electronic device may also include a communication interface 803 and a bus 810. The processor 801, memory 802, and communication interface 803 are connected via the bus 810 and communicate with each other.

[0135] The communication interface 803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0136] Bus 810 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 810 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0137] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores program instructions; when these program instructions are executed by a processor, they implement any of the methods in the above embodiments.

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

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

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

[0141] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0142] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0143] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0144] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0145] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A calling method, characterized in that, Applied to backend services, the method includes: Receive a call request sent by the calling party, the call request being used to call the called party; If the address field is included in the call request, and the address in the address field does not conform to the preset address rule, then a Session Initiation Protocol (SIP) response message is sent to the calling end. The preset address rule is used to indicate whether the address field contains the real public Internet Protocol (IP) address of the calling end that initiated the call. If the caller and the called party fail to connect, and if the caller receives first Real-Time Transport Protocol (RTP) silence data sent by the caller based on the SIP response information within a preset time, then the first public IP address of the caller that initiated the call is determined based on the first RTP silence data. The method further includes: If the first RTP mute data sent by the calling end according to the SIP response information is not received within the preset time, and if the callee responds to the connection information sent by the calling end, the address information of the backend service and the connection information are sent to the calling end. The connection information is used to indicate that the calling end and the callee have successfully communicated, and the address information is used to indicate the address of the backend service. Receive the second RTP mute data sent by the calling terminal based on the address information during a call; The second public IP address of the calling terminal is obtained by parsing the second RTP mute data; If the first RTP silence data sent by the calling end according to the SIP response information is not received within a preset time, and if the callee responds to the connection information sent by the calling end, before sending the address information of the backend service and the connection information to the calling end, the method further includes: If the address field is included in the call request, and the address field conforms to the preset address rule, then the third public IP address of the calling party that initiated the call is obtained from the address field. After parsing the second RTP mute data to obtain the second public IP address of the calling end that initiated the call, the method further includes: The second public IP address and the third public IP address are verified to obtain a verification result, which is used to indicate whether the second public IP address and the third public IP address are consistent.

2. The method according to claim 1, characterized in that, The step of determining the first public IP address of the calling end that initiated the call based on the first RTP silence data includes: Obtain the target network address translation (NAT) address of the calling terminal from the first RTP mute data; Obtain the first public IP address corresponding to the target NAT address from the preset mapping relationship, wherein the preset mapping relationship includes a one-to-one correspondence between multiple NAT addresses and multiple IP addresses.

3. A calling method, characterized in that, Applied to the calling end, the method includes: The current public IP address in the current network environment will be stored in the address field; The address field is stored in the call request, and the call request containing the address field is sent to the backend service. The call request is used to call the called party. Upon receiving the SIP response information sent by the backend service in accordance with the call request, if the calling end and the called end fail to connect successfully, the calling end sends first RTP mute data to the backend service based on the address information of the backend service in the SIP response information, so that the backend service can determine the first public IP address of the calling end that initiated the call based on the first RTP mute data.

4. The method according to claim 3, characterized in that, The method further includes: If the calling end and the called end successfully connect, and the calling end receives connection information and address information sent by the backend service, then the calling end sends second RTP silence data to the backend service according to the address information, so that the backend service can determine the second public IP address of the calling end that initiated the call based on the second RTP silence data. The address information is used to indicate the address of the backend service, and the connection information is used to indicate that the calling end and the called end have successfully communicated.

5. A calling device, characterized in that, The device is used for backend services and includes: A receiving module is used to receive a call request sent by the calling end, the call request being used to call the called end; The first sending module is used to send Session Initiation Protocol (SIP) response information to the calling end if the address in the address field does not conform to a preset address rule when the call request carries an address field. The preset address rule is used to indicate whether the address field contains the real public IP address of the calling end that initiated the call. The determination module is used to determine the first public IP address of the calling end that initiated the call if, within a preset time, it receives first Real-Time Transport Protocol (RTP) silence data sent by the calling end according to the SIP response information, when the calling end and the called end fail to connect successfully. The first sending module is further configured to, if it does not receive the first RTP silence data sent by the calling end according to the SIP response information within a preset time, send the address information of the backend service and the connection information to the calling end if it receives the connection information sent by the calling end in response to the called end. The connection information is used to indicate that the calling end and the called end have successfully communicated, and the address information is used to indicate the address of the backend service. The receiving module is also used to receive second RTP mute data sent by the calling terminal according to the address information during a call; The parsing module is used to parse the second RTP mute data to obtain the second public IP address of the calling end that initiated the call; The acquisition module is used to, if it does not receive the first RTP silence data sent by the calling end according to the SIP response information within a preset time, and if it receives the connection information sent by the calling end in response to the called end, before sending the address information of the backend service and the connection information to the calling end, if the address field is carried in the call request and the address field conforms to the preset address rule, then it obtains the third public IP address of the calling end that initiated the call from the address field. The verification module is used to verify the second public IP address and the third public IP address after parsing the second RTP silence data to obtain the second public IP address of the calling end. The verification result is used to indicate whether the second public IP address and the third public IP address are consistent.

6. A calling device, characterized in that, The device, applied to a calling terminal, includes: The storage module is used to store the current public IP address in the address field under the current network environment; The second sending module is used to store the address field in a call request and send the call request containing the address field to the backend service. The call request is used to call the called party. The third sending module is used to send first RTP mute data to the backend service based on the address information of the backend service in the SIP response information if the calling end and the called end fail to connect successfully, upon receiving SIP response information sent by the backend service according to the call request, so that the backend service can determine the first public IP address of the calling end that initiated the call based on the first RTP mute data.

7. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the calling method as described in any one of claims 1-4.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the calling method as described in any one of claims 1-4.

9. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device causes the electronic device to perform the calling method as described in any one of claims 1-4.

Images