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

[hristo (JIRA)]

hristo created ASTERISK-22082:
---------------------------------

             Summary: 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 devices 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