Freeswitch Codecs

[Anais Wachowski]

FreeSWITCH supports a large number of VoIP compression codecs out of the box, however the default config does not enable them all for all transport types. Codecs are built from various modules and from the core FreeSWITCH source (no need to load modules for core codecs, they are in CORE_PCM_MODULE, e.g. they're built into the core of FreeSWITCH). For codecs not in core, you need to compile and load the corresponding module.

Note: iLBC@30i configures the iLBC codec to default to 30ms frames instead of 20ms frames which will allow you to receive iLBC calls from Asterisk servers which unfortunately do not correctly send their iLBC codec preferences.

If you see any error while loading module then you need to compile the mod_h26x from freeswitch source.This module will present in the mod/codec directory. just do make and make install in module source code directory, and load the module by above command.

Codec negotiation can be a confusing subject. If you are not familiar with SDP (Session Description Protocol) then this adds an extra layer of mystery. If you are new to the subject (or are just confused by what you've read and experienced) then consider this brief introduction and hopefully things will be a bit clearer.

First of all, what do we mean when we say "codec negotiation"? We are talking about the process of choosing which codec will be used on each leg of a call. FreeSWITCH supports a lot of codecs. Most SIP endpoints will also support multiple codecs. Each leg can have only one codec, so the codec negotiation process sifts through the choices and settles on a single codec to use. It's this "sifting process" that can cause confusion. How does this process work? How can it be modified? This page is written to help you answer those questions.

FreeSWITCH supports two basic modes of codec negotiation: early and late. Early negotiation means that the codec is negotiated between FreeSWITCH and the endpoint as soon as possible, even before FreeSWITCH needs to send media (such as ringing) or answer the the call. This occurs before an incoming call even hits the dialplan. Late negotiation means to delay the choosing of the codec until after the call hits the dialplan and more information can be gathered. This additional information can be used to influence the negotiation process. Let's illustrate the differences between early- and late-negotiation.

Note the difference in the timing of the negotiation of the A leg codec. With early negotiation, FreeSWITCH chooses a codec (G722) immediately. It does not wait to see what happens on the outbound leg (that is, the B leg) of the call. So the A leg is using G722. After deciding on the codec for the A leg, FreeSWITCH passes this call through the dialplan, which eventually comes to a bridge application to call Bob's phone. To initiate the bridge, FreeSWITCH calls the B leg and offers a pretty big list of codecs. These are the "outbound codec prefs" for FreeSWITCH. (This list is customizable, but more on that later.) Bob's phone sees all those codecs and chooses the first one that matches, in this case PCMU. At this point we have both call legs negotiated:

As soon as Bob's phone sends back a ringing signal, the two legs are bridged together. FreeSWITCH has to transcode from Alice's codec (G722) to Bob's codec (PCMU) because two different codecs were negotiated. Usually this is okay, but let's say you'd prefer that both phones have the same codec so that there's less CPU usage. This is where late-negotiation comes into play.

As you can see, when FreeSWITCH picks a codec for the A leg without knowing what codec is set on the B leg then there can easily be a "codec mismatch." A codec "mismatch" isn't always a bad thing, but many times it is nice to have both call legs share the same codec. Using late-negotiation and a technique called "inherit codec" we can force the A leg to use which ever codec is negotiated on the B leg. (This process is described in specific detail later on - for now we are only considering the basic concepts.)

The basic call flow in our second example has FreeSWITCH getting the A leg but *not* negotiating a codec right away. Instead, FreeSWITCH holds off on negotiating a codec for the A leg until after the A leg has passed through the dialplan. In this case, the dialplan ended up with a bridge to Bob's phone. During the bridge process, FreeSWITCH negotiated a codec with Bob's phone - in this case PCMU. Once that codec was chosen on the B leg, FreeSWITCH went back to Alice's phone and told it that we would be using PCMU on the A leg. Now both call legs are using the same codec, which is what we wanted.

That's really all there is to the difference between early- and late-negotiation. Just keep this in mind: simply enabling late-negotiation does not automatically force the A leg to inherit the B leg's codec. It simply allows for "inherit codec" as one way of negotiating codecs. Late-negotiation allows for other codec negotiation tricks. Read on for a more specific description of codec negotiation in FreeSWITCH.

This is a parameter you may set in the outbound SIP profile.
This will force the codec proposed to leg B (outbound leg) to be the same as the codec negotiated on leg A (inbound leg).
To set this, add the following line to the required SIP profile:

This parameter (only applicable when late-negotiation is off) will take the negotiated codec from leg A and offer it as the only option in leg B (ignoring any other codec settings) if the B leg cannot use that same codec the call will fail

This is a channel variable you may set in the dialplan, typically just before bridging.
This will force the codecs list proposed to leg B, without taking into account anything else.
Here is an example:

Note: This parameter prevails on disable-transcoding. So if you disable transcoding in the outbound SIP profile and you use absolute_codec_string in the dialplan to set the outbound codec to be different from the inbound codec, transcoding will occur anyway.

This is a channel variable you may set in the dialplan, typically just before bridging.
The defined codec list will override the one set in the outbound-codec-prefs parameter of the outbound profile.
Here is an example:

inherit_codec=true (only applicable when late-negotiation is enabled) will take the codec negotiated when the B leg answers and pass it to the A leg so it also uses the same codec (if the A leg supports it); otherwise, it will use whatever it can from its own list

This variable is only available if late negotiation is enabled on the profile. It's a readable string containing all the codecs proposed by the calling endpoint. This can be easily parsed in the dialplan.

If you want FreeSWITCH to be able to match two legs with different codecs (where it transcodes) there are several variables you will need to set to make it possible. First you must set media_mix_inbound_outbound_codecs=true either globally (ie vars.xml) or on the b leg explicitly on the bridge (ie ).

Here is a dialplan example that will allow you to change the codec preference order and still enjoy the low cpu usage of proxy_media mode. It is similar to subst() in openser/opensips/kamailio textops module.

The reason I ask is because the FreeSWITCH folks tend to be breaking new ground, doing things we can only dream about in Asterisk, particularly with regard to wideband audio. For example, today they posted this:

Putting this in perspective: CD-quality audio is 44.1kHz. This means CELT supports better than CD-quality audio in a VoIP environment! The only bad news here is that you might need to upgrade your headset so that your microphone is sensitive enough to handle such a wide range. Also, consider bandwidth usage: 48kHz of super high-quality audio requires a mere 48kbps of bandwidth. By comparison, the venerable PCM mu-law codec, G.711u, consumes 64kbps of bandwidth and yields only 8kHz audio quality!

Both Asterisk and FreeSWITCH will have their strengths and weaknesses. FreeSWITCH has the benefit of hind site while Asterisk has the benefit of millions of installations, many many features and years of usage. Having two good engines out there will be great for all and neither one is going to stop evolving and improving.

A telephony software is not only a piece of code, it is as well a very good understanding of the traditionnal telephony world, to find the right way to migrate or use together traditionnal telephony and IP telephony. Asterisk poorly fail in this regard (no bandwith management for example, we have this in the ATM world since decades).

Another example : we still have no standard solution for sending ANI through SIP. There is still no difference inside asterisk between ANI and CID at the SIP level. ANI is mandatory for interfacing the SIP world to the SS7 world at the country and world scale. Without a serious standard ANI transmission method, final clients and providers using IP telephony do not respect the law in most country and do not give urgency services the level of geolocalization required.

Asterisk needs to focus on Enterprise PBX feature sets, not esoteric carrier features. There are several commercial SS-7 stacks for Asteisk that are Telcordia certified for interconnection to the provider SS-7 networks.

129 * Added DNS manager support to registrations for peers referencing peer entries.
130 DNS manager runs in the background which allows DNS lookups to be run asynchronously
131 as well as periodically updating the IP address. These properties allow for
132 better performance as well as recovery in the event of an IP change.

In the case where we deal with multisite client installations, and using full IP telephony (SIP or IAX trunk to the provider) we have to deal with ANI transmission. If not, as soon as the client mask its CID, the provider has no means to get the proper client ANI in the trunk. Then the call can be terminated without ANI, causing problems to urgency services, or billing problems if the client need independant billing for each location.

c80f0f1006