A method for sharing an IPTV real-time picture to a mobile terminal for playing

Abstract

This invention relates to a method for sharing real-time IPTV content to a mobile terminal for playback, belonging to the field of wireless communication and terminals. The method includes: the IPTV device and the mobile terminal sending a STUN request to a public STUN server to bypass NAT and automatically obtain the corresponding public IP address; the IPTV device and the mobile terminal establishing an IPSec encrypted tunnel based on the IPSec protocol; the IPTV device receiving the operator's playback stream, extracting video and audio data, re-encapsulating it into RTP format, encrypting it, and transmitting it to the mobile terminal through the IPSec encrypted tunnel; the mobile terminal decrypting and verifying the integrity of the data packets, extracting the RTP payload, and playing the corresponding video and audio data in real time; the mobile terminal sending control commands to the IPTV device through the IPSec encrypted tunnel; the IPTV device parsing the control commands and calling an API to switch channels, synchronously updating the electronic program guide information to the mobile terminal. This method enables mobile devices to remotely receive and play television channel content from a home IPTV device via the public network, overcoming spatial limitations.

Description

Technical Field

[0001] This invention belongs to the field of wireless communication and terminals, and particularly relates to a method for sharing real-time IPTV video to a mobile terminal for playback. Background Technology

[0002] IPTV devices are interactive network televisions, which utilize broadband cable television networks and integrate multiple technologies such as the Internet, multimedia, and communications to provide home users with a variety of interactive services, including digital television.

[0003] Currently, most IPTV playback devices (such as set-top boxes) are based on the Android system and play TV channels through software terminals. However, users can only watch through fixed terminals (such as TVs), which lacks mobility.

[0004] Existing solutions for watching IPTV on mobile devices rely on streaming media servers for relay or public network push, which has the following drawbacks: 1. Relies on the stability of the network environment; public network transmission is easily affected by bandwidth limitations or latency.

[0005] 2. Additional servers need to be deployed, increasing costs and maintenance complexity; 3. Insufficient security; user data (such as accounts and playback content) is easily intercepted or tampered with.

[0006] 4. High device dependence: Users need to be stationary in front of the TV to watch, lacking mobility.

[0007] 5. Lack of remote access: Existing IPTV systems do not provide a standardized solution for remotely receiving and playing TV channels via mobile devices.

[0008] 6. Difficulty in network penetration: Home IPTV devices are usually located behind NAT / firewalls, making it difficult for mobile devices to establish direct end-to-end communication.

[0009] 7. Insufficient transmission security: Transmitting TV streaming media over the public network poses a risk of data leakage and lacks encryption protection mechanisms.

[0010] Current technologies do not allow mobile terminals to securely and with low latency remotely access home IPTV devices. Traditional remote desktop / VPN, OTT streaming services, and DLNA / Miracast protocols each have their own shortcomings: 1. Remote desktop / VPN only enables screen mirroring and cannot be optimized for IPTV streaming media features (such as dynamic bitrate and multicast to unicast), and it relies on a fixed public IP address.

[0011] 2. OTT streaming services (such as YouTube TV): These require transit through the operator's content delivery network (CDN), and are subject to copyright restrictions and additional traffic costs.

[0012] 3. DLNA / Miracast protocol: Only supports interconnection between devices within a local area network and cannot penetrate NAT to achieve remote access. Summary of the Invention

[0013] In view of the shortcomings of the existing technology, the purpose of the invention is to provide a method for sharing real-time IPTV video to mobile terminals for playback, enabling mobile devices to remotely receive and play TV channel content from home IPTV devices via the public network, thus breaking through spatial limitations.

