I have chosen QuteCom SIP client for windows to chat.I have installed and configured the account with my public server. My SIP server is kamailio.The connection to the server is not established. The application is connecting to the server for a long time.
Any help is appreciated.
If looks like keep connecting, then I guess the SIP messages don't get to the server.
You can install Wireshark to monitor traffic on windows host on port 5060 (the SIP port) in order to see if SIP messages are sent to the server.
On server, you can install ngrep for the purpose of seeing if traffic from the phone comes there. The command would be like:
ngrep -d any -qt -W byline port 5060
If you don't see traffic coming to the SIP server, then might be a firewall or an ALG between the client and the server, or, a firewall even on client host or server itself.
If it is something in between (not on client host or server), then you should try to use TCP or better TLS.
Note that if you have the firewall on the server, you will see the SIP packets coming on the network, but they will be dropped by the kernel before getting to application layer. Typically on Linux you can see the firewall rules with:
iptables -L
If the SIP packets come to the server, then set debug=3 in kamailio.cfg, restart kamailio and watch the syslog file (e.g., /var/log/syslog or /var/log/messgaes) for kamailio-specific debug messages -- you should get hints of what happens during processing.
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 a web server running CentOS and a separate mail server running Microsoft Exchange. I have the web server connecting to the mail server via SMTP on port 587 to send emails.
Sometimes the connection to the mail server refuses, but it's rare. Could an intermittent failure be related to port settings? I would have thought it's all or nothing.
For the CentOS web server, what rules should I be looking to configure in the iptables if any? Do I need to add an entry for port 587 on this server? Or do I just need to allow incoming connections on the mail server for 587?
Thanks in advance.
You don't need to set up any iptables rules on your webserver, since outgoing connections are allowed by default. Your occasional drops won't have anything to do with the webserver's firewall, so you'll want to look at tuning your Exchange server, if the error is impactful enough to worry about it.
I am trying to route the call from opensips server to freeswitch server. My freeswitch server is actually a container which i have created using 'lxc/lxd' and it is running CentOS.
When I route the call from opensips server to freeswitch server container i got the INVITE requests sip log in 'ngrep' but getting nothing in Freeswitch log as in nothing in fs_cli and my call is failing with the disposition 'SIP 408 - Request Timeout'
I have tried with routing the call from opensips server to other freeswitch server which is actually having a physical ip and not the container server and when I tried that, i am able to get the logs in freeswitch as in fs_cli.
Sip profile parameters auth-calls, auth-all-packets, aggressive-nat-detection set to true, there is no firewall or iptable rule between opensips and freeswitch servers. i can access the osips server from freeswitch server and vice versa.
So, what am i missing here. please suggest me something.
In fs_cli, sofia status will show you on which IP address the SIP profile is bound. Probably it's not the address you're sending invites to.
Your freeswitch server is not listening on the port with interface on
which you are sending. Just check out freeswitch profile on which
port and interface they are listening.
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.
I've got dedicated server to run all my sites from.
I created domain and updated all DNS records to this server, everything is fine and propagated however when i try and receive mail nothing happens but it can send.
I went to dnsstuff.com and this is the error i got...
All connections to Mailservers port 25 have failed. The standard port
for SMTP transactions is 25, so your servers should be operating on
that port. It is recommended that it be fixed in order for your mail
service to operate properly. The Mail Servers that failed are:
xx.xxx.xxx.xxx | failed message send with: failed cx open with: failed socket connect with: Operation now in progress
/*****************
UPDATE
*****************/
Running a linux box using centOS.
The mailserver being used is, I believe, Postfix.
How do i fix this problem?
Check your firewall configuration on your server. If you can send from localhost (that is, direclty from your server), but mail can't be delivered from remote servers to your box, your firewall is the best bet to look at. Basically port 25 should be open to any IP. It's hard to give you specific details on how to configure your firewall, as you do not specify your OS and dikstribution. Most Linux distro's run some flavour of iptables. If iptables is what you have, you could try this command from the command line:
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
Before you open up your firewall, you might want to dive into configuring postfix. It would not be nice to the rest of the world if you started running an open relay. That will get your server blacklisted in no time. This artice on the postfix website will give you a decent start.