Internet Telephone

Does a simple Internet telephone interface exist?

I think perhaps not, or not at a cost less than $200.

Google finds plenty of devices, but most have complexities I just don't want.

Let me explain and specify what I'd like.

I'd like a device, probably not much bigger than a USB memory stick, which has just three connectors. Power, RJ11 and RJ45. A POE option might also be useful which would leave the power connector unused.

RJ11 connects to a standard telephone.

RJ45 connects to the Internet, either directly to a modem or through a NAT router.

Using two of these devices, with each device at a different location, I can talk to someone, just like a telephone call, who has their device connected to a standard telephone and also to the Internet.

The device will get its IP address using DHCP and perhaps light up a green LED when it's successfully obtained an IP address.

When I make a phone call I make it to a remote IP address not a phone number.

The destination IP address has another identical device connected to the Internet and to a standard telephone.

To keep it simple, the device is configured via the telephone keypad and might reply with one beep when a command is understood and actioned or with two beeps for WTF do you mean?

I might use a key sequence like ###123#124#125#126##200* which means make an outbound TCP/IP connection to a remote device where the remote device is at

123.124.125.126 and is listening on port 200. Another green LED might light up when the TCP/IP Internet connection is successfully established between two devices.

The remote destination device might be configured with a key sequence such as ##200* which means listen for an inbound connection to port 200. If the device is behind NAT then a port will also have to be forwarded in the NAT router.

Other key sequences might be provided for lesser used configurations such as static IP and lockout of further configuration until reset.

Whether the configuration is retained without power depends on cost.

No complicated http configuration interface is wanted or needed but a recessed reset button would be useful to wipe all existing configuration.

Encryption is not required. If you want encryption then make a VPN between two routers.

Another useful feature might be the ability to connect one of the devices to a phone line rather than a telephone. Then my home phone can be used anywhere in the world if my remote device can establish a TCP/IP connection to my home device.

I've been doing a lot of Googling on this and found the Tiger560B but I want a device directly online, not via a computer with all the software complexities that requires. Keep the software to 8051 complexity level if possible then I can maybe write it myself. Google found other chips which could perhaps be used together to almost complete the picture. The WIZnet W7100A is nice but the serial interface, if it's fast enough, isn't going to be directly compatible with the MC14LC5480 which might then connect to a CPC5622. Perhaps the serial interface translation, a DTMF decoder, a configuration reply beep generator, and any remaining glue logic can be put in a custom chip.

There are likely to be many things I haven't thought of. Some of which might mean it isn't feasible. One possible problem is how do you know a call is coming in? Is it feasible for the device to be able to make the connected phone ring? Something tells me that this might require a transformer which makes the device a bit bigger but perhaps not too big.

Reply to
John Smith
Loading thread data ...

If you're eskert of anything too complicated to run on an 8051 then you may as well lay down the project now.

You don't need a transformer to make a phone ring. For most electronic phones you can just drive an interrupted 24V to the phone and get it to ring, but for an old electro-mechanical ringer you really need that good old 100V RMS 20Hz business.

I think it's quite doable, even with the ringing, but not unless you're happy with playing with TCP/IP stacks and other Ethernet fun stuff.

--
Tim Wescott 
Control systems, embedded software and circuit design 
I'm looking for work!  See my website if you're interested 
http://www.wescottdesign.com
Reply to
Tim Wescott

...

Ok. Let's say my phone line interface uses a CPC5622. To get 24V the device will either have to be powered from 24V or convert a lower voltage rail up to a suitable 24V. There may be further complications if I want it to be connectable to a phone line as well as a phone.

I'm happy playing with TCP/IP but I'm not likely to code a TCP/IP stack myself. To have any chance of doing it myself I'd have to use the WIZnet W7100A.

Thanks for your reply.

Reply to
John Smith

MagicJack. Ok, so it's USB, but you could insert an MCU with USB and Ethernet inbetween, assuming you can get all the drivers and usage rights to do it this way (maybe talk to MJ themselves about realizing the full thing?).

Putting all the interface at the handset side seems rather ambitious, but it would be easy enough (relatively speaking) to put a voice interface in there. "Press 1 to configure your D.H.C.P. settings, press.." Or, ehh... :^)

