[asterisk-bugs] [Asterisk 0018763]: [patch] CallCompletionRequest() / Cancel() exit non-zero if no call/pending call

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18763 
====================================================================== 
Reported By:                p_lindheimer
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18763
Category:                   Core/CallCompletionSupplementaryServices
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.8.2.3 
JIRA:                       SWP-3042 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-02-07 12:06 CST
Last Modified:              2011-02-09 21:00 CST
====================================================================== 
Summary:                    [patch] CallCompletionRequest() / Cancel() exit
non-zero if no call/pending call
Description: 
When Calling CallCompletionRequest() if there is no call to make a request
on (timer has expired), or there is already a pending request (in generic
mode) then the call returns with a non-zero return and hangs up the call.

When this happens, in both above scenarios, the following is printed out
the the log/clli:

[Feb  7 09:22:28] CC[10693]: ccss.c:3886 ccreq_exec: Couldn't find a core
instance for caller SIP/3000

in the case where there is a pending request, it is the same message, but
as a result that there was a pending request and thus no instance was saved
from the last call since all 'slots' were taken (max 1 slot for generic).

example, the following occurs upon making a subsequent call elsewhere if
you have a current pending request, thus the above equivalent behavior in
both cases:

[Feb  7 09:22:08] CC[10670]: ccss.c:1522 cc_monitor_destroy: Core 77:
Calling destructor for monitor 2000 at from-internal
[Feb  7 09:22:08] CC[10670]: ccss.c:1415 cc_interface_destroy: Destroying
cc interface 2000 at from-internal
[Feb  7 09:22:08] CC[9099]: ccss.c:2944 cc_do_state_change: Core 77: State
change to 1 requested. Reason: CC offered to caller SIP/3000-00000106
[Feb  7 09:22:08] CC[9099]: ccss.c:2947 cc_do_state_change: Core 77:
Unable to find core instance.

Similar issue when calling CallCompletionCancel() if there is no pending
request to cancel. This results in a non-zero exit as well, but no log
message from the ccss system:


    -- Executing [*83 at from-internal:5]
CallCompletionCancel("SIP/3000-0000010a", "") in new stack
  == Spawn extension (from-internal, *83, 5) exited non-zero on
'SIP/3000-0000010a'

====================================================================== 

---------------------------------------------------------------------- 
 (0131771) p_lindheimer (reporter) - 2011-02-09 21:00
 https://issues.asterisk.org/view.php?id=18763#c131771 
---------------------------------------------------------------------- 
The uploaded patch ccss.patch is a suggested fix for this issue. It allows
CallCompletionRequest() and CallCompletionCancel() to always return 0, in
all cases a CC_REQUEST_RESULT or CC_CANCEL_RESULT is set to PASS/FAIL and
in the case of FAIL, I have added another CC_REQUEST_REASON and
CC_CANCEL_REASON with some reason information. Someone may have something
better for the reason code but at least this allows for proper return to
the dialplan so that it can be handled as needed. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-09 21:00 p_lindheimer   Note Added: 0131771                          
======================================================================