Strange behaviour on Sip Trunks

Hi

Strange behave that happened on one of our main FreePBX used as a sort of SIP GW facing many carriers.

We are hosting SIP PBX of all kinds and all phone calls needs to pass through a pair of FreePBXs before going out to the outside world.

The problem we are facing are only for outbound calls.
Calls coming from downstream PBXs, passing through our pairs of FreePBX and being sent out to different carriers.

For easy deployment, we choose to trust outbound calls that are coming out from our managed downstream PBXs. Theses call are passing through the from-internal context by the User Details of the trunks on the Incoming side of the trunk facing each managed PBXs:

type=peer
qualify=yes
port=5060
nat=yes
insecure=very
host=pbx1.voip.com
directmedia=false
context=from-internal

When a call comes in from one of our managed PBXs, FreePBX simply looks for the best outbound routes to pass this outbound calls to one of our carriers.

All our SIP trunks are configured the same way.

Now, once in a while, when creating a new trunk, we cannot pass outbound calls from the newly installed PBX. When placing a call, all we heard is the FreePBX “This call cannot be completed as dialed”.

When this is happening, in the Asterisk CLI, we can see that theses calls are not being treated by the from-internal context but by the from-trunk context instead. This explained why calls cannot be treated by FreePBX as there is no inbound routes matching the call.

pbx.c: Executing [[email protected]:1] Set(“SIP/IN TRUNKNAME-00074093”, “GROUP()=OUT_120”) in new stack

[2022-12-14 13:18:24] VERBOSE[2198][C-0003aa7f] pbx.c: Executing [[email protected] - TRUNKNAME:2] Goto(“SIP/IN - TRUNKNAME”, “from-trunk,dialednumber,1”) in new stack

[2022-12-14 13:18:24] VERBOSE[2198][C-0003aa7f] pbx_builtins.c: Goto (from-trunk,dialednumber,1)

[2022-12-14 13:18:24] VERBOSE[2198][C-0003aa7f] pbx.c: Executing [[email protected]:1] Set(“SIP/IN - TRUNKNAME -00074093”, “__FROM_DID=dialednumber”) in new stack

[2022-12-14 13:18:24] VERBOSE[2198][C-0003aa7f] pbx.c: Executing [[email protected]:2] NoOp(“SIP/IN - TRUNKNAME-00074093”, “Received an unknown call with DID set to dialednumber”) in new stack

[2022-12-14 13:18:24] VERBOSE[2198][C-0003aa7f] pbx.c: Executing [[email protected]:3] Goto(“SIP/IN - TRUNKNAME-00074093”, “s,a2”) in new stack

[2022-12-14 13:18:25] VERBOSE[2198][C-0003aa7f] pbx.c: Executing [[email protected]:3] Log(“SIP/IN - TRUNKNAME-00074093”, “WARNING,Friendly Scanner from IPADDRESS”) in new stack

[2022-12-14 13:18:27] VERBOSE[2198][C-0003aa7f] pbx.c: Executing [[email protected]:5] Playback(“SIP/IN - TRUNKNAME-00074093”, “ss-noservice”) in new stack

[2022-12-14 13:18:27] VERBOSE[2198][C-0003aa7f] file.c: <SIP/IN - TRUNKNAME 00074093> Playing ‘ss-noservice.ulaw’ (language ‘en’)

The only way we found to fix that is by disabling the trunk itself, then playing around with the USER-CONTEXT and the TrunkNAME in the Trunk configuration pages, changing one or two characters in both field, submit and reload, then re-enabling the trunk, submit and reload again.

After that manipulation, every other outbound calls are now being processed through from-internal context and are being forwarded as expected by FreePBX.

Under FreePBX 14, this happened once with +/-2 or 3% of our newly created trunks.
We upgraded our FreePBX to FreePBX 15 and this issue now happened about for 10 or 15% of newly added trunks.

Some trunks we adds are just working straight from the first time, some not and needed to extra manipulation.

Anyone have the same problem ?
How can this issue being resolved ?
Are we doing something wrong on our side?
This seems to me like a sort of bug during the trunk creation process ?

Thanks.

The log shows a problem on the inbound side, namely that the call isn’t for a configured DID, and is being placed in the context reserved for unrecognised peers.

The channel name here is invalid, which means you haven’t redacted the information cleanly, and I can’t be sure that the other redactions are reliable.

Also, insecure=very hasn’t been a valid value (it is invalid, not just deprecated) for many years. Calls probably only work because you have no secret and don’t need insecure.

You should urgently plan to move to chan_pjsip.

Hi

I changed the channel name in the example to keep privacy about our setup, as we named our trunks with our customer names… Could a bad characters can lead to that kind of issues ? Is there is some characters that should be avoided ?

What is the “modern” equivalence to insecure=very if we want to rely on the source ip address ?

Thanks.

insecure has nothing to do with source IP addresses.

insecure=very literally translates as insecure=invite,port

The invite part means do not challenge for the secret, only supply it when challenged. As you do not have a secret, this option has no effect. If you did have one, a slightly less ancient way would be to use remotesecret, rather than secret.

The port part means accept traffic from any port at that address. For UDP, that is rarely needed.

nat=yes is still valid, but rarely needed.

You should have disallow=all and a small set of allow lines.

Incoming chan_sip channel names are formed from the name of the sip.conf section that matched, a hyphen and a serial number. There are special values for allowguest matches, and for outbound channels with literal URIs, but the hyphen and serial number are always present. They were missing in one of your redactions.

Your underlying problem may be that you have multiple sections with the same name, and the match isn’t on the one you intended. In this case, you probably only require a single (peer) section.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.