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

[Hristo Trendev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130715/86bf775e/attachment.htm>