[0014] This invention proposes a method for sharing real-time IPTV video to a mobile terminal for playback, comprising: S1. Start the STUN client. The IPTV device and the mobile terminal send a STUN request to the public STUN server. The public STUN server works with the IPTV device and the mobile terminal to penetrate the NAT device and automatically obtain the corresponding public network address. S2, the IPTV device and the mobile terminal establish an IPSec encrypted tunnel based on the IPSec protocol to achieve two-way authentication and dynamic key negotiation between the devices, including: The mobile terminal sends an IKE_SA_INIT request to the public address of the IPTV device. The IPTV device responds to the IKE_SA_INIT request, confirms the parameters, and generates a temporary key. Based on the temporary key generated by IKE_SA_INIT, the transmission is encrypted. The IPTV device and the mobile terminal exchange IKE_AUTH messages and verify their identities, generating an IPSec security association (IPSec SA) security parameter set to establish an IPSec encrypted tunnel between the two parties. S3, the IPTV device receives the operator's playback stream, extracts the video and audio data from the operator's playback stream, re-encapsulates it into RTP format, and transmits it to the mobile terminal through an IPSec encrypted tunnel after encryption; the mobile terminal decrypts and verifies the integrity of the data packet, extracts the RTP payload, and plays the corresponding video and audio data in real time. S4. When the mobile terminal receives a channel switching command triggered by the user through the APP, it sends the control command to the IPTV device through the IPSec encrypted tunnel. The IPTV device parses the control command and calls the API to switch channels, and synchronously updates the electronic program guide information to the mobile terminal.

[0015] Further, in S1, the IPTV device and the mobile terminal send a STUN Binding Request, which is then sent to the public STUN server after being mapped by the NAT device. The STUN Binding Request carries the SOFTWARE attribute to identify the client type. The public STUN server returns a STUN response, which is mapped back to the IPTV device and mobile terminal according to the NAT type. The STUN response carries the public network address of the IPTV device and mobile terminal.

[0016] Furthermore, in S1, the STUN client built into the IPTV device periodically sends a Binding request to the public STUN server to obtain its own public IP address. The STUN client built into the mobile terminal runs independently of the IPTV device. It obtains the public IP address of the mobile terminal behind NAT and automatically performs STUN detection when the APP starts. If the detection fails, it prompts the user to check the network configuration.

[0017] Furthermore, in S1, the traversal strategy for cascaded NAT devices includes: if the IPTV device is located behind a multi-layer NAT device, the outermost STUN address is preferentially used as the communication endpoint.

[0018] Furthermore, in S2, the mobile terminal selects the optimal IPTV device to establish an IPSec encrypted tunnel based on the public network latency RTT returned by the STUN server.

[0019] Furthermore, in S2, after the IPSec SA is established, the IPTV device sends a test UDP packet to the public address of the mobile terminal through the STUN server to verify the authenticity of the address; the mobile terminal needs to return a response packet within a preset time period, otherwise the establishment of the IPSec encrypted tunnel will be terminated.

[0020] Furthermore, in S2, if the STUN server detects symmetric NAT, the IPTV device sends a USE_TRANSPORT_MODE notification during the IKE_AUTH phase to force the use of the transport mode; the mobile terminal listens on UDP port 4500, receives ESP-over-UDP packets, and maintains a heartbeat via STUN to prevent NAT mapping timeout.

[0021] Furthermore, in S2, the IPTV device and the mobile terminal exchange IKE_AUTH messages to verify their identities using a pre-set digital certificate or a pre-shared key.

[0022] Furthermore, in S3, the IPTV device uses the encryption key Enc_Key to encrypt the RTP packet using AES-CBC and calculates the HMAC-SHA256 integrity check value, which is then sent to the mobile terminal through the IPSec encrypted tunnel.

[0023] Furthermore, when the following abnormal scenarios are detected, corresponding abnormal handling strategies will be adopted respectively: When the STUN server is detected as unreachable, it falls back to the default NAT-T mode, limiting the maximum number of concurrent connections to 2, and prompts the user to check the network. When a conflict is detected between the STUN server return address and the local configuration, the IPSec protocol is renegotiated, forcing the use of NAT-T and logging the conflict. When frequent changes in NAT mapping are detected, the STUN probe interval is shortened to 10 seconds, and the video bitrate is reduced to 2 Mbps to reduce the impact of network fluctuations.

[0024] The beneficial effects of this invention are as follows: The method described in this invention enables mobile devices (such as mobile phones) to remotely receive and play television channel content from home IPTV devices via the public network, breaking through spatial limitations.

[0025] 1. This invention is the first to apply the STUN+IPSec combination to the IPTV field, enabling configuration-free, secure communication between mobile terminals and fixed devices across the public network. The STUN+IPSec collaborative mechanism can solve the dual requirements of NAT traversal and secure transmission, establishing a reliable communication tunnel between mobile devices and IPTV devices.

[0026] 2. This invention enables end-to-end streaming media forwarding: IPTV devices directly serve as streaming media sources, avoiding latency and image quality loss introduced by relay servers.

