Fongo Community Forums

i use FreePBX, so freephoneline is just a SIP trunk provider for me (10+ years)
my wife has a friend in Kars (i'm in Ottawa)
whenever she calls, it calls my cell after a fairly long delay, as if the connection to my PBX is down
it isn't down
it seems to be just her number
this worked in the past, but has been the last 6 months or so
everyone else calling goes to my pbx correctly
i've checked my pbx logs and no call gets to me
there doesn't appear to be anything in the fpl interface to block a particular phone #
any ideas?

mark

just took a quick look at the log
'normal call clearing' from her # to my cell #
she dialed my home #, not my cell #

I’m unsure why you posted in the Fongo Home Phone forum originally. I’ll
move this thread.

1. Troubleshoot/test with Follow Me disabled: https://www.freephoneline.ca/followMeSettings

2. Determine who the carrier is for the incoming call: https://freecarrierlookup.com/.
Then find out if the problem is happening with all incoming calls from that carrier.
ex. Rogers is Fido and Chatr. Zoomer also uses Rogers.

3. Login to your router.
Navigate to Routing & Firewall—>Firewall tab.
Click Settings.
Set SIP to Off.

Incoming calls from certain carriers don’t work with SIP ALG enabled with some routers. Keep SIP ALG off.
Reboot router.

4. FPL doesn’t block numbers, but Freepbx can (and so can physical phones that you may be using; they may have a block list, and blocking numbers can happen accidentally using them): https://wiki.freepbx.org/download/temp/ ... cation/pdf

please let me know where you moved it

standard Bell landline
ALG off
call never gets to FreePBX

mark

mkaye wrote:please let me know where you moved it

You replied in this thread, so you appear to have found it. I already moved the thread to Freephoneline's Community Support forum, where this thread belongs.

standard Bell landline

Okay

call never gets to FreePBX

I was explaining that there's no way to block individual calls using FPL user portal settings alone.

Just to confirm, are you running FreePBX locally?

Since you can see the call at https://www.freephoneline.ca/callLogs, the incoming call is reaching Fongo/Freephoneline's network.
So the problem is occurring somewhere from Fongo's network to your router.

The simplest way to test if your router is blocking the call is to

1) test with Follow Me off, and
2) connect device running Asterisk server directly to your modem (if it's a modem/router combo, gateway, or hub, ensure that it's in bridge mode)

Alternatively, If you can, test with a SIP App (Acrobit's Groundwire, for example) or FPL's desktop app after first disabling FPL's SIP account registration in FreePBX.

It would be pretty odd for an incoming call to reach all the way to your FPL account but not have it directed to you, when all other incoming calls are. Something appears to be blocking it (firewall, buggy router firmware, something weird with Follow Me, which I'm not interested in testing). Here is a case where buggy (stock, Asus) router firmware was blocking some incoming calls, but not all: viewtopic.php?f=8&t=20466#p80217.
You should check your Ubiquiti router's syslog to see if the call is hitting your router. If it is, check for a firmware update (I would do this anyway).

whenever she calls, it calls my cell after a fairly long delay

Turn Follow Me off. If the problem isn't fixed, the incoming call will drop to FPL's voicemail system. Determine whether the incoming call is reaching 1) your ISP's modem and 2) your router.

follow me turned off - call goes directly to FPL voicemail

mkaye wrote:follow me turned off - call goes directly to FPL voicemail

While you haven't stated whether Asterisk is being run locally, the one reasonable explanation I can think of is router is blocking the call, which was the case here (most calls weren't being blocked, but one was) due to a problem with router firmware: viewtopic.php?f=8&t=20466#p80217. Router/NAT firewall blocked the call; call drops to FPL's voicemail system. In this example, Router/NAT firewall wasn't blocking most calls, but it was blocking calls from his wife's workplace.



If you're running Asterisk locally, you need to be able to determine whether the call is reaching your ISP's modem first.

