promt re-recording ignoring file type

recordings are made in the same format used when dialing *77. And if you had multiple recording types because you manually uploaded multiple formats, it wouldn't know which one to make.

This is further complicated because FreePBX does not store the type and it is not worth the complexity to check the file and parse it to determine the type dynamically. It could be done but...

So at this point, closing as wontfix, since it records in the same format as was done to create the file, it's fine. If you want to add a feature to set the recording format that it and *77/*99 always use, you are welcome to do that, although the cleanest thing to leave recordings in is a linear format unless you know every phone and trunk on the system is going to be encoded into something else and then use that.

well then set the default to sln, which is always asterisk perfered. Otherwise, if a recording is originaly in sln, using the feature code will re-record it in wav, which will never be played.

(and if you are saying that the file gets re-recroded in the same format tat it was originaly - well that would be ideal, but its not the case)

lazytt - *77, *99 and the auto-generated feature codes all use the exact same macro:

exten => *77,1,Macro(user-callerid,)
exten => *77,n,Wait(2)
exten => *77,n,Macro(systemrecording,dorecord)
exten => *99,1,Macro(user-callerid,)
exten => *99,n,Wait(2)
exten => *99,n,Macro(systemrecording,docheck)

as do the auto-generated feature codes to edit them:

exten => *2924,1,Macro(user-callerid,)
exten => *2924,n,Wait(2)
exten => *2924,n,Macro(systemrecording,docheck,custom/DayTimeMessage)

The only difference is that *77 uses a default name before it is renamed when you save it:

exten => s,1,Set(RECFILE=${IF($["${ARG2}" = ""]?/tmp/${AMPUSER}-ivrrecording:${ARG2})})

So the format is going to be the same. I understand you might not make the original recording using the *77 feature code, but as mentioned, if you start getting fancy such as multiple formats, it would not know what to do and as it stands, it is generating the same format as it used for *77 (it's the same code).

so lets ask this questions differently: what are the benefits of wav vs. recording to sln in the first place?

the tracker is not a place to discuss the last question. For now closing this as wontfix - it records in the same format as using *77 to make the original recording and is designed as a companion to that feature - if anything, I guess we should delete any other versions as that may be a bug? (in case you have one format there, this records a different format, and then you have some instances where the other format is chosen and the old message is played?) If you think that is an issue, then that may be an appropriate bug but lets test it first to see what happens in that scenario.

already did. and thats what i mentioned before: "...sln, which is always asterisk perfered. Otherwise, if a recording is originaly in sln, using the feature code will re-record it in wav, which will never be played. "

lazytt, that is not how Asterisk works, it picks the lowest cost translation as far as I have always understood it. So there are times when it would pick different files that may not be sln if better were available.

(In [6553]) closes #3142 delete all forms of a recorded file before re-recording so that there are not transcoded versions left around that say some thing different

Replying to p_lindheimer:

lazytt, that is not how Asterisk works, it picks the lowest cost translation as far as I have always understood it. So there are times when it would pick different files that may not be sln if better were available.

true. So in the case of a call on g729 we would perfer a recording in g729 (vs. sln). but being that I never heard of a device that work in wav, wav is defiantly not the ideal codec.

However encoding from sln is easiest as it is 'raw' and no decoding is required first.

wav is a container, which is effectively a linear format for Asterisk (vs. WAV). If you use sln, you can't listen to your file in the System Recordings GUI with most plugins, so wav is a better format and has the same cost (for all practical purposes).