Or it already exists and I simply don't know, because I don't shop around for this kind of thing. :P

Tim

-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website:

formatting link

Reply to
Tim Williams

...

I think it might be cleaner to use an isolated ringing circuit such as the transformer coupled one on this page.

formatting link
I think it would have to be disconnected with a relay when the phone picks up. The complete device could then be powered from 12V DC with a switcher for whatever the chips need.

If I want to make further progress I think the CPC5622 evaluation board is needed.

Reply to
John Smith

Yes I found them on my Google travels. If it has to have a USB bridge then Tiger560B is also an option.

Google hasn't found anything close to my exact requirement although there may be some very expensive boxes which can do that and a lot of other things. This surprised me a little but maybe it's because although the average person is familiar with phone numbers, doing things by IP address is another matter, and few people have a static IPV4 address.

Thanks for your reply.

Reply to
John Smith

Vonage, maybe?

There's even a mobile phone app for Vonage that allows you to place a call while using wifi through your mobile phone. It came in really useful when placing calls to the US cheaply while I was vacationing in Asia.

Michael

Reply to
mrdarrett

[Sorry for not trimming your post but thought it easier to keep it intact as I "revise" your thoughts...]

Two devices:

- (1) one that lets a phone tunnel over IP to another phone ("somehow")

- (2) another that lets a phone *line* tunnel over IP (to "whatever")

To start, google "FXO" and "FXS"

(1) is called an Analog Telephone Adapter. It allows a "regular telephone" to connect to an IP network. (It also includes protocol implementations to move voice and signaling information across the network; how compatible those are with your needs is a different issue...)

(2) is called a VoIP gateway. It allows a "regular phone line" to connect to an IP network. (same caveats as ATA, above).

I.e., to convert your business phone system to "digital", you would run CAT5 to every phone, install an ATA on the end of the cable and plug the POTS "telephones" into those ATA's. A server on the network would allow these "phones" to talk to each other (i.e., intra-office intercom)

Your PSTN "trunks"/lines would terminate in VoIP gateway(s) which would be serviced by that same "server".

So, the PSTN is accessed VIA THE VoIP SERVER in much the same way that any other "telephone set" INSIDE your business was accessed (the server would move packets between these "endpoints" to effect calls -- intra-office, office-to-PSTN and PSTN-to-office)

How "standard"/interoperable you want to be is a separate issue.

If you want to talk to a "traditional" phone and plan on driving 1 REN, then you need to be able to deliver ~1W at ~90VAC/~20Hz to the station set during the ring cycle.

You'll need to supply a talking battery of ~40V.

You'll need to be able to decode DTMF as well as count "load drops" (breaks from dial pulses).

You'll need to deal with the idiots who think they can cleverly add a splitter and plug *10* phones into your little jack.

Etc.

(The point I am making is that you may *not* want to deal with "traditional phones"!)

PoE requires a fair bit of real-estate and volume. You're taking a nominal 48VDC supply and regulating it down to 3-5V for your "brains" and *up* to 90VAC for ring current, etc.

[The alternative of trying to steal power from the PSTN is frowned on]

Instead, for (1), why not consider using a smartphone or some other wireless device for the "handset"? "Talk to it" over BT or WiFi, whatever is more common (I don't use a cell phone so can't offer an opinion, there). This also opens up the possibility of putting some of the smarts/features/application *in* the smartphone ("There's an APP for that!"). Let the phone TELL the "black box" what needs to be done...

(2) is a bit harder because it has to deal with the PSTN (FCC, etc.) The hack-ish way of doing this is with an old-fashioned (e.g., 57K) modem "with voice capability". Let it be the (certified!) interface to the PSTN and you just move data to and from *it* (that data potentially including digitized voice).

Interfacing to the device depends on what the UI hardware looks like. E.g., if using a smartphone, then you can draw pictures of dancing bears or flying toasters or...

