I'm trying to understand how spydroid (https://code.google.com/p/spydroid-ipcamera/) works so I can write a similar app for my phone. Based off of spydroid here is what I understand about RTSP, RTCP and RTP.
RTSP runs on a specified port and sets everything up.
RTCP can run on any port. There is a client port and a server port. This is the control flow for RTP
RTP can run on any port. There is a client port and a server port. This contains the streams for audio and video. This is confusing because it seems it doesn't actually send the audio and video on this port. In spydroid it sends the video on port 5006 and the audio on 5004.
Spydroid is sending this message via RTSP to confirm the ports...
Transport: RTP/AVP/UDP;unicast;destination=123.456.789.00;client_port=65234-65235;server_port=44580-44581;ssrc=ba98a863;mode=play
I think what this is saying is that the client (VLC in my case) is listening on 65234 using UDP for RTP and 65235 for RTCP messages. Also spydroid is listening on 44580 for RTP and 44581 for RTCP. Is this right?
Now in the DESCRIBE sequence for RTSP, spydroid is telling the client m=video 5006 RTP/AVP 96 I think this is saying that it will be sending the video via UDP over port 5006.
Does everything I said in the above sentences sound correct?
What I really want to know is how to forward this information to the correct ports. The client ports are auto assigned by VLC. I tried running this command... vlc "rtsp://192.168.1.104:8086" --rtp-client-port=58866 but VLC seems to ignore it and pick it's own ports. So I have forwarded ports 8086, 5004 and 5006 but I don't know which port to forward for the RTP and RTCP connection because it changes every time. The only way I can make this work is by forwarding all ports to my computer. (I have a linksys router and it has a DMZ option) But this is a bad solution. Can someone please guide me in the right direction.
Also it is good to know that I am doing this because I am sending everything through an external IP address over the internet. Where as spydroid is intended to be used on a local area network.
I don't know how RTSP works and how to configure VLC but I know a thing or 2 about RTP.
I am guessing that client port means where the spydroid would be sending packets and server port is what it would be using as source port. So at UDP level, RTP packet would look like:
| SRC_PORT=44580 | DST_PORT=65234 | ... RTP_PACKET |
Next : m=video 5006 RTP/AVP 96
According to SDP standard 5006 is the port where spydroid would be listening on for incoming RTP packets
(not sure why) and the RTP payload type would be 96.
So, check if making VLC listen to port 65234 and forwarding {44580, 65234} packets to your PC works.
The info you gave is a little confusing and seems self contradictory. So, can't conclude anything concrete based on that.
According to the SDP standard...
Actually it indicates the source port.
The port (range) just indicates that is where the media will be sent from.
E.g if your source sends on 5006 but its routed via 10002 that's where rtsp helps Via the transport header.
The source port may really be 5006 but an intermediate router or firewall that is somewhere inside the LAN received the packet and sent it via another port and address.
Most software doesn't automatically know about your network setup and thus without modifying the sdp for external network use it cant really be used anywhere outside of YOUR network address space.
If you needed the port to match it can you just have to manually configure your sockets and software. (E.g. multicast or otherwise there's a few reasons why that port (range) needed to be different from what's in the rtsp transport header but if it is... then now you understand how and why.
Live 555 and some others send a probe packet and if that packet is returned via icmp the source port is reset to 0 so it can be discovered,be aware that this can conflict with existing traffic from the host if not done correctly.
QuickTime and vlc actually screw this up (mostly everyone does)and allow injection straight to the decoder from any port from the same host when 0 is used and ffmpeg and lav don't support ranges properly in the media port.
Just as excersize in thought, what if the port number was 1 or 65536 or * or -7?
Should that not also be handled?
What if the range was * or - or otherwise?
Remember that just because a value doesnt exists doesn't mean that you can't do the right thing with respect to the existing information if desired Even if the data received is not as expected Or indicated a value which should not be used.
Related
am trying to stream video from android to wowza streaming engine running on local host and using the android library libstream, the problem is am not sending anything. The app works fine but on checking incoming streams from wowza there is nothing, I have set the ip address of my pc, port, application name and the stream name as STREAM_URL = "rtsp://192.168.1.227:1935/sound/myStream" correctly but with no success, i have also disabled the firewall on my pc. Please help. Thanks
the RTP protocol used by libstreaming uses by default UDP datagram packages to send the stream. Even if the packages are sent from Android, it is possible that the firewall on the server where Wowza is running is not opened up. Please check in Wowza admin console on the Server page the "RTP Datagram Starting Port" setting. The UDP port negotiated for a live source starts from that port number, than for each live source that port number is increased by 1.
Please check the the Wowza server firewall is opened up for a range of port starting with the value from the "RTP Datagram Starting Port" settings. You can open up untill 10000.
I've installed Linphone on my Galaxy S2 device and I ran tcpdump on it to capture SIP traffic that Linphone is sending to my Asterisk server. I noticed that sometimes my device sends a special packet from UDP port 3526 to my Asterisk server port (5060) that contains:
HEX: 0d0a0d0a
ASCII: 13101310
Wireshark resolves this port (UDP 3526) to starquiz-port (this name is not useful because most clients use ephemeral ports). I searched the net about this port and starquiz. The only useful information that I found is this link at IANA. Does anyone know what is this packet, and why my phone is sending it to Asterisk?
PS: In section 3.5.1 of RFC 5626 a keep-alive using CRLF is mentioned but it is only for connection oriented protocols:
CRLF Keep-Alive Technique
This approach can only be used with connection-oriented transports
such as TCP or SCTP. The client periodically sends a double-CRLF
(the "ping") then waits to receive a single CRLF (the "pong"). If
the client does not receive a "pong" within an appropriate amount of
time, it considers the flow failed.
You softphone can use any port.
That is normal.
Softphone or asterisk(if set qualify=yes) can send empty udp packet for keeping NATed connection active. That is also normal.
I highly recommend you read more about SIP before dooing any softphone or other sip-related programming.
My application must stream device camera over 3g connection to server .
I follow this question link and use with success libstreaming (spydroid streaming lib) on wifi.
If device and server aren't on same lan, I need a 3g connection to do same thing, but I think there are problems caused by NAT .
Packets of libstreaming are sent by UDP , and over 3g they are blocked.
There are other solutions? Maybe using streaming over TCP I can reach my purpose.
When you are outside of the NAT you can't send data inside.
Unless:
Someone asks for that data.
In case 1 you need to make a UDP server with the fix IP and request
its data by IP:PORT
Using port forwarding.
In case 2 you need to set a port forwarding at the router level.
If all incoming ports are blocked on a ip camera (due to cellular network stuff), is it possible to have the ip camera initiate the connection to the client-viewer?
I am looking at using a android phone as a ip camera, (there are plenty of examples for the rtsp portion) but will need to figure out how to control the phone from the client-viewer using control connection initiated by the phone itself.
Would SDP announce work?
In this situation, you need an RTSP server, which can accept announcements from the IP camera, and relay the RTP streams from the IP camera to the RTSP client.
Otherwise, the RTSP client cannot reach the Ip camera directly.
I try to create sip phone application on android and I have some problem which is the RTP packet is unreachable to android emulator.
I'm not sure about this problem because of IP emulator.
I can do SIP Register and can call to other soft phone but when I talk there is no audio.
After I try to capture the packet, I see that the server cannot send RTP packet to the android emulator. So, it makes my program cannot have audio.
How can I fix this problem?
Have you done capture from start of call?
Have you seen no packet sent by server from start of call?
If server not sent single packet then you must check SDP parameters like,
a=sendrecv
connection ip
port of RTP
Also check that you (client) and server both are in same network.
If both are not in same network then NAT may affect RTP flow.