Fusion Voice problems

FreePBX Providers
1

Running into an intermittent problem that I cant pin down with registration to my SIP provider. I have a single trunk setup in FreePBX, that registers to Fusion (formerly Broadvox iirc). The issue has been intermittent for quite some time now, but a simple “fwconsole restart” seemed to fix it for the longest time. That would resolve the issue for around a month or so. It’s gotten to where it needs done multiple times a day now.

I believe this is an issue on the providers side, but I am just not sure at the moment. I hadn’t changed anything in years (outside of upgrades), until this week. I’ve changed the incoming peer details and outgoing registration string to match what I could find in online documentation. Confirmed the credentials with the provider, provided them with the peer detail information and registration string, and they didnt see a problem with it. Other than confirming those details, I matched the sip registration timeout with what I believe is being advertised by the provider as detailed in this string in sip debug
" Outbound Registration: Expiry for nd01-03.fs.fusionconnect.net is 90 sec (Scheduling reregistration in 75 s)"

Here’s the full sip debug for the call reject/403 forbidden

<--- SIP read from UDP:64.190.248.6:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK2b41a145;rport=5060
From: "Company Name" <sip:[email protected]>;tag=as399f24ab
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Broadvox Fusion
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---

<--- SIP read from UDP:64.190.248.6:5060 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK2b41a145;rport=5060
Max-Forwards: 70
From: "Company Name" <sip:[email protected]>;tag=as399f24ab
To: <sip:[email protected]>;tag=2Za2cyQp6F1jK
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Broadvox Fusion
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Reason: Q.850;cause=21;text="CALL_REJECTED"
Content-Length: 0
X-Disconnect-Reason: Source IP Not Mapped to Trunk

<------------->
--- (15 headers 0 lines) ---
Transmitting (NAT) to 64.190.248.6:5060:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK2b41a145;rport
Max-Forwards: 70
From: "Company Name" <sip:[email protected]>;tag=as399f24ab
To: <sip:[email protected]>;tag=2Za2cyQp6F1jK
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: FPBX-16.0.40.4(16.30.0)
Content-Length: 0

Any help is appreciated :slight_smile:

2

Source IP Not Mapped to Trunk

Did your registration ‘drop off’ prior to the call ? (Use sngrep)

3

Thanks for chiming in :+1:
I found this thread: SIP Trunk Registration issues with FusionSIP
where the same problem was diagnosed and “resolved”. Their registration server has a failover IP. I was getting responses back from their secondary IP while registration was still active on the primary. I implemented the “fix” of hardcoding the IP instead of using the FQDN. We’ll see how long this lasts.

4

What SIP channel driver are you using?

5

for the clients, chan_pjsip. For the trunk, chan_sip I assume? I think thats what you mean by the driver.

6

Don’t assume, check :wink:
chan_pjsip allow you to ‘permit’ several sources without needing separate trunks as chan_sip does, also chan_sip is ‘deprecated’ so you need to re-think perhaps.

7

How do I change the trunk to chan_pjsip? Also, I’m not sure the provider supports it, but I can reach out to confirm

edit
NM. Looks like I can just recreate it.

8

This has nothing to do with the chan_pjsip or chan_sip settings of the PBX. You are reading the packet wrong.

This indicates that it is an incoming packet to the PBX. So this is being received.

This indicates that the user agent sending the packet is Broadbox Fusion (not FreePBX).

This indicates the source IP (FreePBX) is not mapped to their trunk at the Fusion side.

These indicates that FreePBX is sending an ACK back to Fusion for the 403 Forbidden that Fusion sent.

So the real issue here is that Broadvox Fusion didn’t like the IP that the outbound call was sent from.

9

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