[asterisk-bugs] [JIRA] (ASTERISK-29025) pbx_spool: Call remains up when it shouldn't be

[Derrick Hammer (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251752#comment-251752 ] 

Derrick Hammer commented on ASTERISK-29025:
-------------------------------------------

I can confirm this issue does exist as a bug as well. it also seems to be a weird edge case. The following is the research I have found on it so far:

* On the cases where this happened, it seems the call had extra long periods of ringing before voicemail kicked in, 10+ rings.
* It appears the retries counter on the outgoing struct either does not increase or somehow gets decreased, so https://github.com/asterisk/asterisk/blob/fcd8e9d6ef6cad66ba3bfe58540aa1cdb372fc2c/pbx/pbx_spool.c#L524 is always getting hit, and causing the loop
* I am unsure if retries starts at 0 or 1, but on https://github.com/asterisk/asterisk/blob/fcd8e9d6ef6cad66ba3bfe58540aa1cdb372fc2c/pbx/pbx_spool.c#L524 it seems the "<=" might need to be a "<"?
* It seems that disabling the app_amd.so module prevents this bug from happening, so it may have an issue with interacting with it or just exposes an edge case bug.
* I have confirmed in my case, codec_g72x and res_speech_vosk aren't loaded and I do not get segfaults.
* With AMD off, it seems the call may not actually forward to the other end (to a queue or extension) despite the voicemail. This could imply some sort of connection signal shutting it down, but I cannot confirm this, only speculation.
* My Asterisk version is 13.32.0.

I hope this information helps :)

> pbx_spool: Call remains up when it shouldn't be
> -----------------------------------------------
>
>                 Key: ASTERISK-29025
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29025
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: PBX/pbx_spool
>    Affects Versions: 16.12.0
>         Environment: Centos 7  OS 64 BIT
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
>     link/ether 9a:61:a0:a5:c8:49 brd ff:ff:ff:ff:ff:ff
>     inet XXX.XXX.XXX.X/18 brd 104.131.63.255 scope global eth0
>        valid_lft forever preferred_lft forever
>     inet 10.17.0.5/16 brd 10.17.255.255 scope global eth0
>        valid_lft forever preferred_lft forever
>            Reporter: PARTHA PAUL
>            Severity: Minor
>
> I am using asterisk 16.12.0 version to originate calls, Following problem arises from time to time, a call will successfully
> terminate
> {noformat}
> [root at 99 outgoing]# asterisk -rx "core show channels verbose"
> Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgeID
> Local/6661 at default-0 paul sw_7_"020" 12 Up SpeechBackgr "020",2 9123943000 03:54:02
> {noformat}
> FileName: 9123943000.call
> Location: /var/spool/asterisk/outgoing
> {noformat}
> Channel: Local/6661
> MaxRetries: 2
> RetryTime: 60
> WaitTime: 30
> Callerid: 9123943000 <9123943000>
> Context: AMD
> Extension: 8881
> Priority: 1
> StartRetry: 31932 1 (1597095345)
> DelayedRetry: 31932 0 (1597095345)
> DelayedRetry: 31932 0 (1597095405)
> DelayedRetry: 31932 0 (1597095465)
> DelayedRetry: 31932 0 (1597095525)
> DelayedRetry: 31932 0 (1597095585)
> DelayedRetry: 31932 0 (1597095645)
> DelayedRetry: 31932 0 (1597095705)
> DelayedRetry: 31932 0 (1597095765)
> DelayedRetry: 31932 0 (1597095825)
> DelayedRetry: 31932 0 (1597095885)
> DelayedRetry: 31932 0 (1597095945)
> AbortRetry: 12581 1 (1597096005)
> StartRetry: 12581 1 (1597096065)
> EndRetry: 12581 1 (1597096036)
> StartRetry: 12581 3 (1597096125)
> DelayedRetry: 12581 2 (1597096096)
> DelayedRetry: 12581 2 (1597096125)
> DelayedRetry: 12581 2 (1597096156)
> DelayedRetry: 12581 2 (1597096185)
> DelayedRetry: 12581 2 (1597096216)
> DelayedRetry: 12581 2 (1597096245)
> DelayedRetry: 12581 2 (1597096276)
> DelayedRetry: 12581 2 (1597096305)
> DelayedRetry: 12581 2 (1597096336)
> DelayedRetry: 12581 2 (1597096365)
> DelayedRetry: 12581 2 (1597096396)
> DelayedRetry: 12581 2 (1597096425)
> DelayedRetry: 12581 2 (1597096456)
> DelayedRetry: 12581 2 (1597096485)
> DelayedRetry: 12581 2 (1597096516)
> DelayedRetry: 12581 2 (1597096545)
> DelayedRetry: 12581 2 (1597096576)
> DelayedRetry: 12581 2 (1597096605)
> DelayedRetry: 12581 2 (1597096636)
> DelayedRetry: 12581 2 (1597096665)
> DelayedRetry: 12581 2 (1597096696)
> DelayedRetry: 12581 2 (1597096725)
> DelayedRetry: 12581 2 (1597096756)
> DelayedRetry: 12581 2 (1597096785)
> DelayedRetry: 12581 2 (1597096816)
> DelayedRetry: 12581 2 (1597096845)
> DelayedRetry: 12581 2 (1597096876)
> DelayedRetry: 12581 2 (1597096905)
> DelayedRetry: 12581 2 (1597096936)
> DelayedRetry: 12581 2 (1597096965)
> DelayedRetry: 12581 2 (1597096996)
> DelayedRetry: 12581 2 (1597097025)
> DelayedRetry: 12581 2 (1597097056)
> DelayedRetry: 12581 2 (1597097085)
> DelayedRetry: 12581 2 (1597097116)
> DelayedRetry: 12581 2 (1597097145)
> DelayedRetry: 12581 2 (1597097176)
> DelayedRetry: 12581 2 (1597097205)
> DelayedRetry: 12581 2 (1597097237)
> DelayedRetry: 12581 2 (1597097265)
> DelayedRetry: 12581 2 (1597097297)
> DelayedRetry: 12581 2 (1597097325)
> DelayedRetry: 12581 2 (1597097357)
> DelayedRetry: 12581 2 (1597097385)
> DelayedRetry: 12581 2 (1597097417)
> DelayedRetry: 12581 2 (1597097445)
> DelayedRetry: 12581 2 (1597097477)
> {noformat}
> I think, it's a bug



--
This message was sent by Atlassian JIRA
(v6.2#6252)