Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations dencom on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Remote H323 handset set up issue

Status
Not open for further replies.

Jimbo2015

Technical User
Nov 9, 2013
317
GB
Hi,

I have an IPO that already has a couple of remote H323 extensions working fine which I set up a year ago on site. They were then shipped out to various locations and they are working fine.

I then tried to set up two further extensions from our office using the customers public IP etc.

The handset seems to set up fine and then it reboots and says contacting call sever and then it asked me to log in with an extension. I created a new extension and made sure that auto create extension was configured on the IPO but after I type in the extension and press enter the handset just goes back to Discover xx.xx.xx.xx and then nothing happens.

Any idea how to resolve this? Its been a year since I configured one of these so maybe I am abit rusty.

Thanks in advance,
 
Also, is it possible to create the extension remotely? Should I have already created the extension on the system and then log into it remotely?
 
You need to have created the extn and user and then set it to a remote handset or it can't work.

Never turn and leave auto create on, especially if you have forwarded the handset reg ports to the system, you're asking to be hacked :)

 
ok thanks, I think the other issue is that they already have 4 H323 remote licences and require teleworker licence now.
 
I have now bought teleworker licences and set up the extensions and users as teleworkers and enabled remote worker but when I enter all of the details into the ADDR section of the handset the handset reboots and then asked me to log in, I log in and then it restarts and then said discover xx.xx.xx.xx the call server and http etc are all the same details as another H323 remote handset that is working remotely fine. The only details I changed in the ADDR are the router and phone IP and kept all of the other details the same as the other remote handset but it is still saying discover.

I noticed AMRiddle said about the handset registration ports being forwarded to the system, I am not sure if this is done, I currently have auto create on so thought this would be enough but what ports need to be forwarded to allow remote registration? As I think this could be causing the issue.
 
You shouldn't be changing the router IP on the handsets, they should get that from the users router, all you need to set is call server and file server addresses.

Remember not all service provider routers/connections allow remote phones to work, some actively block it, as users typically use their own residential broadband it's pot luck whether it works or not,
Same is true of business routers, Drayteks don't like them for example :)

 
It was a Draytek router I was connecting to at the office so thought you had cracked it.

I took the phone home and connected it to my sky router which worked when I set this up last time. I cleared the handset and just entered their public IP in the call server, http and https fields and left the rest as 0's.

It rebooted and then said contacting call server and the asked for the extension but is now saying discover xx.xxx.xxx.xx and has not changed.

I thought it could be a setting on the router or something put there are 4 other remote H323 handsets working fine on this system so it is very odd.

I have also pinged the public IP and received a response
 
I have just remembered one thing that has changed since we last installed a handset and that is that we installed a Netgear FVS336Gv2 between this site and another site. When we installed this it did not effect the other H323 remote extenions but do you think it could be preventing the handset from registering?

Thanks in advance,
 
Check the maximum number of remote H.323 handset in the doc's.
I'm pretty sure you will find a maximum number of 4.

Johan W.
ACIS-SME
ACSS-SME
APSS-SME
 
Yes thats correct for essential editon but they have vm pro and I have bought teleworker licences. It is like the Avaya is not giving it an IP address, I will check the pool sizes on the Avaya and see if that helps.

I also asked netgear to take a look and there only suggestion was to turn on SIP ALG or UPNP? but wasnt sure if either of these would help
 
The system doesn't give it an address, that's given by the local router.... which then routes the traffic to the external IP you entered. This is not a DHCP issue on the IP Office :)

 
Ok I think I will go back to netgear and see if someone more experienced can investigate
 
Netgear are sure its nothing to do with their router but I think I will go back to the customers site and connect their old Linksys router and see if that works atleast this will eliminate the router
 
Also just to confirm that I am not doing any thing stupid. The customer has 4 remote handsets that all worked fine remotely over H323. This is the first handset that has been configured through a teleworker licence and the customer does have vm pro. The only difference I have made to the way I previously set up the other 4 handsets is that I selected teleworker from the drop down box when I configured the user and ticked the boxes that appeared below with the exception of softphone.
 
Yes they were quite quick to blame the handset and I explained that I had tried around 4 different 9620's so they said it must be the remote routers or the phone system
 
This issue is still causing issues. I have checked the ports using and it says that 1719 is closed. Is this showing as closed for security reasons or should it be showing as open?

Netgear are useless in helping me with this one and new extensions will still not register
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top