Section 6.3. Project 6.1. Set Up Custom Codec Selection and Enable an Independent Call Path

6.3. Project 6.1. Set Up Custom Codec Selection and Enable an Independent Call Path

6.3.1.1 What you need for this project:

• Asterisk

• Two or more hard or soft SIP phones

• LAN

Within Asterisk, it's possible to set preferences for each SIP channel as to which codecs should be used, or allowed. This can be a necessity if a particular channel is connected to the server using a low-bandwidth link. It would be prudent to limit that SIP channel to codecs that preserve bandwidth. Figure 6-6 shows how calls across a WAN might use G.729A, a low-bandwidth codec, while local Ethernet-based calls might use G.711.

Figure 6-6. Codec selection schemes are often based on bandwidth availability on different data links

Codec selection is a function of the call setup routine, handled by SIP, H.323, or a proprietary signaling protocol, but there are varying degrees to which you can tune the process. Depending on vendor, the softPBX has some control over codec selection on a phone-by-phone basis. Some VoIP vendors call this per-peer selection.

6.3.1.2 Per-peer codec selection on Cisco media gateways

Cisco's media gateway devices, themselves just simple VoIP softPBXs, allow the definition of endpoint and trunk peers using SIP and H.323 signaling configurations. One of the parameters that can be assigned to each peer is a codec preference.

6.3.1.3 Per-peer codec selection on Asterisk

In Asterisk's sip.conf configuration, it's possible to set an order for codec preferences on a per-peer basis. Consider the following snippet of a sip.conf file:

 [103]     type=friend     context=default     username=103     callerid=103 Budgetone Phone     canreinvite=no     disallow=all     allow=ulaw     allow=gsm 

This definition, for a SIP peer called 103, allows only G.711 m law and GSM codecs to be employed. Asterisk prefers the codecs in the same order specified in each SIP peer definition.

What this sample SIP peer cannot do is have an independent call path. In order to allow SIP peers to operate with independent call paths, the canreinvite setting must be yes . This enables SIP phones to establish a direct media channel with the phone on the other end of the call, cutting the softPBX out of the proverbial loop. Enabling this option doesn't force the SIP phones to use an independent call path, though: in situations in which transcoding is needed or the softPBX is required in the call path because of the design of the network, Reinvite won't get used.