As mentioned in another post, we’re having problems with RTSP streaming on Android. I suspect this has something to do with UDP problems.
Is it possible to disable UDP RTSP streaming in Wowza, thus forcing streaming over TCP?
There is not a way to do this inside of Wowza. You can set your firewal to block UDP.
I have an Android device and I do not believe it supports RTSP/RTP interleaved. So it will not fail over to TCP delivery.
Charlie
The slow connection time is most likely because UDP ports are not opened properly. The player is probably trying to connect using RTSP/RTP over UDP and failing the switching to RTSP/RTP interleaved over UDP. Take a look in the Wowza Server logs and see if you see two connection attempts one for UDP and one for TCP.
Charlie
Hi,
we’re losing a ~17 seconds because of UDP bind/unbind:
15:41:11 RTPUDPTransport.bind[livetv/definst]: 0.0.0.0/0.0.0.0:6974
…
15:41:27 RTPUDPTransport.unbind[livetv/definst]: 0.0.0.0/0.0.0.0:6974
How can we avoid this? We have blocked UDP on our FW, but Wowza still tries to stream via UDP. Is there no way to instruct Wowza not to use UDP?
Thanks!
Hi,
I’ve changed this, but still get bind/unbind messages in logs:
2011-05-31 08:52:10 RTPUDPTransport.bind[livetv/definst]: 0.0.0.0/0.0.0.0:6970
…
2011-05-31 08:52:26 RTPUDPTransport.unbind[livetv/definst]: 0.0.0.0/0.0.0.0:6970
Application.xml looks like this:
forceInterleaved
true
Boolean
is this OK?
What else should I check?
Hi,
I’m using wowza 2.1.0 and Android Wildfire (2.2), Desire and Desire HD.
For the bind/unbind, what IP has to be listed in the message:
RTPUDPTransport.unbind[livetv/definst]: /IP_ADDRESS
I’ve tried with 0.0.0.0 and local IP address, but without success. Should the public IP be listed there?
I get it working on UDP in VLC on the local network (same vlan), but outside network it always fallsback to TCP. Network has been configured according to your instructions. (https://www.wowza.com/docs/how-to-troubleshoot-rtsp-rtp-playback)
I want to completely disable UDP, so that it immediately goes to TCP. Can this be done? if the device cannot do TCP, it’s not a problem.
Upgrade to Wowza 2.4. requires us to stop the service and spend a lot of time configuring it again, so it’s not a simple task to do.
Our configuration of ip addresses is:
PRIVATE_IP
NAT_IP
NAT_IP
Thanks!
Hello,
we’ve upgraded to 2.2.4. + patch01.
The problem is still present. the messages are a bit different in v2.2.4:
2011-06-02 10:10:08 RTPUDPTransport.bind[livetv/definst]: in:/Wowza:6974 out:/CLIENT_PUBLIC_IP:33522 -
…
2011-06-02 10:10:27 RTPUDPTransport.unbind[livetv/definst]: /Wowza:6974 -
What else can we check?
Thanks!
I’m looking at RTSP messages from Wowza in Wireshark and at first it tries to setup a standard RTSP connection:
Transport: RTP/AVP;unicast
After 10-15 seconds it fails and only then Wowza initiates a TCP connection:
Transport: RTP/AVP/TCP; unicast interleaved:0-1
How can I force Wowza to initiate TCP connection from start? We have set the parameter:
forceInterleaved
true
Boolean
in our current application conf file.
Thanks!
we noticed that if the client is behind NAT and does not have public IP, the UDP does not start.
Mobile devices have to have public IP to be able to access UDP. Some operators do not use public IP for mobile phones and UDP does not work then.
Srange this is that the UDP bind/unbind times vary quite a lot:
2011-06-06 14:11:21 CEST comment server INFO 200 - RTPUDPTransport.bind[livetv/definst]: in:/192.168.220.56:6970 out:/X.X.X.X:34100
…
2011-06-06 14:12:31 CEST comment server INFO 200 - RTPUDPTransport.unbind[livetv/definst]: /192.168.220.56:6970
This is almost a minute. The RTSP message with RTSP SETUP for RTP/AVP/TCP is sent from the client device 17 seconds after the RTSP SETUP for RTP/UDP streaming. Where are the other 40 seconds lost after switching to RTSP/TCP? This is quite strange.
Does anyone have a clue how to get RTSP working properly on Andorid?
Thanks!
Hi,
we finally found the problem. The problem is the client device NAT, firewall in front of Wowza and not the Wowza directly. Client device is behind NAT and the firewall was not aware of the UDP ports that we agreed by client-Wowza for RTP/UDP streaming. Firewall only knew ports that were used for client’s public IP address/NATing.
We had to turn on RTSP packet inspection on firewall infront of Wowza and have RTSP running on port 554 - because only then the firewall would know that the messages are RTSP.
We increased loading of video on Android HTC Wildfire, but it still takes approx. 10 seconds.
What could be the problem for this? It should load it much faster with RTP/UDP.
May I send you the RTSP link, maybe you can see why it loads it so long?
Thanks!
Add forcedInterleaved Property to /conf/[app-name]/Application.xml /MediaCaster /Properties
<Property>
<Name>forceInterleaved</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
Richard
Some rtsp mobile devices are not able to use TCP over 3g.
What version of Wowza? There is a major update for RTSP to mobile in 2.2.4 patch 1
https://www.wowza.com/docs/wowza-streaming-engine-software-updates
Richard
There is good chance that upgrading to 2.2.4.01 will fix this.
Otherwise, all the advice we have for reaching RTSP mobile devices is in this article:
https://www.wowza.com/docs/how-to-troubleshoot-rtsp-rtp-playback)
Most folks have a dev copy of Wowza to work with.
Richard
As mentioned, not all devices are able to use TCP over 3g. Is the forceInterleaved Property set properly in the MediaCaster Properties container? Best to just open all UDP ports
Richard
Sorry, I was looking at this the wrong way, forceInterleaved does not affect outgoing streams.
Richard
If you see that pattern consistently, UDP ports are blocked somewhere. If the Wowza mobile example works with that device, and you see that pattern in your logs, then it is UDP ports blocked in your system, the firewall on the machine Wowza is on, or a router or proxy.
Richard
Send it to support@wowza.com, and include a link to this thread for reference
Richard