[0027] 3. This invention achieves dynamic tunnel and traffic collaborative optimization: It automatically adjusts IPSec parameters (such as encryption algorithms and retransmission mechanisms) and playback stream bitrate according to network status. Such a joint optimization strategy is not disclosed in the prior art.

[0028] 4. This invention achieves a lightweight design: adaptable to resource-constrained mobile devices and IPTV hardware.

[0029] 5. This invention achieves operator compatibility: It does not modify the existing IPTV software terminal architecture, only requires adding forwarding functionality. This invention is compatible with existing Android system IPTV devices, requiring no hardware modifications or upgrades to operator infrastructure, only software updates, resulting in low deployment costs.

[0030] 6. This invention ensures the security of transmitted content and prevents data leakage or tampering. This invention employs IPSec encryption to prevent content theft or alteration, thus enhancing security.

[0031] 7. This invention reduces transmission latency, ensuring smooth live TV playback. Users can watch TV channels anytime, anywhere via their mobile phones, enhancing the user experience.

[0032] 8. This invention does not require a third-party relay server, and balances security, low latency, and ease of use. It is suitable for scenarios such as home entertainment and operator value-added services, filling the technological gap for remote IPTV viewing on mobile devices and has strong market competitiveness. Attached Figure Description

[0033] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.

[0034] Figure 1 This is a flowchart illustrating a method for sharing real-time IPTV video to a mobile terminal for playback, according to an embodiment of the present invention. Detailed Implementation

[0035] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0036] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.

[0037] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0038] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.

[0039] This invention proposes a method for sharing real-time IPTV video to mobile terminals for playback. It is an IPTV mobile playback method based on STUN service and IPSec tunnel. This method can realize secure interconnection and playback streaming between mobile terminals (such as mobile phones) and home IPTV devices without the need for third-party relay servers. It balances security, low latency and ease of use, and is suitable for scenarios such as home entertainment and operator value-added services.

[0040] like Figure 1 As shown, the present invention proposes a method for sharing real-time IPTV video to a mobile terminal for playback, comprising: S1. Start the STUN client. IPTV devices and mobile terminals send STUN requests to the public STUN server. The public STUN server works with the IPTV devices and mobile terminals to bypass NAT devices and automatically obtain the corresponding public network addresses.

[0041] Specifically, IPTV devices and mobile terminals send STUN Binding Request requests, which are then mapped by the NAT device and sent to the public STUN server. The public STUN server returns a STUN response, which is then mapped back to the IPTV devices and mobile terminals according to the NAT type. The STUN response carries the public IP addresses of the IPTV devices and mobile terminals.

[0042] 1. Perform STUN detection on the IPTV device side: The built-in STUN client of the IPTV device periodically (every 30 seconds by default) sends a Binding request to a public STUN server (such as stun.l.google.com:19302). This request carries the SOFTWARE attribute to identify the client type (such as "IPTV-STUN-Client / 1.0"). The IPTV device receives the Binding Response and obtains its own public IP address (MAPPED-ADDRESS:port) and RESPONSE-ORIGIN (server source address).

[0043] The public IP address of the IPTV device includes its own public IP address and port mapping (e.g., 203.0.113.45:5004), recorded as IPTV_Public_Addr. The public IP address / port obtained by STUN is written into the IPSec SA database as the tunnel endpoint address.

[0044] The STUN client built into the IPTV device supports the STUN protocol RFC 5389 standard and parses the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes. XOR-MAPPED-ADDRESS is an address attribute defined in the STUN protocol, which sends the public IP address and port after NAT translation during NAT traversal.

[0045] It should be noted that when STUN detection fails, IPTV devices can try manually opening UDP ports 500 / 4500 on the router via the UPnP protocol and record the operation log for users to troubleshoot.

[0046] 2. Perform STUN detection on the mobile terminal side: The STUN client built into the mobile terminal runs independently of the IPTV device. It obtains the public IP address of the mobile terminal behind NAT, Mobile_Public_Addr (e.g., 198.51.100.67:3478), and automatically performs STUN detection when the APP starts. If the detection fails, it prompts the user to check the network configuration (e.g., whether the firewall allows UDP port 19302).

