successful H323 video call setup and completion without actually working

[wildflower1977]

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:

• • SearchRule (4)
  • • Name: Local Zone - full URI
  • • Zone (1)
    • • Name: TraversalZone
    • • Type: TraversalServer
    • • Protocol: H323
    • • Found: True
    • • StartTime: 2014-05-28 15:29:13
    • • Duration: 0.02
    • • Gatekeeper (1)
      • • Address: xxx.xxx.xx.xxx:1719
      • • Alias (1)
        • • Type: H323Id
        • • Origin: Unknown
        • • Value: EX60@xxxx.com

The end point is then correctly found on the VCS-C:

• • SearchRule (2)
  • • Name: Local Zone - full URI
  • • Zone (1)
    • • Name: LocalZone
    • • Type: Local
    • • Protocol: H323
    • • Found: True
    • • StartTime: 2014-05-28 15:29:14
    • • Duration: 3.29
    • • Gatekeeper (1)
      • • Address: xxx.xxx.xx.xxx:0
      • • Alias (1)
        • • Type: H323Id
        • • Origin: Unknown
        • • Value: EX60@xxxx.com

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

[Chris Swinney]

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

[JustForVoice_2]

Is there any problem with NAT? I have a deployment and I am not sure if the firewall is configured in proper way.

[wildflower1977]

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).

[Chris Swinney]

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

[wildflower1977]

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.

[Chris Swinney]

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?

[wildflower1977]

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

[Wayne DeNardi]

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.

[wildflower1977]

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."

[Martin Koch]

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

[TABISH ANSARI]

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