Summary:	ASTERISK-00641: [request] allowing gsm codec should not override allow= ordering
Reporter:	Andrew Kohlsmith (akohlsmith)	Labels:
Date Opened:	2003-12-08 12:56:44.000-0600	Date Closed:	2011-06-07 14:04:54
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	if the GSM codec is allowed it should _not_ be top prioirty.  It should have whatever priority any other codec would have in the list of allowed codecs.  It's currently impossible to favour any other codec if GSM is also to be allowed.
Comments:	By: Brian West (bkw918) 2003-12-08 13:36:15.000-0600 Please tell me what you are speaking about sip? iax? what?  You haven't included any information that could help me figure out what you are talking about. By: Andrew Kohlsmith (akohlsmith) 2003-12-08 13:44:47.000-0600 It is a core * codec (or config file I suppose) issue -- at least IAX2 and SIP if not others.  I only have those those data paths. Reproduce easily (iax.conf): disallow=all allow=ilbc allow=gsm You will never ever get an iLBC call if both ends can do GSM, even if both ends can do iLBC since GSM gets top #1 priority, and it shouldn't. By: Brian West (bkw918) 2003-12-08 13:46:05.000-0600 I recall something about this now... Wonder if a config option could fix this? By: Andrew Kohlsmith (akohlsmith) 2003-12-08 13:50:05.000-0600 it's the configuraiton parsing that is causing the problem...  there must be a special case in the source as it exists today which is giving gsm top priority if it is allowed...  this needs to be taken out so that it gets whatever priority any other codec would have in its place. Like I said: disallow=all allow=ilbc allow=gsm gsm should get #2 priority, but somewhere the code is saying "ahh gsm is allowed, I will use it if I can instead of ilbc, even though I can also use ilbc." By: Brian West (bkw918) 2003-12-08 13:59:32.000-0600 Accually try this: disallow=all allow=gsm allow=ilbc If I recall the list is built in reverse order. By: Tilghman Lesher (tilghman) 2003-12-14 12:33:04.000-0600 Actually, it's neither.  The preference is based upon a hardcoded list of an order of codecs, given their ease of use and computing complexity (i.e. codecs that take less CPU power are rated higher).  See channel.c:ast_best_codec() for the list. I don't know where you got the impression that the order in which codecs are specified had anything to do with how codecs are negotiated, but it simply isn't true (and has never been true, to my knowledge). This is a feature request, not a bug. By: zoa (zoa) 2003-12-15 03:57:55.000-0600 i want this too... By: atacomm (atacomm) 2003-12-15 22:57:32.000-0600 Codec selection has always been explained to me as an order of preference.  All other configuration files go in that order, either it is documented poorly, or it should go in the order selected. Or possibly do: allow=ilbc,preferred or preferred=ilbc By: Andrew Kohlsmith (akohlsmith) 2003-12-16 08:18:23.000-0600 Why add another option?  I mean if preference can be specifed by order why not leave it as simple as that?  Adding more config options just adds complexity without really giving you any added benefit. By: Olle Johansson (oej) 2004-03-21 16:08:49.000-0600 In chan_sip this seems to be handled ordered for the codecs in the [general] section and non-ordered for codecs under [client] sections. Any coders? Otherwise, we need to add the current state of affairs to documentation and close this bug id. By: Olle Johansson (oej) 2004-03-25 02:46:37.000-0600 Keeping request in Mantis, but closing it while waiting for coders to fix this. If you have a patch, bug a bug marshal to reopen this bug.