CN109672929B - Method and device for detecting video service message - Google Patents
Method and device for detecting video service message Download PDFInfo
- Publication number
- CN109672929B CN109672929B CN201811530909.2A CN201811530909A CN109672929B CN 109672929 B CN109672929 B CN 109672929B CN 201811530909 A CN201811530909 A CN 201811530909A CN 109672929 B CN109672929 B CN 109672929B
- Authority
- CN
- China
- Prior art keywords
- video service
- message
- service
- network node
- header
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 33
- 238000001514 detection method Methods 0.000 claims abstract description 21
- 230000005540 biological transmission Effects 0.000 claims abstract description 20
- 238000012545 processing Methods 0.000 claims description 24
- 238000004891 communication Methods 0.000 claims description 15
- 238000013507 mapping Methods 0.000 claims description 7
- 238000005259 measurement Methods 0.000 abstract description 16
- 230000008569 process Effects 0.000 description 12
- 230000003287 optical effect Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 238000005516 engineering process Methods 0.000 description 10
- 238000005538 encapsulation Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 6
- 238000004590 computer program Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000013467 fragmentation Methods 0.000 description 3
- 238000006062 fragmentation reaction Methods 0.000 description 3
- 238000000691 measurement method Methods 0.000 description 3
- 238000011144 upstream manufacturing Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 125000004122 cyclic group Chemical group 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 239000003550 marker Substances 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000012163 sequencing technique Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 239000000523 sample Substances 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/64—Addressing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明的实施例提供一种视频业务报文的检测方法和设备，涉及网络技术领域，能够提高测量精度的同时，还能够应对不同场景中视频业务报文的检测。该方法包括：业务源端设备将预定业务的视频业务报文的RTP的序列号映射至视频业务报文的IP报头的预定字段；将视频业务报文以数据流的形式发送网络节点设备，以便网络节点设备将数据流发送至终端设备；网络节点设备接收数据流，在数据流中获取视频业务报文；解析视频业务报文的IP报头，获取视频业务报文的源地址和目的地址；确定视频业务报文所属的业务流；根据业务流中视频业务报文IP报头中的RTP序列号的排序，确定连续丢失的RTP序列号的数量大于M时，确定业务流发生传输故障。
Embodiments of the present invention provide a method and device for detecting video service packets, which relate to the technical field of networks, which can improve measurement accuracy and also cope with the detection of video service packets in different scenarios. The method includes: the service source device maps the RTP sequence number of the video service message of the predetermined service to the predetermined field of the IP header of the video service message; and sends the video service message in the form of a data stream to the network node device, so that The network node device sends the data stream to the terminal device; the network node device receives the data stream and obtains the video service message in the data stream; parses the IP header of the video service message to obtain the source address and destination address of the video service message; determine The service flow to which the video service packet belongs; according to the ordering of the RTP sequence numbers in the IP header of the video service packet in the service flow, when it is determined that the number of consecutively lost RTP sequence numbers is greater than M, it is determined that the service flow has a transmission failure.
Description
Technical Field
The embodiment of the invention relates to the technical field of networks, in particular to a method and equipment for detecting a video service message.
Background
With the rapid development of network communication means such as a 1000M optical broadband of a family and the like in the 4G mobile internet, the increase of the network bandwidth brings prosperity of network video service, and the resolution of video content develops from standard definition and high definition to blue light, 4K and the like. With the development of 5G technology, 8K, AR/VR video will be gradually popularized. However, the popularity of large bandwidth video-like traffic also poses challenges to the bearer capabilities of the operator's network. The video service is very sensitive to network packet loss, which can cause the phenomena of video content jitter, screen splash, screen blackness, blocking and the like, and seriously affect the user experience. The network structure of an operator is complex, video service messages from a program source to a user home finally need to pass through a video head end service platform, a carrier network, an access network and a home network, and packet loss may occur on any equipment node and link in the network, so the operator needs to deploy a network detection system to monitor the network quality.
However, the existing measuring means has the problems of limited scenes, insufficient precision and the like. The existing measurement techniques are classified into a direct measurement technique and an indirect measurement technique. The network direct measurement technology is based on real service messages for measurement, and common technologies include eMDI/MDI, IPNICE, packet conservation, Y.1731, IPFPM and the like. The eMMC needs the network equipment to analyze the message to reach an application layer, consumes equipment resources and has potential safety hazard to user information; the statistics of IPNICE have an error between two points of < 5%; packet conservation supports only unicast schemes and does not support multicast schemes; y.1731 only supports the measurement of a two-layer network, and does not support a three-layer network; IPFPM can only support point-to-point scenarios. The indirect measurement technology indirectly simulates the service packet loss by inserting the detection message and calculating the packet loss condition of the detection message, and common measurement technologies include Ping, NQA, TWAMP/OWAMP and the like. The indirect measurement technology is limited in that a detection object is not a real service message, the problems of different paths of the detection message and the service and low measurement precision exist, and the performance condition of the service cannot be truly reflected. In addition, the probe packet may occupy the bandwidth of the real traffic stream.
Disclosure of Invention
Embodiments of the present invention provide a method and an apparatus for detecting a video service packet, which can improve measurement accuracy and simultaneously can cope with detection of video service packets in different scenes.
In a first aspect, a method for detecting a video service packet is provided, in which a service source end device maps a sequence number of an RTP of a video service packet of a predetermined service to a predetermined field of an IP header of the video service packet; the service source end device sends the video service message to the network node device in a data stream form, so that the network node device sends the data stream to a terminal device; the network node equipment receives a data stream and acquires the video service message from the data stream; the network node equipment analyzes the IP header of the video service message to obtain a source address and a destination address of the video service message; the network node equipment determines the service flow to which the video service message belongs according to the source address and the destination address of the video service message; and when the network node equipment determines that the number of the RTP serial numbers which are continuously lost is larger than M according to the sequencing of the RTP serial numbers in the IP headers of the video service messages in the service flow in a preset statistical period, determining that the service flow has transmission failure, wherein M is a maximum packet loss retransmission number threshold value.
In the above scheme, since the service source end device maps the serial number of the RTP in the predetermined field of the IP header of the video service packet, when detecting the video service packet, each network node device in the network can directly resolve the serial number of the RTP of each video service packet according to the service flow to which the service packet belongs, so that the network node device determines whether the service flow has a transmission failure or not according to the serial number of the RTP included in the IP header of the video service packet in the service flow, thereby avoiding the limitation that some direct measurement technologies in the prior art can only support a point-to-point scenario, and simultaneously, the measurement accuracy is improved without using a detection packet and additional bandwidth is not occupied.
In a second aspect, a service source end device is provided, which includes:
the processing module is used for mapping the serial number of the RTP of the video service message of the predetermined service to the predetermined field of the IP header of the video service message; and the sending module is used for sending the video service message generated by the processing module to the network node equipment in a data stream form so that the network node equipment can send the data stream to the terminal equipment.
In a third aspect, a network node device is provided, including: a receiving module, configured to receive a data stream, and obtain the video service packet in the data stream, where the data stream includes a video service packet of a predetermined service, and a sequence number of an RTP of the video service packet is mapped to a predetermined field of an IP header of the video service packet; the analysis module is used for analyzing the IP header of the video service message acquired by the receiving module and acquiring a source address and a destination address of the video service message; the processing module is used for determining the service flow to which the video service message belongs according to the source address and the destination address of the video service message acquired by the analysis module; and the processing module is further configured to determine that a transmission failure occurs in the service stream when it is determined that the number of consecutive lost RTP sequence numbers is greater than M according to the ordering of the RTP sequence numbers in the IP headers of the video service messages in the service stream in a predetermined statistical period, where M is a maximum packet loss retransmission number threshold value.
In a fourth aspect, a service source device is provided, which includes a communication interface, a processor, a memory, and a bus; the memory is configured to store a computer execution instruction, the processor is connected to the memory through the bus, and when the service source end device runs, the processor executes the computer execution instruction stored in the memory, so that the service source end device executes the video service packet detection method.
In a fifth aspect, a network node device is provided, comprising a communication interface, a processor, a memory, a bus; the memory is used for storing computer execution instructions, the processor is connected with the memory through the bus, and when the network node device runs, the processor executes the computer execution instructions stored in the memory, so that the network node device executes the video service packet detection method.
A sixth aspect provides a computer storage medium, which includes instructions, when the instructions are executed on a computer, cause the computer to execute the video service packet detection method as described above.
In a seventh aspect, a computer program product is provided, where the computer program product includes instruction codes for executing the video service packet detection method as described above.
It can be understood that any of the service source end device, the network node device, the computer storage medium, or the computer program product provided above is used to execute the method corresponding to the first aspect provided above, and therefore, the beneficial effects that can be achieved by the method according to the first aspect above and the beneficial effects of the solutions corresponding to the following specific embodiments may be referred to, and are not described herein again.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.
Fig. 1 is a schematic diagram of an IPTV bearer network architecture according to an embodiment of the present invention;
fig. 2 is a schematic diagram illustrating a video service packet encapsulated in a PPPoE scenario according to an embodiment of the present invention;
fig. 3 is a schematic diagram illustrating encapsulation of a video service packet in an IpoE scenario according to an embodiment of the present invention;
fig. 4 is a schematic diagram of a method for detecting a video service packet according to an embodiment of the present invention;
fig. 5 is a mapping manner of a sequence number of an RTP packet to an IP header of an IPv4 packet according to an embodiment of the present invention;
fig. 6 is a mapping manner of a sequence number of an RTP packet to an IP header of an Ipv6 packet according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram of a service source end device according to an embodiment of the present invention;
fig. 8 is a schematic structural diagram of a service source end device according to another embodiment of the present invention;
fig. 9 is a schematic structural diagram of a network node device according to an embodiment of the present invention;
fig. 10 is a schematic structural diagram of a network node device according to another embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
At present, in the process of flowing a data stream of a video service from a service source end device to a terminal device, the data stream needs to be forwarded by a multi-hop network node device and carried by a multi-port link between devices. Taking an operator self-operated IPTV service as an example, a service source end device of a data stream is on an IPTV platform in a provincial center, as shown in a schematic view of an IPTV bearer network architecture provided in fig. 1, the data stream needs to sequentially pass through an integrated access switch LSW (load balancing switch), a metropolitan area network core router CR (core router), a metropolitan area network broadband access gateway BNG (broadband network gateway), a two-layer aggregation switch), an access network optical line terminal OLT (optical line terminal ), a home gateway unit (optical network unit), and finally reach an IPTV set-top box STB (set-top-box, that is, a terminal device). The network node devices are connected by optical fibers at the physical layer. When a data stream is generated at a service source end device, the data stream needs to be encapsulated by multiple layers of protocols, including an application layer, a transmission layer, an IP layer, and the like, and after becoming an IP data packet, the data stream is transmitted by the service source end device in a manner of sending the data stream to a network according to a destination IP address.
In the prior art, in a service source device, when a video service packet is encapsulated by an RTP (real-time transport protocol), a sequence number of the RTP needs to be provided for a packet receiver to repack a packet sequence and perform packet loss detection. Fig. 2 provides a schematic diagram of encapsulation of a video service packet in a point-to-point protocol over ethernet (PPPoE) scenario. The header includes a 14-bit (bytes) ethernet header, an 8-bit PPPoE header, a 20-bit IP header, an 8-bit UDP header, an 8-bit RTP header, and several video packets (which may be, for example, MPEG2 TS, moving picture experts group2 transport stream, moving picture experts group2 transport data) with a length of 188 bits for carrying video data, and a final check bit CRC (cyclic redundancy check). Fig. 3 provides a schematic diagram of encapsulation of a video service packet in an IpoE (internet protocol over ethernet) scenario. The header includes a 14-bit (bytes) ethernet header, a 20-bit IP header, an 8-bit UDP header, an 8-bit RTP header, and several video packets (which may be, for example, MPEG2 TS, moving picture experts group2 transport stream, moving picture experts group2 transport data) with a length of 188 bits for carrying video data, and a last check bit CRC (cyclic redundancy check). In PPPoE scenario, the sequence number of RTP is located in the 53 th and 54 th consecutive bytes; in the IPoE scenario, the sequence number of RTP is located in the 45 th, 46 th consecutive bytes. Meanwhile, the RTP protocol is positioned in a transmission layer in a network protocol stack, and the network node equipment only analyzes the video service message in the data stream to an IP layer in the network transmission process of the data stream, so that the message is forwarded according to a target IP address. Since the RTP protocol is encapsulated inside the IP header, further parsing of the packet not only causes a decrease in network forwarding efficiency, but also presents a security risk of leaking user private data. In summary, the network node device cannot directly use the sequence number in the RTP protocol to perform packet loss detection on the video service packet. The direct measurement technology and the indirect measurement technology provided by the prior art have the problems of limited application scenes and low measurement precision.
In order to solve the above problem, an embodiment of the present application provides a method for detecting a video service packet, which is shown in fig. 4 and includes the following steps:
101. the service source end device maps the sequence number of the RTP of the video service message of the predetermined service to the predetermined field of the IP header of the video service message.
The predetermined service may be a video service, for example: iptv (btv), iptv (vod), self-service OTT, internet OTT video, and the like. Each service employs a different network bearer scheme and encapsulation protocol. Taking the video service carried by the operator as an example, the BTV service uses RTP/RTCP/RTSP protocol to encapsulate the service packet in the streaming media application layer, the transport layer uses UDP protocol encapsulation, and the network carrying mode is multicast. The VOD service is encapsulated by adopting HDP/HLS/DASH/HSS protocol at the application layer, the transmission layer is encapsulated by adopting TCP protocol, and the network bearing mode is unicast. The self-operated OTT video service application layer adopts HDP/HLS/DASH/HSS protocol encapsulation, the transmission layer adopts TCP protocol encapsulation, and the network bearing mode is unicast. The internet OTT video service application layer adopts HLS/DASH/HSS protocol encapsulation, the transmission layer adopts TCP protocol encapsulation, and the network bearing mode is unicast.
In general, in the header of an RTP (RTP packet), there are 16bits for identifying the sequence number of the RTP of a message transmitted by a sender, and the sequence number is increased by 1 every time a message is transmitted. The sequence number can be used for detecting packet loss and disorder of the message by a service receiver. However, since the RTP protocol is located in the transport layer of the TCP/IP protocol stack, the parsing of the packet by the network node device is only parsed to the IP layer, and the sequence number is not perceived. In step 101, mapping the sequence number of the RTP to the IP header for the video service packet (e.g., IPv4 packet and IPv6 packet), so that the network node device can perform packet loss and out-of-order statistics on the video service packet according to the sequence number of the RTP of the IP header, thereby achieving the purpose of network fault detection. The video service message is an IPV4 message, and the predetermined field includes an option field of the IPV4 message. If the video service message is an IPV6 message, the predetermined field includes an extension header of the IPV6 message.
Specifically, at the service source end device, for the IPv4 packet, the option field in the header of the IPv4 packet is used to perform mapping and padding of the sequence number of the RTP to the IP header. The mapping mode of the RTP sequence number to the IP header of the IPv4 message is shown in fig. 5, where an option of an IPv4 message header is a selectable item of the IP header, the length of the option is an integer multiple of 32bits, the first 8 bits are code fields, and include a 1-bit copy bit to identify whether a packet is copied to all packets, a 2-bit class bit to identify the use category of the option, and a 5-bit field to record the number of the option. The middle 8 bits are used to identify the length (length) of the option, and the remaining 5 numbers of the option field of the current IP header are available, 26, 27, 28, 29, and 31, respectively. In the present invention, number 31 is defined to identify the option field for recording the sequence number of RTP. The last 16bits are used to store the sequence number of the RTP so that the sequence number of the RTP is mapped into the IP header. Also shown in FIG. 5 is the identification in the RTP header, V (version) 2bits, used to designate the RTP version number; the protocol initial version is 0 and the version number specified in RFC3550 is 2. P (padding, additional information) 1bit, if the bit is set, additional information is included at the end of the packet, and the last byte of the additional information indicates the length of the additional information (including the byte itself). This field exists because some encryption mechanisms require fixed-length data blocks, or in order to transport multiple RTP packets in one underlying protocol data unit. X (extension) 1bit if the bit is set, there is an extension header after the fixed header. CC (CSRC count, contract Source count) 4bits, how many CSRC identifiers there are after the fixed header. M (marker) 1bit, the function of which depends on the profile definition. Profile can change the length of the bit, but keep the total length of marker and payload type constant (8 bits total). PT (payload type): 7bits, marks the type of information the RTP packet carries. sequence number:16bits, sequence number. timestamp:32bits, timestamp. Reflecting the sampling time of the first byte in the packet carried by the RTP packet. SSRC identifier (Synchronization source identifier): 32bits, Synchronization source identifier. There should be a different SSRC for each data flow during an RTP session. CSRC identifier list:0to 15 entries, 32bits each, identifies the special source identifier. Also shown in fig. 5 is the inclusion of a fixed portion and a variable portion in the IP header, where the variable portion includes the code, length, and sequence number of RTP as described above. The fixed part comprises the following marks: version, which identifies the version of the IP protocol, the current IP protocol version number is 4, and the next-generation IP protocol version number is 6. IHL (IP header length), length of IP header. TOS (type of service). Total length: total length of IP message. The sum of the length of the header and the length of the data portion. Identification (identification): each datagram sent by the host is uniquely identified. Usually every message sent, its value is incremented by one. When the length of the IP packet exceeds the MTU (maximum transmission unit) of the transmission network, fragmentation is necessary, and the value of this identification field is copied into the identification fields of all data fragments, so that the fragments can be reassembled into the original data according to the content of the identification fields when reaching the final destination. Flag (flag): and 3 bits in total. R, DF and MF. Currently, only the last two bits are valid, DF: a value of 1 indicates no fragmentation, and a value of 0 indicates fragmentation. MF: a value of 1 indicates "more slices" and a value of 0 indicates that this is the last slice. Slice displacement (flag offset): the slice is offset from the first bit in the original data packet. TTL (time to live), the maximum number of routers allowed to pass an IP packet. Every time a router is passed, the TTL is decremented by 1, and when 0, the router discards the datagram. The TTL field is an 8-bit field initially set by the sending end, the recommended initial value is specified by the distribution number RFC, and the current value is 64. The TTL is often set to a maximum value of 255 when sending ICMP echo reply. Protocol (protocol) indicates which protocol is used for the data carried in the IP packet, so that the IP layer of the destination host can know which process the datagram is handed over to (different protocols have different processes for processing). Like the port numbers, protocol numbers are used here, TCP having a protocol number of 6 and UDP having a protocol number of 17. The protocol number of ICMP is 1, and the protocol number of IGMP is 2. Header checksum (header checksum): the checksum of the IP header is calculated and the integrity of the IP header is checked. The source address identifies the source end device of the IP datagram. Destination address: the destination address of the IP datagram is identified.
In addition, at the service source end device, for the IPv6 packet, an extension header (as part of the dashed box in fig. 6) may be defined to carry the sequence number of the RTP. Referring to fig. 6, the extension header protocol number is identified with an undefined 252 and carries an option, the option type format being set to 0x1D (00011101). When there are multiple extension headers in the IPv6 packet, the extension header of the sequence number newly added to carry the RTP should be located before the upper layer protocol header, as shown in fig. 6, and before the UDP header, for example, next header 17(PDU), where Hdr ExtLen is 0 and the header length is zero. The serial number of RTP occupies 32bit, the first 16bit bearing service source terminal device maps the RTP serial number to the value of the serial number of the extension head of IP header, and the latter 16bit is completed by 0.
102. And the service source end equipment transmits the video service message to the network node equipment in a data flow mode, so that the network node equipment transmits the data flow to the terminal equipment.
103. And the network node equipment receives the data stream and acquires the video service message from the data stream.
104. And the network node equipment analyzes the IP header of the video service message and acquires the source address and the destination address of the video service message.
105. And the network node equipment determines the service flow to which the video service message belongs according to the source address and the destination address of the video service message.
106. And in a preset statistical period, determining that the transmission fault of the service flow occurs when the number of the RTP sequence numbers which are continuously lost is larger than M according to the sequencing of the RTP sequence numbers in the IP headers of the video service messages in the service flow, wherein M is a maximum packet loss retransmission number threshold value.
If the condition in 106 is not satisfied, it is determined that the traffic flow has no transmission failure. Thus, when a network node device (e.g., a router) receives a video service packet forwarded to the node by an upstream device, an IP header in the video service packet is identified according to a source address and a destination address binary group of the IP header, and a sequence number of the video service packet at an RTP of the IP header is obtained according to the IP header. When the serial number of the video service packet in the RTP of the IP header is discontinuous (missing), it is determined that the upstream network device or the link has a packet loss, and if the number of consecutive packet losses Nt is greater than or equal to M in the statistical period and M is the maximum packet loss retransmission number threshold value specified by the ARQ standard, it is determined that the service flow has a transmission failure, for example, the upstream device or the link of the network node device has a failure. If a plurality of monitoring points are deployed on the IP network node equipment, the purpose of network fault delimitation can be achieved, and if each piece of IP network node equipment is deployed to be a monitoring point, the delimitation range can be accurate to equipment and a link level.
Finally, the network node device forwards the data stream to the next hop device according to the destination address, and if the next hop device is another network node device, the step 102 and 106 are repeatedly executed in the another network node device until the data stream is forwarded to the terminal device, and the terminal device receives the video service packet and decapsulates the video service packet.
In the above scheme, since the service source end device maps the serial number of the RTP in the predetermined field of the IP header of the video service packet, when detecting the video service packet, each network node device in the network can directly resolve the serial number of the RTP of each video service packet according to the service flow to which the service packet belongs, so that the network node device determines whether the service flow has a transmission failure or not according to the serial number of the RTP included in the IP header of the video service packet in the service flow, thereby avoiding the limitation that some direct measurement technologies in the prior art can only support a point-to-point scenario, and simultaneously, the measurement accuracy is improved without using a detection packet and additional bandwidth is not occupied.
Referring to fig. 7, there is provided a service source device, including:
a processing module 71, configured to map a sequence number of an RTP of a video service packet of a predetermined service to a predetermined field of an IP header of the video service packet;
a sending module 72, configured to send the video service packet generated by the processing module 71 to the network node device in a data stream form, so that the network node device sends the data stream to a terminal device.
Optionally, if the video service packet is an IPV4 packet, the predetermined field includes an option field of the IPV4 packet. If the video service message is an IPV6 message, the predetermined field includes an extension header of the IPV6 message.
All relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and the function thereof is not described herein again.
In the case of using an integrated module, the service source end device includes: the device comprises a storage unit, a processing unit and an interface unit. The processing unit is configured to control and manage actions of the service source device, for example, the processing unit is configured to support the service source device to execute the process 101 in fig. 4; the interface unit is configured to support information interaction between the service source device and other devices, for example, the interface unit is configured to support the service source device to execute the process 102 in fig. 4. And the storage unit is used for storing the program codes and data of the service source end equipment.
For example, the processing unit is a processor, the storage unit is a memory, and the interface unit is a communication interface. The service source device is shown in fig. 8, and includes a communication interface 801, a processor 802, a memory 803, and a bus 804, where the communication interface 801 and the processor 802 are connected to the memory 803 through the bus 804.
The processor 802 may be a general-purpose Central Processing Unit (CPU), a microprocessor, an Application-Specific Integrated Circuit (ASIC), or one or more Integrated circuits configured to control the execution of programs in accordance with the teachings of the present disclosure.
The Memory 803 may be a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to these. The memory may be self-contained and coupled to the processor via a bus. The memory may also be integral to the processor.
The memory 803 is used for storing application program codes for executing the scheme of the application, and the execution of the application program codes is controlled by the processor 802. The communication interface 801 is used for information interaction with other devices, for example, to support the service source device to perform step 102. The processor 802 is configured to execute the application program code stored in the memory 803, so as to implement the method performed by the service source device in the embodiment of the present application, for example, step 101.
Referring to fig. 9, there is provided a network node device comprising:
a receiving module 91, configured to receive a data stream, and obtain the video service packet from the data stream; the data stream comprises a video service message of a predetermined service, wherein the sequence number of the RTP of the video service message is mapped to a predetermined field of the IP header of the video service message;
an analyzing module 92, configured to analyze the IP header of the video service packet obtained by the receiving module 91, and obtain a source address and a destination address of the video service packet;
a processing module 93, configured to determine a service flow to which the video service packet belongs according to the source address and the destination address of the video service packet obtained by the parsing module 92;
the processing module 93 is further configured to determine that a transmission failure occurs in the service stream when it is determined that the number of consecutive lost RTP sequence numbers is greater than M according to the ordering of the RTP sequence numbers in the IP headers of the video service messages in the service stream in a predetermined statistical period, where M is a maximum packet loss retransmission number threshold.
All relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and the function thereof is not described herein again.
In case of an integrated module, the network node device comprises: the device comprises a storage unit, a processing unit and an interface unit. The processing unit is configured to control and manage actions of the network node device, for example, the processing unit is configured to support the network node device to execute the process 104 and 106 in fig. 4; the interface unit is configured to support information interaction between the network node device and other devices, for example, the interface unit is configured to support the network node device to execute the process 103 in fig. 4. A storage unit for storing program codes and data of the network node device.
For example, the processing unit is a processor, the storage unit is a memory, and the interface unit is a communication interface. The network node device shown in fig. 10 includes a communication interface 1001, a processor 1002, a memory 1003, and a bus 1004, and the communication interface 1001 and the processor 1002 are connected to the memory 1003 through the bus 1004.
The processor 1002 may be a general-purpose Central Processing Unit (CPU), a microprocessor, an Application-Specific Integrated Circuit (ASIC), or one or more Integrated circuits configured to control the execution of programs in accordance with the teachings of the present disclosure.
The Memory 1003 may be a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to these. The memory may be self-contained and coupled to the processor via a bus. The memory may also be integral to the processor.
The memory 1003 is used for storing application program codes for executing the scheme of the application, and the processor 1002 controls the execution. The communication interface 1001 is used for information interaction with other devices, for example, to support the network node device to execute step 103. The processor 1002 is configured to execute the application program code stored in the memory 1003, so as to implement the method executed by the network node device in the embodiment of the present application, for example, step 104 and step 106.
Further, a computing storage medium (or media) is also provided, which comprises instructions that when executed perform the method operations performed by the service source end device or the network node device in the above embodiments. Additionally, a computer program product is also provided, comprising the above-described computing storage medium (or media).
All relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and the function thereof is not described herein again.
It should be understood that, in various embodiments of the present invention, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other ways. For example, the above-described device embodiments are merely illustrative, and for example, the division of the units is only one logical functional division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.
Claims (10)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811530909.2A CN109672929B (en) | 2018-12-14 | 2018-12-14 | Method and device for detecting video service message |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811530909.2A CN109672929B (en) | 2018-12-14 | 2018-12-14 | Method and device for detecting video service message |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109672929A CN109672929A (en) | 2019-04-23 |
| CN109672929B true CN109672929B (en) | 2021-04-27 |
Family
ID=66144370
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811530909.2A Active CN109672929B (en) | 2018-12-14 | 2018-12-14 | Method and device for detecting video service message |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109672929B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113179171B (en) * | 2020-01-24 | 2023-04-18 | 华为技术有限公司 | Fault detection method, device and system |
| CN113748645B (en) * | 2020-04-30 | 2023-07-25 | 新华三技术有限公司 | Data stream analysis |
| CN114422397A (en) * | 2021-12-27 | 2022-04-29 | 中国电信股份有限公司 | Streaming media channel monitoring method and device, electronic equipment and readable storage medium |
| CN114866848B (en) * | 2022-04-02 | 2023-01-06 | 北京广播电视台 | IP video main and standby data filtering system and filtering method |
| CN114979093B (en) * | 2022-05-13 | 2024-03-29 | 深圳智慧林网络科技有限公司 | RTP-based data transmission method, device, equipment and medium |
| CN114979092B (en) * | 2022-05-13 | 2024-04-02 | 深圳智慧林网络科技有限公司 | RTP-based data transmission method, device, equipment and medium |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE60110303T2 (en) * | 2000-03-03 | 2006-03-09 | Ntt Docomo, Inc. | Method and apparatus for packet transmission with packet header compression |
| JP2003152752A (en) * | 2001-08-29 | 2003-05-23 | Matsushita Electric Ind Co Ltd | Data transmission / reception method |
| CN1567915A (en) * | 2003-07-02 | 2005-01-19 | 明基电通股份有限公司 | A wireless transmission control protocol/internet protocol header setting transmission method |
| JP4401864B2 (en) * | 2004-05-17 | 2010-01-20 | パナソニック株式会社 | Packet generation method, communication method, packet processing method, and data structure |
| CN102572531B (en) * | 2012-02-21 | 2014-08-27 | 德科仕通信(上海)有限公司 | Method and system for delimiting packet loss faults of internet protocol television (IPTV) network |
-
2018
- 2018-12-14 CN CN201811530909.2A patent/CN109672929B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN109672929A (en) | 2019-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109672929B (en) | Method and device for detecting video service message | |
| JP6901524B2 (en) | Bit forwarding ingress router, bit forwarding router and operation management maintenance test method | |
| US10833998B2 (en) | Method and apparatus for flow control | |
| EP3958521B1 (en) | Method and apparatus for providing service for service flow | |
| CN110086578B (en) | Data transmission method, device and system | |
| US7899048B1 (en) | Method and apparatus for remotely monitoring network traffic through a generic network | |
| US9935881B2 (en) | Method and apparatus of load sharing | |
| US8306063B2 (en) | Real-time transport protocol stream detection system and method | |
| KR100910818B1 (en) | Method and system for tunneling macsec packets through non-macsec nodes | |
| US8351352B1 (en) | Methods and apparatus for RBridge hop-by-hop compression and frame aggregation | |
| TWI277322B (en) | Switch capable of controlling data packet transmission and related method | |
| US20180212798A1 (en) | Path Detection Method and Apparatus | |
| EP3849160A1 (en) | Method, device and system for realizing data transmission | |
| US8817820B2 (en) | System for controlling path maximum transmission unit by detecting repetitional IP packet fragmentation and method thereof | |
| US20070160050A1 (en) | Diagnostic mechanism for Layer 2 and Layer 3 networks | |
| CN108141387B (en) | Length control for packet header samples | |
| US9313246B2 (en) | Resilient video encoding control via explicit network indication | |
| EP2636191A1 (en) | Real time protocol packet tunneling | |
| AU2012207713B2 (en) | Method and apparatus for transmitting a multimedia data packet using cross-layer optimization | |
| CN101242321A (en) | An end-to-end throughput measuring method and device | |
| TW201737664A (en) | Cluster precise speed limit method and device | |
| US20230327983A1 (en) | Performance measurement in a segment routing network | |
| WO2021088813A1 (en) | Packet encapsulating method and apparatus, and packet decapsulating method and apparatus | |
| CN101741752B (en) | The methods, devices and systems of video streaming | |
| US20240236214A1 (en) | Transient Hiding of Internet Protocol Header Options |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |