mkaye wrote:no, not saying fpl to fpl works
we have 3 cell #'s that work just fine all the time
Sorry, I'm thoroughly confused now.
You have 3 Bell Mobility (or what are the carriers?) cellular numbers that work just fine for what? Work fine all the time for calls to and from both FPL numbers?
we have an fpl, bell, cell that don't work 100% of the time
Don't work 100% for what? Outbound calls to the failing FPL number?
Is the failing FPL number not on your PBX, normally? Is it at another location?
Do outgoing calls from this failing FPL number to non-FPL numbers work?
Disable PBX FPL trunk(s), remove router, stick modem gateway (if it's a modem/router combo, gateway, or Hub) in bridge mode, export current ATA settings, reset ATA, configure ATA using one of the guides found at viewforum.php?f=15, and connect ATA directly to the modem (with it in bridge mode).
If you're using a Granstream ATA, make sure that you have "SIP REGISTER Contact Header Uses" set to "WAN Address".
Check for incoming calls from both non-FPL and FPL numbers. Don't move on until incoming calls work.
Once you get that configuration working, connect ATA to Ubiquiti router and test again without PBX. Get that working before moving on to next step.
Finally, restore/import previous ATA settings (depends on ATA model) and connect to PBX.
we were using the failing fpl # to test
Okay, I'm not sure where this failing FPL number is normally registered. On your PBX? Or at another location?
If you have two FPL numbers registered with the same WAN IP on your PBX, don't use the same FPL proxy server for both FPL numbers.
Don't use the same local (LAN) UDP SIP port both both numbers either.
my friend would then use his cell with linphone connected to his fpl #
this worked if my phone wasn't connected to my wifi
which pointed us to a firewall issue on my router
I have no idea why you're testing this. You initially indicated the problem was with an incoming Bell landline call.
FPL to FPL is treated as SIP URI (internally, AFAIK). SIP to SIP is different and affected by SIP ALG at either end/not having true bridge mode (and possibly IPv6 based on an old Fongo Mobile issue with Fido/Rogers ISP).
At first, I was wondering about a Fibernetics call routing issue, but that's not the case since incoming calls are reaching FPL voicemail.
but now another router has exactly the same issue, so really can't be the router
That's inconclusive since you're not checking logs.
It is possible INVITE isn't being by proxy to the correct IP address. You should get able to check outbound SIP contact header from your end for correct external IP.
Anyway, I'm pretty confused by your description.
1. I would start by confirming I'm getting true bridge mode.
What brand and model modem are you using?
2. Disable PBX FPL trunk(s), remove router,
stick modem gateway (if it's a modem/router combo, gateway, or Hub) in bridge mode, export current ATA settings, reset ATA, configure ATA using one of the guides found at viewforum.php?f=15, and connect ATA directly to the modem (with it in bridge mode).
If you're using a Granstream ATA, make sure that you have "SIP REGISTER Contact Header Uses" set to "WAN Address"
To export with Grandstream, visit
https://forums.grandstream.com/t/how-to ... ta/37251/2.
Obihai settings export is located in the OBi2xx PDF guide on this forum.
3. Check for incoming calls from both non-FPL and FPL numbers (ensure person on other end of outbound FPL call to you is using cellular data, so that I don't have to question some ALG/NAT issue on the other end). Don't move on until incoming calls work.
If you get a SIP error code at this point, let me know.
4. Once you get that configuration from #3 working while connected directly to modem (and modem only), connect ATA to usual Ubiquiti router and test again without PBX. Get that working before moving on to next step.
5. Finally, restore/import previous ATA settings (depends on ATA model) and connect back to PBX. Troubleshoot from there (especially check Contact and Via headers).
At least after step 4, the problem isn't your modem (calls are reaching your WAN), and you should be able to confirm at that point whether you've configured something improperly.
Lastly, question what's going on if everything works fine while using Linphone while connected to cellular data.