- August 30, 2019 at 12:24 pm
I have installed a VitalPBX box connected to a router which does PPP dialing for VDSL. VitalPBX has been set up to use a SIP trunk provided by my DSL provider. I can place and receive calls correctly most of the time, however when I receive calls from some phone numbers I can hear no audio (the other party can hear me just fine). In the trunk configuration I have left the codecs field empty and for the time being the only thing that seems to differ between the calls that have one way audio and the others (as seen in wireshark), is that the former use A-law while the latter use U-law (I’m still not sure if that is completely correct, since I am still in the process of gathering data). Any ideas? The provider is COSMOTE, in Greece.
My sip configuration is
[+30ΧΧΧΧΧΧΧΧΧΧ] context=trk-2-in description=OTE SIP host=ims.otenet.gr port=5060 insecure=invite type=friend transport=udp defaultuser=+30XXXXXXXXXX@ims.otenet.gr remotesecret=XXXXXXXX fromuser=+30XXXXXXXXXX fromdomain=ims.otenet.gr qualify=yes outbound_registration=yes auth_rejection_permanent=yes max_retries=10 expiration=3600 retry_interval=60 forbidden_retry_interval=10 [+30XXXXXXXXXX@ims.otenet.gr] context=trk-2-in description=OTE SIP host=ims.otenet.gr secret=XXXXXXX insecure=port,invite qualify=yes type=user
(Password and usernames have been reducted)0
- August 30, 2019 at 8:30 pm
- August 31, 2019 at 9:11 am
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
- September 3, 2019 at 6:44 pm
Even though SIP ALG is intended to assist users who have phones on private IP addresses (Class C 192.168.X.X), in many cases it is implemented poorly and actually causes more problems than it solves. SIP ALG modifies SIP packets in unexpected ways, corrupting them and making them unreadable. This can give you unexpected behavior, such as phones not registering and incoming calls failing.
What is your current NAT conf on VitalPBX?0
- September 3, 2019 at 8:32 pm
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
- September 3, 2019 at 8:35 pm
- September 4, 2019 at 6:55 am
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
- September 4, 2019 at 4:51 pm
- September 5, 2019 at 8:55 pm
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
- You must be logged in to reply to this topic.