[RESOLVED] International call toll bypass

Hello everybody. I’m new on Asterisk and this forum!
I would need to know if this setup is possible with Asterisk:

A softphone in a remote country (say, Mexico)
place a voip call
to an Asterisk box (say, in Italy)
which provides the client a local (“italian”) dial tone
to place a “regular” pstn call.

I figure out that the Asterisk box has to be:
a) permanently connected to the internet and have a known, public ip address
b) connected to the pstn via a pci FXO card known to be compatible with asterisk
c) configured to automatically answer to the incoming voip call and connect it to the pstn
d) pass or “regenerate” the DTMF tones generated by the softphone and make sure they are understandable by the network

Are my assumptions correct?
Is this setup common or…“esoteric”?
Does it poses a fraud threat, eg. someone discovering this service up and running and placing free calls to the pstn? How can I mitigate it?
How much guaranteed bandwidth does it needs?

I would really appreciate your help.
Sincerely,
Qzu

Assumption a) is correct except: not the Asterisk-box has to know it’s public IP but Your Softphone-client has to know the Publiv-IP of the Asterisk-box (cn be achieved by any dyndns-Service if a Dynamic IP is in play at the Asterisk-side)

Assumption b) is one solution another one is the use of a Mediagateway like patton

Assumption c) is correct if the softphone should get an local dialtone, otherwise it*'s not necessary as the technologies (SIP and PSTN) could be seamless bridged by asterisk

d) is not necessary, it’s implicit.

It’s a standard setup of an Asterisk-Server with remot SIP-clients used e.g. by nearly all VOIP-providers (Retail as well as some Wholesale) worrkling with Asterisk

The installation needs to be “hardened” in a way, that the Asterisk-box only processes calls from registered clients. There are a lot of how-tos on hardening a Asterisk-server, You just may search for this in the net. A hardened server won’t permit anybody unregistered to place calls.

Bandwith depends on codec You’re using. Used codec is related to voice quality. Just asssume 80KBit/s in each direction (upload/download) per (parallel) call for alaw or ulaw codec (equivalent to digital subscriber line (BRI/PRI) quality)

You assumptions are correct. I think that this is not a “classical” deployement, but it should be fine. For every call you will need about 80kbps/80kbps for alaw/ulaw codec.

Just to go over your questions:

a) permanently connected to the internet and have a known, public ip address
This can be avoided with using VPN tunnels. If you decide on running Asterisk on a public IP address have the common sense to secure it very good.

b) connected to the pstn via a pci FXO card known to be compatible with asterisk
Yes - if possible use Digium hardware. You can also use a FXO-VoIP gateway instead of a dedicated card.

c) configured to automatically answer to the incoming voip call and connect it to the pstn
If you want to do this, you can implement this in the Asterisk dialplan.

d) pass or “regenerate” the DTMF tones generated by the softphone and make sure they are understandable by the network
Asterisk is not a SIP Proxy but a back-to-back user agent. So ““regenerate” the DTMF tones” is the correct method that Asterisk is using.

Thank you very much for the incredibly quick, complete and clear responses.
While trying to implement the solutions provided, I’ll mark the thread as RESOLVED!
Bye,
Qzu

  1. You would not normally let the caller hear the actual dial tone; they would normally have keyed the whole number before the gateway was even called.

c. It is normally bad practice to answer the incoming call before the outgoing call is answered, although it might not be important if there is no charging on the incoming side.

x. It is not a particularly unusual configuration. Lots of people have local SIP users that phone over the internet, as well as those using LAN connections. Doing it internationally is slightly more uncommon, but doesn’t differ in principle.

y. Follow the security best practices document - strong passwords, don’t use the extension number as the device name, restrict the allowed IP address ranges, etc.