Tutorial

Overview of device capabilities

Android: Most Android devices support RTSP/RTP streaming. When streaming to an Android device using RTSP/RTP, the RTP portion must flow over UDP. Android doesn't support RTSP/RTP interleaved (RTP over TCP). This means that if UDP is unavailable for RTP playback, RTP over TCP won't work as a failover and your stream won't play. Android devices can't play MP3 streams over RTSP/RTP in any combination (audio/video or audio-only).

Some customers have reported RTSP/RTP playback issues on the DroidX and Droid 2 with streams that certain frame sizes. The following frame sizes will play properly on these devices:

Troubleshooting

Encoding

It's best to encode the video using a low bitrate, frame rate, and low encoding complexity. For mobile streaming, a total bitrate between 64Kbps and 250Kbps is best. Many mobile devices may not be able to handle a full 30 frames per second (fps). A frame rate between 15fps and 24fps may be best for mobile. It's best to encode to a lower H.264 complexity. Most mobile devices only support H.264 Baseline Profile. Encoder complexity and level are discussed in this Wikipedia article.

Networking (UDP and TCP setup)

UDP

It's best to open all UDP ports (0-65535) for RTSP/RTP streaming. On the incoming side, the Wowza media server software tries to use ports in the range 6970-9999. On the outgoing side, the port choice is made by the receiving device so it's best to open all ports to outgoing UDP traffic. Setting up UDP networking correctly is sometimes difficult and depends on your router and firewall configuration. If behind NAT (network address translation), it's important that all UDP ports are mapped to the server running the Wowza media server software.

Wowza provides a RTSP/RTP test stream running on Amazon EC2, which seems to work on most mobile networks/devices. Amazon EC2 is a great place to experiment with RTSP/RTP streaming. For more information, see Wowza for Amazon EC2.

Some carriers don't allow RTP or UDP over the carrier network. Many mobile devices will rollover to RTSP/RTP interleaved (RTP over TCP). These devices will work when the carrier doesn't support UDP. Some devices don't support RTSP/RTP interleaved and won't work if RTP or UDP is blocked by the carrier. Use the RTSP/RTP test stream to see if it works first before setting up your streams.

TCP

The default port for RTSP streaming is TCP port 554. Playback may not work properly when including the default Wowza media server streaming port (1935) in the playback URL as some players only use port 554.

Wowza Streaming Engine Manager configuration

To enable the Wowza media server to use port 554 for RTSP streaming:

In Wowza Streaming Engine Manager, click the Server tab, and then click Virtual Host Setup in the contents panel.

In the Virtual Host Setup page, click Edit in the Basic tab.

Scroll down to the Host Ports section of the page and click Edit (pencil icon) for the Default Streaming item.

Add 544 and 80 to the comma-separated Port(s) list (for example, the value may be 1935,544,80), and then click Apply.

Click Save, and then restart the application when prompted to apply the changes.

Use a text editor to open the [install-dir]/conf/VHost.xml file and add 554 and 80 to the HostPort/Ports list:

<Port>1935,554,80</Port>

Restart the Wowza media server software to apply the changes.

Make sure that you don't have another RTSP/RTP streaming server running on the same computer (such as Darwin Streaming Server). It may also use TCP port 554, which will lead to a port conflict. With TCP port 554 enabled, you can use RTSP playback URLs without having to specify the port number. For example, in the tutorials we suggest the following video on demand RTSP URL:

rtsp://[wowza-ip-address]:1935/vod/mp4:sample.mp4

With port 554 enabled, this can be changed to:

rtsp://[wowza-ip-address]/vod/mp4:sample.mp4

How to add additional logging for RTSP debugging

You can log extra debug information about the RTSP handshake between the Wowza media server and the RTSP/RTP source.

In the details page, click the Properties tab, and then click Custom in the Quick Links bar.

Note: Access to the Properties tab is limited to administrators with advanced permissions. For more information, see Manage credentials.

In the Custom section, click Edit.

Click Add Custom Property, specify the following settings in the Add Custom Property dialog box, and then click Add:

Path  Select /Root/Application/MediaCaster.

Name  Enter debugRTSPSession.

Type  Select Boolean.

Value  Enter true.

