Virtual extension, PSTN FMFM confirm no answer not working?

Hi folks.

I have a call flow that routes via a time group/time condition to a virtual extension, which has FindMe/FollowMe to an external PSTN number. See configuration in this image:

The intent is to confirm these outbound calls, and if not answered, to route the calling party to another part of the dial plan via an announcement.
I have used confirm calls successfully for years on a number of ring groups, but I’ve not had to rely on the no answer fallback before.

When I try a test call the called party hears the confirmation announcement, and the calling party gets ring tone.

  • If the called party confirms the call, they are connected as expected.
  • If the called party does not confirm OR does not answer at all (in which the call goes to voicemail, and that records the announcement) the calling party eventually moves from ringing tone to busy tone, rather than following the no answer path to the subsequent announcement, as I’d expected?

I’ve created a PasteBin of the log in the last case, and I’d appreciate any wisdom. It proceeds as expected as far as line 491 where waiting for digits, then the no answer is triggered at line 546, but it goes to hangupcall at line 551 rather than the announcement I expected?

Is this linked to similar behaviour for custom extensions, because I’m not sure how to mark the virtual extension as “external” from the time condition that directs the flow toward it?
E.g. is there anything I can do in the “Destination matches” to tell it that this should get the full confirm call treatment? I can’t use a Misc Destination for this as it lacks confirm call altogether?

Any help gratefully received…!
Mike Thomson

Would this be a suitable situation to use a Queue rather than an Extension, I wonder?
It seems like overkill as there’s only one external PSTN “agent”, and my initial googling found this thread which suggests I might end up in the same position anyway?

Now I’m really confused. I altered the call flow so the Time Condition passes to a Ring Group, and that has one external number (with a terminal #) in it. It’s configured (as far as I can tell) like my other ring groups that do retrieve calls if not confirmed, but this new one is failing to reach the announcement and still dropping the calling party into busy tone after the answerphone picks up but doesn’t press 1…

Have you tried another announcement (like one you know works) to rule out the announcement as the issue?

Patebin of a working and non-working RG so we can see the difference.

Hi @comtech - thanks for replying.

I can confirm that adding an Announcement after the Time Condition, and before the Extension that has FindMe/FollowMe configured, causes it to work as expected!

I didn’t change the extension configuration, I ONLY changed the routing from Time Condition 2 → Announcement → Extension (working case) versus Time condition 2 → Extension (failing case).

Working case (link to Pastebin) with line numbers:

  • Incoming Route (001)
  • Languages (051)
  • Time Condition (bank holidays) (055)
  • Time Condition (office hours) (087)
  • Announcement (102)
  • Extension (106)
  • Calling FMFM number (260)
  • Answered call (487)
  • Confirm announcement played (494)
  • Nothing entered (500-533)
  • No answer fallback (542)
  • Announcement (568)
    (after this the remaining call handling is exactly as expected / hoped for.)

In this case the calling party gets ringing tone for the full 60 seconds while waiting for the called party to confirm.

Failing case (link to Pastebin) with line numbers:

  • Incoming Route (001)
  • Languages (051)
  • Time Condition (bank holidays) (055)
  • Time Condition (office hours) (087)
  • Extension (098)
  • Calling FMFM number (252)
  • Answered call (not did not confirm) (472)
  • Confirm announcement played (487)
  • Nothing entered (492-539)
  • No answer abort (546)
  • Hang up. (551)

Oddly, in this case the calling party gets ringing tone for only around 20-30 seconds, then busy tone. However, the called party is still hearing the confirmation announcement repeating, so it’s the incoming leg that is dropped first?

If I’ve done something wrong / assumed how it should work incorrectly, please let me know, but I’m willing to live with this workaround for now. If I should report this as a bug, would the attached PasteBins and the explanation in this thread be sufficient or would more be needed?

Cheers
Mike

I remember an earlier post about time conditions breaking CDR for FMFM, I wonder if this is related. This might be a bug. Certainly worth escalating to Sangoma.