I am using twilio. I followed their doc provided here for PJSIP
I can make outbound calls with no issues and can receive inbound calls only for 30 seconds after I made that outbound call. After 30 seconds calls get denied at twilio’s end.
I am assuming its because it is keeping the session open.
Per the doc it has the auth only on outbound.
Anybody setup this config successfully and know what I am missing?
Do you redirect UDP ports 5060 and 10000-20000 from your external address to the PBX? If not, try that.
Yes I have an SNAT with those specific ports going to the PBX. In the firewall I see the traffic fine however incoming calls will get get authenticated at the trunk level per the initial post.
So, if you make an outbound call, the system works as long as the call comes in within 30 seconds? Audio all works, call terminates in the PBX and is connected to a local phone or service?
I’m still thinking it’s a problem with your router not passing the traffic from your external address to the PBX because, well, that’s almost always what causes this. Do you have all of the SIP addresses set correctly?
If you look back through the forum, you’ll find lots of cases where everything works for about 30 seconds, and the problems are almost always a problem at the router.
I have port 5060 and 10000-20000 forwarding from twilio’s list of IP addresses to our PBX internal IP. I have the pbx firewall off for testing purposes.
There are 0 denials in the firewall log.
This is almost always an indication that the NAT session is expiring. Once you make an outgoing call, a new session is established, which allows incoming calls once again, that again fail after the session is expired and the cycle repeats.
… and if the NAT session is closing and the system stops working after that, the firewall is not allowing the traffic through the router.
Have you got SIP-ALG or some other “SIP Helper” turned on? While this usually results in a different set of headaches, it might be masking the problem you are seeing.
To be clear: incoming calls not making it to the server (which you can check in the /var/log/asterisk/full log) is a firewall problem. While you vehemently argue that “your stuff must be right”, the fact that you are still having problems would indicate that the problem is either in your network NAT-Firewall or in your Integrated Firewall (which you think is turned off).
I’m don’t mean to sound so strident, but this is an extremely common problem and the solution is one of the three things we’ve mentioned a couple of times each now.
If it’s opening an audio stream but dropping it might not be acknowledging the call setup properly, if you do a SIP trace are there SIP re-transmissions after the audio streams start?
Had to reconfigure the SNAT and everything is working well. Thanks for the help guys.