<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1887/">https://reviewboard.asterisk.org/r/1887/</a>
</td>
</tr>
</table>
<br />
<p>On April 27th, 2012, 10:55 a.m., <b>Leif Madsen</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">And further to the note, is there really no way to have such dependency on the announcement length having such an adverse effect to all the queue positions being announced? That is a really awkward way of having to handle things. I can imagine someone wanting to adjust the announcements dynamically through the Record() application so that they can update announcements, hold times etc...
I really don't like the dependency on the file length and the adjustment of the periodic announce values to provide a sane experience to the caller.</pre>
</blockquote>
<p>On April 29th, 2012, 4:11 a.m., <b>Olle E Johansson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Thanks for the feedback, Leif.
If you can find funding I'm sure we can find a way. For this customer, this is acceptable. And I'd rather document this than just let it slip by. Isn't that better?
/O</pre>
</blockquote>
<p>On April 29th, 2012, 9:11 a.m., <b>Leif Madsen</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I disagree that's better. Doing it right and giving the general community an experience that makes sense is important. There are so many things in Asterisk that were little one offs to fix a particular persons issue and then not cleaned up prior to merge, that you end up having to document around things, or the experience continuing changes over and over again. I think Asterisk has gone far enough that we should be doing it right, not just doing it for the sake of doing it.
I personally would not be comfortable with the feature going in as-is. If someone else in the community needs to finish the feature up so it works in a manner that many will expect, then so be it. If you need to continue supporting this as-is out of band for your customer, then so be that as well.</pre>
</blockquote>
<p>On April 30th, 2012, 1:25 a.m., <b>Olle E Johansson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Leif,
I think you are over-reacting to a comment I wrote to explain the system to users.
I am adding a new feature that is designed a certain way. You do not want different messages to your customers waiting in the queue to interrupt each other either in the new way of doing things or in the old way. In the current system you also have to adjust your prompts to make sure they do not overlap.
If you really want to your queue position messages to cut into your periodic messages, you can put them in your music-on-hold playlist and everything will work as it does now.
Please test the code before you get more upset. You will see that from a functionality standpoint it's a big improvement, just like the other reviewers say. Please don't let a comment that explains how users should work with the new feature upset you. If it still does, please explain to me how you want it to function so that customers waiting in the queue won't be confused by one prompt suddenly cutting in during another prompts play-out. I don't see a good way of handling that - but if you find one, we need to fix both the current code and this code.
/O</pre>
</blockquote>
<p>On May 9th, 2012, 12:42 p.m., <b>Leif Madsen</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">You misunderstand me. I'm not upset. I'm simply stating that, as best I understand the documentation, that if a prompt length changes, that a change to the configuration needs to be done. If that is not correct, then the documentation needs to be updated to reflect what the actual experience the administrator can expect is. If that is how it works (and please correct me if I'm wrong), then I personally do not think the feature should go in as-is. It seems counter intuitive to me that a configuration change needs to happen if the prompt length is going to change, especially something that has a direct effect on the callers experience.
There must be some method to determine if the prompt was playing while the position was changed in order to "hide" the extra position announcements from the caller. If not, then it seems like something that should be added in order to make the feature robust and complete for the community. I know you, as someone who teaches this stuff, has made it a point that a clean experience for the administrator is important so that things can be taught in a concise and sane manner. I'm just pointing out something that appears to reflect that value.</pre>
</blockquote>
<p>On May 9th, 2012, 2:30 p.m., <b>Olle E Johansson</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Leif. That problem exists TODAY in the current code. It just behaves differently in my code.i agree that it would be nice to fix that, but I think it should be fixed for both ways of playing prompts as a separate project. </pre>
</blockquote>
<p>On May 9th, 2012, 2:32 p.m., <b>Russell Bryant</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">With how long this thread has been going on, it could have probably just been fixed by now.</pre>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I am of the opinion that the issue being discussed here is not enough of a problem to stop this code from going in. The only time this is going to be a really big issue is if the announcements are so long as to overlap 2 (or more) 'position announcement' cycles, and if a user does that with app_queue today, they've already got a problem (their callers probably won't get any position announcements at all). Even if the caller hears two position announcements in a row, that's not awful... it's telling the caller what the situation is, which is better than we have now. Sure, it would be *even* better if that didn't happen, but as Olle said, that can be handled as a separate effort which also includes fixing the foreground-mode problems too.</pre>
<br />
<p>- Kevin</p>
<br />
<p>On April 26th, 2012, 9:42 a.m., Olle E Johansson wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By Olle E Johansson.</div>
<p style="color: grey;"><i>Updated April 26, 2012, 9:42 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Today, when a prompt is being played to a call waiting in the queue and an agent becomes available, the agent will not get the call until the prompt is finished. Both customer and agent is kept waiting.
With this rather big piece of code, we attach a generator to play prompts. The generator can, like all generators, be stopped at any time so that the agent (queue member) can get the call immediately.
The generator is now placed in app_queue, but could propably be moved somewhere else. It also changes functionality in main/say.c in order to be able to place those prompts in the same prompt queue for background processing. The same generator could be used to sevice conference bridges and maybe be added as a dialplan function at some point for background playlists.
</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Quite a lot of testing in our environment during the rather long time we've been testing this. Customer is happy.
There was some complaints from a bowl of petunias, which made me a bit surprised.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/19795">19795</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/trunk/apps/app_queue.c <span style="color: grey">(364000)</span></li>
<li>/trunk/configs/queues.conf.sample <span style="color: grey">(364000)</span></li>
<li>/trunk/include/asterisk/channel.h <span style="color: grey">(364000)</span></li>
<li>/trunk/include/asterisk/file.h <span style="color: grey">(364000)</span></li>
<li>/trunk/main/asterisk.dynamics <span style="color: grey">(364000)</span></li>
<li>/trunk/main/file.c <span style="color: grey">(364000)</span></li>
<li>/trunk/main/say.c <span style="color: grey">(364000)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1887/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>