• How to troubleshoot RTSP/RTP playback

    This mobile streaming troubleshooting guide covers RTSP/RTP out to devices such as Blackberry, Android, and other mobile phones. It doesn't cover Apple HLS streaming to iPhone, iPad, or iPod Touch.

    Contents



    Tutorial

    Troubleshooting

    Related Articles


    Tutorial



    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:
      • 800x480
      • 480x320
      • 240x160

    • 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.


    Configuration


    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.

    Live

    To set up an application for live streaming, see one of the following tutorials (based on encoder type):



    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, 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.

    TCP

    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:
    Code:
    <Port>1935,554,80</Port>
    Be 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:
    Code:
    rtsp://[wowza-ip-address]:1935/vod/mp4:sample.mp4
    With port 554 enabled, this can be changed to:
    Code:
    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 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):
    Code:
    <Property>
        <Name>debugRTSPSession</Name>
        <Value>true</Value>
        <Type>Boolean</Type>
    </Property>
    To enable the extra logging for the RTSP handshake between 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 > server and server > client message 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 > Server: Request
      Code:
      OPTIONS rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov RTSP/1.0
      CSeq: 2
      User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
      Server > Client: Response
      Code:
      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
    2. 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
      Code:
      DESCRIBE rtsp://184.72.239.149/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
      Server > Client
      Code:
      RTSP/1.0 200 OK
      Content-Base: rtsp://184.72.239.149/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
    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 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:

      Audio
      • 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

      Video
      • 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
      Code:
      SETUP rtsp://184.72.239.149/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
      Server > Client
      Code:
      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
      Server: Wowza Media Server 3.6.2 build5334
      Cache-Control: no-cache
      Client > Server: SETUP request for video track
      Code:
      SETUP rtsp://184.72.239.149/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
      Server > Client
      Code:
      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
      Server: Wowza Media Server 3.6.2 build5334
      Cache-Control: no-cache
    4. 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:
      Code:
      <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.

      Client > Server
      Code:
      PLAY rtsp://184.72.239.149/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-
      Server > Client
      Code:
      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/vod/mp4:BigBuckBunny_175k.mov/trackID=1;seq=1;rtptime=0,url=rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov/trackID=2;seq=1;rtptime=0
      Server: Wowza Media Server 3.6.2 build5332
      Cache-Control: no-cache
    5. 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
      Code:
      TEARDOWN rtsp://184.72.239.149/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):
    Code:
    <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)
    Code:
    http://[wowza-ip-address]:1935/vod/mystream/playlist.m3u8
    With port 80 enabled, this can be changed to:
    Code:
    http://[wowza-ip-address]/vod/mystream/playlist.m3u8
    For problems with non-iOS-based players that support Apple HTTP Live Streaming (HLS) streams, see How to turn off data event processing for Apple HTTP Live Streaming streams.

    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://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov.

    Test H.264 video on demand file: http://www.wowzamedia.com/_h264/BigBuckBunny_175k.mov