atcomsystems.ca/forum Forums TDM Business Telephone Systems NEC Telephones & Systems Dterm IP phone home and remote users

Hi, trying to get this working but our vendor doesn't know whats wrong.

We have a IPS 2000 system with a 8IPLA card to our internal network and some Dterm IP phones. It works great internally but now we want to allow employees to take the phone home and work from there. On our internet gateway, as per our vendor's provided information, we opened up some UDP ports to allow communications to the 8IPLA card which is on our internal network.

When we reconfigured the phone to use the external gateway IP as DRS, we got a timeout error on the phone. Vendor then told us to add 2 more ports for forwarding. Now the phone seems to connect, screen stays blank for a few seconds and then it reboots to the Initializing... prompt and goes into this loop.

Out of curiosuty, I port forwarded all UDP and TCP ports from the internet gateway to the 8IPLA's IP, and same thing happens. Connects, blank screen then reboot to initializing message on the phone.

I don't understand how the Dterm's IP protocol works, what ports it uses, and have no documentation for it so it's hard to figure out how to setup the forwarding. Also, we have no software to look at the 8IPLA card's configuration so we have to do a service call to try different things.

How safe is it to have our vendor reconfigure the 8IPLA to sit wide open on the internet side? I'm not comfortable with it but was told this may be the only way to get it working.

pstar;

the 8ipla card doesnt come into play as far as getting the phones connected as ip devices. the ipla card is for converting traditional telephony (tdm) to ip packets, and visa versa. all the ip dterms need to get 'logged on' is a connection to the DRS, which resides on the MP card of the IPS.

You say you can connect OK internally. Do users connect via a VPN client when off site, if so, does it have a 'STATUS FIREWALL'. I have had issues using softphones whilst running a VPN firewall. When turned off, it connected and worked 100%.

Good luck.

Also, the programming manual lists several ports that need to be open ... 8000, 10000, 58000, 58001 spring to mind off the top of my head.

Some routers have an issue with UDP. I'm not certain that I have it right, but after a transfer of UDP packets, there's a pause of up to 10 seconds before repeating the UDP transfer.

The VPN needs to have "tunnels" between ALL possible paths (i.e. if you have locations A, B and C, you need tunnels A=B, A=C, and B=C)

Best method for troubleshooting is to try back-to-back (i.e. in-house) then move out to the subnet where the router / firewall is, then from the "outside" of the firewall / router, then across the internet from the same site to the PBX, then from the remote site. This will help determine which piece of network equipment is creating the logjam.

Also, you're going to need to use a static IP address. The IP and Subnet info for inside the network won't work over the Internet. This may cause some problems.

One thing that is a concern: When I went to NEC training, the NEC instructor preached about the copy of MATWorX which comes with a new processor belonging to the end user, and not to the vendor. You may wish to check with your vendor and see if that is still the policy.

Does the DTerm have built in VPN functionality? If so it would make it much easier, as I could assign each phone a VPN account, connect, grab an internal IP from anywhere and it would be transparantly on the internal network.

Looks like the only way for home users to connect is for me to put together a VPN router so they would be on the same routable subnet as our internal network. Plug the VPN router to the internet, and plug the phone into the router. Painful but doable, and it makes it much more difficult for travelling employees that wish to work from the hotel room, as they will have to lug around more equipment.

Our vendor is contacting NEC for advice on how to set it up in our environment. Apparantly, they're having problems deploying the same thing within their internal network as well.

If the phones do need to be routable and connect to each other, then what really is the point of moving to IP phones other than slightly less wiring? You would think that the design would make it simple to just grab a phone from the office, go anywhere there's internet and be up and running without any troubles.

NEC has designed your IP fones for use w/ a hardware VPN only. With that being said, if you put your CPU and IPLA ethernet ports on a DMZ at your main office you can make your fones work offsite. I do not recomend this configuration because of obvious security issues. There has been alot of grumbling about the fone's inability to perform NAT and that should be supported soon.

The original idea of the IP phone was to allow teleworkers to work from home, on an established VPN. That would allow people to do tech support, ACD, and other functions from a home office.

If you don’t want to make a hardware VPN from your network to their house, you can get a SoftPhone and use a software VPN. The downfall with the SoftPhone is that it resides on the users PC. The benefit of the SoftPhone is that it is designed for the road warrior, you can put the software on a Laptop and they can take a "phone" with them wherever they go. They will have a designated extension if they are at home, in the office, or travelling. You will have to get the requirements needed for PC’s/Laptops to run the SoftPhones from your vendor if you want to use that option. Depending on the Software revision of your switch you might have seats available for SoftPhones, so you might not need to purchase seats, just the Software.