[asterisk-users] ignore 183 session progress in parallel call scenarios

[Steve Davies]

I am sure I submitted the following "alternative" behaviour to the
bug-tracker in the past, but cannot find any reference to it. Here is the
patch I use to IMHO improve this behaviour.

In case it is not officially uploaded, I will state here that this code is
"disclaimed" and "unencumbered" as if uploaded to JIRA.

Regards,
Steve

On 15 July 2013 17:20, Hristo Trendev <dist.lists at gmail.com> wrote:

> I think I have found the answer to my questions in the source code of Dial:
>
> case AST_CONTROL_PROGRESS:
> 	ast_verb(3, "%s is making progress passing it to %s\n", ast_channel_name(c), ast_channel_name(in));
> 	/* Setup early media if appropriate */
> 	if (single && !caller_entertained
> 		&& CAN_EARLY_BRIDGE(peerflags, in, c)) {
> 		ast_channel_early_bridge(in, c);
> 	}
> 	if (!ast_test_flag64(outgoing, OPT_RINGBACK)) {
> 		if (single || (!single && !pa->sentringing)) {
> 			ast_indicate(in, AST_CONTROL_PROGRESS);
> 		}
> 	}
>
> .....
> .....
>
>
> Asterisk will attempt to bridge the media only for the case of a single outgoing channel, but at the same time it will happily forward progress messages for parallel calls: (!single && !pa->sentringing) as long as no 180 Ringing message was sent out to the caller yet. The questions still remains if this should be reported as bug or if there is indeed a use case when sending 183 progress message, without actually bridging the media stream is desired.
>
>
>
> On Mon, Jul 15, 2013 at 4:14 PM, Hristo Trendev <dist.lists at gmail.com>wrote:
>
>> Hi,
>> I am using asterisk 1.8.22 and have a problem when calling in parallel
>> several SIP endpoints and I am not sure how to resolve it. In this case
>> Asterisk will not bridge any audio to the caller before the 200 OK. Which
>> means any progress announcements, including remotely generated ringback,
>> are not passed back to the caller.
>>
>> This behavior is completely correct, because there is no way to know
>> which early media audio stream to pass back to the caller in a parallel
>> call scenario (as in this case several endpoint may indicate session
>> progress all at the same time).
>>
>> The question is why is asterisk still sending 183 session progress back
>> to the caller if no audio is to be bridged before the 200 OK anyway? If 183
>> are not passed back to the caller, then at least a 180 Ringing that may
>> come from another endpoint will cause the calling endpoint to generate
>> local ringback. This won't happen if the caller has received a 183 already.
>>
>> So it's a bit of a race condition as well - if the first endpoint to
>> reply sends a "183 session progress" this means the caller will not hear
>> any ringback even if some of the other endpoints are sending back 180
>> Ringing.
>>
>> The question is can I somehow block 183 messages from being passed back
>> to the calling endpoint when dialing several destinations in parallel? I
>> don't see a point (please correct me if I'm wrong) to pass only the 183 SIP
>> message back to the caller without the corresponding RTP stream, so it may
>> be much better to actually ignore it when dealing with parallel call
>> scenarios (bug?).
>>
>> BR,
>> Hristo
>>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130716/daa1be83/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiple_early_media
Type: application/octet-stream
Size: 1398 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130716/daa1be83/attachment.obj>