- Networking (UDP and TCP setup)
- How to add additional logging for RTSP debugging
- RTSP call-flow
- Problematic SDP files
- Apple HLS streaming on non-iOS-based players
- Test stream URLs
Overview of device capabilities
This section briefly describes device capabilities and supported streaming protocols.
- Android: Most Android devices support RTSP/RTP streaming. Newer Android devices that are running version 2.2 (Froyo) or later also support Adobe Flash player 10.1 and can play RTMP and Adobe HDS streams. Android devices can't play MP3 streams over RTSP/RTP in any combination (audio/video or audio only). Android devices that support Flash player 10.1 can play MP3 using RTMP or Adobe HDS. 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.
Customers have reported issues with RTSP/RTP playback on the DroidX and Droid 2. It seems that only the following frame sizes will play properly on these devices:
- Sony Ericsson: A customer has 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 Blackberry devices support RTSP/RTP interleaved (RTP over TCP) if RTP over UDP isn't available.
- iOS: iPhone, iPad, and iPod touch devices support Apple HTTP Live Streaming only. RTSP/RTP streaming isn't supported on iOS devices.
- Windows Phone: Windows Phone devices support Microsoft Smooth Streaming through applications that are built on the Microsoft Media Platform Player Framework.
- Other devices: Most other mobile devices such as Nokia, Samsung, Sony Ericsson, etc., that support video/audio streaming support RTSP/RTP. Support for MP3 over RTSP/RTP isn't as common as AAC-LC.
Tutorials are available to help you set up an application for video on demand or live streaming.
Video on demand
To set up an application to stream video on demand (VOD), see How to set up video on demand streaming.
Note: The Wowza Media Server installation provides a preconfigured application named vod.
To set up an application for live streaming, see one of the following tutorials (based on encoder type):
- How to set up live streaming using an RTMP-based encoder
- How to set up live streaming using an RTSP/RTP-based encoder
- How to publish and play a live stream (MPEG-TS based encoder)
- How to set up live streaming using a native RTP encoder with SDP file
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)
It's best to open all UDP ports (0-65535) for RTSP/RTP streaming. On the incoming side, Wowza Media Server 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 Wowza Media Server.
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.
The default port for RTSP streaming is TCP port 554. Some players only use this port for streaming. So even even if you include the default Wowza Media Server streaming port (1935) in the playback URL, playback may not work properly. To enable Wowza Media Server to use this port, edit [install-dir]/conf/VHost.xml and add 554 and 80 to the HostPort/Ports list:
How to add additional logging for RTSP debugging
You can log extra debug information about the RTSP handshake between Wowza Media Server and the RTSP/RTP source to the log file by adding the following property to the MediaCaster/Properties container in [install-dir]/conf/[application]/Application.xml (be sure to get the correct <Properties> container, there are several in the Application.xml file):
<Property> <Name>debugRTSPSession</Name> <Value>true</Value> <Type>Boolean</Type> </Property>
A typical RTSP streaming session, where the RTP payload is streamed over UDP, uses a workflow described in the following client > server and server > 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.
Client > Server: Request
OPTIONS rtsp://18.104.22.168/vod/mp4:BigBuckBunny_175k.mov RTSP/1.0 CSeq: 2 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
RTSP/1.0 200 OK Supported: play.basic, con.persistent Cseq: 2 Server: Wowza Media Server 3.6.2 build5334 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER Cache-Control: no-cache
- 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.
Client > Server
DESCRIBE rtsp://22.214.171.124/vod/mp4:BigBuckBunny_175k.mov RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Accept: application/sdp
RTSP/1.0 200 OK Content-Base: rtsp://126.96.36.199/vod/mp4:BigBuckBunny_175k.mov/ 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 Server: Wowza Media Server 3.6.2 build5334 Cache-Control: no-cache v=0 o=- 408754851 408754851 IN IP4 127.0.0.1 s=BigBuckBunny_175k.mov 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
- 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.
In the following example, the client will use the following ports:
- The server will send RTP packets from UDP source port 7066 to the client UDP destination port 57780
- The server will send RTCP sender reports from UDP source port 7067 to the client UDP destination port 57781
- The client will send receiver reports from UDP source port 57781 to the server UDP destination port 7067
- The server will send RTP packets from UDP source port 7064 to the client UDP destination port 57782
- The server will send RTCP sender reports from UDP source port 7065 to the client UDP destination port 57783
- The client will send receiver reports from UDP source port 57783 to the server UDP destination port 7065
Client > Server: SETUP request for audio track
SETUP rtsp://188.8.131.52/vod/mp4:BigBuckBunny_175k.mov/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
RTSP/1.0 200 OK Date: Tue, 23 Apr 2013 14:19:15 UTC Transport: RTP/AVP;unicast;client_port=57780-57781;source=184.108.40.206;server_port=7066-7067;ssrc=07938AE3 Session: 408754851;timeout=60 Expires: Tue, 23 Apr 2013 14:19:15 UTC Cseq: 4 Server: Wowza Media Server 3.6.2 build5334 Cache-Control: no-cache
SETUP rtsp://220.127.116.11/vod/mp4:BigBuckBunny_175k.mov/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
RTSP/1.0 200 OK Date: Tue, 23 Apr 2013 14:19:15 UTC Transport: RTP/AVP;unicast;client_port=57782-57783;source=18.104.22.168;server_port=7064-7065;ssrc=1206BD1C Session: 408754851;timeout=60 Expires: Tue, 23 Apr 2013 14:19:15 UTC Cseq: 5 Server: Wowza Media Server 3.6.2 build5334 Cache-Control: no-cache
- 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:
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.
Client > Server
PLAY rtsp://22.214.171.124/vod/mp4:BigBuckBunny_175k.mov/ RTSP/1.0 CSeq: 6 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Session: 408754851 Range: npt=0.000-
RTSP/1.0 200 OK Range: npt=0.0-596.458 Session: 408754851;timeout=60 Cseq: 6 RTP-Info: url=rtsp://126.96.36.199/vod/mp4:BigBuckBunny_175k.mov/trackID=1;seq=1;rtptime=0,url=rtsp://188.8.131.52/vod/mp4:BigBuckBunny_175k.mov/trackID=2;seq=1;rtptime=0 Server: Wowza Media Server 3.6.2 build5332 Cache-Control: no-cache
- 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.
Client > Server
TEARDOWN rtsp://184.108.40.206/vod/mp4:BigBuckBunny_175k.mov/ RTSP/1.0 CSeq: 7 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Session: 408754851
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 Media Server to ignore the profile-level-id value in the SDP data and instead derive this value from the sprop-parameter-sets value by adding the following property to the RTP/Properties container in [install-dir]/conf/[application]/Application.xml (be sure to get the correct <Properties> container, there are several in the Application.xml file):
<Property> <Name>rtpIgnoreProfileLevelId</Name> <Value>true</Value> <Type>Boolean</Type> </Property>
Apple HTTP Live Streaming on non-iOS-based players
To play using Android 4.0 or higher with (Cupertino/Apple HTTP Live Streaming)
Test Stream URLs
RTSP/RTP test stream: http://www.wowzamedia.com/mobile.html
This is a properly setup test stream running on Amazon EC2. The direct RTSP URL is rtsp://220.127.116.11/vod/mp4:BigBuckBunny_175k.mov.
Test H.264 video on demand file: http://www.wowzamedia.com/_h264/BigBuckBunny_175k.mov
- Click here, if you are having problems or would like to discuss this article.
- Leave a comment below, if there is some aspect of this article you would like to see changed or improved.