[asterisk-bugs] [JIRA] (ASTERISK-22082) incorrect 183/180 handling in parallel calls

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-22082:
-----------------------------------------

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.
                
> incorrect 183/180 handling in parallel calls
> --------------------------------------------
>
>                 Key: ASTERISK-22082
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22082
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_dial
>    Affects Versions: 1.8.23.0
>         Environment: Debian 64-bit
>            Reporter: hristo
>            Severity: Minor
>
> 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).
> 2. Additionally, in a parallel call, Dial() will never bridge any early media audio, which is completely normal behavior especially if we consider two outbound channels providing early audio streams at the same time. However, what I believe to be incorrect behavior is to still forward the "183 Session Progress" message back to the calling endpoint, even though it will never receive any early media stream. In particular this causes problems with subsequent "180 Ringing" messages, which may come from some/all of the other devices that are being called in parallel. Almost any end device will ignore a "180 Ringing", which is received after a "183 Session Progress" and will never generate local ringback (which is exactly what I experience).
> I believe the problem in this case is in line 1352 in app_dial.c (1.8 branch):
> {code}
> if (single || (!single && !pa->sentringing)) {
> {code}
> and specifically the part that will evaluate to true for all parallel calls, as long as the calling channel hasn't received any "180 Ringing" yet.
> I am not sure if there is a use case in which sending "183 Session Progress" without providing a media stream is desirable/required, but if there is no such case, then probably a much better approach will be to simply ignore any upstream "183 Session Progress" messages when dealing with parallel calls.
> I believe the second problem above may be related to ASTERISK-17524, because ignoring the 183 will probably resolve the problem described there in a much cleaner way than using the 'r' option. Please add a relation between the two issues if appropriate. 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).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira