| Summary: | ASTERISK-22082: 180 Ringing not forwarded out on inbound channel during parallel Dial due to Dial waiting on provisional response from outbound channels | ||||
| Reporter: | hristo (hristo) | Labels: | |||
| Date Opened: | 2013-07-16 10:02:48 | Date Closed: | |||
| Priority: | Minor | Regression? | |||
| Status: | Open/New | Components: | Applications/app_dial | ||
| Versions: | 1.8.23.0 13.18.4 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Debian 64-bit | Attachments: | |||
| Description: | I have identified two cases, in which parallel calls may result in no ringback tone being heard by the caller:
1. In some cases "180 Ringing" is not being forwarded to the calling channel, because Dial() is waiting for provisional response from outbound channels, which are in a state of either busy, congested or nochan. I believe the problem is in line 1331 in app_dial.c (1.8 branch): {code} if (ignore_cc || cc_frame_received || num_ringing == numlines) { {code} if I understand the line correctly, a comparison is made between the number of channels in the ringing state (num_ringing) and the total number of outbound channels (numlines). However, it doesn't take into account (a simple subtraction?) any channels, which never sent back any 18x response and are in a state of busy, congested or nochan (num.busy, num.congestion and num.nochan counters respectively). As a result in certain cases even though the rest of the outbound channels all have sent back "180 Ringing", the Dial app will not forward it to the caller. This exact problem is in fact described in the comments just above this line in the source code itself. I am experiencing this problem when calling two end devices in parallel and when one of them has DND set. In this case no ringback will be sent to the calling channel, because the Dial app will wait for the device in DND to send back 180 Ringing, but it gets instead "480 Do Not Disturb" (at least with a SNOM 760 I will get this message). [Edit by Rusty Newton - separated second issue out to ASTERISK-22201] I want to mention, that adding the 'r' is not an option in the cases above, because it will generate ringback immediately and unconditionally and not when/if the 180 Ringing is actually received from upstream (consider a call to a mobile). | ||||
| Comments: | By: hristo (hristo) 2013-07-17 06:51:16.781-0500 Another possible workaround for point 2 in the description above was posted on the users mailing list: http://lists.digium.com/pipermail/asterisk-users/2013-July/279906.html (see attachment). It treats a 183 as if it is a 180. By: Rusty Newton (rnewton) 2013-07-26 15:57:13.814-0500 Thanks for the report and great descriptions of the issue. I'm pretty sure the behavior you describe here has been this way for a long time. If you think it has changed recently or within the branch then let us know what version it last behaved differently in. I don't think this is a bug. It does sound like the behavior could be improved, which would require a patch. We don't log improvement requests without a patch on the issue tracker unless someone is actively developing it. Let us know if you are working on a patch for this. As for your mailing list link, we can't grab code off the mailing list and patch it here ourselves. The author will have to submit it here with a signed [contributor's agreement|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-DigiumSubmissionLicenseAgreement] before it can be reviewed and considered for inclusion. I haven't had much experience with parallel dials in a long time, so I'll ping some folks to make sure this behavior is expected as is. I could see there easily being some complex reasons why things are the way they are in these scenarios. By: Rusty Newton (rnewton) 2013-07-26 16:40:12.680-0500 It's debatable whether these issues are bugs or not, but we'll keep these open as they are close enough to being bugs. The behavior is definitely not optimal. Though we consider the 'r' option to Dial a viable workaround in both scenarios. Since we don't want two separate problems in a single issue, I've separated out the second into a new issue: ASTERISK-22201 * Please gather Asterisk logs (VERBOSE and DEBUG turned up to 5) including SIP debug for both issues and attach them to the respective issues in the tracker. This will help with documenting the exact behavior that you are describing and help any developer looking to reproduce the scenario for testing. | ||||