[0047] In this invention, enterprises can build their own public STUN servers (based on the Coturn / Restund open-source solution) and deploy them on public cloud servers (such as AWS EC2), avoiding reliance on third-party services. The public STUN servers are configured with TLS encryption (STUNover DTLS) to prevent man-in-the-middle attacks, and the certificates are issued by authoritative CAs.

[0048] In this invention, the traversal strategy for cascaded NAT devices includes: if the IPTV device is located behind multiple layers of NAT (such as an enterprise firewall + home router), the outermost STUN server address (with the smallest RTT) is preferentially used as the communication endpoint. The STUN server address is used to establish an IPsec tunnel. STUN is an assistant that helps devices discover and establish direct communication paths; its core purpose is NAT traversal, helping devices behind firewalls / NATs discover their public IP addresses and ports to establish point-to-point direct connections. IPsec provides secure communication, offering encryption, authentication, and integrity verification for IP layer data packets, establishing a secure private tunnel.

[0049] For example, if the enterprise's NAT public IP is A and the home's NAT public IP is B, then B should be selected as the IPSec tunnel target address to reduce the number of hops.

[0050] The logic for determining NAT type and the penetration measurement are explained below with reference to Table 1.

[0051] Table 1 NAT Type Determination Logic S2: IPTV devices and mobile terminals establish an IPSec encrypted tunnel based on the IPSec protocol to achieve two-way authentication and dynamic key negotiation between devices.

[0052] Specifically, dynamic path selection is performed first: The mobile terminal selects the optimal IPTV device to establish an IPSec encrypted tunnel based on the public network latency RTT returned by the STUN server.

[0053] For optimal IPTV equipment, for example: if the RTT of a home network is <50ms, it should be connected first; if the RTT of a 4G network is >200ms, it should be downgraded to an IPTV equipment with a bitrate of 720P.

[0054] Users can click "Connect to IPTV" in the app to initiate the first phase of IPSec IKE (Internet Key Exchange) negotiation. First, the mobile terminal sends an IKE_SA_INIT request to the public IPTV address of the selected IPTV device, IPTV_Public_Addr. The IPTV device responds to the IKE_SA_INIT request, confirms the parameters, and generates a temporary key.

[0055] The IKE_SA_INIT request includes: supported encryption algorithms (such as AES-256), hash algorithms (SHA-256), and Diffie-Hellman groups (such as Group 14).

[0056] Then, authentication and key generation: the temporary key generated by IKE_SA_INIT is encrypted and transmitted. The IPTV device and the mobile terminal exchange IKE_AUTH messages and verify their identities, generate the IPSec security association IPSec SA security parameter set, and realize the establishment of IPSec encrypted tunnel between the two parties.

[0057] In this invention, the IPTV device and the mobile terminal exchange IKE_AUTH messages to verify their identities using a pre-set digital certificate or a PSK pre-shared key.

[0058] The IPSec SA (Security Association) security parameter set includes: encryption key (Enc_Key), integrity key (Auth_Key), and validity period (e.g., 8 hours).

[0059] In this invention, STUN data injection during IKEv2 negotiation: In the IKE_INIT exchange, the IPTV device fills the public IP address obtained by STUN (such as 203.0.113.45:5004) into the NAT source address NAT-OA (NAT Originating Address) payload.

[0060] Once received, the mobile terminal verifies whether the address matches its own STUN probe results to prevent address spoofing attacks. This step primarily verifies the legitimacy of the STUN server, typically through methods such as signature verification, to prevent the STUN server's domain name from being hijacked.

[0061] This invention implements a collaborative security mechanism of STUN and IPSec: After the IPSec SA is established, the IPTV device sends a test UDP packet (with HMAC-SHA256 signature) to the public address of the mobile terminal through the STUN server to verify the authenticity of the address.

[0062] The mobile terminal must return a response packet within a preset time (e.g., 5 seconds), otherwise the establishment of the IPSec encrypted tunnel will be terminated.

[0063] Furthermore, this invention performs NAT-T dynamic port switching: If the STUN server detects a symmetric NAT, the IPTV device sends a USE_TRANSPORT_MODE notification during the IKE_AUTH phase to force the use of transport mode, thus avoiding the double encapsulation problem in tunnel mode. The USE_TRANSPORT_MODE notification specifies the configuration parameters for IPsec to operate in transport mode.

[0064] During the IKEv2 negotiation phase, if NAT is detected on the IPTV device (triggered by the CHANGE-REQUEST attribute returned by STUN), the NAT-T mechanism is automatically enabled to encapsulate ESP protocol data in UDP port 4500.

