Reply
Occasional Visitor
Lain
Posts: 2
0

Call failing to complete between a HDX7000HD C and HDX8000HD B.

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

Polycom Employee
Kendo
Posts: 520
0

Re: Call failing to complete between a HDX7000HD C and HDX8000HD B.

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.

Ken
Polycom
Sr. Product Support Technician
Occasional Visitor
Lain
Posts: 2
0

Re: Call failing to complete between a HDX7000HD C and HDX8000HD B.

[ Edited ]

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

Polycom Employee & Moderator
SteffenBaierUK
Posts: 6,207
0

Re: Call failing to complete between a HDX7000HD C and HDX8000HD B.

Hello Lain,

 

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

 

Steffen Baier

 

Polycom Global Services

Please be aware:

The purpose of these forums is to allow community members collaborate and help each other.
Questions posted here do not follow Polycom’s SLA guidelines.
If you require assistance from Polycom technical support, please open a
web service request or call us .

Above is necessary in order to track issue internally within Polycom.

Please ensure to always check the VoIP FAQ, Video Endpoint FAQ , PSTN FAQ or RPM FAQ

If you find my post helpful, and it answers your question, please mark it as an "Accepted Solution" and feel free to give me Kudos.
Frequent Advisor
sharps
Posts: 52
0

Re: Call failing to complete between a HDX7000HD C and HDX8000HD B.

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

Occasional Visitor
Moraks
Posts: 1
0

Re: Call failing to complete between a HDX7000HD C and HDX8000HD B.

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,