Call Limit--Send to Voicemail

[Jonathan Black]

We use the call_limit dialplan in conjunction with the max_calls variable in domain_variables dialplan. This works by ringing busy after the limit is reached. However, we'd rather handle this by sending to voicemail instead of ringing busy. I've tried changing the action/limit data in the call_limit dialplan from:

hash inbound ${domain_uuid} ${max_calls}!USER_BUSY

to:

hash inbound ${domain_uuid} ${max_calls}*99100

to send the calls to vmail for ext 100, but it isn't working. It looks like the transfer to voicemail sends the call back through the dialplan, which hits the call_limit again, and hangs up the call.

Anyone have ideas on how this might be made to work?

 

[Jonathan Black]

Should have been a space between ${max_calls} and the last bit. My copy/paste messed up, sorry. The lack of the space is not the problem though--it's correct in my dialplan, but still isn't working.

 

[whut]

try changing your *99100 to transfer:*99100 XML customerdomain.jonathan.com

 

[Jonathan Black]

try changing your *99100 to transfer:*99100 XML customerdomain.jonathan.com

Thanks for the suggestion. Unfortunately, it still seems to be going through the dialplan multiple times. So it's going through the dialplan and hitting this

EXECUTE ... limit(hash inbound <domain UUID> 1 transfer:*99100 XML test.mydomain.com

about 66 times over several seconds. The last time it is followed by:

Hangup sofia/external/972XXXXXXX@sip.telnyx.com [CS_EXECUTE] [EXCHANGE_ROUTING_ERROR]

and the call hangs up. Maybe that was a timeout? Anyway, all the other times, it is going all the way through the dialplan and hitting "not-found", then starting over.
The call generated over 4000 lines of logs, so here's the tail end of one iteration through the dialplan (not-found) and the beginning of the next (caller-details):

a2901275-6e60-4ab6-94da-d42ed013fb87 Dialplan: sofia/external/972XXXXXXX@sip.telnyx.com Regex (PASS) [not-found] () =~ // break=on-false
a2901275-6e60-4ab6-94da-d42ed013fb87 Dialplan: sofia/external/972XXXXXXX@sip.telnyx.com Action set(call_direction=inbound) INLINE
a2901275-6e60-4ab6-94da-d42ed013fb87 EXECUTE [depth=0] sofia/external/972XXXXXXX@sip.telnyx.com set(call_direction=inbound)
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] mod_dptools.c:1673 SET sofia/external/972XXXXXXX@sip.telnyx.com [call_direction]=[inbound]
a2901275-6e60-4ab6-94da-d42ed013fb87 Dialplan: sofia/external/972XXXXXXX@sip.telnyx.com Action log(WARNING [inbound routes] 404 not found ${sip_network_ip})
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] switch_core_state_machine.c:281 (sofia/external/972XXXXXXX@sip.telnyx.com) State Change CS_ROUTING -> CS_EXECUTE
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] switch_core_state_machine.c:640 (sofia/external/972XXXXXXX@sip.telnyx.com) State ROUTING going to sleep
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] switch_core_state_machine.c:581 (sofia/external/972XXXXXXX@sip.telnyx.com) Running State Change CS_EXECUTE (Cur 2 Tot 494)
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] switch_core_state_machine.c:647 (sofia/external/972XXXXXXX@sip.telnyx.com) State EXECUTE
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] mod_sofia.c:213 sofia/external/972XXXXXXX@sip.telnyx.com SOFIA EXECUTE
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] switch_core_state_machine.c:323 sofia/external/972XXXXXXX@sip.telnyx.com Standard EXECUTE
a2901275-6e60-4ab6-94da-d42ed013fb87 EXECUTE [depth=0] sofia/external/972XXXXXXX@sip.telnyx.com set(caller_id_number=972XXXXXXX)
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] mod_dptools.c:1673 SET sofia/external/972XXXXXXX@sip.telnyx.com [caller_id_number]=[972XXXXXXX]
a2901275-6e60-4ab6-94da-d42ed013fb87 EXECUTE [depth=0] sofia/external/972XXXXXXX@sip.telnyx.com set(RFC2822_DATE=Mon, 05 Jun 2023 10:32:12 -0500)
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.348545 99.57% [DEBUG] mod_dptools.c:1673 SET sofia/external/972XXXXXXX@sip.telnyx.com [RFC2822_DATE]=[Mon, 05 Jun 2023 10:32:12 -0500]
a2901275-6e60-4ab6-94da-d42ed013fb87 EXECUTE [depth=0] sofia/external/972XXXXXXX@sip.telnyx.com export(origination_callee_id_name=transfer:*99100)
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] switch_channel.c:1315 EXPORT (export_vars) [origination_callee_id_name]=[transfer:*99100]
a2901275-6e60-4ab6-94da-d42ed013fb87 EXECUTE [depth=0] sofia/external/972XXXXXXX@sip.telnyx.com limit(hash inbound b9350c57-786a-4c1d-9eb2-89ea56cd39d3 1 transfer:*99100 XML test.mydomain.com)
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] switch_limit.c:124 incr called: inbound_b9350c57-786a-4c1d-9eb2-89ea56cd39d3 max:1, interval:0
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [INFO] mod_hash.c:180 Usage for inbound_b9350c57-786a-4c1d-9eb2-89ea56cd39d3 is already at max value (1)
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] switch_ivr.c:2288 (sofia/external/972XXXXXXX@sip.telnyx.com) State Change CS_EXECUTE -> CS_ROUTING
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [NOTICE] switch_ivr.c:2295 Transfer sofia/external/972XXXXXXX@sip.telnyx.com to XML[transfer:*99100@test.mydomain.com]
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] switch_core_state_machine.c:647 (sofia/external/972XXXXXXX@sip.telnyx.com) State EXECUTE going to sleep
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] switch_core_state_machine.c:581 (sofia/external/972XXXXXXX@sip.telnyx.com) Running State Change CS_ROUTING (Cur 2 Tot 494)
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] switch_core_state_machine.c:640 (sofia/external/972XXXXXXX@sip.telnyx.com) State ROUTING
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] mod_sofia.c:149 Call appears to be already acknowledged
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] mod_sofia.c:158 sofia/external/972XXXXXXX@sip.telnyx.com SOFIA ROUTING
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [DEBUG] switch_core_state_machine.c:230 sofia/external/972XXXXXXX@sip.telnyx.com Standard ROUTING
a2901275-6e60-4ab6-94da-d42ed013fb87 2023-06-05 10:32:12.368546 99.57% [INFO] mod_dialplan_xml.c:639 Processing Diamond Voice <972XXXXXXX>->transfer:*99100 in context test.mydomain.com
2023-06-05 10:32:12.368546 99.57% [NOTICE] switch_cpp.cpp:1465 [xml_handler] single key:dialplan:test.mydomain.com
a2901275-6e60-4ab6-94da-d42ed013fb87 Dialplan: sofia/external/972XXXXXXX@sip.telnyx.com parsing [test.mydomain.com->caller-details] continue=true
a2901275-6e60-4ab6-94da-d42ed013fb87 Dialplan: sofia/external/972XXXXXXX@sip.telnyx.com Regex (PASS) [caller-details] () =~ // break=never