[0065] The mobile terminal listens on UDP port 4500, receives ESP-over-UDP packets for IPsec NAT-T, and maintains a heartbeat via STUN to prevent NAT mapping timeout. The STUN heartbeat is maintained by sending a BindingRequest every 60 seconds to prevent NAT mapping timeout.

[0066] This invention prevents replay attacks in the following ways: The STUN Binding Request carries the USERNAME and MESSAGE-INTEGRITY attributes and generates an HMAC checksum using a pre-shared key (PSK).

[0067] IPSec tunnel keys and STUN keys are rotated periodically (default 24 hours) to avoid the risk of long-term key exposure.

[0068] If it's a NAT address, the client will first request the STUN server to establish a peer-to-peer connection. Then, a secure IPSec tunnel will be established, and the IPTV data stream will be forwarded through this connection.

[0069] S3: The IPTV device receives the operator's playback stream, extracts the video and audio data from the stream, repackages it into RTP format, and transmits it to the mobile terminal through an IPSec encrypted tunnel after encryption. The mobile terminal decrypts and verifies the integrity of the data packet, extracts the RTP payload, and plays the corresponding video and audio data in real time.

[0070] Specifically, IPTV devices receive IPTV streams from operators (such as UDP multicast 239.255.255.1:5004) via a built-in soft terminal, decapsulate the original stream (such as MPEG-TS), and extract the video (H.264) and audio (AAC) data from the operator's playback stream. Then, the video (H.264) and audio (AAC) data are recapsulated into RTP format, timestamps and sequence numbers are added, adapted for mobile network transmission, and then encrypted before being directly transmitted to the mobile terminal via a PSec encrypted tunnel.

[0071] The process involves repackaging the data into RTP format, as detailed below: RTP Header (12B) | H.264 NALU (variable length) | AAC Frame (variable length) In this invention, the IPTV device uses the encryption key Enc_Key to encrypt the RTP packet (i.e., video and audio data repackaged into RTP format) with AES-CBC, calculates the HMAC-SHA256 integrity check value, and sends it to the mobile terminal Mobile_Public_Addr through the IPSec encrypted tunnel (UDP encapsulation, destination port 4500).

[0072] It should be noted that IPTV devices dynamically adjust the bitrate during transmission: by estimating and monitoring the current network bandwidth in real time through TCP RTT, if the bandwidth drops below 2Mbps, it switches to a lower bitrate level (such as from 8Mbps to 3Mbps).

[0073] The mobile terminal receives encrypted RTP packets, decrypts and verifies the integrity of the data packets, and extracts the RTP payload. Video data is decoded using the Android MediaCodec API and rendered and displayed via SurfaceView; audio data is played using AudioTrack.

[0074] Furthermore, this invention further implements NAT mapping maintenance: when the IPTV device is idle (no video stream transmission), it sends a STUN Keepalive packet every 5 minutes to prevent the operator's NAT device from releasing port mappings. If three consecutive STUN probes fail, the IPSec encrypted tunnel reconstruction process is triggered.

[0075] S4. When a user triggers a channel switching command via the APP, the mobile terminal sends the control command to the IPTV device through an IPSec encrypted tunnel. The IPTV device parses the control command and calls the API to switch channels, and simultaneously updates the electronic program guide information to the mobile terminal.

[0076] In this step, the mobile terminal decodes and plays the video in real time, and supports remote interactive control by the user (such as channel switching and volume adjustment). Users can send control commands through the mobile terminal to dynamically adjust playback parameters.

[0077] Specifically, when a user switches channels on their mobile phone, they send control commands in XML format (such as...) through the mobile terminal's app. <command type="channel_change" value="CCTV-1"> ), which transmits control commands through an IPSec tunnel.

[0078] IPTV devices parse control commands and call the soft terminal API to switch channels, and synchronously update EPG (Electronic Program Guide) information to mobile phones.

[0079] In this invention, the IPTV device periodically (every 30 seconds) sends a heartbeat packet containing data such as the current playback progress and signal strength, which is then updated and displayed on the mobile phone UI to provide playback status feedback.

[0080] In this invention, when the following abnormal scenarios are detected, corresponding abnormal handling strategies are adopted respectively.

