Avoiding codec transcoding - how to?

I’ve got a customer whom I’m providing termination to. I want to offer them ulaw, g723 and g729, since several of my terminating providers support those as well. To keep CPU utilization down, I want to do NO transcoding. For example, if they request g723, I want to do g723 to any/all terminating providers.

How do I accomplish this? One idea I had was this:

[ol]
[li]Set up single sip friend, allow all three codecs[/li]
[li]Set up extension section that determines codec of current call[/li]
[li]Based on codec, hand call to sip endpoint that supports only the incoming requested codec[/li][/ol]

However, $(SIP_CODEC) isn’t set in extensions.conf when I tried to see if it was available.

I’d prefer not to have to set up three incoming sip friends and three outgoing sip friends PER PROVIDER just to avoid transcoding, but if that’s what it takes, I’ll do it.

I’m using v1.4 at the moment. What sip setting am I missing? Is there a Match_codec setting? something in extensions.conf?

Nobody knows how to avoid codec transcoding/translating? I’ve scoured google, these forums, voip-info.org and found nothing that says how to do it. Maybe it cannot be done?

In order to avoid transcoding, you would have to ensure that all devices have a particular codec, and that all configurations allow only that one codec.

Transcoding is actually a feature of the system. It’s not considered something that you would avoid.

If your endpoints support multiple codecs, you may choose to allow certain codecs, and even have the endpoints express a preference for one or the other. But if the preference of one device is g723, and the preference of another is g729, you will have transcoding.

If your goal is to reduce CPU overhead, you should consider setting the devices to allow re-invites. In that way, incoming invites would be sent to the endpoints directly, which would negotiate a protocol that suits the incoming protocol. As long as the endpoints support the incoming protocol, it should work.

Thanks for your reply, dufus, I appreciate it.

I can be down with the fact that transcoding is just something that can be done and isn’t a big deal. But why do it, if it can be avoided? If both endpoints don’t support REINVITE, but both can speak the same language, why hire a translator because one endpoint’s native language happens to use fewer words than the other? There’s still the cost of the translator (CPU).

When transcoding is necessary, it is a fine feature to have. When it is NOT necessary, it seems ridiculous to transcode. In fact, there have been several threads on asterisk-dev about PREFERED_CODEC being able to be set before initiating a second leg. But I haven’t seen it implemented, discussed, and while I haven’t grep’ed for it in source, I’m guessing it’s not there yet.

Of course I realize how asterisk will choose the codecs in the order I place them in the config, but there isn’t a way (that I’ve found) to say I much prefer to match codecs where possible, and transcode only when necessary. THAT is what I’m trying to figure out.

I wholeheartedly agree that you should avoid transcoding whenever possible.

Sadly, we’re dealing with only the first generations of this technology. For the most part, we’re still re-inventing the wheel, and trying to duplicate all the functions you’ll find on the TDM telecom network.

Once the technology becomes more widely adopted, you’ll probably find that refinements like the one you’re looking for will appear.

Perhaps this might be an opportunity to crack into the code and do some development of your own. That’s the real power that open source applications have. The ability to customize the code to your specific need.