Summary:	ASTERISK-19244: g729 not offered in SIP INVITE
Reporter:	PAtryk Rzadzinski (rzadzins)	Labels:
Date Opened:	2012-01-25 10:31:48.000-0600	Date Closed:	2012-02-22 14:17:26.000-0600
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	General
Versions:	1.8.7.2 1.8.8.2	Frequency of Occurrence	Constant
Related Issues:
Environment:	Gentoo x64	Attachments:	( 0) extensions.conf ( 1) sip.conf
Description:	I've came across a weird issue and I am not sure in which version of asterisk this problem begun to happen. A new SIP provider only offers g729 as the codec for their trunk, however in SIP debug I was getting error 488. Upon closer investigation I saw that the codec g729 is not being offered from my end, so I went on to investigate why. I've removed all other optional codecs (had disallow=all, allow=alaw, allow=g729 in that context), but then I would get an error that no audio codecs have been selected. I have installed the binary codec_g729.so in /usr/lib/asterisk/modules after choosing the one compiled for core2, like all other packages on my system. I have also tried removing the format_g729.so from the modules directory (tried all combinations, restarting the service in between each). modules show like g729 would display no errors and the module loaded correctly. The command sip show peer "mypeer" would show that the preferred codec was g729 and it was the preferred one, however I was still getting the g729 error. Finally I've managed to convince the SIP provider to allow alaw and it works for me now, but I'm sure you'd like to investigate as to why g729 is not being offered, despite the module is loaded and the configuration is correct.
Comments:	By: Matt Jordan (mjordan) 2012-01-27 08:26:47.488-0600 When this occurred, what did "core show codecs" display?  Did you have sufficient g729a licenses? A SIP trace (either from a pcap or with 'sip set debug on') and a DEBUG log would indicate why the negotiation failed. By: PAtryk Rzadzinski (rzadzins) 2012-01-27 08:38:50.103-0600 I have no g729 licenses. I've learned that format_g729 should be enough if I am not doing any transcoding, so I reverted to using only that codec. Unfortunately when dialing through the sip trunk from the provider who only accepts g729, the SIP invite coming from my server would still not list the g729 codec as an option and as a response the provider would send error 488. I had a hint that if the agent (linksys spa921) had the alaw format set as preferred (and the call originated from it), then asterisk would decide it wants to transcode. Naturally, without a license there is no transcoding path for g729, so that could be the reason. It would however be extremely useful to have an error informing that this is the case, showing up in the CLI, rather than no error at all. By: PAtryk Rzadzinski (rzadzins) 2012-01-27 08:39:37.160-0600 Please confirm that "could" be the case, as I'm struggling to confirm this, because I had to bring the server into production asap (settled by agreeding with the SIP provider to offer alaw instead of g729). By: Leif Madsen (lmadsen) 2012-02-16 07:06:44.636-0600 Are you going to be able to provide additional information such as the configuration you were using, and the dialplan in question? These are things that developers need to be able to reproduce the issue and see what is going on. It's true that you shouldn't always need codec_g729, but the dialplan and how you have your system setup is going to dictate that. If you need to record calls or listen for DTMF in the media stream (for example) then Asterisk needs to be able to decode/encode the media stream, which would of course require the use of a codec_g729 license. By: PAtryk Rzadzinski (rzadzins) 2012-02-16 07:55:00.369-0600 dialplan By: PAtryk Rzadzinski (rzadzins) 2012-02-16 07:55:19.401-0600 sip configuration By: PAtryk Rzadzinski (rzadzins) 2012-02-16 07:57:00.778-0600 Sure, since this was initial testing of outbound communication from a sip phone via asterisk to a sip provider, the configs are really basic. Please let me know if you require further info. By: Leif Madsen (lmadsen) 2012-02-22 14:17:20.151-0600 The use of 'wW' in the Dial() line is your problem. As explained above, those types of options cause Asterisk to "listen" to the audio path, thus it needs to use a decoder to decode the audio to analyse it, and then an encoder to re-encode it to something else. Not a bug. Closing.