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

[Hristo Trendev]

Thanks Steve!

I too believe that this is indeed much better handling of 183 replies in a
parallel call. After testing for several hours today I actually wen't a bit
further (see ASTERISK-22082) and proposing to ignore the 183 altogether as
far as parallel calls are concerned. In my case I don't even need to
convert the 183 to 180, because all upstream providers are sending a 180 in
addition to the 183 and as long no 183 was sent to the caller prior to that
it just works...well almost always, see note 1 in the ticket above.

At first I was also tempted to simply convert it from 183 to 180, but then
I figured out that the 183 may sometimes contain an announcement as opposed
to a ringback tone. The caller won't hear it anyway, but simply sending 180
in this case will result in ringback being generated too early and not when
a real 180 ringing (possibly from another call leg) is received.

Ideally this can be a per sip peer or dialplan option, because some
providers will only send 183 and no 180 and in this case your patch will
work great, while others may send both, so simply ignoring the 183 will
provide ringback only when there is indeed a ringback tone and not some
other announcement (for example subscriber not available or similar), but
that's probably pushing it to far ;)

Whatever the solution, I think it will certainly be better than providing
no ringback at all.

Best,
Hristo


On Tue, Jul 16, 2013 at 12:33 PM, Steve Davies <davies147 at gmail.com> wrote:

> 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
>>
>
>
> --
> _____________________________________________________________________
> -- 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/0d5b3ca6/attachment.htm>