Forum Replies Created
My VitalPBX version is 2.3.6-1, Asterisk 16.5.0-1 and DAHDI 2.11.1-7
I’m looking into sngrep, but for the time being I think I’ve noticed something strange, while checking the sip flow in wireshark: While in both successful and unsuccessful cases the connection establishment flow is the same, there seems to be a small difference in the sip flow between the PBX and the extension which picks up the call. I’ve attached two outputs, one working and one not working, as produced by wireshark. In the case where there is one-way audio, the PBX sends a packet in g711U and then switches to g711A. I have even tried to remove 711U from the accepted codecs, but this still happens.
By the way: 192.168.1.110 is the PBX. 192.168.2.1 is a softphone I am using for testing, behind a VPN (regular extensions are in the range 192.168.1.111 and above, and exhibit the same behaviour)0
I just tried your suggestion (disabled ALG, forwarded RTP ports and configured global NAT settings). The result was the same, with the addition that the call dropped in about 5 seconds.
Another issue with this approach would be that the public IP of the router is dynamic, not static, but I guess I could use dyndns for that. In my test, I did use the current public IP.
I still haven’t understood, however, why this happens for specific phone numbers.0
Thanks again for your time and effort!
Following your comment regarding SIP ALG, I went ahead and turned it off, and set up port forwarding for the RTP ports. I also tried all NAT options inside the trunk configuration of VitalPBX, one by one. The result was still the same, one way audio between my home phone and the PBX (I was able to hear sound from the extension connected to the PBX, but they were unable to hear me).0
Thanks for replying,
Right now my router is set up using SIP ALG, however I have also tried port forwarding as well as setting the NAT options in VitalPBX. However, I wonder, if the issue had something to do with NAT, shouldn’t the problem exist on all calls? I see no difference in the way the calls are routed from the outside world, since all of them come through ims.otenet.gr with identifiers such as sip:+302XXXXXXXXX@ims.otenet.gr for fixed line and sip:+3069XXXXXXXX@ims.otenet.gr for mobile. Most of the calls work correctly, no matter if they come from fixed or mobile connections. Some, however (including my own landline, which uses the same internet provided and is handled by the ISP’s equipment), result in one way audio.0