SOLVED Polycom VVX Transfer to *99[ext] loops back call

[PBXMePlz]

So this one has me scratching my head a little. I setup a new FusionPBX box, it's not brand new, I've made some changes but none that should cause this (from what I can tell). It's possible maybe something with SRTP, but I don't think so. I'm honestly not sure at this point.

Dialing *99[ext] gets the extensions voicemail as expected.
On a Grandstream phone, transferring to *99[ext] sends the call to the extensions voicemail as expected.
On a Polcyom VVX 411 or 500, transferring a call to *99[ext] sends the call right back to the handset that transferred it. The call goes away for a half a second and then the handset rings again as if it's receiving a new incoming call from the originating number. The log indicates there's some sort of loop back happening, but nothing in the Outbound nor Inbound route would cause that, and the Dialplan Manager has *99[ext] as default, which again, this works on a Grandstream GRP2615.

I think a big part of this is me having not played with Polycoms for a minute...part of me wants to say this is a Digitmap thing???

 

[ricktendo]

Is polycom_digitmap enabled or disabled in Default Settings? (Note: this is disabled by default)

I assume you are autoprovisioning?

 

[PBXMePlz]

Is polycom_digitmap enabled or disabled in Default Settings? (Note: this is disabled by default)

I assume you are autoprovisioning?

It was Disabled, this was largely due to the fact that I was playing with it and I recall the default digitmap not being ideal but hadn't remembered why exactly. Upon enabling it, the phone times out before I get the last digit in. I get to *99[2 digit] instead of the required *99[3 digit ext]. That said I added a 2 digit extension and we see the same problem where the call loops back to the handset that tried to transfer direct to extension.

I am autoprovisioning from the FusionPBX box. I've actually pulled old configs from old phone systems; this makes me think it isn't the config, but...it kind of has to be the config doesn't it?
As I said before it worked with a Grandstream phone...at least I thought. I just was able to reproduce the issue with a Zoiper agent. I'm going to test with more agents later.

 

[PBXMePlz]

The issue was that loopback was the default option for treating domain bridge, and TLS was enabled at the gateway level

 

[PBXMePlz]

Well...it worked for a second there, and then stopped. I don't yet have any idea as to why.

Edit: I got it to work a second time by changing all the ring group and inbound routes to go to 4 digit extensions (for some reason I had them as 3 digit extensions). But it went back to not working after that one fortunate instance.

 

[PBXMePlz]

So, I backed out of changes I had previously made using this article:

SSL/TLS Setup — FusionPBX Docs documentation

docs.fusionpbx.com

Then I flushed the cache a couple times, no improvement.
I restarted the server, partially because I had made a few changes so why not, partially because I was getting frustrated and that felt like a good way to proverbially kick it. That appears to have fixed it I guess.