Using T.38 termination with Eutelia provider could present a scenario where you can receive faxes using g729, but not being able to receive it, even if you are able to receive it while using  alaw.

It might be the case that the remote endpoint, Eutelia, will need to detect the Fax Tones and send the T.38 ReINVITE to you, they may not have T.38 enabled. If that’s the case, your Asterisk installation will need to detect the Fax Tones so as to make the decision the incoming call is a fax and then switch to the fax extension. For Asterisk to detect the Fax Tones you will need to set faxdetect to either yes or cng, you will also require using alaw or ulaw codec.

It might be suggested that you configure your incoming calls from Eutelia to go directly to the fax receive function whilst having the g729 codec enabled, I expect you will then see T.38 re-invite come from Asterisk. (more…)

These are the instructions to configure OpenVPN + SIP configuration, based on a brainstorming discussion of the Asterisk Users Mailing List.

The server is running on a uClinux appliance, with /dev/net/tun, and OpenVPN is 2.0.9. The clients will be Windows hosts connecting through Ethernet in hotels or public wifi hotspots.

1. Install OpenVPN on Asterisk server. On appliance, there’s only a single binary /bin/openvpn, and configuration files are in /etc/openvpn/.

To be positive SIP/RTP packets go through the OpenVPN tunnel, make sure the firewall in front of the OpenVPN/Asterisk server only has OpenVPN port open (default: UDP 1194).

2. On client, from http://www.openvpn.net, download and install OpenVPN for Windows, which includes Service + GUI

3. If using an appliance with just the openvpn binary, use a workstation to install the OpenVPN package and create certificates + keys: apt-get install openvpn (more…)

Last Updated: 14-March-2013

If you are about to dive into the process of virtualizing some of your Asterisk infrastructure then some primary issues might be preventing you from moving (e.g. the lack of proper timing as you need it for IAX2 trunking). If this is your case, consider these options and the pro and cons of each one:

• OpenVZ - Better resource usage, lower overhead. Primary issue is how to grant access to host node timing source (physical device, or dahdi_dummy in /dev/dahdi/) to the containerized Asterisk process.
• KVM - Higher overhead, easier installation, ‘true virtualization’. Primary issue is not timing per se, but KVM scheduling. Timing source, while present from dahdi_dummy natively may still not get proper scheduling by KVM process. This could also affect general call quality (even non IAX2 trunked voice), DTMF, etc.
• VMware – They are moving all server products to their ESXi engine. (The old VMware “server” and ESX products are moving to legacy status – with these you could actually do stuff on the kernel). ESXi is no longer a kernel you can mess with, can’t install drivers, etc. ESXi is being treated as an appliance that you cannot and should not touch (even authorized partners like HP only get to add software through VMware). Many of these devices are not (and will not be) recognized by the VMware kernel, so forgot about host support. At best you can pass-through the device to a single guest, but then you lose the whole point of a shared timing source.
• XEN - Virtual machines can use both hardware- or paravirtualization. It has been used to separate machines where people should do their sip-registration (internet / intranet /
  pstn-gateway) and the actual dial-beast.

In order to take the most out of virtualization besides easy scaling and ability to perform an upgrade in no-time, upgrade to the latest version of Asterisk, as it has a newer timing source that don’t rely on Dahdi and a complete rewrite of ConfBridge which doesn’t require Dahdi for mixing at all.

What things do you wish you had been warned while configuring Digium Cards at client’s site? These tips and suggestions will help you avoid pitfalls that will arise (according to Murphy’s law) late in the night and when you have the bigger pressure to have the whole thing working.

This information is based on a brainstorm that was raised in the community user’s list.

Information you should ask for:

• What are the Ts configuration settings? You could try to get an order form from the client.
  • Line coding (ami, b8zs, hdb3)
  • Framing (d4/esf, cas, ccs)
  • Jack type (RJ48X, RJ45)
  • ISDN protocol (NI2, etc.)
  • Primary D-Channel assignment
• What’s the relationship between the Ts? NFAS ?
• Will a telco’s tech who can make changes be available for you by phone?
• Willl you be receiving digits, if so, how many?
• How will CID be configured?
• How they want you to send numbers on outgoing calls, do you need to insert the STD code even for a local call?

Things you must take into account:

Reminders you might found useful:

• The dahdi program dahdi_genconf creates 2 files:

1. /etc/dahdi/system.conf
2. /etc/asterisk/dahdi-channels.conf

The latter is the one that maintains the configuration for asterisk. File chan_dahdi.conf is where the configuration is maintain, you will need to have an

at the start of chan_dahdi.conf, otherwise it will never be read. Else you can type the configuration yourselft in chan_dahdi.conf

There are no contexts ( [XXXX] ) in chan_dahdi.conf, so you have specify the characteristics and then specify the channels the characteristics apply to.

results in channel 1 having foo and bar while channel 2 has foo and baz.

Lastly, get sure to bring caffeinated beverages with you, as it will help you keep sharper focus.

In order to set up a user in Asterisk so that It can register via sipml5, on Asterisk 11. In the sip.conf entry for the account you are trying to register as place the following:

Example:

Now, modify the sipml5 library so that the URL looks like this: ws://example.org:8088/ws (with the /ws at the end, as instructed). In order to get sure that the 8088 port is open, and that Asterisk is actually listening for WebSockets traffic, remember to enable the http.conf module: