Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

successful H323 video call setup and completion without actually working

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:17H323 (Setup)paris.MeetingroomEX60@xxxx.comFound 
2014-05-28 15:16:17H323 (LRQ)paris.MeetingroomEX60@xxxx.comFound 

 

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 ID40
Remote numberh323:paris.Meetingroom
Callback numberh323:paris.Meetingroom
Display nameparis.Meetingroom
DirectionIncoming
ProtocolH323
Call rate4096 kbps
Call typeVideo
Encryption typeAES-128
Call priorityNone
Booking ID 
Duration24 seconds
Start time2014-05-27T23:36:51Z
End time2014-05-27T23:37:15Z
Disconnect causeNormal
Disconnect cause code16 (Q850)
Disconnect cause typeRemoteDisconnect
Occurrence typeReceived
Is acknowledgedAcknowledged
AudioTransmitReceive
Packet loss0/0 (0%)0/0 (0%)
Max jitter00
VideoTransmitReceive
Packet loss0/0 (0%)0/0 (0%)
Max jitter00

 

11 REPLIES

Hi,I suspect this will be a

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

 

New Member

Is there any problem with NAT

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

New Member

hi guys, I have checked the

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

 

Hi Wildflower,I have to ask,

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

New Member

Hi Chris,The 'slight change'

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.

Ah - that "slight change" is

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?

New Member

error log report:VCS-C tvcs:

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

VIP Green

It could be that your VCS isn

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.

 

 

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
New Member

Hi Wayne,I have attached some

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

 

The search details or the

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

New Member

Hi,I suspect this as a

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

 

417
Views
5
Helpful
11
Replies