Troubleshoot RTSP/RTP playback from Wowza Streaming Engine

This guide provides troubleshooting techniques for RTSP/RTP output from Wowza Streaming Engine™ media server software to mobile devices such as those that run on Android.

Overview of RTSP/RTP playback

---

This section briefly describes device capabilities and supported streaming protocols.

Android

Most Android devices, including those from Nokia, Samsung, and Sony Ericsson, 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). Support for MP3 over RTSP/RTP isn't as common as AAC-LC.

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

• 800x480
• 480x320
• 240x160

One customer has also reported that some Sony Ericsson phones requires Baseline Profile Level 1.2 or lower for video playback.

BlackBerry

Most BlackBerry devices support RTSP/RTP streaming. Many support RTSP/RTP interleaved (RTP over TCP) if RTP over UDP isn't available.

Note: iOS devices and Windows Phone devices do not support RTSP/RTP playback.

You can use the Wowza Test Players webpage to test your streaming applications.

Optimize encoding

---

For mobile streaming, it's best to encode the video using a low bitrate, low frame rate, and low encoding complexity. A total bitrate of 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 the H.264 Baseline profile.

Open UDP ports

---

For incoming UDP streams, Wowza Streaming Engine tries to use ports 6970 to 9999, but in many cases it's best to open all UDP ports (0 to 65535) for RTSP/RTP streaming. 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 Wowza Streaming Engine.

Some carriers don't allow RTP or UDP over their network. Many mobile devices will roll over 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 Wowza RTSP/RTP test stream to see if it works first before publishing your stream.

Configure TCP port 554

---

The default port for RTSP streaming is TCP port 554. Playback may not work properly if you include the default Wowza Streaming Engine port (1935) in the playback URL, as some players only use port 554.

To enable Wowza Streaming Engine to use port 554 for RTSP streaming, do the following:

1. In Wowza Streaming Engine Manager, click the Server tab, and then click Virtual Host Setup in the contents panel.
    
2. In the Virtual Host Setup page, click Edit in the Basic tab.
    
3. Scroll down to the Host Ports section of the page and click Edit (pencil icon) for the Default Streaming item.
    
4. Add 554 and 80 to the comma-separated Port(s) list (for example, the value may be 1935,554,80), and then click Apply.
    
5. Click Save, and then restart the application when prompted to apply the changes.

For more information, see Configuring streaming ports.

Alternatively, you can configure Wowza Streaming Engine to use port 554 for RTSP streaming in XML:

1. Use a text editor to open the [install-dir]/conf/VHost.xml file and add ports 554 and 80 to the <HostPort>/<Ports> container element:
    

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

2. Restart Wowza Streaming Engine to apply the changes.

Make sure that you don't have another RTSP/RTP streaming server, such as Darwin Streaming Server, running on the same computer as Wowza Streaming Engine. It may also use TCP port 554, which will cause a port conflict.

With TCP port 554 enabled, you can use RTSP playback URLs without having to specify the port number. For example, instead of using the VOD RTSP URL:

use the URL:

Add RTSP debug logging

---

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

To configure Wowza Streaming Engine to add RTSP debug information to the log file, do the following:

1. In Wowza Streaming Engine Manager, click the Applications tab and select your application in the contents panel.
    
2. 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.
3. In the Custom section, click Edit.
    
4. 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 rtspDebugSession.
      
   • Type - Select Boolean.
      
   • Value - Enter true.
5. Click Save, and then restart the application when prompted to apply the changes.
6. (Optional) To enable the extra logging for the RTSP handshake between Wowza Streaming Engine and RTSP streaming clients, repeat the process but select /Root/Application/RTP as the Path value when creating the second rtspDebugSession custom property.

Alternatively, you can configure Wowza Streaming Engine to add extra RTSP debug information to the log file using XML:

1. 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 in the file.
    

   <Property>
       <Name>rtspDebugSession</Name>
       <Value>true</Value>
       <Type>Boolean</Type>
   </Property>

2. Restart Wowza Streaming Engine to apply the changes.
3. (Optional) To enable the extra logging for the RTSP handshake between Wowza Streaming Engine and the RTSP streaming clients, add the rtspDebugSession property to the RTP/Properties container in [install-dir]/conf/[application]/Application.xml.

Follow the client and server communications flow

---

A typical RTSP streaming session, where the RTP payload is streamed over UDP, uses the following exchanges.
 

1. 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.
   
   Client options request:
    

   OPTIONS rtsp://184.72.239.149/myApplication/mp4:sample.mp4 RTSP/1.0
   CSeq: 
   2
   User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)

   Server response:
    

   RTSP/1.0 200 OK
   Supported: play.basic, con.persistent
   CSeq: 2
   Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER
   Cache-Control: no-cache

2. The client sends a DESCRIBE message and the server responds with a Session Description Protocol (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.
   
   Client describe request:
    

   DESCRIBE rtsp://184.72.239.149/myApplication/mp4:sample.mp4 RTSP/1.0
   CSeq: 3
   User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
   Accept: application/sdp

   Server response:
    

   RTSP/1.0 200 OK
   Content-Base: rtsp://184.72.239.149/myApplication/mp4:sample.mp4/
   Date: Tue, 23 Apr 2013 14:19:15 UTC
   Content-Length: 576
   Session: 408754851;timeout=60
   Expires: Tue, 23 Apr 2013 14:19:15 UTC
   CSeq: 3
   Content-Type: application/sdp
   Cache-Control: no-cache
   v=0
   o=- 408754851 408754851 IN IP4 127.0.0.1
   s=sample.mp4
   c=IN IP4 0.0.0.0
   t=0 0
   a=sdplang:en
   a=range:npt=0- 596.458
   a=control:*
   m=audio 0 RTP/AVP 96
   a=rtpmap:96 mpeg4-generic/48000/2
   a=fmtp:96 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1190
   a=control:trackID=1
   m=video 0 RTP/AVP 97
   a=rtpmap:97 H264/90000
   a=fmtp:97 packetization-mode=1;profile-level-id=42C01E;sprop-parameter-sets=Z0LAHtkDxWhAAAADAEAAAAwDxYuS,aMuMsg==
   a=cliprect:0,0,160,240
   a=framesize:97 240-160
   a=framerate:24.0
   a=control:trackID=2

3. 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 client 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.
   
   In the following example, the client uses the following ports:
   
   Audio
   • The server sends RTP packets from UDP source port 7066 to the client UDP destination port 57780
   • The server sends RTCP sender reports from UDP source port 7067 to the client UDP destination port 57781
   • The client sends receiver reports from UDP source port 57781 to the server UDP destination port 7067
   Video
   • The server sends RTP packets from UDP source port 7064 to the client UDP destination port 57782
   • The server sends RTCP sender reports from UDP source port 7065 to the client UDP destination port 57783
   • The client sends receiver reports from UDP source port 57783 to the server UDP destination port 7065
   
   Client setup request for audio track:
    

   SETUP rtsp://184.72.239.149/myApplication/mp4:sample.mp4/trackID=1 RTSP/1.0
   CSeq: 4
   User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
   Transport: RTP/AVP;unicast;client_port=57780-57781

   Server response:
    

   RTSP/1.0 200 OK
   Date: Tue, 23 Apr 2013 14:19:15 UTC
   Transport: RTP/AVP;unicast;client_port=57780-57781;source=184.72.239.149;server_port=7066-7067;ssrc=07938AE3
   Session: 408754851;timeout=60
   Expires: Tue, 23 Apr 2013 14:19:15 UTC
   CSeq: 4
   Cache-Control: no-cache

   Client setup request for video track:
    

   SETUP rtsp://184.72.239.149/myApplication/mp4:sample.mp4/trackID=2 RTSP/1.0
   CSeq: 5
   User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
   Transport: RTP/AVP;unicast;client_port=57782-57783
   Session: 408754851

   Server response:
    

   RTSP/1.0 200 OK
   Date: Tue, 23 Apr 2013 14:19:15 UTC
   Transport: RTP/AVP;unicast;client_port=57782-57783;source=184.72.239.149;server_port=7064-7065;ssrc=1206BD1C
   Session: 408754851;timeout=60
   Expires: Tue, 23 Apr 2013 14:19:15 UTC
   CSeq: 5
   Cache-Control: no-cache

4. After the communication ports are established, the client sends 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 a third-party packet analyzer such as Wireshark 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.
   
   Client play request:
    

   PLAY rtsp://184.72.239.149/myApplication/mp4:sample.mp4/ RTSP/1.0
   CSeq: 6
   User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
   Session: 408754851
   Range: npt=0.000-

   Server response:
    

   RTSP/1.0 200 OK
   Range: npt=0.0-596.458
   Session: 408754851;timeout=60
   CSeq: 6
   RTP-Info: url=rtsp://184.72.239.149/myApplication/mp4:sample.mp4/trackID=1;seq=1;rtptime=0,url=rtsp://184.72.239.149/myApplication/mp4:sample.mp4/trackID=2;seq=1;rtptime=0
   Cache-Control: no-cache

5. When the viewer stops playback or closes the player, a TEARDOWN request is sent to the server to inform it that playback has stopped. The server then stops sending RTP data to the client and stops the streaming session.
   
   Client teardown request:
    

   TEARDOWN rtsp://184.72.239.149/myApplication/mp4:sample.mp4/ RTSP/1.0
   CSeq: 7
   User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
   Session: 408754851

Fix 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 Wowza Streaming Engine to ignore the profile-level-id value in the SDP data and instead derive this value from the sprop-parameter-sets value.

To derive an ID value from sprop-parameter-sets in Wowza Streaming Engine Manager:

1. Click the Applications tab and select your application in the contents panel.
    
2. 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.
3. In the Custom section, click Edit.
    
4. 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.
5. Click Save, and then restart the application when prompted to apply the changes.

Alternatively, set the custom property in XML:

1. 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 element. Be sure to add the properties to the correct <Properties> container in Application.xml, as there are several in the file.

   <Property>
       <Name>rtpIgnoreProfileLevelId</Name>
       <Value>true</Value>
       <Type>Boolean</Type>
   </Property>

2. Restart Wowza Streaming Engine to apply the changes.

Play Apple HLS streams on non-iOS devices

---

To play on Android 4.0 or later with Cupertino/Apple HTTP Live Streaming use the URL:

With port 80 enabled, use the URL:

For problems with players on non-iOS-devices that support Apple HLS streams, see Turn off data event processing for HLS streams in Wowza Streaming Engine.

Test stream URLs

---

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 About deploying Wowza Streaming Engine on Amazon.

You may also use our H.264 test stream, which is a H.264 test VOD clip. 

More resources

---

• Players and playback
• Set up an application for RTSP/RTP streaming in Wowza Streaming Engine