I am developing STUN for VoIP behind NAT(SIP protocol)..
I have a couple of routers for use..I find that the routers are changing the SIP messages(SDP and contact field)for NAT traversal...If I disable SIP ALG in routers,then NO SIP packets are forwarded..Is there any setting so that the Routers don't put any SIP intelligence and just forward the packets and not change the sip packet.
Thanks and regards
Buy a new router. Seriously, any NAT existing in 2013 that is still trying to translate application protocols (other than FTP) and modifying message contents (beyond the IP header) should be thrown out.
Is your SIP traffic sent over TCP or UDP? Is there a SIP gateway involved? Or are you trying to do a SIP INVITE between two endpoints without a signaling server?
In any case.... the standard solution to this problem is that the SIP messages should be sent over TLS/SSL (encrypted) to the SIP gateway. Your router won't be able to interpret these messages and will just treat them as a standard TCP traffic.
If you code for both endpoints, a simpler fix is to simply base64 encode your messages
Related
I am making a web-system for a callcenter, where I need an integration to SIP (so I can call phonenumbers).
I found this tool that looks like it's suitable as a softphone. https://www.doubango.org/sipml5/call.htm?svn=170
I have made an test account at sipdiscount.com (it looked cheap) that I suppose, I can connect to doubango's softphone tool. But how do I connect? What is private/public identity? And do you have any better suggestions?
To connect to a SIP Proxy (UAS) you only need Host Name or IP Address AND username/password. Also, online SIP providers typically give your a Trunk, which can be used telephone number to dial-out and/or accept new calls. However, SIP provides provide trunks and allow you to define your own telephone numbers, which route through the SIP trunk. Default UDP port is 5060. For security purposes, some SIP providers provide SSL\TLS over TCP port 5061, while others support DTLS over UDP port 5061.
private/public identity is not part of SIP protocol, so might be some proprietary doubango thing. I never used doubango, so not sure. I've been using Zoiper, which is the most basic SIP Phone and a UI that is common to all softphones.
Hi guys I'm new to understanding protocols used over the web and need some help in understanding the basics of websockets,TCP/IP and HTTP.
My understanding of the relation between TCP/IP and HTTP is that IP is required to connect all networks. TCP is a mechanism that allows us to transfer data safely and HTTP, which utilizes TCP to transfer its data, is a specific protocol used by Web servers and clients.
Does this mean you can't send a HTTP request without TCP?
Websockets communicate using TCP layer and a connection between client and server is established through HTTP which is known as the handshake process.
Does websockets have its own protocol? How can you send a http request(hand shake process) to establish TCP/IP when you need TCP to carry out an HTTP request. I know I am missing something really important here and would be great to get my understanding of these protocols sharpened!
Firstly, IP is not necessarily required to connect all networks. However, it is the most widely used and adopted today (For now that is). Old network protocols such as Appletalk, IPX, and DECNet are all legacy network protocols that are not much used anymore, however they are still around to an extent. Don't forget IPv6 is out there as well, in some places, and can ride over IPv4 networks if your configuration is done properly.
When you say TCP being "safe", I would give it another word, and that would be intelligent. TCP is a transport protocol, and is the header that comes directly after the IPv4 header. TCP is primarily used for flow control and has become very efficient at error recovery in case a part of a packet or packets has been last when transferring/receiving. While this is great for some transactions, the error control requires an additional amount of overhead in the packet. Some applications, let's say VoIP for example, is very sensitive to delay, jitter (Variation in delay) and congestion. This is why it uses UDP.
Like TCP, UDP is a transport protocol, however there is no flow control. Think of it this way: When sending packets over TCP, it's like asking the other end if they received your message. If they did, they will acknowledge it. If not, you now have to determine how you will resend this information. UDP has none of this. You send your message to the other side, and hope it gets there.
Now if you want to talk about "safe" protocols, this is usually done at either the network layer (IPSec) or the application layer (SSL). Safe typically means secured.
A usual TCP three-way handshake looks like this:
Whoever sends the SYN is the client. Whoever receives that initial SYN is the server.
Client sends SYN --> Server
Now, if the server is listening, and/or there's not a firewall blocking the service (Which in that case you'd receive a TCP frame from the server with the RST,ACK bits set most likely), the server will respond with a SYN-ACK:
Server sends SYN/ACK --> Client
If the client received this packet, he will acknowledge he received it. This completes the three-way handshake and these two may begin exchanging information.
Client sends ACK --> Server
Here's a good site for some info:
http://www.tcpipguide.com/free/index.htm
I am testing a setup with one sip client (tested with sipp and a softphone) and an IMS server that auto answers (so it is a two way RTP-communication between those 2 network elements).
In RTCP, must both the two entities communicating in such a scenario send RTCP packets? I am asking that because when i use the sipphone, it sends some RTCP packets at first and then the server answers, whereas the sipp scenario doesn't send rtcp packets at all and gets no response from that protocol. Also, all the ports for RTP+RTCP are open both in the router and in the testing machine.
Can an IMS server be configured to send RTCP packets (one direction only) on an RTP flow?
Does it say anywhere in the RTCP Protocol, that a client has to send RTCP paskets to receive such packets from the server?
You need to negotiate ports for RTP and RTCP first using SIP and SDP before those messages can be sent, so if the server doesn't respond with any SIP message then something else is wrong. Please check all the IP addresses in the outgoing INVITE from SIPP.
So verify it.
As per the rtp rfc and others.
Rtcp ports are algortimthiclly chosen most times on an odd port And most times 1 after the rtp port..
just because something sends you a packet doesn't mean you have to respond.
You should be filtering packets anyways because a source could be mixing rtp and rtcp together.
I have a network set up with 2 UACs behind a NAT (one is Jitsi and the other is my own UA coded in C with SIP support). Asterisk is set up on a public IP.
In sip.conf I have the following for both UACs: nat=yes directmedia=no
I then execute my code which calls the Jitsi client. I answer via Jitsi and everything seems great.
Asterisk provides each UAC an RTP host/port to send video to via an SDP packet which I've parsed appropriately (audio is not included in this session). Each user agent begins transmitting RTP packets.
Here's where the problem occurs:
Asterisks starts printing out
"Got RTP packet from XX.XXX.XX.XXX:XXXXX (type XX, seq XXXXX, ts XXXXXx, len XXXXXX)"
repeatedly from both UACs but never actually sends any of the RTP packets anywhere (I would expect "Send RTP ....").
I've tested my H264 RTP code through a QuickTime Broadcasting Server and the packets properly decode on the local network through various media players. My SIP call seems to have no problems connecting and Asterisk never prints out any Warnings or Errors in the console.
I cannot for the life of me figure out why Asterisk is not forwarding the RTP packets. Any help would be appreciated.
First, Asterisk doesn't "hold onto" RTP packets. There are three ways in which two SIP UAs can be bridged:
Local bridge - the RTP traffic flows through Asterisk, but is not interpreted by Asterisk. In this case, each UA directs its RTP to Asterisk, and Asterisk retransmits the RTP to each UA. A minimal amount of decoding is done.
Remote bridge - in this case, signalling is still handled between each UA and Asterisk, but Asterisk renegotiates the destination of the RTP with each UA to be the other corresponding UA. In the end, each UA sends its RTP to the other UA directly, while sending the SIP signalling information to Asterisk. This minimizes the load on Asterisk, as no RTP traffic directly goes through it.
Native bridge - similar to a local bridge, the RTP traffic from a UA flows into Asterisk. Asterisk fully decodes the RTP into audio frames and manages the transmission of the audio frames. This occurs when Asterisk has to "understand" the contents of the RTP traffic, such as when using features.conf for DTMF transfers.
The directmedia setting informs Asterisk that the UAs optimally want to send their media between each other, and bypass Asterisk. It will attempt to send the necessary re-INVITEs to set that scenario up, once the call has been established by both UAs.
Since you have directmedia enabled for both of your UAs, Asterisk will attempt to place them in a remote bridge. It may not succeed, depending on a number of factors, but in general, it will expect that it is not "in the loop" with respect to RTP being sent back and forth between the UAs. This would explain why it isn't forwarding the RTP traffic it receives from one of its UAs.
I would suspect, since Jitsi handles this setting well, that the UA you wrote is not honoring the new destination IP address in the SDP of the re-INVITE Asterisk sent to it, and is instead continuing to send the RTP to Asterisk when it should instead be sending it directly to the Jitsi UA.
It seems I needed to use STUN in order to find my public IP address.
I switched from Asterisk to FreeSWITCH. Though this did not solve my problem, I found FreeSWITCH much easier to configure and debug which helped in my search.
Turns out that neither FreeSWITCH nor Asterisk really care what IP address you provide them during a SIP session, they'll simply use the IP address/port that a packet is received on (via the IP header) for communication. This confused me because I could make a call between 2 UACs but after a call was answered the audio/video media would never arrive at the correct destination. Turns out RTP implementations will use the IP address provided in the SDP message when setting up a media stream, regardless of what IP address SIP was using for its communication.
In the end, I used STUN to discover the public IP/port for the calling UAC and inserted this correct IP/port combo into the SDP message. Subsequently when the answering UAC (Jitsi) set up its media stream it now had the correct IP/port combo to send/receive media from.
I'm trying to find a way for client to know socket server ip:port, without explicitly defining it. Generally I have a socket server running on portable device that's connect to network over DHCP (via WiFi), and ideally clients should be able to find it automaticaly.
So I guess a question is whether socket server can somehow broadcast it's address over local network? I think UPnP can do this, but I'd rather not get into it.
I'm quite sure that this question was asked on Stack lot's of times, but I could find proper keywords to search for it.
One method of doing this is via UDP broadcast packets. See beej's guide if you're using BSD sockets. And here is Microsoft's version of the same.
Assuming all the clients of the application are on the same side of a router then a broadcast address of 255.255.255.255 (or ff02::1 for IPv6) should be more than adequate.
Multicast is another option, but if this is a LAN-only thing I don't think that's necessary.
Suggestion
Pick a UDP port number (say for the sake of an example we pick 1667). The client should listen to UDP messages on 255.255.255.255:1667 (or whatever the equivalent is. e.g.: IPEndPoint(IPAddress.Any, 1667)). The server should broadcast messages on the same address.
Format Suggestion
UDP Packet: First four bytes as a magic number, next four bytes an IPv4 address (and you might want to add other things like a server name).
The magic number is just in case there is a collision with another application using the same port. Check both the length of the packet and the magic number.
Server would broadcast the packet at something like 30 second time intervals. (Alternatively you could have the server send a response only when a client sends a request via broadcast.)
Some options are:
DNS-SD (which seems to translate to "Apple Bonjour"): it has libraries on macOS, but it needs to install the Bonjour service on Windows. I don't know the Linux situation for this. So, it's multi-platform but you need external libraries.
UDP broadcast or multicast
Some other fancy things like Ethernet broadcast, raw sockets, ...
For your case (clients on a WiFi network), a UDP broadcast packet would suffice, it's multi-platform, and not too difficult to implement from the ground up.
Choosing this option, the two main algorithms are:
The server(s) send an "announce" broadcast packet, with clients listening to the broadcast address. Once clients receive the "announce" packet, they know about the server address. Now they can send UDP packets to the server (which will discover their addresses for sending a reply), or connect using TCP.
The client(s) send a "discover" broadcast packet, with the server(s) listening to the broadcast address. Once the server(s) receive the "discover" packet, it can reply directly to it with an "announce" UDP packet.
One or the other could be better for your application, it depends.
Please consider these arguments:
Servers usually listen to requests and send replies
A server that sends regular "announce" broadcast packets over a WiFi network, for a client that may arrive or not, wastes the network bandwidth, while a client knows exactly when it needs to poll for available servers, and stop once it's done.
As a mix of the two options, a server could send a "gratuitous announce" broadcast packet once it comes up, and then it can listen for "discover" broadcast requests from clients, replying directly to one of them using a regular UDP packet.
From here, the client can proceed as needed: send direct requests with UDP to the server, connect to a TCP address:port provided in the "announce" packet, ...
(this is the scheme I used in an application I am working on)