Asterisk
  1. Asterisk
  2. ASTERISK-16115

[patch] problem with ringinuse=no, queue members receive sometimes two calls

    Details

      Description

      Dear all

      on a debian amd64 i've installed (from source) asterisk 1.4.31

      On the system we have in average 50 concurrent calls in queue and 40
      sip members.

      I'm experiencing an apparently random problem:
      sometimes some users receive 2 calls from asterisk, apparently
      ignoring the ringinuse=no settings.
      It appears on users that are members of many queues

      As you can see from the log, the user goes in a status Ring+Inuse.

      Any idea?
      Why the call is still dispatched to the user if it is not in the "Not
      in use" status?

      i've added some customized log in the ring_entry function and this is the result:

      [May 18 14:13:04] DEBUG[24945] app_queue.c: KUMBELOG: queue=queue_1        count=1,membercount=13,ringinuse=0,device=SIP/PL1009,status=1
      [May 18 14:13:04] DEBUG[24945] app_queue.c: Found matching member SIP/PL1009 in queue 'queue_2'
      [May 18 14:13:04] VERBOSE[24945] logger.c:     -- Called SIP/PL1009
      [May 18 14:13:05] VERBOSE[24945] logger.c:     -- SIP/PL1009-00001807 is ringing
      [May 18 14:13:06] DEBUG[25098] app_queue.c: KUMBELOG: queue=queue_2        count=2,membercount=15,ringinuse=0,device=SIP/PL1009,status=1
      [May 18 14:13:06] DEBUG[25098] app_queue.c: Found matching member SIP/PL1009 in queue 'queue_1'
      [May 18 14:13:06] DEBUG[25098] app_queue.c: Found matching member SIP/PL1009 in queue 'queue_3'
      [May 18 14:13:06] VERBOSE[25098] logger.c:     -- Called SIP/PL1009
      [May 18 14:13:07] VERBOSE[25098] logger.c:     -- SIP/PL1009-00001808 is ringing
      [May 18 14:13:07] DEBUG[25312] app_queue.c: KUMBELOG: queue=queue_3        count=1,membercount=18,ringinuse=0,device=SIP/PL1009,status=6
      [May 18 14:13:08] DEBUG[25382] app_queue.c: KUMBELOG: queue=queue_4        count=1,membercount=18,ringinuse=0,device=SIP/PL1009,status=6
      [May 18 14:13:08] DEBUG[25224] app_queue.c: KUMBELOG: queue=queue_2        count=2,membercount=15,ringinuse=0,device=SIP/PL1009,status=6
      [May 18 14:13:12] VERBOSE[25098] logger.c:     -- SIP/PL1009-00001808 answered SIP/192.168.55.32-000017e6
      [May 18 14:13:13] VERBOSE[25098] logger.c:     -- Native bridging SIP/192.168.55.32-000017e6 and SIP/PL1009-00001808
      [May 18 14:13:14] DEBUG[25224] app_queue.c: KUMBELOG: queue=queue_2        count=1,membercount=15,ringinuse=0,device=SIP/PL1009,status=7
      

      It seems that the system does not change the status of the user after calling it, and then re-schedule a new call.

      After that the status is updated and goes in a ring+inuse status (7)

      Do you have any idea about what can cause that?

      This is an example of my config

      [PL1009]
      context=mycontext
      callerid=PhoneLine1009 <1009>
      secret=pwd1009
      type=peer
      host=dynamic
      call-limit=3
      disallow=all
      allow=ulaw
      
      queues:
      [queue_1]
      weight=10
      wrapuptime=0
      strategy=leastrecent
      joinempty=no
      retry=0
      autopause=yes
      setinterfacevar=yes
      eventwhencalled=yes
      eventmemberstatus=yes
      ringinuse=no
      
      member => SIP/PL1009
      
      [queue_2]
      weight=10
      wrapuptime=0
      strategy=leastrecent
      joinempty=no
      retry=0
      autopause=yes
      setinterfacevar=yes
      eventwhencalled=yes
      eventmemberstatus=yes
      ringinuse=no
      
      member => SIP/PL1009
      
      
      [queue_3]
      weight=10
      wrapuptime=0
      strategy=leastrecent
      joinempty=no
      retry=0
      autopause=yes
      setinterfacevar=yes
      eventwhencalled=yes
      eventmemberstatus=yes
      ringinuse=no
      
      member => SIP/PL1009
      
                • ADDITIONAL INFORMATION ******

      I've tried:

      1.4.31
      1.4.30

      run the system using ESXi on DL380
      run the system using ESXi on HP Blade
      run the system directly on hardware without virtualization
      used slackware 13.0 instead of debian AMD 64
      changed the kernel hertz to 1000 instead of 250
      added dahdi to optimize timing

      On client-side, i've tested
      Sjphone on windows
      CISCO 7940 phone

      in all these test-case i had the problem, and it occurs with a frequency of 100 times each 4000 calls.

      1. app_queue.c.patch
        3 kB
        Shlomi Gutman
      2. app_queue.c-1.6.2.10.patch
        5 kB
        Bruce Spidel
      3. app_queue.c-svn-r368404.patch
        5 kB
        art
      4. app_queue.c-svn-r370418.patch
        0.9 kB
        Italo Rossi
      5. app_queue.c-svn-r375015.patch
        2 kB
        Italo Rossi
      6. debug_.txt
        9 kB
      7. debug.filtered.gz
        34 kB
        Mikhail Lundberg
      8. jira_asterisk_16115_revert_r370418_v1.8.patch
        0.9 kB
        Richard Mudgett
      9. jira_asterisk_16115_single_q_v1.8.patch
        6 kB
        Richard Mudgett

        Issue Links

          Activity

          Hide
          Richard Miller added a comment - - edited

          Doesn't the download link on the right-hand panel of this page retrieve the latest version? That file is dated April 25, 2016 which is the day this issued was deemed resolved?

          https://gerrit.asterisk.org/#/c/2679/1/apps/app_queue.c

          Show
          Richard Miller added a comment - - edited Doesn't the download link on the right-hand panel of this page retrieve the latest version? That file is dated April 25, 2016 which is the day this issued was deemed resolved? https://gerrit.asterisk.org/#/c/2679/1/apps/app_queue.c
          Hide
          Joshua Colp added a comment -

          Ah, I see. I'd suggest opening up an issue with details to track it. There is no one working on app_queue, so if you feel as though you can take a look then feel free to.

          Show
          Joshua Colp added a comment - Ah, I see. I'd suggest opening up an issue with details to track it. There is no one working on app_queue, so if you feel as though you can take a look then feel free to.
          Hide
          Joshua Colp added a comment -

          The download link downloads that specific change, not the latest version.

          Show
          Joshua Colp added a comment - The download link downloads that specific change, not the latest version.
          Hide
          Richard Miller added a comment -

          Should a new (linked) issue be created, or should it be continued here?

          Show
          Richard Miller added a comment - Should a new (linked) issue be created, or should it be continued here?
          Hide
          Joshua Colp added a comment -

          A new issue should be created.

          Show
          Joshua Colp added a comment - A new issue should be created.

            Dates

            • Created:
              Updated:
              Resolved:

              Development