If you want to resort to the original "telephone" concept, consider using the dial/DTMF keypad for user "data entry" and *voice* prompts/feedback (if you can move audio to/from the phone and the network, then you can move *synthetic speech* just as easily -- even if it is *canned* speech.

(sigh) Lots of other options, depending on what you actually choose to pursue. I've been exploring the VoIP gateway design for use, here -- mainly as a way to interface to the PSTN *as* a "telephone" (both for incoming and outgoing).

Time to eat...

Reply to
Don Y

For VoIP, no. The industry is a maze of acronyms and buzzwords that have sent friends and competitors screaming for help. Don Y. gave a good explanation of the major terms, but under the covers are hundreds more. That which you do not understand, will turn around and bite you.

Not necessarily. The other end is usually an Asterisk phone switch.

The SIP protocol allows for dialing directly by IP address as you describe, but that only works if you know the IP address. Fortunately, there are acronyms to take care of that such as a STUN server: and various redirect servers and proxy servers which translate a domain style dialing address into a reachable destination. For example:

It's called SIP URI dialing in the form of: SIP-URI = sip:x@y:Port where x=Username and y=host (domain or IP). The default port is 5060. I have static IP's in both my home and office, so I don't need a directory server or a SIP broker, but to make it easy, my VoIP PSTN provider provides the service. You can call me from any SIP phone at something like (the phone numbers are intentionally mangled): or direct at: I sometimes use these to direct connect between two SIP phones, but prefer to use a SIP broker:

The remote destination of a SIP phone usually listens on port 5060 or

5060 thru 5063 for a 4 line phone. Port numbers under 1024 are reserved for system services.

You just described most of the low end devices, such as the Linksys PAP2t, Linksys SPA3102, Cisco SPA112, etc. They can all programmed from the keypad or once an IP address is assigned, from a web browser. For example, for Vonage:

No kidding. I have a few Linksys (Sipura) SPA941 and SPA942 phones that have no way to save their seriously complexicated settings to a file. The logic is that the office in which the phone live will have a TFTP server with saved configurations on it. When a phone powers on, it looks for the TFTP server, logs in, and downloads its configuration by MAC address. Works nicely, but is overkill on small systems.

Huh? Punching keypad buttons is somehow easier than a web based configuration utility? I don't think so. Methinks you should reconsider that requirement. Such devices are only programmed from a phone keypad in desperation when no computah is available.

Also, reset buttons are nice, but far too easily abused by customers and support personalities who's standard answer to all problems is to clear all the settings. Incidentally, that's also Comcast's answer to all problems with their "gateway" boxes, where a reset blows away all my custom settings. Their boxes have no official way to save any settings even though it's fairly trivial for their NOC to do it via SNMP.

SIP and most VoIP involve voice compression. Once you have compression, adding encryption is fairly simple. However, that's usually not done, leaving encryption and security in the hands of the vendors and users using either SIP over TLS or SRTP. VPN's have a high overhead and will add enough latency to make it difficult to talk. 150 msec maximum end to end one-way latency.

I did that when I want my office phone to also ring at home, and when I want to make calls from a hotel and not pay their sky high prices. I still do that for the hotel problem, but for ringing in more than one place, I have "simultaneous ring" or "concurrent ring" from my VoIP provider(s).

With SIP, an incoming call is just a few SIP packets instructing the instrument to make noises. You can even by stand alone SIP ringers that can put plugged anywhere on the network and sniff for ringer packets:

Yes. Power for the ringer is built into the IP phone or into the FXS. In the IP phone, it's all internal in the phone. In the FXS, it generates the usual 20Hz and 70Vrms (no load) ringer signal. Note that not all FXS boxes have a ringer output. Some just close a relay contact.

Yep, probably needs an xformer. I'm too lazy to open up one of my FXS boxes and see what's inside. The PAP2t photo doesn't show any ring generator xformer: Ok, I don't know how it's done. I'll probe it with a scope when I have time and see what I find.

Enough for now. I'm not getting anything done tonite. I think you need to read up more on what's currently available, what protocols are in use, what services are already in place, and how the financial end of VoIP operates. Once you determine what the product is suppose to do, how it's to be sold, and how to make it profitable, then you can discuss the fun part of the project (design). Good luck.

--
Jeff Liebermann     jeffl@cruzio.com 
150 Felker St #D    http://www.LearnByDestroying.com 
Santa Cruz CA 95060 http://802.11junk.com 
Skype: JeffLiebermann     AE6KS    831-336-2558
Reply to
Jeff Liebermann

"Don Y" wrote in message news:np0b9r$s4j$ snipped-for-privacy@dont-email.me...

No problem, I'll trim it for you for my reply.

Already had, but most of the devices I found were either fairly complex, no longer available, or very expensive. I don't necessarily have any problem configuring such devices and setting up IP networks if I put my mind to it, but what I had in mind was a device designed simply for a two way conversation between a home or small office and a remote location using existing easily available telephones.

That's part of the problem. I didn't find anything simple which was compatible with my needs so I started researching how hard it might be to make one or have one made.

I'm sure there are plenty of devices available to do just that, but I found none to do just the simple thing I wanted.

It crossed my mind that a variation of the device I want, or want to make, could form the basis of a very flexible LAN based company office phone system which is initially compatible with existing telephones. Each device would have an extension number. Now we need to map extension number to LAN IP address. How about local DNS. Lookup 12345.somelan.com. and get the LAN IP address of the device for extension 12345. Reverse DNS lookup tells you your extension number. Each device can make multiple TCP/IP connections so conferencing and all kinds of other phoney things shouldn't be hard. Connection to an external line uses exactly the same device and it can probably figure out for itself that it's on a line rather than a phone by the presence of the line voltage or by a DNS lookup which returns line1.somelan.com. If you have two or more outside lines then you just need two or more devices between the lines and the LAN. All devices get their LAN IP address from the LAN router or server. It's true that home grade routers don't usually do LAN DNS but they do if you put DD-WRT on them. The phone devices can query the line devices to find out the status of the outside lines. When you want to upgrade the phones just use phones with the device built in. These phones connect directly to the LAN and may have more capabilities with better keyboards and maybe displays. There are probably many things I haven't thought of, such as how an incoming call knows which extension to go to, so I'll leave that there.

For my device I think it's ok to specify that you can only connect one phone and it should be a reasonably recent phone not something from the 70s or earlier. Pulse dialing is not required.

True, but what if I do? :)

