| Summary: | ASTERISK-17363: [patch] CallCompletionRequest() / Cancel() exit non-zero if no call/pending call | ||
| Reporter: | Philippe Lindheimer (p_lindheimer) | Labels: | |
| Date Opened: | 2011-02-07 12:06:03.000-0600 | Date Closed: | 2011-04-01 16:36:54 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/CallCompletionSupplementaryServices |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) ccss.patch | |
| 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@from-internal [Feb 7 09:22:08] CC[10670]: ccss.c:1415 cc_interface_destroy: Destroying cc interface 2000@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@from-internal:5] CallCompletionCancel("SIP/3000-0000010a", "") in new stack == Spawn extension (from-internal, *83, 5) exited non-zero on 'SIP/3000-0000010a' ****** ADDITIONAL INFORMATION ****** I discussed this issue with Mark Michelson on IRC and he agrees this is not expected behavior and is probably a bug. The expected behavior would be normal termination and some sort of CHANNEL variable response as to the success or failure of the request. I understand from discussions with Mark that there is an asynchronous behavior here and the quality of an initial Channel variable result may be mis-leading. However, given the bug, there seems to be a level of 'consistency' in the way it is responding vs. failing that some level of feedback could be provided. I from the failure modes with CallCompletionRequest(), it looks like you would just not be able to differentiate between the fact that there was a pending request vs. no call to make a request to, though… I would hope that it might be possible at the time of calling CallCompletionRequest() that you may be able to go as far as to return in a channel variable the fact that the requesting extension has N outstanding requests currently as a piece of information that we may be able to use in the dialplan, as well as whether a successful 'attempt' was made or not to queue this as a new request. | ||
| Comments: | By: Philippe Lindheimer (p_lindheimer) 2011-02-09 21:00:59.000-0600 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. By: Leif Madsen (lmadsen) 2011-02-10 13:13:12.000-0600 Contains patch, so updated to Confirmed. By: Digium Subversion (svnbot) 2011-04-01 16:31:41 Repository: asterisk Revision: 312461 U branches/1.8/main/ccss.c ------------------------------------------------------------------------ r312461 | rmudgett | 2011-04-01 16:31:40 -0500 (Fri, 01 Apr 2011) | 25 lines CallCompletionRequest()/CallCompletionCancel() exit non-zero if fail. The CallCompletionRequest()/CallCompletionCancel() dialplan applications exit nonzero on normal failure conditions. The nonzero exit causes the dialplan to hangup immediately. The dialplan author has no opportunity to report success/failure to the user. * Made always return zero so the dialplan can continue. * Made set CC_REQUEST_RESULT/CC_REQUEST_REASON and CC_CANCEL_RESULT/CC_CANCEL_REASON channel variables respectively. Also documented the values set. * Reduced the warning about no core instance in CallCompletionCancel() to a debug message. It is a normal event and should not be output at the WARNING level. (closes issue ASTERISK-17363) Reported by: p_lindheimer Patches: ccss.patch uploaded by p lindheimer (license 558) Modified Tested by: p_lindheimer, rmudgett JIRA SWP-3042 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=312461 By: Digium Subversion (svnbot) 2011-04-01 16:36:54 Repository: asterisk Revision: 312462 _U trunk/ U trunk/main/ccss.c ------------------------------------------------------------------------ r312462 | rmudgett | 2011-04-01 16:36:53 -0500 (Fri, 01 Apr 2011) | 32 lines Merged revisions 312461 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r312461 | rmudgett | 2011-04-01 16:31:39 -0500 (Fri, 01 Apr 2011) | 25 lines CallCompletionRequest()/CallCompletionCancel() exit non-zero if fail. The CallCompletionRequest()/CallCompletionCancel() dialplan applications exit nonzero on normal failure conditions. The nonzero exit causes the dialplan to hangup immediately. The dialplan author has no opportunity to report success/failure to the user. * Made always return zero so the dialplan can continue. * Made set CC_REQUEST_RESULT/CC_REQUEST_REASON and CC_CANCEL_RESULT/CC_CANCEL_REASON channel variables respectively. Also documented the values set. * Reduced the warning about no core instance in CallCompletionCancel() to a debug message. It is a normal event and should not be output at the WARNING level. (closes issue ASTERISK-17363) Reported by: p_lindheimer Patches: ccss.patch uploaded by p lindheimer (license 558) Modified Tested by: p_lindheimer, rmudgett JIRA SWP-3042 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=312462 | ||