The analysis of RTP network transmission video Stream understanding

Why does a host inside Nat have access to a Web server outside of NAT, but cannot get RTSP stream Media server stream?

Reason:

For protocols such as HTTP, the client establishes a socket connection with the Web server, which is monitored by a Web server that binds a fixed TCP port on this port. Clients located behind the NAT randomly select a TCP port connect (2) WEB SERVER.

For RTSP streaming media servers, the use of RTP packaging multimedia load, the general implementation is located in the client side of the player to see UDP 5000 this port (can also be defined as other ports, but most of the mainstream player is this port) is occupied, not occupied is bound this port; if UDP 5000 This port is already occupied, then check up on UDP 5002 (the customary RTP uses an even number port, adjacent to the odd number port to RTCP), etc. until an unused port is found. Then request streaming media stream before passing through the RTSP packet to inform the server player to receive the RTP packet port, streaming media server randomly select a port to send RTP packets, and the upcoming session information through the SDP format to RTSP packaging notification player. Therefore, for RTP communication, the real service side is in the player side, passively receive the RTSP server over there to send the RTP code stream.

A general type of NAT allows a packet to be passed by the condition that:

If the packet is sent from the device inside the NAT to the extranet, it is allowed to pass. The NAT device looks at the source IP address and port and destination address and port information for this packet, and creates a new NAT mapping relationship if no mapping relationship has been established: map the source IP and port to a NAT address and a newly assigned port, depending on the type of NAT device, the mapping relationship is different:
The complete cone type, the address-restricted cone type, and the port-restricted cone are based on (source IP: Source port) A mapping (NAT address: Port),
Symmetric NAT (Source IP: Source port, Destination IP: Destination port) is mapped to (Nat Ip:nat Port).

If the packet is sent from the outside of NAT, see if the packet's information can be found in the NAT map, the corresponding mapping is not found, it is prohibited; if found, different types of NAT have different processing:
Complete cone type: allowed to pass.
Address restricted cone Type: If this mapping corresponds to the NAT internal host before sending packets to this extranet host, then allow to pass, otherwise not allowed.
Port restricted Cone Type: If this mapping corresponds to the NAT internal host before sending packets to this extranet host port, then allow to pass, otherwise not allowed.
Symmetry: Because the mapping contains the source IP, source port, destination IP, destination port, all information, find this mapping description of the corresponding host in the NAT packet to the corresponding extranet host, so allow through.

Therefore, the host located in the NAT can thus normally access the HTTP WEB server of the extranet: when an HTTP request is launched, Nat establishes a mapping relationship for the session, so that the WEB server's response package matches the mapping and can be received by the client browser.

But NAT inside the host to request streaming media is not: for RTSP, and HTTP as normal communication, the key is for RTP packets, the server is in the NAT inside the player, even if RTSP know the NAT inside the player host address and NAT address, RTP packets to reach N At, the above 2 situation, because the mapping relationship has not been established before, this packet will be discarded by NAT.

Some streaming media server will use HTTP to encapsulate streaming media, can get better penetration, but need to implement their own player to decode.
One of the reasons for the RTP packet loss

In the UDP package of RTP transmission video stream, playing a flower screen, mosaic is a possible reason for the packet loss is serious. UDP packet loss in the LAN is not likely to be a physical transmission of interference (generally the performance of the UDP checksum error, available NETSTAT-SU view). Here is a more common reason and performance, from the Linux kernel point of view, is the socket buffer full, before the player read the buffer, another video stream data, then, this UDP packet will be lost.

Why does this socket kernel cache full? There may be the following reasons:

The average processing data speed of the player is less than that of streaming media server.
The average processing speed of     player is larger than that of the end-contract, but the speed of the contract is large, and the kernel socket read buffer is set too small.