Summary:ASTERISK-22201: Despite not bridging early media in a parallel Dial, we forward 183 Session Progress back to the caller
Reporter:hristo (hristo)Labels:
Date Opened:2013-07-26 16:25:20Date Closed:
Versions: 13.18.4 Frequency of
is related toASTERISK-17524 No ringback when 2 or more destinations in dial string
is related toASTERISK-22082 180 Ringing not forwarded out on inbound channel during parallel Dial due to Dial waiting on provisional response from outbound channels
Environment:Debian 64-bit Attachments:
Description: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):
if (single || (!single && !pa->sentringing)) {

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.
Comments:By: Rusty Newton (rnewton) 2013-07-26 16:28:06.054-0500

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

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 16:33:35.355-0500

Put this in a separate issue from ASTERISK-22082 since they are somewhat related, but not the same.

* I think this is pretty much a duplicate of ASTERISK-17524. I'm keeping it open since we feel like it's borderline a bug and though minor it's fairly obviously undesirable behavior that we'd like to see change at some point.
* It's been this way a long while and using the 'r' option with Dial is an appropriate solution