<div dir="ltr">Thanks Steve!<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 ;)</div>
<div><br></div><div>Whatever the solution, I think it will certainly be better than providing no ringback at all.</div><div><br></div><div>Best,</div><div>Hristo</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Jul 16, 2013 at 12:33 PM, Steve Davies <span dir="ltr"><<a href="mailto:davies147@gmail.com" target="_blank">davies147@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<div><br></div>
<div>In case it is not officially uploaded, I will state here that this code is "disclaimed" and "unencumbered" as if uploaded to JIRA.</div><div><br></div><div>Regards,</div>Steve<div><br><div><div><div class="h5">
On 15 July 2013 17:20, Hristo Trendev <span dir="ltr"><<a href="mailto:dist.lists@gmail.com" target="_blank">dist.lists@gmail.com</a>></span> wrote:<br>
</div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div class="h5"><div dir="ltr">
I think I have found the answer to my questions in the source code of Dial:<div><br><div><pre style="word-wrap:break-word"><font color="#000000"><span style="white-space:pre-wrap">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);
}
}</span></font><span style="white-space:pre-wrap">
</span></pre><div>.....</div><div>.....</div><pre style="white-space:pre-wrap;word-wrap:break-word"><br></pre><pre style="word-wrap:break-word"><font color="#000000"><span style="white-space:pre-wrap">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.<br>
</span></font></pre></div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 4:14 PM, Hristo Trendev <span dir="ltr"><<a href="mailto:dist.lists@gmail.com" target="_blank">dist.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<br><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?).</div>
<div><br></div><div>BR,</div><div>Hristo</div></div>
</blockquote></div><br></div>
</div></div><br></div></div><span class="HOEnZb"><font color="#888888">--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></font></span></blockquote></div><br></div></div></div></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br></div>