Dialing parking lot extensions on LAN sends calls to from-sip-external

Hey everyone,

I have a very strange issue happening - hopefully it’s something simple that I’m just overlooking.

New FreePBX build.
FreePBX: 12.0.76.2
Asterisk: 11.19.0

Using Endpoint Manager commercial module
Using Parking Pro commercial module

Parking info:
Default lot = 7000 (parking lots 7001-7005)
Sales lot = 7050 (parking lots 7051-7055)

This issue is happening ONLY to Polycom VVX410 phones that are on the same LAN subnet as the FreePBX.

I have used the Endpoint Manager to create templates for both internal and external Polycom VVX410 phones. The template includes a BLF-XFER button to transfer calls to the parking extension (7000 or 7050), and also includes 5 standard BLF buttons that represent the actual parking lot numbers (so that folks can see when a call is parked).

From the WAN, everything works GREAT - I have no issues…BLF is fine, xfer to park is fine, pick up from park is fine.

From the LAN with an X-Lite softphone, I can retrieve calls from the parking lot just fine with no issue.

From the LAN with Polycom VVX410’s however (same subnet as the FreePBX), there are some issues. First, all of the standard BLF buttons that represent the parking lot spaces are greyed out (as opposed to being blue on the WAN phones). These Polycoms can transfer to the parking lot no problem, but BLF on the parking lot keys does not work.

Finally - the weirdest thing. When they try to press the BLF parking lot key that the call is parked on (or if they dial the parking lot number directly such as x7001), they hear the main auto-attendant greeting from the default inbound route.

These calls appear to be redirected to the from-sip-external context:

-- Executing [[email protected]:1] NoOp("SIP/8900-000000f6", "Received incoming SIP connection from unknown                                                                                                peer to 7001") in new stack
-- Executing [[email protected]:2] Set("SIP/8900-000000f6", "DID=7001") in new stack
-- Executing [[email protected]:3] Goto("SIP/8900-000000f6", "s,1") in new stack
-- Goto (from-sip-external,s,1)
-- Executing [[email protected]:1] GotoIf("SIP/8900-000000f6", "1?checklang:noanonymous") in new stack
-- Goto (from-sip-external,s,2)
-- Executing [[email protected]:2] GotoIf("SIP/8900-000000f6", "0?setlanguage:from-trunk,7001,1") in new stack
-- Goto (from-trunk,7001,1)
-- Executing [[email protected]:1] NoOp("SIP/8900-000000f6", "Catch-All DID Match - Found 7001 - You probably want                                                                                                a DID for this.") in new stack
-- Executing [[email protected]:2] Log("SIP/8900-000000f6", "WARNING,Friendly Scanner from 10.80.241.100;branch=z9h                                                                                               G4bKab619d50C78859E1") in new stack

[2015-11-13 13:27:17] WARNING[24021][C-00000d80]: Ext. 7001:2 @ from-trunk: Friendly Scanner from 10.80.241.100;branc h=z9hG4bKab619d50C78859E1

(I tried to post the full log of this call, but the forum tells me “Sorry, new users can only mention 2 users in a post.”).

Again - softphones on the same LAN subnet and Polycom VVX410’s connecting via the WAN do not have this issue. It is only affecting Polycom VVX410’s on the local LAN subnet - even though those same phones are registered fine with the PBX.

What I have tried so far:

  • I have re-created the Endpoint Manager template for these phones, and ensured that the internal/external IP’s are input properly in the Endpoint Manager General Settings.

  • I have tried to manually change the Polycom line key buttons to BLF-XFER instead of BLF, but that didn’t work.

  • I have played around with Advanced SIP settings - allow anonymous SIP is set to YES. When I set it to NO, the phones on the LAN get fast busy when trying to make calls (even though I have the LAN subnet input correctly in the Advanced SIP settings Local Network).

Does anyone have any idea what might be going on, or what I can try next?

Thanks,
-Chris w/Crosstalk