I currently have issues with SIP User Agents behind a symmetric NAT connecting to my SIP client, which is an IVR voice service.
I read that Asterisk has a solution for this in the sip.conf, where I can set attribute
nat=yes
and this will ignore the IP and Port in the SIP headers and use the one for the SIP request and also waits for an incoming RTP stream to reply to.
I'd like to make use of this feature as we already have an Asterix server installed for AIX requests.
What would be the minimum configuration required for Asterix to act as the man in the middle on a new port as 5060 will still be used to connect directly to the SIP client? I don't care about authentication etc. I just need the Asterix to act as a SIP relay.
Thanks
K
You may also need to have "canreinvite=no" in the [general] section of your sip.conf.
That setting keeps Asterisk in the call path, otherwise voice traffic may be sent directly from one endpoint to the other.
Related
We are facing a technical issue with networking, which I'm not able to comprehend.
We are using Linphone Client to connect to x.x.x.125(Freeswitch box) via x.x.x.101 i.e .101 being a SIP proxy Flexisip.
The SIP flow look as below.
[ Linphone box ] <-> [ `.101` box ] <-> [ `.125` box ]
Now when we register i.e SIP REGISTER request (without VPN connected) to .125 via .101 it works i.e Registration is a success, saying this because I was sniffing around the traffic with TCP dump on both .101 and Linphone Client box (both had 200 OK Response for Register request).
Now here is the deal, when we make a call i.e send SIP INVITE request without VPN connected. We see no traffic on .101 box but same can be found on Linphone box hinting that request is directed to .101.(but at the same time I can constantly see OPTIONS request appearing from .101 to Linphone Machine and also a 200K response getting sent from Linphone machine for OPTIONS request.)
Now, The sooner we connect to VPN, we see the request appearing on the .101 box from Linphone box
Now, had this behaviour would have stayed constant, I would have suspected the Firewall rule but the it would work during SIP REGISTER and not using Regular INVITE invite is something I'm able to understand here.
And when we are connected to VPN it work.
NOTE: If I assume this is a packet loss as a part of UDP even the retransmission too does not go through and this happen in multiple run..
It's only the INVITE packet would not be sent always does not happen with REGISTER request.
Here how the sip flow looks like
Given the REGISTER requests are getting through that rules out an IP routing and firewall issue (assuming it's not doing deep inspection on SIP packets).
That leaves the two most likely culprits as the client software (in this case Linphone) using the wrong network interface,
Try running a test with a tool like sipp where you can explicitly set the local address to use and the type of SIP request to send.
# To test the user agent client scenario (which sends INVITE requests) use:
sipp -bind_local 10.1.10.1 -sn uac -m 1 x.x.x.125
Update:
Some observations from inspecting the packet captures:
In the no VPN case:
there is a NAPT between the softphone and the Proxy translating 10.1.10.1 to 49.36.13.47, e.g. 10.1.10.1:39248 mapped to 49.36.13.47:44150.
REGISTER responses do appear to be coming from the FreeSWITCH server at 63.211.239.125 according to the User Agent string of Flexisip... on the response.
in agreement with the original post there are no responses at all to INVITE requests in the capture.
there are no fragmented UDP packets captured.
In the VPN case:
there is no NAPT between the softphone and the Proxy. The softphone traffic is originating from 172.17.8.37.
the softphone is using an IP address of 192.168.29.134 in it's SDP offer which means the device likely has multiple network interfaces.
there is a fragmented UDP packet recorded when the softphone sends an INVITE request to the Proxy but it doesn't seem to be an issue as the Proxy happily forwards the request to the FreeSWITCH server.
Missing Data:
The no VPN capture does not contain the traffic between the Proxy and the FreeSWITCH server. This is the most crucial leg for the analysis since it could show whether the Proxy is forwarding the INVITE request or not.
Running tcpdump directly on the Proxy would be able to provide this missing information.
Updated Guess:
Based on the still incomplete information my best guess would now be that that Proxy has misconfigured (or perhaps deliberate) SIP settings and is silently dropping INVITE requests received on public interfaces.
When the softphone connects on the VPN the INVITE requests are forwarded because they are considered to originate from an internal network.
For REGISTER requests the Proxy could have a rule that says always forward them no matter which interface the Proxy receives them on since they are not as risky as INVITES.
If the path is different, the INVITE will go through different networks and they may not behave the same.
I can see 2 possible issues with the network used when VPN is not active:
A NAT has an ALG which, being broken, would drop the INVITE and let the other ones go through. This is unlikely, because it's happening for several User-Agent your tried.
The network is configured to drop packet larger than a specific size. This is very likely because the INVITE, with all User-Agent, is always the largest SIP message being sent.
I would advise you:
Try TCP: This should confirm it's a UDP only issue.
Try to remove all codecs and keep only PCMA, with UDP: if it works, it's likely a UDP/MTU/SIZE issue.
EDIT:
To make it clear, you certainly have an MTU issue.
Thus, I advise you to test your UDP network and the MTU size limit with and without the VPN. You don't have to use your android, but you need to use the same network.
On sip server, starts:
$> nc -u -l -p 2399
On LAN side, any PC with same network with netcat tool...
$> cat invite1000.example | nc -u sip.antisip.com 2399
$> cat invite1200.example | nc -u sip.antisip.com 2399
$> cat invite1500.example | nc -u sip.antisip.com 2399
$> cat invite2000.example | nc -u sip.antisip.com 2399
$> cat invite8000.example | nc -u sip.antisip.com 2399
Make several invitexxx.example files with any data, but with specific number of char in it.
In theory, nc/netcat on the server will stop receiving the packets when going over the MTU (or the packet will be incomplete).
Then, this will confirm it's an MTU issue.
I have installed freeswitch on a machine which is kept in the LAN behind the firewall named PFSense.I was looking in the freeswitch logs and I found that there are some unknown sip request coming from the unknown IP from outside of the network.
I have not done any setting or port forwarding in the pfsense.But don't know why this is happening.Please tell me how can I block those requests.
Thanks
it's most probably just typical port scanners. They scan for port 5060 and then try to send some INVITE or REGISTER requests there. It's quite harmless if your PBX is secure enough.
Do I need to have a server to work with sockets?
Can I directly send packets to other client and receive it without neither of the host being a server?
Yes, you can do this. Even on the very same computer. Just make sure they use the same port and the client tries to connect to localhost. I use this technique on a regular basis to test my networking apps.
Any two computers may talk, but one must be a server and the other the client. They can swap roles and each can be the opposite of the other.
The Client / Server distinction in socket programming isn't as specific as it sounds. Basically it has to do with the way the two machines connect.
The server uses bind, listen, and accept to constantly wait for incoming connections. The client has to know the IP address of the server. This is why URLs and DNS exist, to provide an easy-to-remember name that maps to a server's IP address.
Once the client connect()s and is accept()ed by the server, the differences are pretty much over. The client and server can both send() and recv() bytes whenever they want, and there are no restrictions on the data.
Any computer can be a server. You could have a 386 laptop as a server and a brand new dual-Xeon rack machine as a client.
I have 2 sip clients on the same computer.
Both of them is registering to a server that is running on port 5060.
For the first client the UDP is on port 5060 and for the other is 5061. When I come from one client to another, after the ringing part i receive the error:
only one usage of each socket address is normally permited.
Got any ideas why I got this error?
Your server and client are both trying to use port 5060, hence the error message. Change the first client to use 5062 or something else.
Also, 5061 is normally used for secured SIP (normal listening port + 1 in the proxy/server). Do not use it for the second client.
It means you're clients are both trying to claim the same socket for the communication channel, or the server is trying to reclaim the socket given to client A, to reuse it for client B.
The software handeling the socket, should be smart enough to rely on the OS to assign port numbers instead of hardcoding the port numbers in the code, this is a 100% guarantee for socket issues.
I´ve searched and didnt find which ports does XMPP uses.
I need to implement XMPP server and client and use XML transfer, file transfer and streaming.
Do they use different ports?? Is there a way I can make them use all the same, so I dont need to bother the network admin?
Thanks
According to Wikipedia:
5222 TCP XMPP client connection (RFC 6120) Official
5223 TCP XMPP client connection over SSL Unofficial
5269 TCP XMPP server connection (RFC 6120) Official
5298 TCP UDP XMPP JEP-0174: Link-Local Messaging / Official
XEP-0174: Serverless Messaging
8010 TCP XMPP File transfers Unofficial
The port numbers are defined in RFC 6120 § 14.7.
According to Extensible Messaging and Presence Protocol (Wikipedia), the standard TCP port for the server is 5222.
The client would presumably use the same ports as the messaging protocol, but can also use http (port 80) and https (port 443) for message delivery. These have the advantage of working for users behind firewalls, so your network admin should not need to get involved.
The ports required will be different for your XMPP Server and any XMPP Clients. Most "modern" XMPP Servers follow the defined IANA Ports for Server-to-Server 5269 and for Client-to-Server 5222. Any additional ports depends on what features you enable on the Server, i.e. if you offer BOSH then you may need to open port 80.
File Transfer is highly dependent on both the Clients you use and the Server as to what port it will use, but most of them also negotiate the connect via your existing XMPP Client-to-Server link so the required port opening will be client side (or proxied via port 80.)
The official ports (TCP:5222 and TCP:5269) are listed in RFC 6120. Contrary to the claims of a previous answer, XEP-0174 does not specify a port. Thus TCP:5298 might be customary for Link-Local XMPP, but is not official.
You can use other ports than the reserved ones, though: You can make your DNS SRV record point to any machine and port you like.
File transfers (XEP-0234) are these days handled using Jingle (XEP-0166). The same goes for RTP sessions (XEP-0167). They do not specify ports, though, since Jingle negotiates the creation of the data stream between the XMPP clients, but the actual data is then transferred by other means (e.g. RTP) through that stream (i.e. not usually through the XMPP server, even though in-band transfers are possible). Beware that Jingle is comprised of several XEPs, so make sure to have a look at the whole list of XMPP extensions.