True, I can probably do without POE if it adds too much complexity and cost.

That crossed my mind too but it seemed reasonable to assume that it wouldn't play well with rules and regulations if this ever became a commercial product so I dropped it.

Although I do have a cell phone, the device I want should preferably not have anything to do with cell phones. One reason is because it might be used by a senior person who is comfortable receiving calls on what appears to be a standard telephone.

Yes there are certainly lots of options, perhaps too many where VoIP is concerned. It's likely that the exact device I want will never exist, unless I win a lottery. Then I'll get Tim Wescott to do it for me.

Time to sleep.

Reply to
John Smith

That was immediately apparent when I started Googling anything to do with VoIP. Like swimming in treacle is one way I'd put it. That's one reason why I had thoughts of a simple device which did only what I wanted to do and without any of the other seemingly (to me) unnecessary complexity.

With regard to http configuration interfaces versus keyboards, I prefer no such configuration at all when possible. After all, standard telephones don't have http configuration interfaces, they just work. See my reply to Don Y.

Thank you for your reply. I have read the rest of it. [polite snip]

Reply to
John Smith

Hardware sounds like a standard ATA. Firmware modified to behave a bit differently. They're like $60 at the moment.

Without some kind of central server, or static IPs (IPv6?), making contact with the remote device might be an issue.

--
Best regards,  
Spehro Pefhany 
Amazon link for AoE 3rd Edition:            http://tinyurl.com/ntrpwu8
Reply to
Spehro Pefhany

What is it about the MagicJack that you can't tolerate? Current versions like USB for initial configuration, but after that, all you need is a phone, power supply and an internet connection. I used one for home phone for years without issue. There's an android app that lets you use the phone from your smart phone. Costs $35/year per device for the phone number. You used to be able to connect between magic jacks without paying for a phone number, but not sure it's still available.

If you want point-to-point communication for free, there's an ancient windows app called picophone. Type in the IP address of the other end and you're on the phone. I use it all the time with windows7 and a pseudo-fixed ip thru mooo.com

Reply to
mike

DynDNS.

Or, the way I sort out *my* current IP remotely: email a message to yourself with your IP in it. Retrieve your email from wherever you happen to be. See what the most recent message claims your (home) IP to be.

