Hello,
Asterisk version: 11.10
Operating System: Ubuntu 12.04 Server (64-Bit)
Our Asterisk server is installed in Amazon EC2 (Behind NAT). We can not say about SIP devices (users), because they may behind the Nat or may not behind the Nat. Our number vendor is bandwidth.com.
Scenario: Our SIP users are able to make/receive calls successfully.
Problem: The calls are disconnecting and sometimes audio is not audible.
Please find my below configuration at a glance. I am not giving some common parameters and values:
sip.conf:
[general]
nat=force_rport,comedia
localnet=172.31.12.36/255.255.240.0
externip=54.219.36.12
bindaddr=0.0.0.0
bindport=5060
disallow=all
allow=ilbc
allow=ulaw
allow=alaw
allow=g729
allow=g723
rtcachefriends=yes
qualify=yes
rtsavesysname=yes
rtupdate=yes
ignoreregexpire=yes
alwaysauthreject=yes
insecure=port,invite
directrtpsetup=no
directmedia=no
trustrpid = yes
sendrpid = yes
sendrpid = rpid
SIP User Configuration:
insecure=port,invite
type=friend
disallow=all
allow=all
nat=force_rport,comedia
directmedia=no
Peer (outbound) Configuration:
nat=force_rport,comedia
directmedia=no
type=peer
disallow=all
allow=ulaw
qualify=yes
I guess that I am doing some mistake with allow, nat, and directmedia parameters.
Can anybody suggest the correct configuration for the above environment?
Thanks in advance.
Mouli
Please shut this system down immediately. It appears to be a gift to the toll fraudsters. Then do some research into type=friend and insecure=invite. These typically come from blindly following recipes, but you have gone beyond their normal sloppy use.
I’ll have a think about the original problem separately, although I would point out that running VoIP on a VM, particularly where you don’t control the host, is not a good idea.
If the connection losses are random, I would suspect the problem is running as a guest on an overloaded VM host. If they are systematic to particular peers, I would suspect a configuration problem at the peer end.
Obviously both force_rport and comedia are forcing it to do something against the protocol, but I think that the cases where that breaks things are very rare, and they may help in rather more cases.
Why does this happen?
A NAT device in the signalling path. A misconfigured NAT device is in the signalling path and stops SIP messages.
A firewall that blocks messages or reroutes them wrongly in an attempt to assist in a too clever way.
A SIP middlebox (SBC) that rewrites contact: headers so that we can’t reach the other side with our reply or the ACK.
A badly configured SIP proxy that forgets to add record-route headers to make sure that signalling works.
Packet loss. IP and UDP are unreliable transports. If you loose too many packets the retransmits doesn’t help and communication is impossible. If this happens with signaling, media would be unusable anyway.
What can I do?
Turn on SIP debug, try to understand the signalling that happens and see if you’re missing the reply to the INVITE or if the ACK gets lost. When you know what happens, you’ve taken the first step to track down the problem. See the list above and investigate your network.
For NAT and Firewall problems, there are many documents to help you. Start with reading sip.conf.sample that is part of your Asterisk distribution.
The SIP signalling standard, including retransmissions and timers for these, is well documented in the IETF RFC 3261.
Most of those produce predictable failures, although I guess that they might still appear random until you understand the logic.
Hi,
I am sorry for the delay in giving reply to you. I spent time on understanding and resolving the issue.
Finally, my issues are resolved.
Thank you.