It seems like either it won't work in this scenario, or else I need something to break it out of this loop.

 

[whut]

I think you need the ! delimiter before the transfer

hash inbound ${domain_uuid} ${max_calls}!transfer:*99100 XML customerdomain.jonathan.com

 

[Jonathan Black]

With that change, it looks like it's immediately triggering the hangup. Are you sure that ! is not just a shortcut for "hangup"? Here's the relevant log portion:

fcb0e60c-57bc-4f54-9698-184748269e48 EXECUTE [depth=0] sofia/external/972XXXXXXX@sip.telnyx.com limit(hash inbound b9350c57-786a-4c1d-9eb2-89ea56cd39d3 1 !transfer:*99199 XML test.ivrnetworks.com)
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [DEBUG] switch_limit.c:124 incr called: inbound_b9350c57-786a-4c1d-9eb2-89ea56cd39d3 max:1, interval:0
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [INFO] mod_hash.c:180 Usage for inbound_b9350c57-786a-4c1d-9eb2-89ea56cd39d3 is already at max value (1)
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [NOTICE] mod_dptools.c:4816 Hangup sofia/external/972XXXXXXX@sip.telnyx.com [CS_EXECUTE] [NORMAL_CLEARING]
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [DEBUG] switch_core_session.c:2973 sofia/external/972XXXXXXX@sip.telnyx.com skip receive message [PHONE_EVENT] (channel is hungup already)
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [DEBUG] switch_core_state_machine.c:647 (sofia/external/972XXXXXXX@sip.telnyx.com) State EXECUTE going to sleep
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [DEBUG] switch_core_state_machine.c:581 (sofia/external/972XXXXXXX@sip.telnyx.com) Running State Change CS_HANGUP (Cur 2 Tot 512)
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [DEBUG] switch_core_state_machine.c:844 (sofia/external/972XXXXXXX@sip.telnyx.com) Callstate Change RINGING -> HANGUP
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [DEBUG] switch_core_state_machine.c:846 (sofia/external/972XXXXXXX@sip.telnyx.com) State HANGUP
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [DEBUG] mod_sofia.c:468 Channel sofia/external/972XXXXXXX@sip.telnyx.com hanging up, cause: NORMAL_CLEARING
fcb0e60c-57bc-4f54-9698-184748269e48 2023-06-05 12:41:30.128549 99.77% [DEBUG] mod_sofia.c:613 Responding to INVITE with: 480

