[asterisk-bugs] [JIRA] (ASTERISK-22203) Despite not bridging early media in a parallel Dial, we forward 183 Session Progress back to the caller

[Rusty Newton (JIRA)]

Rusty Newton created ASTERISK-22203:
---------------------------------------

             Summary: Despite not bridging early media in a parallel Dial, we forward 183 Session Progress back to the caller
                 Key: ASTERISK-22203
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22203
             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


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. 

--
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