Can anyone else who has the latest Distro installed (1.816.210.58 64-bit) do a test for me?
Access the speaking clock by dialing *60. Listen for 10 seconds of so. Hang-up, and call again, and see if it works.
When I call the second, third, fourth, etc., time, the call hangs up a second after completing.
The problem did not occur with 1.813.210 32-bit, and has not occurred in prior versions.
Can anyone tell me if this is unique to me?
For me it is not working at all. Here is the console output:
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Executing [*60@from-internal:1] Answer("SIP/102-0000001a", "") in new stack
-- Executing [*60@from-internal:2] Wait("SIP/102-0000001a", "1") in new stack
-- Executing [*60@from-internal:3] Set("SIP/102-0000001a", "NumLoops=0") in new stack
-- Executing [*60@from-internal:4] Set("SIP/102-0000001a", "FutureTime=1350294655") in new stack
-- Executing [*60@from-internal:5] GosubIf("SIP/102-0000001a", "1?sub-hr24format,s,1():sub-hr12format,s,1()") in new stack
-- Executing [s@sub-hr24format:1] Goto("SIP/102-0000001a", "en,1") in new stack
-- Goto (sub-hr24format,en,1)
-- Auto fallthrough, channel 'SIP/102-0000001a' status is 'UNKNOWN'And the dialplan is:
dialplan show app-speakingclock
[ Context 'app-speakingclock' created by 'pbx_config' ]
'*60' => 1. Answer() [pbx_config]
2. Wait(1) [pbx_config]
3. Set(NumLoops=0) [pbx_config]
[start] 4. Set(FutureTime=$[${EPOCH} + 11]) [pbx_config]
5. GosubIf($["${TIMEFORMAT}"="kM"]?sub-hr24format,s,1():sub-hr12format,s,1()) [pbx_config]
[waitloop] 6. Set(TimeLeft=$[${FutureTime} - ${EPOCH}]) [pbx_config]
7. GotoIf($[${TimeLeft} < 1]?playbeep) [pbx_config]
8. Wait(1) [pbx_config]
9. Goto(waitloop) [pbx_config]
[playbeep] 10. Playback(beep) [pbx_config]
11. Wait(5) [pbx_config]
12. Set(NumLoops=$[${NumLoops} + 1]) [pbx_config]
13. GotoIf($[${NumLoops} < 5]?start) [pbx_config]
14. Playback(goodbye) [pbx_config]
15. Hangup() [pbx_config]
Include => 'app-speakingclock-custom' [pbx_config]
-= 1 extension (15 priorities) in 1 context. =-I’m glad to read that it is in’t just me. If you go to your command prompt and issue this command:
amportal restart
The speaking clock should work, but only once, and then it will fail again.
AdHominem,
thanks for bringing this to our attention and filing the trace ticket as well.
This is clearly an Asterisk bug that was introduced at some point and we are checking to see if it is still broken in the latest release or not. I did confirm it is broken in 10.8.0.
Once we determine this we will decide if we want supply a work around to the Asterisk issue (probable solution) or require a working version of Asterisk to be installed if it is in fact fixed in the latest.
We’ll update this in the ticket as appropriate.
Philippe,
Can you give us any indication as to whether this bug is likely to affect other core PBX functions, i.e. does FreePBX use the Asterisk function that is buggy in any other dialplans?
I can confirm that the bug did not exist in 1.8.13.
I scanned and don’t think it is affecting other areas though given the nature of the bug and as odd as it is, I would be concerned.
The issue is the use of the invalid extension and in the case of speaking clock we use a goto command and expect the invalid extension to catch it.
The more common use of that is IVR’s in conjunction with the WaitExten command and that seems to work properly. There are some other places it’s also used but I think also in that same way.
However, I would be ‘nervous’ especially for a bug like this. It has the ‘feeling’ of some sort of ‘data corruption’ issue in Asterisk given that it works the first time and then after that fails so who knows what else is lurking out there related to this. I would feel most comfortable knowing the root cause in Asterisk, deciding it is relatively ‘harmless’ and thus providing a FreePBX workaround so as not to force people to upgrade Asterisk knowing this issue is not a big deal. I don’t know that at this time.
Philippe,
Thanks for your response.
If the talking clock doesn’t work, that’s not a big deal for me. My concern, however, is that the Asterisk bug causing it could affect more significant functionality.
I considered opening a bug report with Digium, but whenever I do that, they always ask me for information that is beyond my ability.
If you have time, I’d encourage you to open a bug report with Digium, or to verify that one is already opened and follow-up on the status.
AdHominem,
thanks. If appropriate we will open a bug report. Right now we were having discussions with them and furthermore, we need to confirm if the issue is still present in the latest Asterisk release as it could be a bug that is already fixed.
No problem.
If Tony will release a new distro version with the latest Asterisk, I’ll be happy to test it and report back.
Otherwise, if someone can give me instructions on how to update a Distro install with the latest Asterisk, I can do that as well.
I just rolled Asterisk 1.8.17 RPMS and problem is still there.
I did not even realized there was a 1.8.17 and 10.9.0 since Digium did not blog about it so my RSS feed never informed me. Will have a new Distro and upgrade scripts tonight or tomorrow published.
Tony,
If this bug affects core functions, it would be unfair to call any version later than 1.8.13 “stable.”
I’ve noticed that PIAF is using 1.8.13 as their default installation, and does not recommend going to 1.8.14 or above.
Speaking clock is not core function and the only thing at this time effected by this.
Sorry everything on the asterisk 8 is considered stable by us as Digium releases it as stable. We run it through our internal unit testing and if standard features work like make and receive calls and phones register and a few other things it is pushed out.
I agree that speaking clock is not a core function.
But, above, Philippe has explained why the bug underlying this issue might not limit its impact to speaking clock.
Out of interest I have a system 1.811.210.57-2 and speaking clock functions correctly. My other systems are on 1.815.210.58-1 and speaking clock not working. So this bug appeared somewhere between asterisk 8.11 and 8.15.
Thanks for that information. As I said, I have a 1.813.210 system and the speaking clock works. So, the bug was either introduced in Asterisk 1.8.14 or 1.8.15.
Just for fun I put this in globals_custom.conf:
[app-speakingclock]
exten => *60,1,SayUnixTime()
exten => *60,n,Hangup()
This might be good as a workaround until the asterisk problem gets fixed.
Yep…That’s a good work-around…
Thanks!
BF
Bill,
I know you’ve been around a long, long time. I’ve found many of your comments useful, and so I’d like your thoughts on this:
Would you use this version of Asterisk?
Are you not concerned that the bug might cause more severe problems?
What version of Asterisk do you use?
I’ve written many of the instructions contained on this site and would like to write something up on “rolling your own.” Would you be able to assist me in writing up something on that subject?
To tell you the honest truth, I’m running Tony’s commercial version … It’s using asterisk 1.8.15.0, so I’m taking Tony’s lead on this. Really didn’t know there was a problem, until I saw it here. I really haven’t seen any other anomalies in the operation or functions here. System seem to be stable and operating nominally.
I’ve pretty much stayed away from rolling my own, relying on the various distros dating all the way back to Asterisk @ Home, Trixbox, etc.
The main reason we went with the commercial version, is that I am thinking about retirement and didn’t want to leave the city high and dry.
BF
As of today we are using 8.15 or 8.16 in thousands of installs and this bug only effects the speaking clock so please dont worry about it.