Panoramisk / The VoIP druid 

On peut être passionné par la téléphonie et prendre soin de soi : "Faites du sport, faites du vélo" est la devise du site d'e-commerce lancé par l'un des auteurs de Panoramisk : bikeo. Si vous faites du vélo, que ce soit en ville, sur la route ou sur les chemins plus accidentés, n'hésitez pas à aller faire un petit tour sur www.bikeo.fr pour vos prochains achats verts.
En plus leur plate-forme de téléphonie utilise Asterisk, comme quoi on peut la convergence est une réalité.

In order to enable voice call exchange between two PBX the straightforward protocol to use is SIP. It can allows device interconnection, regardless of their respective role, phone, proxy or gateway. This article explains how simply interconnecting two Asterisk PBX and could be used as a template in order to configure a SIP trunk between an Asterisk PBX and any other one available on the market.

There is a separation by design in Asterisk between in-bound and out-bound calls. An in-bound call requires to be accepted by the SIP stack and oriented towards an call plan context. On the other hand, an out-bound call, the Dial application requires either a specific profile in the SIP configuration or a registration to the counterpart. We use registration when our IP address is dynamically allowed and can change, thus mainly for IP phones.

Context

The main complexity for SIP trunking configuration in Asterisk is the role of each parameter in the sip.conf file. In order to illustrate this article, we will use two Asterisk servers called respectivelly asterisk-lyon et asterisk-paris. They are both using a static IP address and sharing the same IP network (no NAT in the middle to interfere with the SIP protocol). In order to exchange calls between Lyon and Paris, we have build prefixes in our dial plan, 91 is used to call Lyon and 98 to call, the routing is really simple.

Simple configuration

To start with, we need a configuration to allow calls to flow from Paris towards Lyon. The configurations on both servers are the following, in sip.conf :

[trunk-lyon-paris]
type=peer
host=asterisk-paris
context=from-asterisk-paris

[trunk-paris-lyon]
type=peer
host=asterisk-lyon

In the dial plan (extensions.conf) the call is leaving Paris with the following:

exten => _91.,1,Set(CALLERID(num)=98${CALLERID(num)})
exten => _91.,2,Dial(SIP/trunk-paris-lyon/${EXTEN:2},20,rt)

In order to respect our multi site dialing plan structure, we modify as the first action the caller identifier by perfixing it with the Paris prefix (98).

The Dial application is directeing the call to the SIP trunk named trunk-paris-lyon, defined in the sip.conf file between [ ]. The trunk type is set to peer since we want to direct calls towards a specific IP address, defined in the host parameter, here set to asterisk-lyon (see DNS or host table for resolution).

When a call needs to be established, a SIP INVITE message arrives on the Asterisk based in Lyon. Asterisk looks in the SIP database for a profile which can accept this call, the IP address is used as the discriminator. The asterisk-paris profile match this requirement. The next action is to direct the call to the specified context and look for an extension match.

Call on the reverse path

Now that a call can be placed from Paris to Lyon, we need the reverse configuration in order for Lyon to be able to call Paris. Required modification to our configuration are in bold below:

[trunk-lyon-paris]
type=peer
host=asterisk-paris
context=from-asterisk-paris

[trunk-paris-lyon]
type=peer
host=asterisk-lyon
context=from-asterisk-lyon

In Lyon we also need a specific set of action to allow a call, prefixed by 98 to be routed towards Paris:

exten => _98.,1,Set(CALLERID(num)=91${CALLERID(num)})
exten => _98.,2,Dial(SIP/trunk-lyon-paris/${EXTEN:2},20,rt)

Authenticated SIP trunk

It is sometimes required to authenticate calls routed from one PBX to another. Most of the time the main point is billing or tracking calls. Authenticating each call acts as an approval for the associated fees or constraints. Keep in mind that configuration is at the PBX level and not at the phone level and is not as strong as what we can do with X.509 certificates. Authentication for SIP is using a digest exchange and MD5 as the signature, therefore the secret exchanged between both entities is never exchanged in clear over the network.

Authentication is based on login and password validation. The password is called secret in the configuration and login is called username. The username is not mandatory and can be derived from the configuration, but specifying it is clearer and easier to troubleshoot in case of. Configuration changes are availabe below:

[trunk-lyon-paris]
type=peer
host=asterisk-paris
context=from-asterisk-paris
username=trunk-paris-lyon
secret=strong_password

[trunk-paris-lyon]
type=peer
context=from-asterisk-lyon
host=asterisk-lyon
username=trunk-lyon-paris
secret=strong_password

The coloured parts should match in both configurations.

Conclusion

A SIP trunk between two Asterisk PBX is as simple and allows to easily expand the IP telephony network. Interfacing an Asterisk with any other SIP PBX will require something similar, this is the case when connecting to an IP telephony provider. We will see in another article how to take care of the NAT issues and the impact on Asterisk configuration and the network infrastructure.