Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

TCL and .au file questions

I have some 2821's that I was running tcl scripts referencing .au files, and saw some really strange results that I was wondering if someone could shed light on.

1.  I was able to get one tcl working out of 7 (14 if I count both routers).  I took that and cloned it 6 times for the first router, renaming and editing ONLY the reference of the sound file, and most didn't work.  After a reboot, a few more worked. For the ones that didn't, I cloned the good one again (same as before), and copied them to the router again, rebooted, and now they worked.  NOTE:  For the audio, I used Cisco's "music-on-hold.au" file cloned and renamed multiple times that wasy I was using something that I knew for sure would work.

2.  I had to reboot/turn the router on off to get most of the new tcls to take affect.  I am new to tcl's, but it seems like horrible behavior for something that runs a phone system (CME router) to have to be reboot for a simple file change...so is that normal, or a bug perhaps in the IOS or corruption, or something else I am missing?

3.  "Music-on-hold" wasn't the plan, so I swapped the sound files out with various sound files that were opened and saved as G.711 u-Law files using Sony Sound Forge 11, and most worked.  For the few that didn't, I recopied the files, and reloaded, and then they worked.

4.  I took all those files, and saved them to my tftp server.  I then dumped them all to the second PSTN...only 2 tcl/au pairs worked out of the seven.  I re-cloned a good tcl, edited it, and re-copied it, and it fixed a few more despite all the files having been identical to begin with since they were made from a single working file, and were all working on my first router!?  For a few of the hold out broken ones it was no good for whatever reason.  My fix was to go back and re-create the audio files again (identically to the way I had already created them mind you, no changes), and then re-tftp again, reload, and FINALLY two more started working.  The last one was really buggy, and took 4 tries, but I changed nothing in the creation, or transfer, and after 4 times, it finally worked.

I am using Win 7 with TFTP64 (32 wouldn't run properly) v 64.400, updated Sony Sound Forge 11, and I even tried pulling the CF cards, putting them in a card reader to copy all the files over to the CF that way (vs tftp), to see if it would work better that way...no difference).  Last, I tried taking one CF card, formatting the long way (no quick format), as fat16, and then copied the files, and then tried to just see if the working router would work using those files and that card like it was its first card...no good.  Some of it just wouldn't take.

Has anyone seen such ridiculous behaviour, or know what may cause such behavior, etc?  I have never seen anything like it before.

Thank you


134
Views
0
Helpful
0
Replies
CreatePlease to create content