Asterisk
  1. Asterisk
  2. ASTERISK-447

SIP_CODEC variable no longer sets codecs as expected

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Core/General
    • Labels:
      None
    • Mantis ID:
      450
    • Regression:
      No

      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

        Activity

        Hide
        x martinp (Inactive) added a comment -

        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.

        Show
        x martinp (Inactive) added a comment - 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.
        Hide
        John Todd added a comment -

        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.

        Show
        John Todd added a comment - 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.
        Hide
        x martinp (Inactive) added a comment -

        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);
        }

        Show
        x martinp (Inactive) added a comment - 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); }
        Hide
        luisbe added a comment -

        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

        Show
        luisbe added a comment - 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
        Hide
        x martinp (Inactive) added a comment -

        It's in CVS.

        Show
        x martinp (Inactive) added a comment - It's in CVS.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development