[Home]

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-0600Date Closed:2004-09-25 02:49:15
Priority:MinorRegression?No
Status:Closed/CompleteComponents: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.