It's unlikely for a call to reach your FPL account and not be directed anywhere, unless SIP signalling is trying to work with a (internal) LAN IP instead of WAN IP, which would be strange given all other calls reach you. Basically, ensure your external WAN IP is in the contact header being used. However, external IP not being used seems less likely to be the issue (to me) since all other incoming calls work. What Asterisk version are you using? 20? By the way, RTP IPs used by FPL at the moment are 208.85.218.149 and 208.85.218.150 (if you're looking at router syslog).

Again, a pretty simple way to test for a configuration problem on your LAN is to setup your FPL account on a smartphone SIP app (such as Acrobits Groundwire) and test with an incoming call from the same number while using cellular data. Then try while connected to Wi-Fi. SIP registration for your FPL account must be disabled in FreePBX/Asterisk first while testing since only one registration is permitted at any time time per FPL account. Registration is required for incoming calls to work.

If the incoming call works while connected using cellular data, the problem isn't with FPL. If the incoming call doesn't work while using cellular data, submit a ticket: https://www.freephoneline.ca/contactUs. Provide the phone number in the ticket and the call log entry from https://www.freephoneline.ca/callLogs. Choose "my account inquiry" as the issue type.

local freepbx - asterisk 16 on pi, asterisk 20 on linux vm - both have the same problem

i guess i'm confused with the connection
trunk says online at both ends, i take that to mean 'ready for business'
so i'm not sure why the call isn't sent to my freepbx?
if it was, i would see something in the freepbx logs - i don't
not sure why the router would block the call as the trunk is up & alive, router has already done its job

mark

mkaye wrote:not sure why the router would block the call as the trunk is up & alive, router has already done its job

NAT holes/associations can close; improper UDP timeouts can also cause problems. See point D from viewtopic.php?f=8&t=20199#p78976. UDP timeouts aren't the issue if all other incoming calls are working during the same 3600 second registration period while the Bell call doesn't.

Regardless, it's pretty simple to remove the router briefly (briefly because everything will be unprotected) and find out while your ISP's modem/router combo is in bridge mode.
Your router isn't blocking connections from either 208.85.218.149 or 208.85.218.150, right? Those are the RTP IPs (audio stream), which differ from the proxy servers (ex. voip.freephoneline.ca is used for sip signalling). The RTP IPs have nothing to do with registration.

Or, better still, just try your FPL account with a smartphone SIP app while connected to cellular data.

It makes zero sense to me that a call from a specific number is reaching your FPL account and not being directed to your public WAN IP address while all others are (when Follow Me is disabled) during the same registration period. It seems likely that your external WAN IP is being sent in the contact header. So if the call is really reaching your WAN IP, then I suspect something is being blocked between your modem and Asterisk.

If this specific call isn't reaching your ISP's modem, while all others are, then I don't know what's going on. You're not using a VPN with Asterisk, right?

OK, you made me think...

running Ubiquiti UDMPro
i set up some vlans a while ago
i created a rule for UDP IN to only go to my FreePBX servers
wrong IP address for my PI server!!
corrected
we'll see what happens with next phone call
thanks

mark

things are working on my pi, vm no, but that must be a freepbx issue
question:
i have 2 copies of freepbx running, only 1 has the freephoneline turnk enabled - i manually disable/enable when i switch back & forth
can i have the trunk enabled on both?
that way my failover would be automatic
not sure if freephoneline would get upset if registered from 2 sources?

mark

You can only have one device registered to FPL at a time.
If you register more than one device it will flip flop between the two and may even get your account temporarily blocked for not following the re-registration time of 3600 seconds or the retry interval of 120 seconds.

You should still be able to make outgoing calls on other devices, as long as you don't register them. Test though to make sure if that's what you are looking for.

A LONG time ago FPL blocked the useragent for FreePBX. I used to run one and had to change the useragent to make it work. I am unaware if this is still the case.
viewtopic.php?f=8&t=4958&p=26200&hilit=useragent+freepbx

mkaye wrote:we'll see what happens with next phone call
thanks

You're welcome.

mkaye wrote:things are working on my pi

I'm glad the problem is resolved.

