Intermittent inbound failure

First thread. Excuse any breech of etiquette or omitting of accepted nomenclature.

PBX Firmware:12.7.5-1807-1.sng7
PBX Service Pack:

Having intermittent call failure on 2 DID’s inbound. Many times it works fine.

PBX is cloud hosted

I believe that the Inbound Edge Strategy or “PoP” SIP servers for load balancing are not consistently resolving to my PBX. But I am not sure…

I have white listed all of the proposed PoP subnets from FlowRoute in the sysadmin module:

I have also trusted them within the firewall in FreePBX module in the appropriate zone. (Note: this is the only firewall.)

I feel like the problem could exist withing the srv lookup that they are using with their Pop servers. They don’t offer a great deal of elaboration on trunk configuration:

Checking in my Fail2Ban log, I see that:

[2018-08-10 10:52:45] WARNING[20377][C-00000166] Ext. s: "Rejecting unknown SIP connection from (This is one of the whitelisted ip addresses mentioned earlier)

That address was specifically allowed through the firewall in the trusted traffic under the addition.

Also, here is the output from a call where I received "the number you have dialed is not in service."

== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
> 0x7efc50046d90 – Strict RTP learning after remote address set to: 74.1 20.93.196:21466
– Executing [[email protected]:1] NoOp(“SIP/”, “R eceived incoming SIP connection from unknown peer to 12082058780”) in new stack
– Executing [[email protected]:2] Set(“SIP/”, “DI D=12082058780”) in new stack
– Executing [[email protected]:3] Goto(“SIP/”, “s ,1”) in new stack
– Goto (from-sip-external,s,1)
– Executing [[email protected]:1] GotoIf(“SIP/”, “1?setlang uage:checkanon”) in new stack
– Goto (from-sip-external,s,2)
– Executing [[email protected]:2] Set(“SIP/”, “CHANNEL(lang uage)=en”) in new stack
– Executing [[email protected]:3] GotoIf(“SIP/”, “1?noanony mous”) in new stack
– Goto (from-sip-external,s,5)
– Executing [[email protected]:5] Set(“SIP/”, “TIMEOUT(abso lute)=15”) in new stack
– Channel will hangup at 2018-08-10 11:34:47.685 MDT.
– Executing [[email protected]:6] Log(“SIP/”, "WARNING,“Rej ecting unknown SIP connection from"”) in new stack
[2018-08-10 11:34:32] WARNING[25179][C-00000168]: Ext. s:6 @ from-sip-external: "Rejecting unknown SIP connection from"
– Executing [[email protected]:7] Answer(“SIP/”, “”) in new stack
> 0x7efc50046d90 – Strict RTP switching to RTP target address 74.120.93. 196:21466 as source
– Executing [[email protected]:8] Wait(“SIP/”, “2”) in new stack
– Executing [[email protected]:9] Playback(“SIP/”, “ss-nose rvice”) in new stack
– <SIP/> Playing ‘ss-noservice.ulaw’ (language ‘en’)
> 0x7efc50046d90 – Strict RTP learning complete - Locking on source addr ess
– Executing [[email protected]:1] Hangup(“SIP/”, “”) in new stack
== Spawn extension (from-sip-external, h, 1) exited non-zero on ‘SIP/ 001d9’

If I have allowed the traffic through the firewall, and it is white listed, why would it block the IP???

Was hoping someone would offer helpful suggestions. Hint’s on configuring Flowroute trunks with srv lookup?

Thank you

I wouldn’t rely on SRV working reliably with chan_sip trunks. You will probably have better luck using Asterisk 15 and PJSIP trunks, or you can create a separate chan_sip trunk for all of the provider’s signalling hosts.

1 Like

I will give that a shot. I saw that was what some people were doing.

This is FlowRoute’s note:

IMPORTANT: Asterisk for Flowroute with New PoPs

If you are taking advantage of our new Points of Presence (PoPs), make sure to do the following:

  1. Update all instances of to this format: {your_preferred_pop} where {your_preferred_pop} might be “us-west-wa” for example. The new value will then be .

  2. Add the IP addresses associated with your preferred PoP to your list of [flowroute-trunk] settings below. To find this information quickly, run the following from a command shell window:

dig {your_preferred_pop} +short

Knowing that Chan_SIP will lock up if you try to change it’s IP address without a restart, I think you could lean on this a little harder. Your error is because your trunks to not specify that the address you are trying to use has an entry. PJ-SIP trunks can be configured to use multiple addresses, and I believe that it can also be configured to use a range of address (having never needed either, though, means that you’ll need corroboration or experimentation to get that squared away).

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