Summary:	ASTERISK-03169: [request] ability to set non-optimized codec priority
Reporter:	Roy Sigurd Karlsbakk (rkarlsba)	Labels:
Date Opened:	2005-01-03 07:44:54.000-0600	Date Closed:	2005-03-03 16:27:12.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dial-cellphone-asterisk-sip-iad.new ( 1) dial-iad-sip-asterisk-cellphone.new ( 2) dial-iad-sip-asterisk-sip-iad.new
Description:	When an incoming call comes in with one codec and the outbound preference to another interface includes a priority list which includes the first codec but not as the highest priority, it would be nice to be able to have an option to allow Asterisk to abide by that priority list and not prioritize the incoming codec as it currently does.  I know I could just remove the codec from the outbound list of codecs, but I just want to change the priority not disable the codec entirely.
Comments:	By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 07:46:51.000-0600 iad is ATA. the ATA used is Yoda IAD100s. I'm using Mysql SIPfriends, but have tried with users in sip.conf and this gives the same result By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 08:07:22.000-0600 Same stuff happens with G.726 By: Brian West (bkw918) 2005-01-03 09:21:04.000-0600 Answering with preferred capability 0x2 (gsm) Answering with preferred capability 0x100 (g729) Answering with preferred capability 0x10 (g726) Answering with preferred capability 0x8 (alaw) Looks like the order we answer gsm,g729,g726 and then alaw And when you say inbound calls you mean calls inbound to the IAD from asterisk or calls inbound from the IAD to asterisk? By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 09:25:59.000-0600 I tried to say in the description above... When dialling from PSTN, I always get ALAW When dialling from SIP ATA to SIP ATA or from SIP ATA to PSTN, I get the codec chosen roy By: Brian West (bkw918) 2005-01-03 09:26:07.000-0600 I have just double checked this in head and in and outbound calls work as expected on codec ordering. By: Brian West (bkw918) 2005-01-03 09:27:00.000-0600 Now I didn't test zap to sip... let me try that out. bkw By: Brian West (bkw918) 2005-01-03 09:27:59.000-0600 Zap to SIP on cvs-head works as expected. By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 09:34:52.000-0600 This is "stable" Can you check again? By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 09:38:38.000-0600 I should've written Stable in version. CVS -r v1-0 By: Brian West (bkw918) 2005-01-03 09:40:46.000-0600 This is clearly an IAX inbound call here thats getting ALAW not Zap. -- Accepting unauthenticated call from x.x.x.22, requested format = 8, actual format = 8 If you start at line 3393 to 3410 ... comment that out it should behave as you want it to. Since the call is coming in via IAX we choose the native format of the existing call over the pref order as written in chan_sip. Answering/Requesting with root capability 8  <--- right here. Answering with preferred capability 0x2 (gsm) Answering with preferred capability 0x10 (g726) Answering with preferred capability 0x100 (g729) Thats why you're not getting to choose that.  This way we don't transcode when we don't need to.  If you don't offer up alaw it would go with pref order. Its doing exactly what it was written to do with respect of what mark wanted. On line 3393 we check to see if the codec/capability of the channel is in our codec list.. if so lets offer it first over all else.  I was personally against doing this since it does override our codec order choosen but it does reduce the amount of transcoding required. bkw By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 09:45:16.000-0600 ok, but then, how can I force it to choose the codec on the SIP gateway, transcoding if nessecary? Not all  users have enough bandwidth, which is the reason we've bought the G.729 in the first place. By: Brian West (bkw918) 2005-01-03 09:46:25.000-0600 You cut out lines 3393 to 3410 Also attached is a verbose fix for the root capabilities answer. bkw By: Kevin P. Fleming (kpfleming) 2005-01-03 09:56:41.000-0600 I don't understand... if you don't want Asterisk to ever use alaw to communicate with your SIP gateway, why have you allowed it? By: Brian West (bkw918) 2005-01-03 10:02:00.000-0600 well personally I think this should be a config option to allow you to totally override the capabilility/requested format of the current channel and use your codec order pref list in the order you want.  Thats how we did it when we first refactored the sip codec pref stuff.  But Mark wanted the native format of the channel to be used over the pref list no matter what thus totally defeating the purpose of a codec pref list if you ask me. bkw By: Kevin P. Fleming (kpfleming) 2005-01-03 10:21:27.000-0600 OK, I guess without looking deeper into the code I don't quite understand. The way I see it, there are two possibilities here: 1) The SIP peer's codec list includes alaw, but as lowest priority. However, since the channel that will be bridged is currently in alaw, Asterisk moves alaw to highest priority, so it won't have to transcode. 2) The SIP peer's codec list _does not_ include alaw, but Asterisk is offering it anyway, and because the peer actually does support it, it accepts the call. If #1 is the scenario, then this is only a configuration problem and the user should not allow the peer to use alaw (take it out of the list if you don't want it to be used). If #2 is the scenario, then this is completely wrong, IMO. By: Brian West (bkw918) 2005-01-03 10:28:05.000-0600 Option 1 is correct. Not offering up alaw would be the best way to solve this.  But I still feel an override option would be helpful. bkw By: Kevin P. Fleming (kpfleming) 2005-01-03 10:57:03.000-0600 I am resolving this bug as a configuration error; if the poster wants to reopen because they are _not_ actually listing alaw in the "allow" list, they can do so. By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 17:06:29.000-0600 The point is, one should be able to force a codec preference, not merely allowing Asterisk to "do the best". My point in particular, is to allow some callers to use G.729 against the SIP server never mind what the PSTN gateway behind wants to do. This, because some users just don't have the bandwidth to do ALAW. Even if PSTN talks ALAW, it doesn't mean they want to. So, please, don't see this as a "it's not a bug...". For me it's a pain in the arse. roy By: Kevin P. Fleming (kpfleming) 2005-01-03 17:44:26.000-0600 Show us exactly what the allow/disallow parameters these ATA peers are. If you are allowing "alaw" for these peers, then Asterisk is doing exactly what you allowed it to do. Without seeing the relevant parts of your config, we can only assume it is a configuration error. If you don't want these ATAs to _ever_ use alaw when talking to Asterisk, then don't allow it in the sip.conf entries for them. By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 17:57:21.000-0600 That's my point I _do_ want them to be able to use ALAW, but I want to prioritise G.726 and/or G.729. I have a bunch of clients all over the country, and I can't just say "reboot your ATAs now, because I want to reconfigure it!". Therefore, allowing all codecs, and prioritising them as I thought Asterisk was meant to do, seems a good option. roy By: Kevin P. Fleming (kpfleming) 2005-01-03 18:00:22.000-0600 I don't understand. You say you have clients who do not have the bandwidth to use alaw, but you want them to be able to use alaw. Then, when Asterisk does use alaw, you don't want it to. I'm not suggesting that you reconfigure their ATAs to not support alaw; I'm suggesting that you change your entries in sip.conf to not allow alaw for that specific peer (or all the ones who don't have enough bandwidth). I do understand that you want to force Asterisk to transcode these calls, and I agree with bkw that there should be a way to stop Asterisk from "preferring" the codec already in use on the other end of the call. However, that will not stop it from using that codec, it will just make it less preferable. In your case, you have asked for it to not use alaw at all; that is a different issue. By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-03 18:10:49.000-0600 Please, Please, PLEASE understand All I want is to define the order in which the codecs are chosen All this is in Asterisk, with a good reason. Why should there be an exception for this to work? By: Kevin P. Fleming (kpfleming) 2005-01-03 18:19:17.000-0600 It works perfectly fine for me; I have my client devices set to only allow GSM and G.729, and my calls always go through, even when Asterisk has to transcode. I don't allow my client devices to use ulaw, because they don't enough bandwidth to do that. If you want Asterisk to always transcode, even when both ends of the call can support the same codec, then someone will have to write a patch giving you the option of doing that. As it stands today, if Asterisk sees that both ends can use the same codec, it will do that, always. To put it simply: yes, you can define codec preferences, but currently those preferences will be overridden by Asterisk's desire to not transcode if it doesn't have to. By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-04 04:58:37.000-0600 Perhaps that choice should be up to the sysadmin, and not Asterisk's developers? It shouldn't be too hard to add a config option to control it, should it? By: Mark Spencer (markster) 2005-01-04 08:40:55.000-0600 Reclassifying as a feature request, since Asterisk *is* operating within its normal parameters.  This should also make the title and subject clearer for someone wanting to read up on it. By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-04 08:44:41.000-0600 Having codec preferences not working because asterisk refuses to transcode if the other part supports the current codec, is for me a bug. If not, please document this clearly in the docs. By: () 2005-01-05 20:20:12.000-0600 why not just set codec settings by peer if this is a problem? Even so, you should be able to define codecs in whatever order and the phone will deliver it's own list of capabilities in it's own order anyways. By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-06 03:55:31.000-0600 The ATAs we're using have limited configuration capabilities, so I need Asterisk to allow transcoding even if ALAW is permitted. I also do not want to disallow ALAW at the server, since this will give administrative overhead with several hundred users. The best approach is to have Asterisk prioritise the codecs and not just override the prioritisation just because then it doesn't need to do transcoding. I have enough CPU on this box to handle this. By: () 2005-01-06 07:10:08.000-0600 Did you upload that patch rkalsba? Taking a stab at it, it seems that the order it is selecting is correct but the output is wrong. However, I think you have a few options: 1. Set codec settings in the [general] settings in the order you want 2. Set the codec settings in each ATA that you want. This isn't such a hard task if you auto-provision the devices. 3. Set the codec settings for each ATA under the [peer] settings and also have [general] settings, and settings for each ATA. By: Brian West (bkw918) 2005-01-07 16:57:20.000-0600 sip_pref_root_verbose_fix.diff  was just a small verbose fix.  I uploaded.. bkw By: twisted (twisted) 2005-01-28 19:51:48.000-0600 Where does this one stand? By: Roy Sigurd Karlsbakk (rkarlsba) 2005-01-29 11:07:52.000-0600 I tried what bkw said, "You cut out lines 3393 to 3410", and that works. AFAIK, this isn't fixed/functionaity hasn't been added to address this. But then, I might be wrong..... By: Kevin P. Fleming (kpfleming) 2005-03-03 16:14:12.000-0600 The new proposed solution in ASTERISK-3313346 will take care of this issue without requiring any new options in sip.conf... please monitor that bug and provide your input as you see necessary.