Panoramisk

Annonce

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é.

Asterisk and voice transport

Since telephony transport is digital, we do transport separately voice and signalling. Each domain should be efficient in different places, performances are different and the way providing service has been adapted on specific architectures and machines. The purpose of this article is to explore how Asterisk fit with regards to these two domains that have been kept for telephony over IP.

For private telephony, that can be from home to enterprise, signalling and voice transport functions are separated from a functional point of view, but some times they are tied together inside the same machine, let call it a PBX. This is mainly the case for solution provided by the manufacturer of legacy voice systems. The new entrants, mainly arriving from the data side, generally separate functions on different machines, more specific and able to scale with customer need.

In the Asterisk world, by default the two functions are linked together; further more calls are forced to flow on the same path as signalling. This is mainly due to the orientation of the product: a back-to-back user agent solution. But, we can configure the Asterisk solution in order to be more compliant to strict separation of voice and signalling, like in the SIP or H.323 models.

The normal Asterisk model is keeping voice and signalling to flow inside the Asterisk box because it is easier to propose enhanced services like call forwarding, voice mail or call monitoring. In that aspect Asterisk is what we call a “stateful proxy” in the SIP world.

Asterisk is proposed with an open but proprietary voice interconnection protocol called IAX for Inter Asterisk Exchange. This protocol has been designed in order to allow a simple, quick and straightforward interconnection of two Asterisk PBX without any hassle on the network configuration, port forwarding or TCP stack usage. On the other hand, SIP is really an only signalling protocol, not specific for voice but more for any kind of communication, including video, application or instant messaging. SIP is not taking care of how the communication will be transported afterwards, it is only putting user agent into contact and helping these in exchanging there capacities and how to talk.

When using Asterisk with SIP phones, voice is not flowing straight between these ones but through the Asterisk. The main advantages we could find with this solution are:

Asterisk can analyze if phone keys are pushed and handle function associated with those (see features.conf).
the solution is independent with regards various phones with regards to specific functions (transfer, voice mail, …), thus easier for migration or phone change.
Asterisk is able to handle a large list of codec and can translate between phones and Centrex not sharing a common one.

But, the voice in transit in the server hosting the Asterisk is stressing this one. It should handle large amount of frames and transform their content. Each call is putting more stress on the server and can impact performances which are critical for voice transport. Further more, this solution with a central point where calls are handled from a voice perspective is not efficient for phone not located on the same site. Two phones located at the same remote location and managed by the Asterisk on a central site would see their voice traffic flowing via the central site which is not efficient. This one of the reason why the SIP distributed model has been designed in a way voice is flowing direct and signalling can go to a central point.

The following datagram shows the call flow using SIP inside an Asterisk system:

We can clearly see the signalling part is going through the Asterisk, but also the voice. This stateful proxy mode is mainly used today in SBC¹ for security reason.

When Asterisk is not wanted in the voice path, we should respect three rules:

the Dial application command should not use in the last argument a function forcing the traffic to flow outside the bridge like t or T.
the sip.conf should not specify the canreinvite=yes option for one of the two SIP phones
the IP phones should be able to accept specific SIP INVITE messages when the call is already engaged.

First rule is easy to put in place and check, the easiest way is to use a Dial application command without any argument but the timeout² – see extensions.conf.

The Re-INVITE thing is a bit trickier. The way Asterisk handle a call outside the bridge is the following:

establish the call with an indirect voice path in the initial INVITE messages³.
when the call is established, if the voice path needs to be direct, a new INVITE message is sent to both parties telling these to modify the voice path to a direct one. This is where IP phones should be able to handle this specific message used to initiate a session and used here to modify an existing one. The SIP protocol is authorizing this behaviour but not every one is able to handle it properly.

The diagram of such an outside bridge call is the following:

First phase is similar to what we saw previously for the bridged call. Phase 2 is showing what changed: the new INVITE message is sent to both engaged parties. These messages are explaining how the voice path should go direct by modifying the RTP IP addresses and port numbers. But the phone call is already engaged, each phone will have to switch the destination without loosing a voice frame.

If one of the phone is not able to handle correctly the INVITE message we can arrive to a half bridge call or a call on which only one path is working well.

If the process is successful, the call will be outside the bridge, which means the signalling path remains through Asterisk but the voice path is now direct. This model is closer to the SIP one and less stressing for Asterisk that could handle this way far more simultaneous call. Gotcha.

If the voice system requires direct voice paths, we will have to validate IP phones supporting the Re-INVITE messages. It will also be mandatory to align codecs used on each phone since Asterisk will not be translating any of these. Some tests and validation steps are thus required prior going to production.

Last but not least, some features proposed by Asterisk staying in the call flow will not anymore be available, like the transfer. Each SIP phone is able to transfer a call but requires specific actions that should be documented and provided to end-users. For example, low end phones are using the Flash key for supervised transfer, some other are smarter and propose a one key transfer mode, it can be either blind or supervised.