Transcoding
Automatic transcoding is performed (if possible) when call legs are connected together. By default negotiation does not take into account possible transcodings since this is route dependent.
Transcoding can work only if RTP passes through Yate. When rtp_forward is enabled transcoding won't work and you must not add formats to the list - at most you can remove.
How to do transcoding in Yate
Currently there is one easy way to compute the list of possible transcoded formats.
The regexroute module offers a transcode function to build an extended list. You should not use this list always, only when you are sure RTP is proxied through Yate.
You can put this line in regexroute.conf section [contexts] that handles call.preroute:
[contexts]
...
.*=;oformats=$(transcode,,${formats})
The empty parameter above (between the two commas) controls which formats are returned.
Please see the comments in regexroute.conf for more info.
If inbound formats=alaw,mulaw you will get something like oformats=alaw,mulaw,slin,gsm,ilbc,speex (assuming the modules are compiled and loaded).
You can then use ${oformats} in routing either in regexroute or in register (database routing) to set the formats parameter:
[default]
...
; Offer transcoded formats on outbound unless rtp_forward is in use
${rtp_forward}^yes$^=;formats=${oformats}
Where to change the codecs
Here is how the list of codecs is passed around inside and outside Yate.
The numbers indicate the places where the list can be altered:
- Inbound channel supported codecs (automatically filters inbound offer)
- Routing (alters inbound and outbound codecs)
- Executing outbound call (alters outbound codecs)
- Outbound channel supported codecs (automatically filters outbound offer)
- Outbound channel supported codecs (automatically filters response)
- Inbound channel supported codecs (automatically filters response)
See also