[You can do similarly with any other "resource" that you can access "from abroad". E.g., a dropbox account, open FTP server somewhere, etc.]

Doing this for a *community* means someone has to take it on as a formal responsibility...

Reply to
Don Y

Don't bother, It's practically worthless IME. Dropped calls, calls that never make it through, and useless support.

Reply to
JW

I think yes, I paid less than $80 for a full featured internet telephone made by Grandstream (an el-cheapo brand).

It looks like a business telephone and has an ethernet connector, can do the things you describe there.

However, for full functionality it is recommended to use a PBX. This can be as simple as a pre-built Asterisk running on a Raspberry Pi.

Reply to
Rob

Where can I find one?

That's why I think the device I have in mind wouldn't have a big market, but still a market for those who know what an IP address is.

Reply to
John Smith

There is this new site at URL

formatting link
where you can enter some search words and it will give you a list of results matching those words. Try it! It works really well.

I entered "voip ata" and it gave me all kinds of matching devices, including the Linksys (now Cisco) devices we use to connect Faxes to the VoIP PBX.

Reply to
Rob

The commonest off-the-shelf implementation of this sort of thing, easily available today, includes:

(1) Either "analog telephone adapters" which support the SIP protocol, or VoIP phones with the SIP support built right in.

These are (universally I believe) able to get their IP addresses from a DHCP server on the LAN.

Plenty of vendors and choices.

You can also run SIP clients (there are many) on most smartphones and tablets, as well as on PCs and notebooks.

(2) A SIP server. This serves as a central switching "hub" for the phones in one or more physical locations. Individual SIP ATAs or phones will 'register' with the server when they boot.

You can run the open-source Asterisk SIP server on an old PC, or on a Raspberry Pi, or on a higher-end home router running DD-WRT.

In many cases, Asterisk will be "in the loop" for call setup and management, but "out of the loop" for the actual flow of media (voice) packets between the phones. With this setup you can handle quite a lot of calls/extensions using a very-low-end processor.

(3) Optionally, one or more accounts with a VoIP telephony provider, which provides a gateway between the PSTN and your SIP network.

With this sort of setup, you can make calls between phones in the same or different locations by just dialing an extension number. Asterisk maps the extension number into a SIP client identifier, via its flexible "dialplan", so the callers don't need to know the callee's actual location or IP address or host name.

Other extensions or numbers can be routed to a SIP server at another location (e.g. another office) which then does its own routing of the call to one of its registered SIP clients.

"Outside" phone numbers can be routed to the VoIP provider, who then switches them to the public telephone network. You can buy one or more phone numbers from such a provider; they'll accept calls for those numbers and route 'em to your SIP server, for delivery to one of your extensions, based on your in-house dialplan.

I've run a setup like this for the best part of a decade... Asterisk running on the small PC I use as a home firewall/webserver/mailserver/ etc., a couple of ATAs to connect to old-style analog phones in the house, and a variety of SIP softphone clients (e.g. my laptops, cellphone, etc.) and VoIP desk phones. I have an account with Vitelity (a VoIP provider) to handle outbound calls, and several registered phone numbers for various personal and business services.

If you really want a stripped-down "server-less" client device, the hardest part is probably the "interface to analog phone" electronics... the voice hybrid and (especially) the ringer drive.

Everything else could be done with something akin to a Raspberry Pi or Beaglebone Black or a C.H.I.P (and these are all gross overkill, processing-power-wise!) and a modified version of some existing SIP client libraries and a user-interface "skin".

I suspect you could probably port an existing SIP client library to one of the higher-end Arduino or Teensy platforms.

If you're willing to give up the ability to connect to an existing analog phone, and instead use a PC-type audio jack/handset and a piezo ringer, then you could probably get started tomorrow for under $20. I rather suspect that the C.H.I.P. has at least one SIP client in its application library already... and if not, building one from source would be pretty easy.

Reply to
Dave Platt

But, what can it do "just by itself"? It was my understanding (various VoIP protocols involved) that you really need a server somewhere (and QoS guarantees on the fabric involved) to have a useful "endpoint"...

I.e., can *you* "call" someone with that GS ATA? What are the prerequisites involved?

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.