[0081] The exception handling and fault tolerance mechanisms under different abnormal scenarios are explained in Table 2 below.

[0082] When the STUN server is detected as unreachable, it falls back to the default NAT-T mode, limiting the maximum number of concurrent connections to 2, and prompts the user to check the network. When a conflict is detected between the STUN server return address and the local configuration, the IPSec protocol is renegotiated, forcing the use of NAT-T and logging the conflict. When frequent changes in NAT mapping are detected, the STUN probe interval is shortened to 10 seconds, and the video bitrate is reduced to 2 Mbps to reduce the impact of network fluctuations.

[0083] Table 2 Exception Handling and Fault Tolerance Mechanisms The implementation environment and implementation steps of this invention are described below: 1. Implementation Environment Hardware: IPTV device with Android 9.0 or above, and smartphone that supports IPSec.

[0084] Software: The IPTV device integrates the STUN client library and IPSec driver; the mobile APP has a built-in tunnel management module.

[0085] 2. Implementation Steps (1) IPTV equipment configuration: Start the STUN client and periodically report the public IP address to the cloud server.

[0086] Listen for IPSec tunnel connection requests and verify the identity of mobile devices (such as pre-shared keys or digital certificates).

[0087] (2) Mobile device operation: Users select IPTV devices through the app, triggering STUN queries and tunnel establishment.

[0088] Receive encrypted streaming media data and call the hardware decoder to play it.

[0089] (3) Exception handling: Automatically reconnects when the IPSec encrypted tunnel is interrupted, and resumes playback from the most recent keyframe.

[0090] The method for sharing real-time IPTV video to a mobile terminal for playback according to the present invention can be applied to the following scenarios: 1. Home remote viewing When users are on business trips or traveling, they can remotely connect to their home IPTV device via their mobile phones to watch live TV channels (such as news and sports events) or on-demand programs in real time, so as not to miss important content.

[0091] Typical scenario: Parents monitor the TV content their children watch at home via their mobile phones from the office, or remotely switch channels for the elderly.

[0092] 2. Multi-device collaborative entertainment Family members can use multiple mobile phones / tablets to connect to the same IPTV device simultaneously, achieving "one person controls, multiple devices watch simultaneously", which is suitable for gatherings or multi-person interactive scenarios.

[0093] Extended applications: Combined with the screen mirroring function, IPTV content from your mobile phone can be projected onto a car screen or smartwatch.

[0094] 3. Value-added services provided by operators Telecom operators can integrate this technology into their IPTV packages to offer users a "mobile TV" add-on service, thereby increasing user stickiness and differentiating themselves from competitors.

[0095] Business model: Charge based on traffic or subscription duration, or operate in partnership with content providers (such as Tencent Video and iQiyi).

[0096] 4. Special scenario coverage In environments without a public IP address: STUN automatically penetrates multiple layers of NAT (such as corporate firewalls and campus networks), solving the problem of traditional port mapping solutions failing.

[0097] Weak network optimization: In scenarios with fluctuating signals, such as subways and elevators, smooth playback is maintained through dynamic bitrate adjustment (ABR).

[0098] The method for sharing real-time IPTV video to mobile terminals according to the present invention is based on the following hardware: Android IPTV devices generally have the ability to integrate STUN clients and IPSec modules (such as OpenIPSec and StrongSwan open-source libraries). Software compatibility: Supports mainstream IPTV protocols (such as IGMP for multicast and HLS / DASH for video-on-demand) and can seamlessly connect to the operator's backend system.

[0099] The method of this invention can save users the cost of purchasing additional streaming media boxes and expand functionality using existing equipment; it can reduce CDN bandwidth expenditures for operators and increase ARPU (average revenue per user) through differentiated services.

[0100] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A method for IPTV real-time picture sharing to mobile terminal playing, characterized in that, include: S1. Start the STUN client. The IPTV device and the mobile terminal send a STUN request to the public STUN server. The public STUN server works with the IPTV device and the mobile terminal to penetrate the NAT device and automatically obtain the corresponding public network address. S2, the IPTV device and the mobile terminal establish an IPSec encrypted tunnel based on the IPSec protocol to achieve two-way authentication and dynamic key negotiation between the devices, including: The mobile terminal sends an IKE_SA_INIT request to the public address of the IPTV device. The IPTV device responds to the IKE_SA_INIT request, confirms the parameters, and generates a temporary key. Based on the temporary key generated by IKE_SA_INIT, the transmission is encrypted. The IPTV device and the mobile terminal exchange IKE_AUTH messages and verify their identities, generating an IPSec security association IPSecSA security parameter set to establish an IPSec encrypted tunnel between the two parties. S3, the IPTV device receives the operator's playback stream, extracts the video and audio data from the operator's playback stream, re-encapsulates it into RTP format, and transmits it to the mobile terminal through an IPSec encrypted tunnel after encryption; the mobile terminal decrypts and verifies the integrity of the data packet, extracts the RTP payload, and plays the corresponding video and audio data in real time. S4. When the mobile terminal receives a channel switching command triggered by the user through the APP, it sends the control command to the IPTV device through the IPSec encrypted tunnel. The IPTV device parses the control command and calls the API to switch channels, and synchronously updates the electronic program guide information to the mobile terminal.

2. The method of claim 1, wherein the IPTV real-time screen sharing to mobile terminal playing is characterized in that, In S1, the IPTV device and the mobile terminal send a STUN Binding Request, which is then sent to the public STUN server after being mapped by the NAT device. The STUN Binding Request carries the SOFTWARE attribute to identify the client type. The public STUN server returns a STUN response, which is mapped back to the IPTV device and mobile terminal according to the NAT type. The STUN response carries the public network address of the IPTV device and mobile terminal.

3. The method of claim 1, wherein the IPTV real-time screen sharing to mobile terminal playing is characterized by, In S1, the STUN client built into the IPTV device periodically sends a Binding request to the public STUN server to obtain its own public network address. The STUN client built into the mobile terminal runs independently of the IPTV device. It obtains the public IP address of the mobile terminal behind NAT and automatically performs STUN detection when the APP starts. If the detection fails, it prompts the user to check the network configuration.

4. The method of claim 1, wherein the IPTV real-time screen sharing to mobile terminal playing is characterized by, In S1, the traversal strategy for cascaded NAT devices includes: if the IPTV device is located behind a multi-layer NAT device, the outermost STUN address is used as the communication endpoint.

5. The method of claim 1, wherein the IPTV real-time screen sharing to mobile terminal playing is characterized by, In S2, the mobile terminal selects the optimal IPTV device to establish an IPSec encrypted tunnel based on the public network latency RTT returned by the STUN server.

6. The method of claim 1, wherein the method further comprises: In S2, after the IPSec SA is established, the IPTV device sends a test UDP packet to the public address of the mobile terminal through the STUN server to verify the authenticity of the address; the mobile terminal needs to return a response packet within a preset time period, otherwise the establishment of the IPSec encrypted tunnel will be terminated.

7. The method for sharing real-time IPTV video to a mobile terminal for playback according to claim 1, characterized in that, In S2, if the STUN server detects a symmetric NAT, the IPTV device sends a USE_TRANSPORT_MODE notification during the IKE_AUTH phase to force the use of the transport mode; the mobile terminal listens on UDP port 4500, receives ESP-over-UDP packets, and maintains a heartbeat via STUN to prevent NAT mapping timeout.

8. A method for sharing real-time IPTV video to a mobile terminal for playback according to claim 1, characterized in that, In S2, the IPTV device and the mobile terminal exchange IKE_AUTH messages to verify their identities using a pre-set digital certificate or a pre-shared key.

9. A method for sharing real-time IPTV video to a mobile terminal for playback according to claim 1, characterized in that, In S3, the IPTV device uses the encryption key Enc_Key to encrypt the RTP packet with AES-CBC and calculates the HMAC-SHA256 integrity check value, and sends it to the mobile terminal through the IPSec encrypted tunnel.

10. A method for sharing real-time IPTV video to a mobile terminal for playback according to claim 1, characterized in that, When the following abnormal scenarios are detected, corresponding exception handling strategies will be adopted respectively: When the STUN server is detected as unreachable, it falls back to the default NAT-T mode, limiting the maximum number of concurrent connections to 2, and prompts the user to check the network. When a conflict is detected between the STUN server return address and the local configuration, the IPSec protocol is renegotiated, forcing the use of NAT-T and logging the conflict. When frequent changes in NAT mapping are detected, the STUN probe interval is shortened to 10 seconds, and the video bitrate is reduced to 2 Mbps to reduce the impact of network fluctuations.

Images