vm no, but that must be a freepbx issue

If you’re trying to register the same FPL account twice simultaneously, then you should expect problems.
Only the most recent registration is valid, and the other server will lose registration (incoming calls won’t work on it).

I’m guessing vm = virtual machine and not voicemail

If you mean voicemail and are using PJSIP extension, set MWI subscription type to unsolicited for Freephoneline.
Also, it takes up to 10 minutes for MW packet to be sent after a message is left with FPL, but you probably already know that.
If you’re trying to register the same FPL account twice simultaneously, then I wouldn’t expect MWI to work properly either.

can i have the trunk enabled on both?

Jake is correct. Only one registration per FPL account is permitted at any time.

not fixed

my cell # would ring my home # correctly, we tested with another fpl user and this always rang my cell after 30s of silence (set for 5 rings)

i connected my cell to fpl with linphone, but using my wifi (so still using my router) - call went to 30s silence and then voicemail (disabled follow me on fpl)

turned wifi off on cell and tried again, call went through properly - this means that my router must be blocking the call attempt

in the SIP logs for a successful call we get an invite msg from fpl, this doesn't arrive for calls that fail

how can my router filter out the invite for certain incoming calls only?

i know this my not be the place to ask, but just hoping there may be some insight as to where to look

mkaye wrote:not fixed

Based on your previous post, I thought you found the source of the problem.

turned wifi off on cell and tried again, call went through properly - this means that my router must be blocking the call attempt

Seems likely. The true test would be to connect Asterisk server directly to your modem. You need to determine whether the failed calls are actually reaching your modem first (they probably are, but you need to check first).

how can my router filter out the invite for certain incoming calls only?

Here's an example of how buggy router firmware did: viewtopic.php?f=8&t=20466.
Check to ensure you're using the lastest firmware version for your router: https://www.ui.com/download/unifi-switc ... mware-4456


You claim to have SIP ALG disabled, so this doesn't apply to you. However, SIP ALG (SIP Passthrough) has been the culprit for this scenario in Asus routers.

Actually, it wouldn't hurt to try voip4.freephoneline.ca:6060 just to see if that works. The purpose of voip4.freephoneline.ca:6060 is to help circumvent buggy SIP ALGs in routers.

i know this my not be the place to ask, but just hoping there may be some insight as to where to look

I would ensure only one registration/trunk is being used (not two). I would connect server directly to modem.
If that works for the incoming call, I would enable router syslog to capture dropped packets and check router syslog for dropped packets/connections from the FPL proxy server IP being used.
Currently,
voip.freephoneline.ca is 208.65.240.44,
voip2.freephoneline.ca is 162.213.111.22, and
voip4.freephoneline.ca is 162.213.111.21.
Also check for dropped connections from 208.85.218.149 and 208.85.218.150 (RTP audio).

If you need help with parsing or enabling your router's syslog, try posting at https://community.ui.com/
Also visit https://www.ui.com/contact/.

tried pbx directly to modem
hard to tell what is happening as there are no extensions connected
& we can't connect to see either

mark

mkaye wrote:tried pbx directly to modem

Did SIP logs indicate anything (for the incoming call while connected to modem) after re-connecting to router for the problematic call?

Since you're familiar with Linphone, can you try Linphone on a desktop/laptop connected directly to your modem instead (via ethernet)? https://new.linphone.org/technical-corn ... cal_corner

Anyway, try voip4.freephoneline.ca:6060 (UDP 6060) just to see if that makes a difference. UDP 6060 is not the local SIP Port. Also check for updated router firmware: https://www.ui.com/download/unifi-switc ... mware-4456.

Are you using Pi-hole?

Anyway, I feel looking around for possible culprits may be pointless if you can't determine whether the incoming call is reaching your modem first.
Based on your cellular linphone test, it does seem probable that the call is reaching your modem (but you were using cellular data).

If the incoming call is reaching your modem, then certainly, the problem resides somewhere on your LAN. Enable router system log to capture dropped packets, and check for dropped packets from the IPs I listed earlier. At least you should be able to verify whether your router is dropping incoming packets from those IPs.