Click Save, and then restart the application when prompted to apply the changes.

To enable the extra logging for the RTSP handshake between the Wowza media server and the RTSP streaming clients, repeat the steps above but select /Root/Application/RTP as the Path value when creating the second debugRTSPSession custom property.

XML configuration

Use a text editor to open the [install-dir]/conf/[application]/Application.xml file for your live application and add the following property to the MediaCaster/Properties container. Be sure to add the properties to the correct <Properties> container in Application.xml as there are several such containers in the file.

To enable the extra logging for the RTSP handshake between the Wowza media server and the RTSP streaming clients, you must add the debugRTSPSession property to the RTP/Properties container in [install-dir]/conf/[application]/Application.xml.

RTSP call-flow

A typical RTSP streaming session, where the RTP payload is streamed over UDP, uses a workflow described in the following client-to-server and server-to-client message exchanges:

The client initiates the session with the server by sending an OPTIONS request. The server replies to this request with information about what it supports and what kind of requests it can receive from the client.

The client sends a DESCRIBE message and the server responds with an SDP file that the client can use to get more information about the content that will be sent by the server. The SDP file contains information about the video/audio codecs used, clip duration, trackIDs, profile level, and so on. In the following example, the audio track is trackID=1 and the video track is trackID=2.

The client sends two SETUP requests to the server, one for the video track and one for the audio track. The track IDs are received during the previous DESCRIBE message response. During the SETUP message exchange, the clinet informs the server about which UDP ports it will use for the RTP and RTCP communication for both video and audio tracks. The server will respond with an acknowledgement of the client ports to be used for the RTP/RTCP communication and inform the client about the UDP server ports that will be used for this session.

After the communication ports are established, the client will send a PLAY request that informs the server that it's ready to receive the RTP data flow. After acknowledging the request, the server starts sending the RTP payload and the periodic sender reports. The server will also receive the receiver reports from the client. Since the RTP data stream is flowing from the server to the client, the receiver reports from the client are the only feedback received by the server about the status of the communication, and confirms that the client is receiving the RTP packets.

The streaming application file [install-dir]/conf/[application]/Application.xml has a parameter that defines how long the server waits for an RTCP receiver report before stopping the RTP data flow:

<MaxRTCPWaitTime>12000</MaxRTCPWaitTime>

If no receiver reports come from the client, it means that there's no client to receive the RTP packets and the RTP stream can be stopped.

During RTSP troubleshooting, you can use the Wireshark packet analyzer to follow the entire communication between the server and a particular client, having information about the ports used for the RTP/RTCP communication and filtering only the source and destination IP addresses.

The RTP packets should arrive client-side in the correct sequence. You can analyze the server sender reports to see which packet was last sent by the server and compare with the received packets client-side.

If a Wireshark trace is taken server-side, you can check to see if receiver reports are present in the trace and get information about the latest packets received by the client. You can also get additional information about the packet loss rate, latest packet sequence received by the client, and so on.

When the user presses the Stop button, or closes the player, a TEARDOWN request is sent to the server to inform it that playback has stopped. The server will then stop sending RTP data to the client and stop the streaming session.

Problematic SDP files

Many RTSP sources, especially IP cameras, incorrectly publish the H.264 profile-level-id value in the Session Description Protocol (SDP) message. This can cause the video to be either blank or corrupted. You can configure the Wowza media server software to ignore the profile-level-id value in the SDP data and instead derive this value from the sprop-parameter-sets value.

In the details page, click the Properties tab, and then click Custom in the Quick Links bar.

Note: Access to the Properties tab is limited to administrators with advanced permissions. For more information, see Manage credentials.

In the Custom section, click Edit.

Click Add Custom Property, specify the following settings in the Add Custom Property dialog box, and then click Add:

Path  Select /Root/Application/RTP.

Name  Enter rtpIgnoreProfileLevelId.

Type  Select Boolean.

Value  Enter true.

Click Save, and then restart the application when prompted to apply the changes.

XML configuration

Use a text editor to open the [install-dir]/conf/[application]/Application.xml file for your live application and add the following property to the RTP/Properties container. Be sure to add the properties to the correct <Properties> container in Application.xml as there are several such containers in the file.