Hi all!
I have a working testbench and a non-working one. They belong to the same LAN and utilize the same exteral IP. Of course I activate only one of them at the same time.
I believe the problem is with SIP.INVITE; it always gets Error 403-Forbidden. Registration seems ok.
Working testbench components:
• IPFire version 2.23 x86_64 (which I suspect embeds a luckily helpful ALG). (Obsolete)
• Asterisk version 16.2.1 + Asterisk GUI (obsolete)
• User Agent: THOMSON ST2030 Non-Working testbench components:
• OPNSense - 21.1.3_3-amd64
• FreePBX - 13.0.197.28
• User Agent: THOMSON ST2030
Unfortunately, and needless to say :), because of the Firewall and Asterisk-GUI obsoletion, I need to transition to the set of components that I’m currently not able to get to work.
Since I spent some effort to try and graphically enhance the SIP messages my systems generate (on the firewall’s outer interface), I will upload them in a separate file, hoping they will result more readable.
Legend
• Context: trying to place an outbound call from #caller#
• aa.bb.cc.dd stands for my Static and public address
• <340abcdefg> stands for a test mobile phone
• Originating User-Agent in BOTH cases : THOMSON ST2030
• I have highlited most outstanding (?) differences and (what seems to me) suspicious data.
I believe that the “most suspicious” datum in the refused INVITE is the “private” extension ID (6001) instead of the “public” CID #caller#; am I wrong?
Please let me have your suggestions on the following points:
1. which of the many differences in the SIP fields and data data you believe more determining the failure of INVITE.
2. Where, in FreePBX GUI, should I configure the suggested corrective settings.
In your Peer Details for the trunk, add fromuser=#caller# fromdomain=voip.fastwebnet.it
and retest. It still might not work, but with luck it will get further.
Two general comments:
Why are you running an older version of FreePBX and Asterisk? If you install the current FreePBX 15 with Asterisk 16 (just download the distro), you can set up the trunk with pjsip, rather than the deprecated chan_sip.
Why are you using g729 codec? Unless you have severe bandwidth limitations, high cost of bandwidth or high packet loss, switching to alaw will give you much better voice quality.
Forgive my being late, but I have made many and laborious tests after having applied the precious advice I received from Stewart1 before answering.
Dearest Stewart1, as soon as I applied your hints regarding fromuser and fromdomain I was immediately able to carry out an outgoing call! Very good, congrats! THANK YOU!!!
Unfortunately I am left with 2 mysterious problems:
Inbound RTP traffic is fine (strange! Generally incoming RTP traffic is hintered by NAT); I have NEVER had problems whit the outbound RTP before. Surprisingly outbound RTP is output from my Firewall WAN interface but will not reach the "external" VOIP terminal (or my provider?).
My ability to place outgoing calls lasts for just a few minutes (about 2 - it looks like a time-out), whereupon the provider will return Forbidden-403 as usual. In order to restore operation the trick is to perform a SIP reload.
Let me answer your legitimate questions:
I am using the old FPBX-13.0.197.28 (13.17.0) because it is the most recent 32-bit version I have found. Unfortunately at the moment I only have old 32-bit hosts.
I’ve tried chan-pjsip, but I can’t even get it to register. I don’t know if it is my inability to configure it properly or mabe my VOIP provider that will not accept pjsip.
g729 codec: I have no bandwidth problems (I have 2.5Gbps down / 0.2Gbps up) but I didn’t pay attention to sound quality. I will now give priority to alaw . Thanks for the advice!
