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.
Related
I am trying to build an embedded device that would be connected to a router.
But I want to be able to know if the device is connected to the router or not using a PC or Mobile.
For example:
How can the PC detect if the google chromecast is connected on the same network or not ?
Do I need to communicate with each IP in the network on a specific port to ask ?
Or do I need to let the embedded device broadcast some information every N seconds ?
Thanks,
In any case you should consider doing a Gratuitous ARP on your embedded device. A gratuitous ARP will announce to all of the devices on your LAN that a new device has joined so they can update their ARP cache.
As far as a PC/Mobile device discovering your embedded device goes, you have a few options:
Option 1
If we can assume that this is a typical flat home network where all of the devices are on a single subnet and there is one gateway router * then you can give your embedded device a unique OUI. If you intend to sell this device you will need to apply for an OUI with the IEEE anyway unless whoever made your chipset supplies it with a MAC address already. Your PC/Mobile app can periodically check its ARP cache for an OUI that matches the unique OUI that you expect.
This will not work if the network is not flat and there are multiple routed subnets or VLANS. Here is a possible scenario: Lets suppose your embedded device connects to a client bridge range extender. If your PC/Mobile app is on the main access point it will never see the MAC address of the embedded device - instead it will see the MAC address of the client bridge. Multiple IPs will be mapped to the client bridge because the client bridge and the client bridge will be switching packets.
*I put the term router in italics because most home routers are merely doing NAT between the WAN/LAN and the LAN side of the router operates like a layer 2 switch.
Option 2
You can do a broadcast ping request, eg. ping xxx.xxx.xxx.255. You'll get a response back from all devices that will accept a broadcast ping request. Just make sure your device does. Then once you have a list of IP addresses you can attempt to open a TCP socket over the arbitrary port of your choosing with all of those IP addresses and then send some unique handshake packet. Your embedded device should be listening over this port and should have some unique reply to this unique packet. Most of the devices on the lan should generally not allow this socket to open, but if they do they should not understand the unique handshake message you send.
Option 3
Send a broadcast UDP datagram with some unique handshake payload. Then your embedded device should reply to the sender of this broadcast UDP packet with some unique response. After this response has been received by your PC/Mobile app you can then open a TCP socket with the IP address the response came from.
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.
I am trying to make a sip call by using android.net.sip but have registration problem.
All responses from the server (I tried multiple servers) correctly reached UDP port number that is described in the Via and Contact headers of the Register.
However, all of responses got ICMP port unreachable.
I am using AVD running on XP machine and I verified both isAPIsupproted and isVoipSupported.
I would appreciate if you can provide a solution.
Does the response packet reach the port which REGISTER packet sent from?
It seems the emulator only listens on the loopback interface (check with netstat, etc.), so if you want to get incoming connections, you need to port forward incoming connections on the host machine's LAN interface (eth0, etc.) to the corresponding ports on loopback. I haven't tried this though, so it's all theoretical.
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.
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.