TIPS Analog and VoIP, same device

[gandalf]

Hi everyone,

I have the following setup: a standard analog telephone connected directly to the landline/copper pair provided by the carrier. Calling and receiving work normally.

I need to route VoIP calls from my remote PBX to this phone (even receive-only is fine if that makes things easier), while keeping the direct analog landline fully operational.

If I use a standard VoIP gateway (ATA) and plug the phone into it, the phone becomes "digital/VoIP", but it won't work on the analog line anymore. Is there a device that allows me to handle both?

Thanks!

 

[kenn10]

The simple solution is to call forward the number on the PBX to the analog phone number. Depending on what country you are in, there is a good chance that you will soon lose your analog (copper POTS) line as all things are converted to digital service over fiberoptic to the home.

 

[gandalf]

But i need the opposite: i need to call the analog phone from the VoIP PBX.

My first thinking was to call transfer the analog number to the PBX, the PBX answer but then if I need to call the analog phone from the PBX, i can't because the number has a call transfer on it.

 

[fredzimm]

Something like a Grandstream HT813 might work.

 

[chris_c_]

I need to route VoIP calls from my remote PBX to this phone (even receive-only is fine if that makes things easier), while keeping the direct analog landline fully operational.

Setup the settings in your PBX, and decide under what conditions calls coming into the PBX, are to be forwarded to the phone number of your land line.

Unless there's something I'm missing.

 

[gandalf]

I cannot modify the customer's telephone line; my system needs to be as transparent as possible. Routing the number through my PBX would mean taking over the customer's phone number (via porting or similar processes) and then forwarding back to them the calls that I don't need to handle.
I need the exact opposite: everything native to the customer, easily bypassable, and with as little hardware as possible.
Let me give you a concrete example: I sell a VoIP PBX with a web-customizable IVR (Interactive Voice Response). X customers subscribe to the service. The quickest solution would be to forward the customer's number to my PBX and have my IVR answer. But this would make it impossible to send the call back (since the original number is forwarded, any call I forward back would get forwarded in a loop).
Some competitors do exactly this kind of forwarding, but they provide the restaurant with a VoIP phone connected to their PBX to manually re-route the calls that need handling. However, this only works for *one* phone; what if the customer has 4 or 5 phones they want to use? Forcing them to use my physical VoIP phone would result in a poor user experience.
The idea, therefore, was to use a Grandstream ATA; the call stays with the customer without forwarding, and the Grandstream makes both the customer's analog setup (one or more phones depending on their internal wiring) and my PBX ring in parallel. If I answer, the analog phones stop ringing, and optionally I could (in theory) perform an internal call transfer via VoIP.
However, this doesn't work with modern, locked-down VoIP lines from ADSL operators. In that case, forwarding might be the only solution, but it still comes with the single-phone problem described above.
Any better ideas? As little hardware as possible at the customer's premises, a maximum budget of 80 to 100 euros, and preferably capable of making all existing phones ring in case I send the call back.
Crucially, it would be best—either via the same device or at most an extremely cheap external one—to be able to send the caller ID to my server in any possible way: via SIP INVITE in the case of a VoIP ATA, an HTTP request, or whatever works.

 

[Samot]

I cannot modify the customer's telephone line; my system needs to be as transparent as possible. Routing the number through my PBX would mean taking over the customer's phone number (via porting or similar processes) and then forwarding back to them the calls that I don't need to handle.
I need the exact opposite: everything native to the customer, easily bypassable, and with as little hardware as possible.
Let me give you a concrete example: I sell a VoIP PBX with a web-customizable IVR (Interactive Voice Response). X customers subscribe to the service. The quickest solution would be to forward the customer's number to my PBX and have my IVR answer. But this would make it impossible to send the call back (since the original number is forwarded, any call I forward back would get forwarded in a loop).
Some competitors do exactly this kind of forwarding, but they provide the restaurant with a VoIP phone connected to their PBX to manually re-route the calls that need handling. However, this only works for *one* phone; what if the customer has 4 or 5 phones they want to use? Forcing them to use my physical VoIP phone would result in a poor user experience.
The idea, therefore, was to use a Grandstream ATA; the call stays with the customer without forwarding, and the Grandstream makes both the customer's analog setup (one or more phones depending on their internal wiring) and my PBX ring in parallel. If I answer, the analog phones stop ringing, and optionally I could (in theory) perform an internal call transfer via VoIP.
However, this doesn't work with modern, locked-down VoIP lines from ADSL operators. In that case, forwarding might be the only solution, but it still comes with the single-phone problem described above.
Any better ideas? As little hardware as possible at the customer's premises, a maximum budget of 80 to 100 euros, and preferably capable of making all existing phones ring in case I send the call back.
Crucially, it would be best—either via the same device or at most an extremely cheap external one—to be able to send the caller ID to my server in any possible way: via SIP INVITE in the case of a VoIP ATA, an HTTP request, or whatever works.

Why must you keeps the POTS line?

 

[phonebuff]

However, this only works for *one* phone; what if the customer has 4 or 5 phones they want to use? Forcing them to use my physical VoIP phone would result in a poor user experience.

Don't see it. Unless you are on top of the exchange, VoIP is most likely going to give the end user a better experience with more opt-ins for fewer dollars.

You could drop a number of physical VoIP phones or a DECT Phone Adapter and x number of handsets. In either case these appera as Extensions not Phone lines in your PBX. Then the Calls to the Property go to a Ring Group or to specific extensions as needed. If they want, they can just cancel the forwarding to turn your service off. The only other option I can think of is to get an ATA with both FXO and FXS ports and be sure that the FXO can be bridged to the FXS without your iPBX.

SNOM - SIP DECT 4-Line Base Station Mfr # M100-KLE. As an example.

 

[gandalf]

because, as wrote, i do not own the customer telephone infrastructure. and it must be kept as is

mine is a plus, a service that i sell, if i have to change the customer telephony, n9one would purchase the service

i have to do in the most clean way

 

[gandalf]

you are suggesting expensive devices, or multiple devices. less hardware i put, better will be the adoption of my system

the customer telephone line/infrastructure must be kept as much as possible untouched. (also, less hardware sold by me were i have to provide warranty or support)

 

[gandalf]

Don't see it. Unless you are on top of the exchange, VoIP is most likely going to give the end user a better experience with more opt-ins for fewer dollars.

because 2 phones are more expensive of one, and more hardware to maintain for me, that's why my competitors only offers a single device. to keep costs low and reduce the hardware to maintain

 

[atsak]

To take an analog line and deliver it via SIP you'll need an FXO adapter. Yeastar and Grandstream make one.