Summary: | ASTERISK-00447: SIP_CODEC variable no longer sets codecs as expected | ||
Reporter: | John Todd (jtodd) | Labels: | |
Date Opened: | 2003-10-28 14:36:25.000-0600 | Date Closed: | 2004-09-25 02:49:15 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | SIP_CODEC is supposed to change the codec before a new SIP leg is created. It no longer appears to do that. This had previously worked fine; something has changed (the allow/disallow syntax, perhaps?) that has changed the functionality from what was expected. ****** ADDITIONAL INFORMATION ****** This does seem not to function as I had remembered it to work. Looking at chan_sip.c at around line 1125, it seems pretty obvious as to how it's _supposed_ to work, and the LOG_NOTICE messages say the right thing, but the call does not get generated with the right codec - as you can see from the notes below, it's ULAW and not g729. [iconnect] type=friend secret=1234 username=12345678 host=213.137.73.177 dtmfmode=inband canreinvite=no disallow=all allow=ulaw allow=alaw allow=g729 allow=gsm Here's the console log: -- Executing SetVar("SIP/2203-8fa8", "SIP_CODEC=g729") in new stack -- Executing Dial("SIP/2203-8fa8", "SIP/14102241145@iconnect|70") in new stack -- Called 14102241145@iconnect -- SIP/iconnect-f818 is making progress passing it to SIP/2203-8fa8 -- SIP/iconnect-f818 answered SIP/2203-8fa8 -- Attempting native bridge of SIP/2203-8fa8 and SIP/iconnect-f818 ms1*CLI> sip show channels Peer User/ANR Call ID Seq (Tx/Rx) Lag Jitter Format 213.137.73.177 1410224114 110cb6c20cf 00103/00000 00000ms 0000ms ULAW 204.92.126.4 2203 0002b9eb-0e 00101/00103 00000ms 0000ms ULAW 2 active SIP channel(s) Here is the messages file for the relevant parts of the call: Oct 28 20:27:37 NOTICE[27665]: File chan_sip.c, Line 1129 (sip_answer): Changing codec to 'g729' for this call because of ${SIP_CODEC) variable | ||
Comments: | By: x martinp (martinp) 2003-11-03 18:09:06.000-0600 SIP_CODEC does work. I tested it many times. The problem is that you don't have in sip.conf allow=g729 and SIP_CODEC can't allow the format that you don't allow. I changed the code so that it will 'warn' you about that. By: John Todd (jtodd) 2003-11-05 02:32:42.000-0600 No, actually, if you look at the "Additional Information" section, you'll see that I have "allow=g729" specified right there, and it still fails. That's why I included the sections of sip.conf that were relevant. To double check, I set SIP_CODEC to alaw, which is also permitted in the list, and it also does not set the codec correctly. I will not include the debug here, as it is identical to that which I have already enclosed. By: x martinp (martinp) 2003-11-05 10:55:44.000-0600 Can you see if that fixes it ? Index: channels/chan_sip.c =================================================================== RCS file: /usr/cvsroot/asterisk/channels/chan_sip.c,v retrieving revision 1.206 diff -u -r1.206 chan_sip.c --- channels/chan_sip.c 4 Nov 2003 02:40:09 -0000 1.206 +++ channels/chan_sip.c 5 Nov 2003 17:21:31 -0000 @@ -1132,7 +1132,7 @@ fmt=ast_getformatbyname(codec); if (fmt) { ast_log(LOG_NOTICE, "Changing codec to '%s' for this call because of ${SIP_CODEC) variable\n",codec); - p->capability=fmt; + p->jointcapability=fmt; } else ast_log(LOG_NOTICE, "Ignoring ${SIP_CODEC} variable because of unrecognized/not configured codec (check allow/disallow in sip.conf): %s\n",codec); } By: luisbe (luisbe) 2003-11-11 20:12:07.000-0600 It fixed it for me when the call comes from SIP to zaptel, but I'm getting the same error when asterisk has to play a file. edited on: 11-11-03 21:43 By: x martinp (martinp) 2003-11-12 10:10:50.000-0600 It's in CVS. |