<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>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 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 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 class=""><div class="h5"><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>--<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></div></div></div>