Incoming call - Delay handling or never ring

if you want these for POTS lines, I don't know of an option. The underlying Zap channel answers the call prior to it being sent on to Asterisk. For other types of digital lines, you can use the fax delay on incoming routes for (1). For (2), you could always route the call to an announcement, using a very long silence first (e.g. silence/10 and chain several of those together in a recording if needed) and then choose the noanswer option on the announcement.

The issue you are encountering here is that the zap channel gets answered since that is what you are going to be using for alarms and probably faxes, and I don't think anything can be done about that to my knowledge.

zap will not answer a call before Answer, so all you have to do is put a wait() befor the answer

then (1) is already handled. And I'm now a bit confused on (2). Why not just use an inbound route and set the value really high for the wait?

rjenkinsgb - can you clarify on these, because they are appearing to look like you can already do both?

For (1), the incoming route has 'Pause after answer' - I believe this is how long the system listens for fax tones *after* answer, before continuing processing if fax is not detected.

There is no pre-answer Fax delay on incoming routes that I can see?

For (2), I realise there are ways around it by editing files or somewhat devious methods, I'm requesting something simple and obvious via the FreePBX interface - either a 'silent delay' ring group option or a separate 'delay' function that can be set up in the same way as a ring group etc.

Or, add a 'pre-process' type delay in incoming routes [as discussed for (1)]that would be useable both with and without fax handling enabled? This would take care of both requests in one go. It should default to zero but be settable up to high values, 120 seconds or so.

Just a refresh, still showing as 'Need Feedback' a couple of weeks on.

this will probably be moved to 3.0 seeing it is a feature request, but putting in 2.5 now to keep visible and make a final assessment in case it is considered more of a bug or real short coming.

OK - given the arguments made wrt to the pre-answer delay, I will consider that a deficiency in the current design since there are legitimate reasons to want that for the incoming routes and there is no reasonable way to achieve it. So I'll let that feature request slide in during this beta period.

As far as a no-answer option on ringgroups, it is not clear what you are trying to achieve with that? Also for that scenario, you can simply choose an announcement with the noanswer option prior to sending it to the ringgoup. If you there is a good reason for that, open up a new ticket for that request and clarify (and cross reference this ticket) once this is closed when the feature is added to incoming routes.

(In [6344]) add delay_answer field to incoming re #2913

(In [6345]) closes #2913 Add pre-answer delay option to incoming routes, rearrange the order of options on incoming screen