• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended

Hey, all.

 

I'm working on the installation and setup of two Polycom HDX 6000 systems, located in different counties to connect two court systems.  Setup was great, both systems are able to call a variety of test sites, and I can call into each from the local LAN from my Fedora machine with Ekiga, both on SIP and H.323.

 

One system (call it "System R") is on a resource-restricted network:  Difficult to get router and public IP configured, no time/money to allocate additional resources, etc.  So we decided that System R will call out to the other system whenever the video conferencing needs to happen.

 

"System J" is on a network where the network admin has given me full access to everything I need to set up the public face of the video conferencing system.  I followed all the various and sundry guides (both Polycom and others) on how to set up the router, firewall, and System J to accept incoming calls.

 

So here's the wrinkle:  Calls to System J are failing, and after some work with Wireshark, I have found out why.  When the call is initiated to the public IP address for System J, it's being properly routed.  However, System J is responding with its internal IP address (128.222.2.188), rather than its public IP address.

 

The calling system then uses that wrong address to finish the call setup, and it fails (of course).  The Wireshark trace shows that the two talk past each other for about 30 seconds, then the client gives up.

 

I've tried many and several combinations of the firewall and IP config, and the best I can get is the above.  The system displays the public IP address on the "Home" screen, so it's well aware of the public address and all indiciations are that it _should_ work.  Complete power-downs/reboots ("hard" and "soft") have not shaken this behavior.  It's still broadcasting the wrong address on the SIP setup (H.323 is not working either, but not getting a definitve trace on that one)

 

So here are my questions:

 

1.  I do software development, and it's my suspicion that having a non-routable address is part of the requirement for this to work (10.0.0.0, 172.0.0.0, or 192.0.0.0), and the fact that System J is on a network that doesn't use those address ranges is the source of the problem.  Is this true (the non-routable requirement)?  I need to confirm this before having the network guy go through the work of reconfiguring a chunk of his network.

 

2.  If #1 is not the case, is there a good blog entry/documentation/guide that others who have been in a similar situation and have overcome this problem?

 

3.  Any pointers on how to track this down or sift through the sites and documentation?  I've tried as many different search terms as I can, but my Google-fu is being defeated by this particular problem.  Maybe I'm not using the proper search terminology.

 

I would be happy to post configs (redacted), capture files, etc. if someone thinks it would help.

1 ACCEPTED SOLUTION

Accepted Solutions
HP Recommended

All,

 

Thanks to Gary's advice, I was able to finish up the setup and make calls from the RealPresence Desktop software.  

 

The final profile export is attached, and I've highlighted the relevent settings in green.

 

The final answer seems to be that the problem lies within the SIP protocol.  Even though the system is set to use H.323 first, it seemed to jump to SIP, and we went down the path of wrong addresses.

 

After getting the settings correct for the firewall, ports, etc, the final change was to disable SIP--uncheck the "Enable SIP" box on the Admin Settings=>Network=>IP Network page.  

 

When you have done this, try a test call, then do a full power-down reboot of the machine to ensure that the setting "sticks"--it had to be reset on my machine after the user accidentally unplugged the machine on the other end, although I had a good call running.

 

I hope this helps someone else out there.  All of my thanks and gratitude to Gary for his insight and patience.

 

I would also recommend getting familiar with the telnet API--it's a good way to see all of the settings in one place, rather than bouncing from screen to screen.

 

 

View solution in original post

9 REPLIES 9
HP Recommended

It sounds like the router on the "R" side doesn't understand how to play nice with H.323.    H.323 embeds address in the Payload and the router/firewall has to understand H.323 and fixup these addresses in the payload.

 

Have you tried the same calls using SIP protocol?    SIP does not embed the addresses and you might be able to get away with your calls.   Just dial by IP address and specify as SIP protocol.

 

Good luck,

 

Gary M

HP Recommended

Gary,

 

The SIP actually is the traceable problem.  I've attached a screenshot of the response coming out of the router to an SIP call.  As you can see, the "Contact" value is the internal address (128.222.2.188), and my machine (10.0.0.7) spends the rest of the session trying to contact that address.

 

Ekiga on Windows just fails when I try to use H.323 calls, but I get failures on my Fedora laptop, too.  If I can get SIP up, I'll call it "good enough" to have the customer start using it.

 

Appreciate the help.  I've played with all kinds of router settings, and the "Contact" message is still the same.

