Terminate Call: Play ringtones to caller until they hang up (no answer option)

in most situations where people use these destinations (ring, moh, etc.) it is usually where they are simply trying to "dump/ignore" the caller. As such, they usually don't care if the call is answered (e.g. caller pays) and answering in order to play ring-tones is usually more reliable since early media on channels varies. Now in the case of ringing though, one might argue that we should just send it to a "wait" forever if the channel is not yet answered and let what ever is naturally generating ringing on the far end to keep it up, and only play the ring-tones if the call is already answered.

What is your usage scenario out of curiosity that you are caring that it is answered vs. not?

It's a case where a person who no longer lives where a particular number terminates occasionally receives automated messages. Apparently if the line is answered, then the device plays a message and considers the information delivered. This is not desirable in this case, since that person is no longer there, so we don't want the calling device to record in its database that the number was answered and that the message was delivered.

I can, of course, do this easily enough in a context in extensions_custom.conf, but it seems to me like it shouldn't even incur that minor degree of difficulty, particularly when FreePBX gives you the option in other cases (such as when playing an announcement) to answer or not answer the call. Really, for the sake of consistency, whatever's played through the terminate call option should give the option to answer or not answer.

If you really need to answer the call - make a anounsment play a 0.1 second silent wav and then send it to Play ringtones to caller...

We should not answer calls if it's not really needed - the meter starts ticking.

In the case of a number that has been vacated by the original user, but that you still want to hang onto for some reason (particularly if it's a free DID and not costing you anything), some of the calls may be from people who are NOT telemarketers or crank callers. The could be regular callers who knew the former user, and I just don't want them to get charged for the call if they happen to be using a traditional landline.

It all sounds reasonable. My internal debate is - do we change what is there for the ringing option (as well as the Congestion option) is do we remove the Answer (and add a "Progress()" which is probably needed)? Or do we add yet more options and have a Answer & Play Ringing (which is what it is now) as well as a simple "Ringing()"

My gut feeling is to just change what is there and see if that is adequate since it is more "right" not to answer. And then see if there is feedback during beta testing if that is breaking otherwise existing dialplan that we need to address? Feedback for or against this approach is welcome.

Just out of curiosity, would it be difficult (from a programming standpoint) to have it so that if someone selects "Terminate Call", the dropdown that shows the various options would appear as it does now, but then after the user selects one of those options, where appropriate a third dropown would appear, containing two options: Don't answer call | Answer call (with Don't Answer Call being the first choice, and the default)? My thought would be that if the user selects "Hangup" you would never answer, or if they select "Put caller on hold forever" you would always answer, but with all the other options there is a chance that someone might want to answer the call, but that should not be the default behavior.

Another possibility would be to simply increase the number of options in the dropdown that's already there. for example:

Answer and play Busy tones
Do not answer, play Busy tones
Answer and play Congestion tones
Do not answer, play Congestion tones
Answer and play ringtones to caller until they hang up
Do not answer, play ringtones to caller until they hang up
Answer and play SIT tone (Zapateller)
Do not answer, play SIT tone (Zapateller)
Hangup
Put caller on hold forever

In my opinion that's not so many options as to be unwieldy, and would still let the user choose the desired behavior. But I don't know if either of those ways of doing it would be too complicated to code.

I think this is partly related for the feature request of being able to answer a call as soon as it hits an inbound route. If we implement that, that would keep the list much cleaner, and then we dont have two offer two sets of options

That would work also, but if you do that please make sure it honors the Pause Before Answer setting (so that if the user chooses to answer the call as soon as it hits the route, it will still delay the numbers of seconds in Pause Before Answer and THEN answer).