<br><br><div class="gmail_quote">On Sun, Mar 27, 2011 at 2:50 PM, Mohammad Khan <span dir="ltr">&lt;<a href="mailto:beeplove@gmail.com">beeplove@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Here is the dialplan in macro:<br>
<br>
exten =&gt; s,n,SayNumber($[${ARG1} % 100])<br>
<br>
when 662 was passed as ARG1, I had the following at log:<br>
<br>
WARNING[15217] pbx.c: We were unable to say the number 62, is it too large?<br>
<br>
Do you see any odd in my dialplan?<div><div></div><div class="h5"><br>
<br></div></div></blockquote></div>662 % 100 = 66.2, not 62. It seems to me that there&#39;s more going on here..Maybe Asterisk is being confused by actually getting 66.2? I&#39;m not readily able to look into the source, but I <u>think</u> that Asterisk (or at least, SayNumber) cannot handle a number with a decimal point, but please don&#39;t take that as gospel. <br>

<br>If Tilghman&#39;s question doesn&#39;t result in a fix, the next thing I&#39;d say is to check and make sure that a floating point number can be supplied as an argument to SayNumber. <br><br>Also make sure you&#39;re logging verbose, debug, error, and warning messages into a logfile, bump the verbosity and debug up to 5, and then run another test call that will result in the number(s) you&#39;re testing. Next, send off a larger amount of the content from the logfile, the single WARNING line is not enough for anything more than a blind guess. For instance, it would be REALLY fantastic is you would send the log line that displays SayNumber actually being executed, like ( <i>[DATE&amp;TIME] VERBOSE[23609] pbx.c:     -- Executing [s@contextname:priority] SayNumber(&quot;CHANNELNAME&quot;, &quot;66.2&quot;) in new stack </i>)... It would be even MORE fantastic if you included almost ALL of that call&#39;s log output, but at the very LEAST there should be around 5 lines, starting from the verbose output for execution of SayNumber. That way, we don&#39;t just get the warning message you&#39;re complaining about, but the EXACT executions and messages outputted leading up to the warning message. <br>

<br>But then again, you could continue to do essentially the same thing and hope for different results...<br>