I'm writing my own simple soft phone, but I fail to understand the basics of how SIP works, so I wanted to see on a low level how a server responds to messages like the REGISTER request. I have a simple OpenWRT PBX in my router at home, and a couple of hard and Android softphones are working normally - they seem to register, perform calls both between themselves and outside too, so I'm sure it's functional. It's serving requests over UDP and port 5060.
But when I try to get a response from the server on a low level, how I used to do with tcp and telnet, just to see what's going on when a phone is working, the server doesn't seem to respond anything.
Can you please guide me how I can use netcat or some other telnet-like tool to see how the server responds over udp to any request, be them good or malformed?
Use tcpdump tool over telnet
Tcpdump Commands – A Network Sniffer Tool
check the link below.
https://www.tecmint.com/12-tcpdump-commands-a-network-sniffer-tool/
The good tool is Wireshark very good support for SIP message flow and RTP/RTCP.
You may capture the packets from the OpenWRT PBX and from your development device in order to compare things. Good learning!
Related
As far as I search, All WebRTC handshakes are done through any signaling server [ HTTP, WebSocket, etc..] even through Mail or Whatsapp.
But I expect to connect without using any of them. Is there any way to archive this?
If yes, please give me a brief solution. ThankYou!
WebRTC (as implemented in browsers) requires signalling. You can choose a different medium for signalling such as a piece of paper or calling someone on the phone, but it needs signalling.
If you want to be able to initiate unsolicited connections you need to use TCP or UDP directly which (if we ignore NAT and firewalls) don't have that restriction.
I have a webcam chat room application (so it's many-to-many video sharing) using WebRTC and a mediasoup server.
I am having problems with SOME of my users not being able to get an incoming video feeds to work. It's a difficult problem because I can't reproduce it at all, and I can't easily "remote-debug" the problem since most of my users are very non-technical. So far the only thing I can tell for certain is that it seems to be network-related, not browser-related, as I have had bug reports from people using Firefox, Chrome, Safari, and Edge. I'm running my server (mediasoup v2) on port 443 with no firewall on the server box, so that should make the door as wide as possible. I just don't know what the exact problem is yet so I'm feeling around in the dark.
So, I'm trying solutions. I don't think(?) I have a TURN server set up but from what I have read, it seems like adding one certainly can't hurt, and could help with my situation.
I don't fully understand the entire WebRTC protocol or RFC 7118 (this stuff is really complicated!) or exactly what/where/how a TURN server fits into the bigger picture. It would help, right? A lot of Googling has led to no clear answers. Would love some help! Thank you!
WebRTC tries everything it can do to make a p2p connection, but there are times that it will fail. The turn server acts as a last resort so that the peers can both connect through the turn server. Obviously this is not a p2p connection, so there will be extra latency, and you will have to make sure that your turn server has enough bandwidth to cover all of the connections you expect.
TL;DR, If you need 100% connection rates, you should have a turn server.
I believe AWS has a ready made instance you can spin up, or if you could use this open source coturn server https://github.com/coturn/coturn
On a debugging note... Check your ice candidates type. You should see host and srflx if you only have a STUN server, but if you have a TURN server you will also see relay. You can replicate this issue by discarding the ice candidates that have host and srflx types.
I'm running my server (mediasoup v2) on port 443 with no firewall on the server box, so that should make the door as wide as possible
That is websocket. The media traffic runs over UDP typically and mediasoup uses random ports. A TURN server which is configured on udp port 443 may help in some cases.
The other problem is UDP being blocked which is easy to reproduce with a local firewall.. Mediasoup supports something called ice-tcp which will allow media to run over a TCP connection. You should check if your mediasoup installation uses ice-tcp. If it does not, a TURN server with TURN/TCP will help.
so i started to work in this summer and the first task they have given to me is to use wireshark to understand why an application that uses webRTC doesn't use the turn server.
Can you guys help me out, to understand which steps should i do to understand better where is the problem.
I already run the wireshark and only get protocols STUN, that bind to a UDP connection.
TURN is a STUN extension so you will only see STUN packets in Wireshark.
You can easily test WebRTC+TURN in isolation using this sample from the WebRTC project. Remove the default stun server and add the url and credentials for your own TURN server.
Fire up wireshark, start capturing.
Click the "gather candidates" button on that page. You should see candidates with host type at least. You should, if the browser can reach the TURN server usually also see candidates with a srflx type.
If the TURN server is working and your credentials are valid, then you will get candidates with type relay. But you probably wouldn't be asking then.
Now go back to wireshark. Set the display filter to 'stun'. You should see some packets sent to the ip address of the TURN server. Right-click on one of them, 'follow' and 'udp stream'. That should show you all the packets between the browser and the TURN server.
You should be seeing binding requests (message_type=0x01) as well as binding success responses (message_type=0x101) from the server. If you don't see those, your turn server is not responding or something is blocking the client. You will also not get srflx candidates on the candidate gathering demo page.
You should also see packets wireshark interprets as 'allocate request udp' (the message type is 0x101). These are the important ones for TURN.
You should see an error from the TURN server with a message type 0x113 and an error code 401 (unauthorized) because in the first packets, there is no username attribute. In response to those the browser will start sending allocate requests that contain both a username and a message-integrity.
If things go well, those should be answered with an allocate success response (message type=0x103) indicating a xor-relayed-address.
If not and you see more 401 errors that usually means your username and password is wrong.
You might also find the articles on using wireshark to reverse-engineer Amazon Mayday and Whatsapp on WebRTChacks useful -- both use Wireshark.
The WebRTC project has some notes on Wireshark, too.
It seems like you should be able to use telnet to manually make json-rpc calls. However, when I try this, I get no response at all from the server and have to shut down the telnet client. Do I need to send headers and/or somehow indicate that my input is complete?
You have a small problem: you've completely misunderstood everything!
https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29
It says right there that it supports JSON-RPC over HTTP. Nothing at all about JSON-RPC over plain TCP (what you're calling "Telnet" protocol).
You say "It seems like you should be able to use telnet to manually make json-rpc calls" but you don't mention how you came to this conclusion.
JSON-RPC is typically implemeted over HTTP, but can be implemented over plain TCP, websockets, or any bi-directional internet protocol. That being said, the overwhelming majority of JSON-RPC server implementations expose their APIs via JSON-RPC over HTTP.
As others have mentioned, you can talk HTTP from a telnet client and the payload of that conversation can be JSON-RPC.... if you know how. Just because you can doesn't meant you should.
I have a project that will let you host a Json-Rpc server over telnet if you like. It doesn't come with telnet support built in, but it would be trivial to host it over telnet. See the console hosting example and just replace the console with a telnet server.
http://jsonrpc2.codeplex.com/
My task is to write a Messenger program for both internal and external staffs, I actually made it. However, I thing this is really not a good approach by using the client software keep "check-mesg" from server. So I think I am just simulating the IM program.
I want to make the client app become a listening server, and let user p2p talking without a "mesg-centre" at the main server(unless offline mesg happen). The question is how do I tell the external user ( other client app ) my location while I am behind a router ?
Are those other IM programs running on the client machine as a server too? and how do they get through ?
Thanks in advance!
It's quite complicated to connect to systems behind a router and not always possible. A well-documented way to do this with UDP is the STUN protocol (used mainly for SIP-based VoIP). If it is not possible to get behind the router, you can only use a server in the open network as intermediator (some P2P systems also promote well-connected peers to such intermediators). SIP uses TURN for as intermediator protocol. SIP's protocol to find out the right solution for a client is ICE.
See also NAT traversal.