05-28-2014 07:14 PM - edited 03-18-2019 03:02 AM
Hi All,
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 ID | 40 |
---|---|
Remote number | h323:paris.Meetingroom |
Callback number | h323:paris.Meetingroom |
Display name | paris.Meetingroom |
Direction | Incoming |
Protocol | H323 |
Call rate | 4096 kbps |
Call type | Video |
Encryption type | AES-128 |
Call priority | None |
Booking ID | |
Duration | 24 seconds |
Start time | 2014-05-27T23:36:51Z |
End time | 2014-05-27T23:37:15Z |
Disconnect cause | Normal |
Disconnect cause code | 16 (Q850) |
Disconnect cause type | RemoteDisconnect |
Occurrence type | Received |
Is acknowledged | Acknowledged |
Audio | Transmit | Receive |
---|---|---|
Packet loss | 0/0 (0%) | 0/0 (0%) |
Max jitter | 0 | 0 |
Video | Transmit | Receive |
Packet loss | 0/0 (0%) | 0/0 (0%) |
Max jitter | 0 | 0 |
05-29-2014 01:03 AM
Hi,
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.
Cheers
Chris
05-29-2014 01:59 AM
Is there any problem with NAT? I have a deployment and I am not sure if the firewall is configured in proper way.
06-16-2014 12:37 AM
hi guys,
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).
06-16-2014 12:48 AM
Hi Wildflower,
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.
Cheers
Chris
06-16-2014 11:47 PM
Hi Chris,
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 (device@domain.com) 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.
06-17-2014 05:07 AM
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 user@domain.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?
06-19-2014 05:39 PM
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
06-17-2014 07:30 PM
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.
Please remember to mark helpful responses and to set your question as answered if appropriate.
06-19-2014 06:07 PM
Hi Wayne,
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."
06-19-2014 01:54 AM
The search details or the debug logs should show more.
Typical issues are like it was said here before:
*firewalls
(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
06-18-2014 04:20 AM
Hi,
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.
-Tabish
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide