Spectrum call forwarding to Flowroute with 3CX with + in front Main Trunk Number.

[Gregg O]

This is an issue that has come up today in which it took me an entire day of troubleshooting, several calls to Spectrum, Flowroute, and email support with 3CX.

The issue that I experienced today started like any normal cutover day. We like to have calls forwarded from the losing carrier to Flowroute (Cloud Voice provider we chose) We called spectrum and logged into clients business site, entered in the forwarding number (Temp DID). After calls are forwarded we are able to test the system with client, make sure everything works and then submit the porting paperwork.

As soon as we turned on the forwarding, we would get network is too busy, or call can't be completed at this time. We double and triple-checked our settings. Test called the temp DID - 3CX phone system rang with no issues. So began the troubleshooting. We called spectrum, first person said it wasn't their issue. We turned off forwarding and used a rollover line to continue troubleshooting.

Called flowroute - They claimed issue wasn't at their end. Support initially wasn't really able to tell me much and I felt like we were getting nowhere.

We again checked all of our settings. This worked for dozens of clients in the last few months, and our process was always the same.

We also submitted tickets to 3CX and support to their credit was fairly responsive. Sent them logs and other requested info. The system was getting authentication errors.

While this was going on I started to run my own tests to basically rule things out. I set up routing in flowroute so when a call would come into the temp DID instead of going to 3CX I had it go to my cell. That worked!! Issue began to narrow issue with 3CX, and config with inbound parameters with flowroute

On other instances that 3CX (all are cloud-hosted, with the same version) This is what was there ( Those instances didn't have a + in front of the Trunk/DID numbers.



I looked at the new instance - deleted the sip trunk - readded it filled in the registration and main trunk number. Went to the same settings as above - and found it to be set this way.



While I was waiting for support ticket responses, etc (Started this at 9:30 am, this was 2:45 in the afternoon) I went into the new instance - changed the settings to the old, went to the main trunk number and REMOVED the +.

I tested and the fracking thing worked!!!!! Call forwarding from SPECTRUM BUSINESS Lines to a Registered number within 3CX worked.

I am writing this to let others know and hopefully guide them down a much easier path. When we complete the port we will change and update the settings, but this was a nightmare to troubleshoot, and we had limited support to go with.

Link to New default inbound parameters screenshot.

Link to OLD default inbound parameters screenshot


From what I can tell there is an issue in how Spectrum is sending the formatting of the number being forwarded to Flowroute which is passing it to 3CX. Although it worked through flowroute, this setting change caused all the issues I was having.

Hope this helps someone else.

 

[YiannisH_3CX]

Not sure I exactly understand the porting process but just to add to your solution, Flowroute has not changed anything from their end.
They are sending the called number in 2 places in the Invite, the Request-Line URI and the To:UserPart
The old template used to read it from the Request-Line URI which does not include a "+" so if you had your Flowroute configured and your DIDs in place nothing changed for you.
The new template reads the number from the To:UserPart header which uses a "+". So if you are adding a Flowroute trunk today you need to add your number with a "+".
We did this to accommodate voice and SMS in the same trunk with the same number format since the SMS API uses the "+" format.
Hope this helps

 

[Gregg O]

My point in all of this was to outline not all carriers are translating that, for example, SPECTRUM, when forwarding was turned on, was able to get to flowroute, but failed to get to 3CX PBX. So while calls from the DID worked without an issue, the forwarding did not from Spectrum. Flipping to Request-Line URI allowed the forwarding to work.

Again we like to forward calls to a PBX when we get ready to do a cutover, this way we control when that transition to the new system happens, and then we take care of the porting paperwork right after. This way we are not waiting for a carrier to tell us a 3 hour window on a date assigned.

 

[Darryl Traylor]

Greg,
I am having to the same issue today. Had to back out of a cut, I am still not sure what fixed the issue. Was it simply changing to the "Old Default"?

 

[JosueN]

Hi. I'm having similar issues. We're about to port away from FusionConnect and when I set up port forwarding on Fusion to an old instance of 3CX all works well, but on a new instance where the + is required on the DID the forwarding doesn't work. This is a 3CX issue as far as I can tell. Darryl, did you find a solution?
Removing the + from the DID on 3CX didn't work for me.

 

[YiannisH_3CX]

Hi. I'm having similar issues. We're about to port away from FusionConnect and when I set up port forwarding on Fusion to an old instance of 3CX all works well, but on a new instance where the + is required on the DID the forwarding doesn't work. This is a 3CX issue as far as I can tell. Darryl, did you find a solution?
Removing the + from the DID on 3CX didn't work for me.

Try to set up the Flowroute trunk again using the new template. Add the numbers with the "+" and it should work. If it does not then enable verbose logging and check how the Invite from Flowroute arrives at the PBX and if the called number has a "+".

 

[tbo]

I've been working all day to try to solve a similar issue. We have a fresh instance set-up and have 2 Flowroute DID's coming in on one SIP. Our inbound rules have been set and when you call the temporary numbers directly they work as they should, directing each DID to the appropriate IVR, each one supporting a different location of our company. The trouble came when we began to cutover the system and were forwarding calls from our current provider (Spectrum Business & AT&T). Whenever the system received calls that were forwarded from our current provider the calls would default to the Main Trunk rules. Looking at the Flowroute CDR logs, it appeared that all of the calls are passing through identically. After turning on Verbose logging in 3cx, I was finally able to see the TO:<sip: information changed depending on if the call was directly dialed or forwarded. The TO:<sip:+* when forwarded was actually our "published" number and not the Flowroute DID. So, I added DID's to the Flowroute trunk in 3cx to match our published numbers (even though they are not yet ported to Flowroute). I created new inbound rules to match and now everything is working as it should.