• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended

Hi folks,

 

I have a problem I can't explain. My gut feeling tells me it's going to be VLAN-related but as that is outside of my sphere of influence, I'm still going through the motions of checking the Polycom logs.

 

The set-up is this:

  1. Firmware for the 7000: 3.0.2-11176;
  2. Firmware for the 8000: 3.0.2-11176;
  3. The sites are remote to one another;
  4. Calls from the 8000 to the 7000 succeed but from the 7000 to 8000 do not;
  5. For the failing direction, the call is "answered" but does not complete the negotiation phase and connect.

I'm not experienced at reviewing the Polycom logs. The only entries I can find that may help are these:

 

  • WARNING avc: pc[0]: H323Call[0]: unhandled call state 10
  • INFO avc: pc[0]: H323Call[0]: outgoing disconnected, cause code:16
  • WARNING avc: pc[0]: H323Call[0]: CallStateChangedCallback unhandled state 0
  • INFO avc: pc[0]: H323Conn[1]: H323Call[0] deleted, address:10.187.99.101

I can place calls from the 7000 to units located at two different remote sites to that of the 8000. It's just this one site that's having issues, hence why I think this is going to come back to the network (most likely the new VLAN).

 

From the UI perspective on the 7000, I get the generic:

 

Failed Attempt; "The call has ended.; Rolling Over."

 

message. It then proceeds to roll over to the SIP protocol, but as that's not enabled on the 8000 I then get the equally generic:

 

Failed Attempt; "Your call could not be completed because the call was routed through an intermediate network that does not service the far site. Contact your network administrator for assistance.; Rolling Over."

 

What I'm hoping to get some feedback on is the "unhandled call state 10" as I have no idea what that may mean. From what I've read, cause code 16 just means a requsted hang-up, so I'm not focusing on that.

 

Cheers,

Lain

5 REPLIES 5
HP Recommended

Cause code 16 is normal call clearing.  usually means the call was 'hung up' by the farend. Even if the call was dropped by the network you will still see 16. The unhandeled call state 10 just means the call did not connect.

 If the call is connecting on port 1720 then most likely the correct ports are not open on the firewall.

The HDX uses TCP 3230-3235 and UDP 3230-3277 (the upper UDP range depends on HDX model and software version) you can find these settings in the Firewall section of the IP network settings section of Admin settings.

Also be sure NAT is properly set up for your firewall.

If you do not use SIP then disable it in Call Preferences settings. The HDX will attempt to place the call over all transports it is configured for if it cannot get through on the first one.

Give us a call (888) 248.4143 and we may be able to advise you on further HDX network settings to match the firewall.

HP Recommended

Hi Ken,

 

Thanks for the phone number, but we're not able to make international calls from work, and I'd hazzard a guess depending on which US timezone you're on that we don't have any overlap in any case (+8 GMT here).

 

Indeed, I wasn't worried about the cause code 16 to begin with, but it's nice to know what call state 10 means as I can ignore that too now. Of course, I'm not not sure if there's anything incriminating in the system log at all, so it feels like one step forwards, two steps back.

For now I might go back and see if I can coerce the network engineer who set up that new VLAN to revisit it's configuration and look for anything he may have missed, as we can call anything else internally and even an Internet-facing bridge from another university, so I'm quite confident the problem's not at our end (being the HDX7000 on this occasion).

 

More as an FYI, we do in fact use SIP as the HDX7000's are registered in Lync, but that's got nothing to do with this particular issue we're tring to troubleshoot. It just means I'm ignoring the second "error".

 

Cheers,

Lain

HP Recommended

Hello Lain,

 

as places outside the US exist please see our international numbers => here <=

 

Steffen Baier

 

Polycom Global Services

------------------------------------------------
Notice: I am an HP Poly employee but all replies within the community are done as a volunteer outside of my day role. This community forum is not an official HP Poly support resource, thus responses from HP Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
If you need immediate and/or official assistance for former Poly\Plantronics\Polycom please open a service ticket through your support channels
For HP products please check HP Support.

Please also ensure you always check the General VoIP , Video Endpoint , UC Platform (Microsoft) , PSTN
HP Recommended

your HDX port range here is shorter than the default range - 3230-3243 and 3230-3341 -

HP Recommended

hello I am new in the forum

I am having some strange challenges with my connection

I am using RMX 4000 and CMA 2000, everything has been working well until recently for some strange reasons, some of the HDX and VVX are not connecting to conference bridge

 

I have done series of troubleshooting but its  not working our. I can reach the device login to them but when attempt to make call it will simply go dumb

 

later the error will come up (for HDX) ""

Your call could not be completed because the call was routed through an intermediate network that does not service the far site. Contact your network administrator for assistance.""

 

 

I checked online but was told may firewall, but there is not fire wall blocking the within my LAN, the existing check, is just there with open permition.

 

also, sometimes it work very briefly and then go dumb again

 

does anybody have an idea what could be wrong?

 

note that other location are working fine,

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.