I am afraid this is not the case. It happens even when g729 is replaced by Speex or any other codec. We’re working in direct media mode anyway, hence no transcoding needed in peer-to-peer.
There isn’t a direct media mode. Direct media is just a hint to use direct media if possible; it doesn’t prevent transcoding, if that is needed.
In this particular case we have nat=force_rport,comedia and directrtpsetup=yes in sip.conf and both phones are using the same codec. Why would there be any need for transcoding in a peer-to-peer call?
comedia only makes sense when direct media is not being used. (force_rport is only about signalling.)
Direct media is also incompatible with, DTMF detection, monitoring, recording, and conferencing.
Inband tones are always generated as SLIN, so need transcoding (or will be silent).
The only real issue here is why Asterisk changed from using all the common formats as its native formats, to only using one preferred one.
1 Like
If you want to avoid transcoding then make sure to reorder codec for endpoint A as
allow=g729,g722.
Also for other endpoints order should be g729 as higher preferred codec.
This order is causing the problem. To avoid transcoding, the codec supported by all the phones (g722) needs to be first, but the OP doesn’t want to do that, as it will never use G.729, and he want that to be used.
I guess the answer is in @jcolp’s reply above–each leg is dealt with separately.
Exactly.
We would like to use g729 whenever possible–i.e. whenever both peers support it (which I think makes more sense).
We will be tweaking with dialplan channel variables to redefine a leg’s codec according to callee capabilities.
Not exactly. The two legs were still negotiated separately, even when a set of native codecs, rather than a single one was used. What would have happened before is that the Dial to B would have been passed both codecs, and would have offered g722 to B. Media from A would have arrived in A’s preferred codec, and media from B would have arrived in g722. Media from B would have been passed to A and media from A would have failed to transcode, if A had preferred g729.
At a guess, the change was made to avoid such a one way audio case, by ensuring the call failed completely. However, one would need to search the change logs to be sure.
One thing to remember is that A could have initially made a call to a g729+g722 phone, and then been transferred to a g722 only one, so, even though the OK was after the codec could have been known for the first phone, the second phone would still have been subject to the problem.
2 Likes
I still find it surprising that Asterisk was not designed to handle such scenario successfully by allowing A<>A calls using g729 and all other calls using g722. What is precisely surprising is the fact that even though two phones A and B do support the same g722 codec, Asterisk is not able to make a call possible between such two compatible phones–without dialplan tweaking and other sorcery.
We hope this will be handled automatically in the future.
Asterisk was designed to handle G.711 coded data from analogue and circuit switched digital systems. As I understand it, VoIP was a later addition.
1 Like