asterisk users - Jul 2013 - ignore 183 session progress in parallel call scenarios

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/4ddb2797/attachment-0001.htm>

On 15 July 2013 15:14, 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
>
> --
> _____________________________________________________________________
>
I think you need to look into early media and also this application

https://wiki.asterisk.org/wiki/display/AST/Application_Progress



-- 

Ishfaq Malik
Department: VOIP Support
Company: Packnet Limited
t: +44 (0)845 004 4994
f: +44 (0)161 660 9825
e: ish at pack-net.co.uk
w: http://www.pack-net.co.uk

Registered Address: PACKNET LIMITED, 2A ENTERPRISE HOUSE, LLOYD STREET
NORTH, MANCHESTER
SCIENCE PARK, MANCHESTER, M156SE
COMPANY REG NO. 04920552
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130715/28448752/attachment.htm>

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>