If the incoming call is not reaching your modem, then ensure your external WAN IP is being sent correctly in the SIP contact header (check SIP log) and your Via header. This potential scenario, where the call isn't reaching your modem (while everything else does during the same registration period), does not make any sense to me.

Other simple things to try include using "voip4.freephoneline.ca:6060".
Ensure router firmware is updated.

an IT friend & i spent ~6hrs troubleshooting yesterday

we can't come up with any explanation why some incoming #'s work and others don't
the invite msg should be the same

mark

sorry, i didn't mean to offend you

just saying, that usually we can come up with a theory and then try to prove whether we are right or wrong

in this case, we think we know what the offending hardware is & that is all we know

mark

I deleted my previous response. My apologies for misinterpreting your post (I'm taking time out of a painful Sunday to respond).

If you're positive the problem is your router, then I know that I would at least try the things I mentioned (enable firewall router syslog to log dropped packets and check for disconnects from the IPs I mentioned; I don't know why dropped connections would be happening for just this single call, but I would at least want to confirm that it's happening), try "voip4.freephoneline.ca:6060" (without the quotation marks) in FreePBX, check for updated router firmware. If you're using Pi-hole, try disabling it (just try regular ISP DNS) briefly to test.

tried voip4, same issue
i still trying to figure out how to see the drop logs on my udmpro...

You could try asking at https://www.reddit.com/r/Ubiquiti/ or https://community.ui.com/. There must be a way to do it. I don't have your router, and I don't want to read through tons of stuff right now while I'm on pain meds.

Ensure UDP traffic is being routed to the correct LAN IP.

But if the call isn't even reaching your modem, then there's nothing for your router to drop. I would then start looking at weird DNS issues, Asterisk config (WAN IP not being sent in contact header), etc.

mkaye wrote:tried voip4, same issue
i still trying to figure out how to see the drop logs on my udmpro...

Does this help?

https://community.ui.com/questions/UDM- ... 59bd689c6d

Connections would be UDP only.

mkaye wrote:i connected my cell to fpl with linphone, but using my wifi (so still using my router) - call went to 30s silence and then voicemail (disabled follow me on fpl)

If FPL's proxy server were blocked by router firewall, I would expect the incoming call to drop to FPL's voicemail system immediately instead of ringing (silently) for 30 seconds first. Registration would have also failed if SIP signalling were impossible, unless NAT holes/associations are closing later on.
INVITE has to be going somewhere, and to me, it seems as though INVITE/RTP (audio stream) isn't being received by the right LAN IP.

Right before testing the incoming call, login at https://www.freephoneline.ca/showSipSettings. Check SIP User Agent to ensure the device/server you expect to be registered, is.

In order to reach the right LAN IP, RTP must first reach public WAN IP (your modem). Checking contact and via SIP headers for the right WAN IP (external_signaling_address) to confirm Asterisk is configured properly makes sense. I suspect the contact header is accurate (since all other calls work, but I'm not positive).

Then UDP packets must be routed to the right LAN IP. That's based on how your LAN is configured, especially your router.

Silent rings for 30 seconds. No answer. And then the incoming call drops to voicemail.
INVITE/RTP data isn't reaching the right LAN IP.
Check your VLAN configuration and incoming UDP rules.

I'm guessing you're VLAN tagging to some endpoint if it's an ATA? Anyway, that's not relevant.
I guess another question I have is, if you've never had this problem before, did you notice an automatic Ubiquiti router firmware update happening recently?

If you can figure out how, also check your open UDP connections and where UDP packets from 208.85.218.149 and 208.85.218.150 are being routed once (or if) they reach your router (syslog).

I had this same sort of thing when I used to run FreePBX, where some numbers would come in and others would go straight to voicemail. In my case is was down to the Codecs I had chosen. From memory I think I just had G729 selected, but that was wrong and I had to also include G711.

I could have the numbers wrong, it was a VERY long time ago now, but my issue was down to the codecs in some way.