Routing filters

In order for a voice call to be established, the two end-points (IP phones or media gateways) must not only be able to exchange IP packets which contain SIP messages, but also agree on a mutually acceptable way to encode the audio signal for transmission over the IP network (codec). There are many codecs available, with different features in terms of voice quality, compression rate and required processing resources. Some are free, while others require royalty payments. As a result, each device, such as an IP phone, is usually capable of supporting only the limited subset of codecs implemented by the manufacturer.

Normally, at the beginning of a call the calling party announces all the codecs it supports, and then the called party replies back with a list of codecs it is willing to accept, and so the decision is made by the two end-points only.

This approach provides great flexibility and since PortaSwitch does not have to interfere in the audio processing and utilize any codecs on its side. But since the two SIP end-points make the decision regarding the choice of the codec without any consideration of the network infrastructure or other important factors, in some situations, their choice may be less than optimal.

For instance, SIP phone A may have the G.711 codec as the first preference by default; and if that codec is supported by the other party, it will be chosen for the call. While this is great for a customer A, with high-speed broadband connectivity (G.711 provides sound quality identical to traditional “wired” telephony service, such as ISDN), if customer B attempts to use G.711 with limited bandwidth it will result in severely degraded voice quality and a negative customer experience. Such a customer B should always use a narrow-bandwidth codec such as G.729 to ensure good sound quality.

Thus it becomes increasingly important for the ITSP to actively control the choice of codecs used by the end-points, in order to optimize network performance and avoid negative customer experiences. How is it done?

Routing filters operate with the concept of call media features. A call media feature is a property of the call or call media, such as a specific codec, T.38 fax, or the ability to guarantee delivery of the correct CLI (caller identification) to the recipient of the call. Since the caller may have his own set of desired call media features, the main idea is to ensure proper “match-making” between the available carriers, while limiting the caller’s choice if required (e.g., the caller may request a video call, but this will be prohibited if he is not authorized to do so).

Be aware that PortaSwitch can convert media stream from one codec format to another. For more information refer to the Transcoding and transrating chapter.

These describe the filters applied to call media features (such as a specific codec or T.38 fax capability), as requested by the calling party. For each feature the PortaSwitch administrator can specify that:

• It is “required” – meaning that the other SIP end-point must have this feature supported in order for the call to be completed.For instance, if the “G.729 codec” feature is marked as “required” for an account making a phone call, then only those vendors specifically marked as “guaranteed to support G.729” will be placed in the routing list.
• It is “suppressed” – meaning that PortaSwitch will prevent the use of this particular feature (e.g., G.722 codec) and will not even show the information about this codec in the SIP request when sending an outgoing call to the other end-point.
• It is “not required” – meaning that PortaSwitch does not do any special processing for this feature. It will be included in the outgoing SIP request, and may be used if the other party supports it. This is the default value for any feature.

These describe the capabilities of the remote party (such as the gateway of a carrier) and our preferences on using them. For each feature it is specified whether it is:

• Supported – meaning that we know for sure that this equipment supports this feature and are willing to use it.
• Not supported – meaning that this equipment is unable to support this particular feature (e.g., G.723 codec). It could also be our administrator’s decision to prohibit it.

For example, although we do not know whether a vendor’s gateway supports the G.722 codec, by marking it as “not supported” we will ensure that, even if the originating end-point shows this codec as available, it will be removed from the codec list sent to the carrier in the SIP call initiation request, and thus never used.