- Monitoring TCP-based Applications
- Monitoring SSL Services
- Monitoring FTP Services
- Monitoring SIP Services
- Monitoring RADIUS Services
- Monitoring Accounting Information Delivery from a RADIUS Server
- Monitoring DNS and DNS-TCP Services
- Monitoring LDAP Services
- Monitoring MySQL Services
- Monitoring SNMP Services
- Monitoring NNTP Services
- Monitoring POP3 Services
- Monitoring SMTP Services
- Monitoring RTSP Services
- Monitoring the XML Broker Services
- Monitoring ARP Requests
- Monitoring the XenDesktop Delivery Controller Services
- Monitoring Web Interface Services
- Monitoring Citrix StoreFront Stores
Monitoring RTSP Services
Apr 08, 2013
The NetScaler appliance has one built-in monitor that can be used to monitor RTSP services: the RTSP monitor. It periodically checks the RTSP service to which it is bound by opening a connection with the load balanced RTSP server. The type of connection that it opens, and the response that it expects, differs depending upon the network configuration. If the RTSP service responds as expected within the configured time period, it marks the service UP. If the service does not respond, or responds incorrectly, it marks the service DOWN.
The NetScaler appliance can be configured to load balance RTSP servers using two topologies: NAT-off and NAT-on. RTSP servers send their responses directly to the client, bypassing the appliance. The appliance must be configured to monitor RTSP services differently depending upon which topology your network uses. The appliance can be deployed either in inline or non-inline mode in both NAT-off and NAT-on mode.
In NAT-off mode, the appliance operates as a router: it receives RTSP requests from the client and routes them to the service that it selects using the configured load balancing method. If your load balanced RTSP servers are assigned publicly accessible FQDNs in DNS, the load balanced servers send their responses directly to the client, bypassing the appliance. The following figure demonstrates this configuration.
Figure 1. RTSP in NAT-off Mode
The flow of requests and responses in this scenario is as follows:
- The client sends a DESCRIBE request to the appliance. The appliance uses the configured load balancing method to choose a service, and routes the request to Media Server-1.
The client sends a SETUP request to the appliance. If the RTSP session ID is exchanged in the DESCRIBE request, the appliance, using RTSPSID persistence, routes the request to Media Server-1. If the RTSP session ID is exchanged in the SETUP request, the appliance does one of the following:
- If the RTSP request comes on the same TCP connection, it routes the request to Media Server-1, maintaining persistence.
- If the request arrives on a different TCP connection, it uses the configured load balancing method to choose a service, and sends the request to that service, not maintaining persistence. This means that the request may be sent to a different service.
Media Server-1 receives the SETUP request from the appliance, allocates resources to process the RTSP request, and sends the appropriate session ID to the client.
Note: The appliance does not perform NAT to identify the RTSP connection, because the RTSP connections bypass it.- For subsequent requests, the client then uses the session ID to identify the session and send control messages to the media server. Media Server-1 performs the requested actions, such as play, forward, or rewind.
In NAT-on mode, the appliance receives RTSP requests from the client and routes those requests to the appropriate media server using the configured load balancing method. The media server then sends its responses to the client through the appliance, as illustrated in the following diagram.
Figure 2. RTSP in NAT-on Mode
The flow of requests and responses in this scenario is as follows:
- The client sends a DESCRIBE request to the appliance. The appliance uses the configured load balancing method to choose a service, and routes the request to Media Server-1.
The client sends a SETUP request to the appliance. If the RTSP session ID is exchanged in the DESCRIBE request, the appliance, using the RTSPSID persistence, routes the request to Media Server-1. If the RTSP session ID is exchanged in the SETUP request, the appliance does one of the following:
- If the RTSP request comes on the same TCP connection, it routes the request to Media Server-1, maintaining persistence.
- If the request arrives on a different TCP connection, it uses the configured load balancing method to choose a service, and sends the request to that service, not maintaining persistence. This means that the request may be sent to a different service.
- Media Server-1 receives the SETUP request from the appliance, allocates resources to process the RTSP request, and sends the appropriate session ID to the client.
- The appliance performs NAT to identify the client for RTSP data connections, and the RTSP connections pass through the appliance and are routed to the correct client.
- For subsequent requests, the client then uses the session ID to identify the session and send control messages to the appliance. The appliance uses RTSPSID persistence to identify the appropriate service, and routes the request to Media Server-1. Media Server-1 performs the requested action, such as play, forward, or rewind.
The RTSP monitor uses the RTSP protocol to evaluate the state of the RTSP services. The RTSP monitor connects to the RTSP server and conducts a sequence of handshakes to ensure that the server is operating correctly.
Parameter |
Specifies |
|---|---|
rtspRequest |
The RTSP request string that is sent to the RTSP server (for example, OPTIONS *). The default value is 07. The length of the request must not exceed 163 characters. |
respCode |
Set of response codes that are expected from the service. |
For instructions on configuring an RTSP monitor, see Configuring Monitors in a Load Balancing Setup.