Summary:	ASTERISK-03049: codec preference doesn't work with mysql sipfriends
Reporter:	Roy Sigurd Karlsbakk (rkarlsba)	Labels:
Date Opened:	2004-12-20 05:20:32.000-0600	Date Closed:	2004-12-30 14:02:45.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) mysqlsipfriendscodec.patch ( 1) sipdebug-all-mysql.new.gz ( 2) sipdebug-in-sipconf-no-codecpref.new.gz
Description:	If getting sip friends from mysql, codec is not chosen by the order set in sip.conf. If I create the same user in sip.conf without a user codec pref, the global codec pref is used. If I setup the client with a specific codec, this is used, and returned by sip show channels. sip show channels with clients supporting both g.726 and alaw always return alaw. ****** ADDITIONAL INFORMATION ****** reproducable on 1.0.3/latest stable CVS and reported to mailing list. Attached is sip debug with all data gotten from mysql, and sip debug when an entry had been made in sip.conf
Comments:	By: brian22942 (brian22942) 2004-12-20 06:07:11.000-0600 Sounds like a configuration issue. You are using RealTime? What does your database table look like? Are you using static conf files? Matthew Boehm recently posted a message to the Asterisk mailing list stating that if you have allow column before the disallow column, it causes problems. Also, I believe if you don't override the global preferences in sip.conf, then they become the defaults for the sip users. By: Roy Sigurd Karlsbakk (rkarlsba) 2004-12-20 06:12:18.000-0600 I'm not using realtime I'm using sipfriends from mysql from stable, as specified. this has no configuration entry for codec, so it should inherit the stuff set in sip.conf, or at least that was what I thought. IIRC The problem from Matthew was realtime related, not related to sipfriends from stable. The globals in sip.conf should always be the the defaults for sip users, but, as (hopefylly) clearly specified above, this does not happen when the users are fetched from mysql, which is exactly what this bug report is all about. roy By: Roy Sigurd Karlsbakk (rkarlsba) 2004-12-20 14:23:24.000-0600 sip.conf contains disallow=all allow=gsm,g726,g729,alaw when taken from sip.conf without any codec prefs set on the [user] entry, thus using the globals, SIP header contains, correctly: Answering with preferred capability 0x2 (gsm) Answering with preferred capability 0x10 (g726) Answering with preferred capability 0x100 (g729) Answering with preferred capability 0x8 (alaw) When the users are taken from a db, the SIP header shows: Answering with capability 0x2 (gsm) Answering with capability 0x8 (alaw) Answering with capability 0x10 (g726) Answering with capability 0x100 (g729) Does this give the new codec order? roy By: Mark Spencer (markster) 2004-12-20 19:01:14.000-0600 I'm not sure it's supposed to be a feature of sipfriends.  Does it work with realtime? By: brian22942 (brian22942) 2004-12-20 21:33:32.000-0600 It seems like it is ordering the codecs by the bitmasks. By: brian22942 (brian22942) 2004-12-20 21:55:43.000-0600 rkalsba:   I took a look at chan_sip.c and if you take a look at lines 3398 to 3440, you'll see where it orders the verbose output of the codec preferences to the CLI. I think Asterisk is merely describing what codec capabilities it has. For instance, if you have a SIP device that only does alaw, then Asterisk has the "capability" to do it. I do not think this changes the order at all. The for loops are different so that's why you get the difference between the preferred codec preferences and the capabilities. They are one in the same essentially. Preferred is what you set in the sip.conf file and the capabilities are what Asterisk can do based on what you set in the DB.   Also, the best guess I can give is the reason why there is a descrepancy between the two different sip debug messages is because there is no codec preferences stored in the ast_codec_pref_index. This would cause the code to break out of the for-loop. It would then go on to the next for-loop and print out the codec capabilities you set in the database, in order.   Try doing a sip show peer and see what the codec order is supposed to be. Line 5753 in chan_sip.c uses the same lookup code as the previous "Preferred Codec Capability" example. edited on: 12-20-04 22:01 edited on: 12-20-04 22:07 By: Roy Sigurd Karlsbakk (rkarlsba) 2004-12-21 03:03:32.000-0600 With entry in sip.conf (only global codec prefs) sip show peer  Codecs       : 0x11a (gsm|alaw|g726|g729)  Codec Order  : (gsm|g726|g729|alaw) sip show channeels  x.x.x.x    100xxxx     8K1j-J1O0Mi  00101/00135   g726   Then with sip from mysql sip show peer  Codecs       : 0x11a (gsm|alaw|g726|g729)  Codec Order  : (none) sip show channeels  x.x.x.x    100xxxx     *PTsV0-J1O0  00101/00154   alaw   so you're right. As it's not possible to set any codec in the database (not realtime, remember), how can I make my sipfriends inherit the global codec order? thanks roy By: Roy Sigurd Karlsbakk (rkarlsba) 2004-12-21 06:25:38.000-0600 That patch adds codec to sipfriends table in mysql. This fixed the problem. By: Mark Spencer (markster) 2004-12-21 06:45:38.000-0600 It is doubtful that Russell will want to add a new column to mysql friends in the stable release, but I will go ahead and close this out to give him the opportunity to make that decision.  I really wish you had tested with realtime as I asked, but  it probably works anyway. By: Roy Sigurd Karlsbakk (rkarlsba) 2004-12-21 06:49:09.000-0600 It's quite useless to test realtime, something not even in alpha, in a production environment. I'm doing some testing on realtime on another server, but I need a solution for this quicky. I'll get back to you on test results on realtime later. thanks roy By: Mark Spencer (markster) 2004-12-21 17:34:41.000-0600 Okay, so.... like I said, nothing to be done in head, up to russell if he wants it in stable, and if realtime doesn't work, open a new bug I guess. By: Russell Bryant (russell) 2004-12-30 14:02:45.000-0600 Since the number of options supported with sipfriends is pretty limited anyway, I'm just going to leave this out.  If someone would like to use this patch, it will be here for them to apply. Thanks for the contribution!