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.
Related
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.
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.
There are so many posts about rtsp protocol, generating rtp packets from android. I wrote a code which can generate rtp packet (stream) and send (unicast / broadcast) to local network. My question is how can i send the packets (stream) to server over Internet? As much i know we can't unicast to a server over inetnet from a local device (have private ip).
Android camera ----> RTP PACKETS -----------------------------------------------> SERVER
Internet
Yes you can. The router is responsible for this. In fact your router which has access to the internet has a public ip address which everyone shares behind the private network. That is how I am typing to you. Your android needs to have internet access to someone's network. The server will then contact that router since it will know its public ip address and your router will send those packets to your android.
I have implemented a sip based real time voice transfer under the impression that two of my phones on the same WIFI network can communicate provided that they have each others IP addresses. However, I could not make it work... I am using rtp to transfer voice between these clients.
Also, it's come to my notice that using a PC on the WIFI network as server is better. Now, can I use this PC as a proxy server to establish a sip end to end connection? If yes, how?
Are there existing implementations for initializing a session? Specifically, if someone could give me an example on what address/ports I would need both of my clients to establish the connection to, it would be great.
If you have implemented correctly all the necessary parts that SIP protocol demands, then you have to install a SIP server on your PC and just create two accounts that the phones will connect with them on the server. I have tried with Android the Asterisk server, but I am sure that there will be many others out there...
By default SIP servers are listening on port 5060 using UDP. This port is used only for the initiation of the session (and other control messages) and NOT for the transfer of RTP packets.