I tried again with just !*99199 but it still immediately hung up at that line.

I then repeated it without the !, and it looped again a bunch of times. But I noticed that this time, it was getting to the "send_to_voicemail" dialplan. But because it was also passing through the "call_limit" dialplan every time, the "limit" action would kick off another pass through the dialplan.

So I made this change:
- Added a "call_limit_vmail" dialplan which is basically a copy of the "send_to_voicemail" dialplan.
- Changed the condition to:
- Changed voicemail_id=199 (Ideally, this would use a variable set in domain_variables)
- Added an "answer" right before the lua action.
- Changed the Order for the dialplan to 24 (right before "call_limit") and set continue to "false".
See screenshot below

Then in the "call_limit" dialplan:
- Changed to:

hash inbound ${domain_uuid} ${max_calls} call_limit_vmail

And it seems to be working. The "call_limit_vmail" shows up as destination in CDR, but for now, that's ok.

 

[whut]

I understand the ! as a delimiter. Seeing your work I believe this is still separating the USER_BUSY but is separating it as the sip hangup cause. Work workaround was a great idea! Good job on that!

I agree with your setting a variable in the domain-variables. If you wanted a different vmail box per DID you could have groups within this dialplan or domain-variables dialplan and add a second condition "if DID = 1234". That group/dialplan then would be setting voicemail_id= to your desired ID.

 

[Jonathan Black]

That's certainly possible. However, in legacy key/PBX systems, if I recall correctly, I think ! was a switchook indicator, so I'm not sure what it means. And it's really hard to search for info on "freeswitch !" and get anything relevant. All the examples I see are using the !USER_BUSY, and not routing elsewhere.

I did go ahead and add a domain variable, and then I'm considering making the following tweak to the "call-limit" dialplan.
That way, if you don't populate a value for "upon_limit_send_to_vmail", it just responds with a busy like it does now by default. If you populate that, then it routes accordingly. And then in the "call_limit_vmail" dialplan, it does:


I'm not sure if this kind of change will be accepted as a PR, though, and I don't want to get my system overall too far from the project.