HP Recommended

Sorry--messed up the file extension.  Here's the corrected file.

HP Recommended

Does the "R" system have "NAT" configured on it ?   If you set that, it "Should" get the public address..   (you may have to manually set the address which, maybe a problem is if is DHCP from the ISP)..

 

Have you tested NAT Configuration ?

 

Gary M

HP Recommended

Here are the IP Network/Firewall settings:

 

Fixed Ports:  Checked

TCP Ports:  3230 to 3232 (auto)

UDP Ports:  3230 to 3246

 

Enable H.460 Firewall Traversal:  Checked

 

Nat Configuration:  Auto (I've set it manually, also--with no difference)

Nat Public (WAN) Address:  173.249.140.220

NAT is H.323 Compatible:  Unchecked

Address Displayed in Global Directory:  Public 173.249.140.220

Enable SIP Keep-Alive Messages:  Checked

 

I decided to go ahead and put out the public IP address--we've already got what looks like an H.323 vulnerability scanner trying to call in all the time, so I'll have to work with the network guy on blacklisting or whitelisting incoming calls to keep those guys out.  

 

I've gone through the process of going from manual to auto, and all of the settings look and behave correctly, according to the guides and how-to blog entries.  But we still get the "Contact:  <null>@128.222.2.188" in the setup response.

 

I'm not sure what you mean by "tested NAT configuration"--could you elaborate a little, please?

HP Recommended

Ok, first off, uncheck the box next to H.460.   I don't believe (from what you have said) you have a H.460 Firewall traversal device.

 

With H.460 unchecked and the NAT Configuration set to manual (and you input the 173.249.140.220 address, have you tried calls ?

 

I'm assuming you have tried dialing both H.323 and SIP with this configuration and they failed.     Have you tried dialing somewhere else (another test site) with the "R" system ?

 

This is, sometimes, another way around this and that is by putting the HDX in the DMZ of the router on that end.    Allowing everything to be passed as if the HDX was actually on the public.

 

I would also suggest that you download the Polycom Real Presence Desktop software.   It will run for 30 days without a license and is fully compatible with your other systems.   This might give you a better "test bed" from a standards based product.   Polycom also has a Real Presence Mobile product that runs on most Android and IOS devices and is completely free.  Again, a good test software.

 

Your idea of trying to prevent rogue calls from coming in with white list/black list might not be very successful.   On my test site, I have seen the calls come in from over 500 different IP addresses with new ones every day.   The only way I was able to reduce or eliminate them was to require "Encryption" in the call and their software doesn't know how to negociate it and it drops straight away.

 

Good luck and feel free to answer back here or PM.

 

Cheers,

 

Gary M

 

 

HP Recommended

Gary,

 

I have successfully made calls to all of the Polycom (and multiple other) test sites from that system with no problem.

 

I reset back to manual and uncheck the H.260 traversal, and I get the exact same behavior.

 

Just for completeness, I am attaching the telnet exportprofile output (serial number redacted) so you can see all of the settings on the system.  The behavior is exactly the same--the Ekiga client tries to connect, and for about 30 seconds it tries to talk to the wrong IP address.

 

If you'd like to try it from your machines, please feel free--you might notice something about the behavior from a Polycom unit that I might have missed.

 

 

HP Recommended

For me to be able to make test calls, I would need the unit's password.   If you are comfortable in giving it to me, just pm it to me.

 

thanks,

 

Gary M

HP Recommended

All,

 

Thanks to Gary's advice, I was able to finish up the setup and make calls from the RealPresence Desktop software.  

 

The final profile export is attached, and I've highlighted the relevent settings in green.

 

The final answer seems to be that the problem lies within the SIP protocol.  Even though the system is set to use H.323 first, it seemed to jump to SIP, and we went down the path of wrong addresses.

 

After getting the settings correct for the firewall, ports, etc, the final change was to disable SIP--uncheck the "Enable SIP" box on the Admin Settings=>Network=>IP Network page.  

 

When you have done this, try a test call, then do a full power-down reboot of the machine to ensure that the setting "sticks"--it had to be reset on my machine after the user accidentally unplugged the machine on the other end, although I had a good call running.

 

I hope this helps someone else out there.  All of my thanks and gratitude to Gary for his insight and patience.

 

I would also recommend getting familiar with the telnet API--it's a good way to see all of the settings in one place, rather than bouncing from screen to screen.

 

 

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.