Summary: | ASTERISK-06037: codecpriority=caller does not seem to work | ||
Reporter: | Jan-Peter Koopmann (jkoopmann) | Labels: | |
Date Opened: | 2006-01-11 02:04:05.000-0600 | Date Closed: | 2006-05-17 17:36:23 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | On most systems I have codecpriority=caller defined in iax.conf. However if I call that host e.g. with idefisk, this happens: -- Accepting AUTHENTICATED call from x.x.x.x: > requested format = ilbc, > requested prefs = (), > actual format = alaw, > host prefs = (alaw|ulaw|g729|g726|ilbc|gsm), > priority = mine ****** ADDITIONAL INFORMATION ****** First thing I notice is that idefisk does not send a preference list or at least this debug message suggest this. Funny thing: If I call that particular * from another * I still get no preference list even though several codecs are defined in both iax.conf. Second thing: The client explicitly requests ilbc as format. However the * seems to ignore codecpriority=caller and chooses "priority=mine". It then chooses the first codec in its own preference list which is alaw even though the requested ilbc is in the allowed list. This looks like a bug to me. I suppose the "priority=mine" is the clue. My C is not brilliant but if I read the code in chan_iax.c correctly, priority=mine is set if there is no preference list from the caller. I am afraid this might even be two bugs: 1. Why is there no preference list sent? If this was just idefisk I'd say it's a client problem but a * <-> * connection shows the same problem. 2. Even if there is no preference list sent by the client, a codecpriority=caller should change priority in such a way that the requested format is chosen if it is supported and allowed by the server. | ||
Comments: | By: kb1_kanobe2 (kb1_kanobe2) 2006-02-27 21:10:17.000-0600 FWIW, how do you have the peer defined in iax.conf? In my experience if you're using 'type=friend' then wierdness happens with codec selection predictability. I have far better experiences using separate 'peer' and 'user' definitions to get explict codec selection, thus: [remote-astpbx-low] type=peer disallow=all allow=g729 host=... secret=... [remote-astpbx-high] type=peer disallow=all allow=ulaw host=... secret=... [remote-astpbx-incoming] type=user allow=all permit=... secret=... With the same entries, reversed on the remote host. That way I can 'dial by codec' from within the dialplan predictably. Just my 2 cents -- your issue may be different, but I can assure you that codec preferences can be fical to get working the way you might expect. k. By: Serge Vecher (serge-v) 2006-05-01 14:59:26 jkoopmann: did you try kb1_kanobe's suggestion? Is this still an issue? By: Jan-Peter Koopmann (jkoopmann) 2006-05-02 04:16:03 Hi, I know I can force things using kb1_kanobe2 syntax. But that is not really the point is it? It is more a workaround for the current situation. Or did I miss something? By: Serge Vecher (serge-v) 2006-05-09 13:47:04 ok, can you please download the latest trunk or 1.2 code, turn debug on and upload a trace here showing the problem? Thanks. By: Joshua C. Colp (jcolp) 2006-05-17 17:36:23 Fixed in 1.2 and trunk (I even tested it - yay!) Thanks. |