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

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-22201:
-----------------------------------------

Quoting hristo from ASTERISK-22082  (the other half of his original report)

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