Forum Discussion
Rodney_Newton_7
Nimbostratus
NimbostratusRTSP Proxy
RTSP Proxy:
Situation: Remote clients point to a virtual server for streaming audio/video… based on the information in the RTSP header the F5 will make a decision on which pool to send it to (iRules). The BigIP contacts the server on behalf of the client… after the initial RTSP call setup the server will then stream to the F5 then the F5 feeds the client. This is a one arm configuration (single interface, one VLAN) and all clients and servers are on the other side of the BigIP’s gateway.
Requirements: Client IP’s must be hidden from the server so the BigIP will sNAT the source address and the servers will communicate directly to the BigIP as if it were the client. All traffic must flow through the BigIP so nPath routing or similar solutions are not an option.
Problem: Once the initial RTSP call setup is complete the server begins streaming UDP packets to the sNAT address… as far as BigIP is concerned these are unsolicited packets and no connection table exist to correlate them to a client on the other side.
Flow:
1.1.1.5 (Client) sends connection request to 192.168.0.1 (VIP)… Actually the clients will point to a public address (5.5.5.4) that NATs at the firewall to the BigIP VIP.
BigIP makes a pool selection using iRules then changes the source IP to 192.168.0.2 and contacts the appropriate server
192.168.0.2 NATs at the firewall to a different public address (5.5.5.5) and routes to server (2.2.2.5)
Server (2.2.2.5) responds to (5.5.5.5) and the connection is made.
Again.. the problem is the initial UDP packet from the server that is rejected by BigIP… certain clients that we tested with actually send a UDP packet to the server first after the call setup and in those instances F5 handles it just fine (session table exist). Other clients (QuickTime Player) actually switch to TCP if UDP fails and that works too. Unfortunately we need all clients to operate and that means the F5 handling those unsolicited UDP packets from the server and redirecting them to the client that requested the stream.
So…. is there a way with iRules or some other method to take the information from the TCP connection, that actually has the agreed upon UDP port numbers in it, and create a session table that allows those packets on the defined ports to map back to the client through BigIP? Any feedback is greatly appreciated.
2 Replies
- You probably want to use the super-secret relate_server command. This will create a new session that is "related" to the control session and will then be cleaned up when the control connection goes away. The syntax would be something like this:
when SERVER_CONNECTED { relate_server { proto 17 clientflow 4092 $snat_addr $snat_port $server_addr $server_port serverflow 4093 $vip_addr $vip_port $client_addr $client_port } }
This code assumes your external vlan is 4092, your internal vlan is 4093. It also assumes you have set the variables at some previous time or event. snat_addr/snat_port are the address and port the server is attempting to connect to and server_addr/server_port are the server's address and port that the connection is coming from. Vip_addr/vip_port are the address/port used going out to the client and client_addr/client_port are the destination client.
Hope this helps. As I've said before, the next release includes complete support for RTSP. 
Mark_Rinfret_64I have been wrestling with a couple of approaches to the RTSP proxy problem. Basically, I have client requests arriving at a virtual server on the external VLAN (192.168.3.50) and I'm trying to load balance a couple of 3GPP streaming servers (10.1.1.11, 10.1.1.21) on an internal VLAN.
I've seen a number of posts promising "full RTSP support" in future releases, but I'm not sure how far that ever got or what was meant by "full". As in the previous post, I need to provide a means for outbound UDP traffic to reach the client,as well as inbound UDP traffic (RTCP reports) to reach the appropriate server. I did some things with global arrays that successfully mapped the incoming RTCP reports to the correct streaming server for the session, but things started looking pretty kludgy.
I'm just starting to investigate the relate_server command and would like to know if it might provide a correct (supported) solution. (It was referred to as "ultra-secret" in one post.) In my current implementation, I'm collecting the payload, then in the SERVER_DATA event, based on the current "state" I'm in(DESCRIBE/SETUP/etc.), I update the SDP response to the DESCRIBE (update o= with the VS address) or extract the client_port and server_port attributes from the response to the SETUP request(Transport header) . I'm still getting my head around the relate_server command, so I guess I'm looking for a vote of confidence that this is the right approach. Should I follow that path, or has something "newer and wonderfuller" come along?
Thanks,
Mark
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}