BLF not working on Polycom VVX601

[tekservpros]

I have a client that we are thinking about moving to 3CX, they currently have Poly VVX601 phones in their environment. I added a new VVX601 to our current 3CX instance hosted on Amazon. The phone has the latest firmware update from Poly and our 3CX instance is running the latest version.

The phone is attached to a dummy extension in our instance, but we have run into a few issues:

• We cannot pickup or answer a call on the BLF, the screen or buttons do not respond.
• Once the call is terminated, a message flashes “Resource Unavailable”.

Has anyone run into this issue?

 

[ltctech]

3CX's handling of NAT for Subscribe/Notify/Refer is inconsistent with other SIP requests:
https://www.3cx.com/community/threa...be-notify-refer-over-tcp-tls-transport.70508/

Is the VVX using UDP transport? Have you attempted to crank up logging on the VVX to diagnose further? Is STUN enabled on the VVX?

feature.nat.stun.enabled
0 (default) - Disable STUN.
1 - Enable STUN. SIP responses are sent to the source IP address and source port where the
request originated. If you also enable parameter voIpProt.SIP.rport, then the VVX phone
adds the received IP address and port in the VIA header while generating the response.
Change causes the system to restart or reboot.

Source: https://support.polycom.com/content...-notes/en/uc-software-release-notes-6-3-0.pdf

It's not clear if Poly phones have the ability to rewrite headers and if they do it's exclusive to UDP transport when used in conjunction with STUN. I only have a VVX 600 to test and it doesn't support 6.X, only 5.9. Ensure that both feature.nat.stun.enabled and voIpProt.SIP.rport is enabled. The 3CX template should already do this if you're using it.

Yealink phones are configured to rewrite Contact/Via SIP headers with the phone's public IP : port to counteract any NAT issues with 3CX, they call it "Direct Process". This has been an option for a while now and works for all transports.

Parameter: account.X.nat.rport
Description: It enables or disables the phone to add the "rport" parameter in the Via header.
Permitted Values:
0 - Disabled
1 - Enabled, the INVITE Contact header uses the port in the "rport" parameter but does not use the
source IP address in the "received" parameter in the Via header of server's response.
2 - Enable Direct Process, the INVITE Contact header uses the port in the "rport" parameter and uses
the source IP address in the "received" parameter in the Via header of server's response.

Source:
Yealink SIP-T2 Series T4 Series T5 Series CP920 IP Phones Administrator Guide V85.1.pdf
http://support.yealink.com/documentFront/forwardToDocumentDetailPage?documentId=142

You may be forced to use a local SBC to workaround this issue.