Details related to the RTSP protocol media data Bundle

Recently completed a RTSP proxy gateway, this is the second development to do RTSP protocol related development work, compared to the simple rough version of 11, this time in the underlying TCP/IP communication and RTSP protocol has a number of new accumulation, here record. Basic RTSP Protocol Interactive process to read rfc2326 on it, here is not to repeat. Here are some of the details related to media data sending and receiving that are actually tested with Vlc/mplayer, as follows

After the 1,setup request, the player sends a NAT-through UDP message (mode UDP as the underlying transport Protocol) to the communication port negotiated in the setup request, which acts as follows

When there is a router between the player and the server, these messages can trigger these routers to add the corresponding Snat table entry in the NAT table, the implementation of the hole, the service side in receiving these messages, should be taken from the UDP message corresponding NAT mapped port as the actual media data sent to the destination port, In this case, the media packets can follow the holes just now, step by step back to the original player, otherwise because of the NAT proxy, the external is unable to directly send the media packets to the player behind the router.

2,transport Head: The function of itself is used for the client and the service to negotiate the communication parameters, wherein the message Destination/source is only the destination IP and source IP of this message, if the server is specified in the transport IP, Then the subsequent NAT pass-through package is the destination as specified in the IP here. If the server is also in the back of the router, through port mapping to provide services, and in the corresponding, directly through the getsockname () to obtain the IP of the service interface, then the corresponding gain is the service host network IP, If this IP is filled into the source of transport, then the player will subsequently send NAT-Pierce messages with this IP as the destination IP, which is naturally wrong.

The workaround is to include the source field player in the transport header in the setup response, refer to the IP in the content-base header, or send the destination IP as a NAT-piercing message with the destination IP of the RTSP link

3,content-base Header: The base path itself is used to make the relative path, the actual complete path is composed of url+ given relative path content-base, which is described in section rfc2068-http 14.11, However, this can also affect the destination address when the player sends a NAT-Pierce message. See above transport header described in the content

4, the use of UDP as media data to send data, it is best to implement a similar to the TCP slow start mechanism, or Non-block FD on a short period of time to send a large number of data, will be prone to ewouldblock errors. For the reasons, refer to TCP slow boot related data.

~~end

Details related to the RTSP protocol media data Bundle