Limit Max setting on extension is apparently ignored

I

iaindooley

New Member
Aug 16, 2024
20
0
1
48
Hi there,
The "Limit Max" field in the Extension form says:

"Enter the maximum number of concurrent outbound calls allowed."

I have set this to 1, however I am still able to make multiple outbound calls through that extension.

I also have the max registrations set to 1, however I use Ringotel which is an intermediary so that allows multiple devices to be registered while only holding one registration on the server.

If Ringotel submits 2 outbound calls, though, shouldn't the second one be denied by this limit?

Thanks,
Iain
 
Hi thanks for getting back to me, that is about limiting calls per domain, I am talking about the Limit Max setting on an extension.

Thanks again,
Iain
 
you know i've been having nothing but issues with getting the limit working... i have 3 lines and they are all SLA (lets ignore the fact that that is a hack and does not work anymore) so multiple-registrations is on, and i have limit set to 1 and 1max, well still allows calls in and out even if one is used... i checked the dialplan i do see 'call-limit' it checks for inbound|outbound but uses the limit.lua then does a hash inbound ${domain_uuid} ${max_limit} !USER_BUSY

so im not sure i get it, ! would let it in and why is it only looking at the domain_uuid should it not be the extetion? either way im working on just bypassing it and making my own dialplan for this issue, or just having a .lua script keep track of it.

this all used to work back in 2016-2019 then it stopped SLA and limit tracking, its simple, call/session extetion set the hash table, call hook the hangup and unset the hash, then have another dp above that to check the hash table of that extetion... nothing crazy
 
I ended up adding this line before the "bridge" in my outbound routes:

Tag: Action
Type: limit
Data: db ${domain_name}-outbound ${extension_uuid} 2 playback misc/misc-your_call_has_been_terminated.wav

I used db instead of hash because I run a replicated DB.

This limits outbound calls per extension to 2. The reason I chose 2 was that during testing I found that I couldn't do an attended transfer if I had it limited to 1.

You can use the "limit" Action similarly to limit any resource. I think in this case because extension_uuid is unique anyway it wouldn't have mattered (ie. I could have removed "-outbound" from the "realm" argument or even just had it as a fixed name like "outbound_limit" because extension_uuid is unique for all domains) but you can put anything instead of ${extension_uuid} for example caller ID or extension number or whatever.

The thing that makes it limit outbound calls is that it's in my outbound route. So if you wanted this to limit some other place like inbound calls then you'd have to put it somewhere on an inbound route.

I think for example if you had something like this:

db global ${domain_name} 2 playback misc/misc-your_call_has_been_terminated.wav

that would limit the total number of calls for any given domain name to 2. If you put that on an outbound route it would limit it to 2 outbound calls, if you put it on your inbound route it would limit it to 2 inbound calls. It could also go anywhere in a dialplan, so for example if you had some component as part of a call flow and you put a limit into that dialplan, then it would limit the number of concurrent calls that could pass through that component.

So basically the "limit" action just accepts 2 arbitrary strings: one is the "realm" the other is a "resource" within that realm, and it can be as local or global as you like.
 
iaindooley said:
I ended up adding this line before the "bridge" in my outbound routes:

Tag: Action
Type: limit
Data: db ${domain_name}-outbound ${extension_uuid} 2 playback misc/misc-your_call_has_been_terminated.wav

I used db instead of hash because I run a replicated DB.

This limits outbound calls per extension to 2. The reason I chose 2 was that during testing I found that I couldn't do an attended transfer if I had it limited to 1.

You can use the "limit" Action similarly to limit any resource. I think in this case because extension_uuid is unique anyway it wouldn't have mattered (ie. I could have removed "-outbound" from the "realm" argument or even just had it as a fixed name like "outbound_limit" because extension_uuid is unique for all domains) but you can put anything instead of ${extension_uuid} for example caller ID or extension number or whatever.

The thing that makes it limit outbound calls is that it's in my outbound route. So if you wanted this to limit some other place like inbound calls then you'd have to put it somewhere on an inbound route.

I think for example if you had something like this:

db global ${domain_name} 2 playback misc/misc-your_call_has_been_terminated.wav

that would limit the total number of calls for any given domain name to 2. If you put that on an outbound route it would limit it to 2 outbound calls, if you put it on your inbound route it would limit it to 2 inbound calls. It could also go anywhere in a dialplan, so for example if you had some component as part of a call flow and you put a limit into that dialplan, then it would limit the number of concurrent calls that could pass through that component.

So basically the "limit" action just accepts 2 arbitrary strings: one is the "realm" the other is a "resource" within that realm, and it can be as local or global as you like.
Click to expand...
Yeah, I get what you're saying—just surprised there's a call-limit in place and a domain-based restriction on trunked lines. No idea why they're doing it that way instead of using extension_uuid. Creating a call-limit per realm based on domain_uuid seems like it only limits total calls per domain, but I’d expect the dialplan to also check the vars defined in each extension under Devices > Extensions.


Mark’s clearly exhausted, and the codebase is massive. He’s made it clear he "owns it," even though it’s technically open source. The push rules are a bit much. Still, it's been a solid project overall, especially considering how often FreeSWITCH changes and breaks stuff—modules disappearing, things getting deprecated... it’s a moving target.


like i said before, some of this was a no brainer working before the refactoring
 
You must log in or register to reply here.
Top Bottom