I am making an inbound external H323 call from a Polycom device to an internal registered cisco end point.
The call traffic is hitting the VCS-E, correctly being identified:
The end point is then correctly found on the VCS-C:
Under search history I get the following:
|2014-05-28 15:16:17||H323 (Setup)||paris.Meetingroom||EX60@xxxx.com||Found|
|2014-05-28 15:16:17||H323 (LRQ)||paris.Meetingroom||EX60@xxxx.com||Found|
The Polycom displays 'call connecting' then the call drops, the EX60 answers but doesn't display anything. The call details from the EX60 are:
|Call rate||4096 kbps|
|Disconnect cause code||16 (Q850)|
|Disconnect cause type||RemoteDisconnect|
|Packet loss||0/0 (0%)||0/0 (0%)|
|Packet loss||0/0 (0%)||0/0 (0%)|
I suspect this will be a firewall/NAT issue.
Where about in the topology are your VCS-E, VCS-C and finial Endpoints located, and are there any firewalls between any of them? Have you opened up the correct ports and ensured that the the firewall is not blocking anything? Do the firewall utilise H.323 fix-up policies? Do you employ NAT, and if so how is it deployed?
I think a fuller description of you network might be in order.
I have checked the firewall and all of the relevant ports are open. The situation has changed slightly as I can now make and receive internal and external SIP calls, I can make and receive internal H323 calls, and I can receive external H323 calls.
The only call type not possible is external outbound H323 calls. The external device answers (h225 handshake) but the 245 media never completes. The external device is able to successfully call back the device from call history (225 element).
I have to ask, what has been the factors that have cause the "situation to change slightly"?
Can I ask where the external Polycom device is located and how is it being called? Is it registered to the VCS-E, or is the VCS-E simply passing the call off directly to the Polycom or another gatekeeper. Is the Polycom device behind a router or additional firewall device?
As mentioned previously, without FULL topology info it is difficult it make summarisation.
The 'slight change' was the customers firewall team adding the complete range of ports (it only took 4 months)
the current calling scenario is outbound IP (xxx.xxx.xxx.xxx) dialing works, outbound H323 (firstname.lastname@example.org) does not.
inbound calling via SIP/H323 works fine.
I have a TAC case raised but the engineer is stumped, I am happy to email the debug logs if someone is keen to have a look.
Ah - that "slight change" is often a fixer!
Debug logs are always useful (albeit they might contain sensitive info), but an understanding of topology is better.
However, you mention something above that you have not mentioned before. The IP dialling will be using H.323, so it may be that H.323 outbound dialling does work, but rather the DNS lookup when using H.323 is working properly.
As you saying that SIP external dialling (which I'm assuming will be a URI format of email@example.com) does work, then we can assume that both your search rules and DNS are set up OK. In which case, it does become more intriguing, especially when you also mention that there is a handshake - which means that the DNS lookup of the relevant record must have been successful.
So are you saying that the IP address you are dialling using H.323 is the SAME as that which is resolved when making an H.323 DNS call? You can check the debug logs and you should see the IP address that is resolved?
error log report for MCU call:
VCS-C tvcs: Event="Search Completed" Reason="Normal call clearing - Security denied" Service="H323" Src-alias-type="H323" Src-alias="MCU1@external VCS-E IP address" Src-alias-type="E164" Src-alias="4220" Dst-ip="external destination"
point to point calls work ok
It could be that your VCS isn't set to query the A or AAAA records if it can't resolve the domain with the SRV record.
See the "URI resolution process using DNS" section of the VCS Administrator Guide.
I have attached some abridged log excepts while looking for A/AAAA details:
line 1: Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="VM-TMS01.local" Type="A and AAAA"
line 2: Module="network.tcp" Level="DEBUG": Src-ip="VCS-C internal IP" Src-port="15238" Dst-ip="VCS-E internal IP" Dst-port="2776" Detail="TCP Connecting"
line 3: Module="network.tcp" Level="DEBUG": Src-ip="VCS-C internal IP" Src-port="15238" Dst-ip="VCS-E internal IP" Dst-port="2776" Detail="TCP Connection Established"
why is a point to point call from internal end point 1 to external end point 2 doing a dns lookup for the TMS?
later in the log is this entry:
Module="network.dns" Level="DEBUG": Detail="Resolved hostname to: ['IPv4''TCP''Site two VCS-E external IP:1719'] (A/AAAA) ['IPv4''TCP''Site two VCS-E external IP:1719'] (A/AAAA) Number of relevant records retrieved: 2"
Module="network.http" Level="DEBUG": Message="Request" Method="POST" URL="http://127.0.0.1:9999/licensemanager/acquire" Ref="0x7f720e1e9170"
Module="network.tcp" Level="DEBUG": Src-ip="Site one VCS-E external IP" Src-port="15189" Dst-ip="Site two VCS-E external IP" Dst-port="1720" Detail="TCP Connecting"
Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="VM-TMS01.local" Type="A and AAAA"
Module="network.dns" Level="DEBUG": Detail="Could not resolve hostname"
once again looking for Site one's internal TMS ??
Module="network.tcp" Level="ERROR": Src-ip="Site one VCS-E external IP" Src-port="15190" Dst-ip="Site two VCS-E external IP" Dst-port="15102" Detail="TCP Connection Failed"
Module="network.h323" Level="ERROR": Action="Sent" Dst-ip="Site two VCS-E external IP" Dst-port="15102"
Detail="Failed to connect outbound H.245 TCP connection. Rejecting inbound H.245 TCP connection."
The search details or the debug logs should show more.
Typical issues are like it was said here before:
(here either proper port ranges, or what I have seen even more, that there is some layer >=3 handling of h323 present which breaks something)
* wrong search rules
* wrong setup on the remote site
Please remember to rate helpful responses and identify
I suspect this as a firewall issue. Even though the ports are opened it has to be opened from both the direction for incoming and outgoing video traffic.