# # IP telephony- No training
APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

IP telephony- No training

I've removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.



Some material is very old and may be incorrect today

© May 2004 Tony Lawrence

Mon May 17 16:31:06 GMT 2004 IP telephony- No training

I had a client install an ip phone at a remote warehouse today. It was a frustrating experience for all concerned, and the frustration came because the phone guy really had no concept of tcp/ip and networks. Of course, I have no idea how his equipment works either, but maybe between us we could get there.

He knew enough to ask for port forwarding and for internal ip addresses. I gave him the addresses he'd need at both ends, and set the port forwarding as he indicated. As expected, it didn't work. Well, that's what I expected, anyway. Call me jaded, but it's rare to find any of these people with a genuine clue. Nice guy, and it's not his fault that nobody bothers to explain ip basics to installers.

Well, after a bit of a struggle, I realized that he had programmed his remote phones to access the internal ip of his phone card. What would be the point of port forwarding, I asked. He had no idea what I meant. I tried to convince him to change them, but he said "No, that doesn't work, I get the customer's web page!". Huh? Turns out he's configuring the main card with a web browser using a machine that has a pptp vpn connection, so of course he could use the internal address for http. I tried explaining to him that his ip phones did NOT have a pptp vpn connection and therefore needed to use the external ip - which is why we did port forwarding. No comprehension. "But I need to access the internal machine". Sigh. Yes, and that's why I did the port forwarding for you. "But I can't use the browser!". Right, we're not forwarding port 80. "And I can't ping!". Right, ping is icmp.

Finally convinced him to make the change and it ALMOST worked - the devices saw each other, but he had no audio. He had happened to mention that port 5004 was the audio port, but had said it was tcp. I asked if it might be udp.

"It's not either. 5566 is tcp, 5567 is udp". Oh, ok.. I added a udp forward for 5004, and asked him to try it again. Of course, it now worked. I told him to remember that 5004 was udp (or maybe he needs both; I didn't tear down the tcp rule) so that the next job doesn't have to be so confused. He said he would. That's helpful, and as long as the expenses from our ignorance are less than the income from our knowledge, we all make out fine.

If you found something useful today, please consider a small donation.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

->
-> IP telephony- No training


Inexpensive and informative Apple related e-books:

Take control of Apple TV, Second Edition

Take Control of OS X Server

Take Control of Numbers

Take Control of Upgrading to El Capitan

Take Control of Preview





More Articles by © Tony Lawrence





Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us


Printer Friendly Version





C++ is just an abomination. Everything is wrong with it in every way. So I really tried to avoid using that as much as I could and do everything in C at Netscape. (Jamie Zawinski)




Linux posts

Troubleshooting posts


This post tagged:

Blog

Networking



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode