Skip to main content

BUG WITH TENANT CALL LIMIT IN MTE

Posted by dannas@triadte… on Fri, 08/14/2009

Alex added the ability to limit the number of simultaneous calls per tenant which is a GREAT feature and works.

The problem is that if a tenant is allowed a set number of call paths and all of their lines are in use, when the next person calls in, instead of getting a busy signal, the caller gets a message saying that 'this number is not in service'.

Is there anyway this can be fixed?

- Don


Submitted by George on Sat, 08/15/2009 Permalink

I know of the limit being set on an extension, but see no place to set a limit on the temant.. please enlighten me to where that's set please.

now as for the message, that's the server sending an no route back to your upstream carrier, the easiest way around that is use something like a SER server to pass a busy back to the upstream provider..

over all I thought it was a bad idea to add this feature for problems just like what your having, what about a user extension thats set to forward to his cell, that taked up two routes, checking voice mail takes up one.. etc etc.. on the extension level you really need to set the number to twice the number of lines the phone has configured.

George

Submitted by dannas@triadte… on Sun, 08/16/2009 Permalink

We paid Alex to add this feature to MTE so that tenants could be sold a number 'lines' separately from a number of sip registrations/extensions. This is set under tenant management.

The features works great; however, if a client forwards their phone, it often only counts as one path which works out in the clients favor.

The message is coming from the Thirdlane MTE implemntation and not an upstream provider.

- Don

Submitted by eeman on Sun, 08/16/2009 Permalink

I believe it only works in one direction too. I do this sort of thing on a gateway machine where I do a few other things like streamline the CDR for billing and route calls back to my clients in the event one client calls another etc. Its also helpful for those that want to force specific callerid numbers when someone calls 911.

Submitted by George on Mon, 08/17/2009 Permalink

interesting, I set a tenant to 3 concurrent calls and made 6 calls into it.. I then set it to 1 concurrent call and made 4 out going calls and 3 in bound calls..

what am I missing..

yes Eric, we do much of the same, thought I'd check this feature out but.. ^^

George

Submitted by eeman on Mon, 08/17/2009 Permalink

there is a global variable you must set to enable it. if your install predates the feature look in /usr/libexec/asterisk/configs/asterisk (or something like that) for the extensions.conf that gets copied over on a new install to learn the global variable name.

Submitted by dannas@triadte… on Tue, 08/18/2009 Permalink

The issue where an inbound call receives a 'not in service' message when the lines are full. He is going to fix this so that it rings busy as it should when there are no more lines available.

I have tested this feature quit a bit and the concurrent path restrictions do work well. The only time the client has the ability to slip in an extra call let is when they use the call forward.

It does do a good job of counting inbound and outbound calls towards the total as you would expect when mimicking 'lines'

Submitted by eeman on Tue, 08/18/2009 Permalink

instead of playing a busy tone, which pisses off upstream providers and keeps a call on your system longer than needed, simply omit any sort of playback (keeps caller from getting billed) and send Hangup(17) which sends a sip '480 Busy Here' message. This will backtrack via SIP and SS7 all the way back to the caller's switch which will take care of busy tones.

Also be aware that if you do not make a different type of handler for 911 calls that avoid tl-dialout-base then your customers will not be able to place 911 calls when other lines are in use. You may already have this disclaimer in your 911 policy or you might not have considered the ramification. I, personally, decided to let my customers call 911 call-count be damned :) Its not like they can abuse it without finding themselves in a precarious situation with the police department.

Submitted by eeman on Tue, 08/18/2009 Permalink

just wanted to add that on many SIP interop tests with providers like Level3, broadvox, verizon, paetec, etc REQUIRE you to send a 480 when busy; its part of the test you must submit with captures.

The nice thing about hangup cause codes is that they work with PRI and SIP. The only time sounds would be needed would be on an analog line but no one would be insane enough to use analog lines for MTE (no DNIS ) and STE users don't have this feature. So regardless if the user had MTE connected to PRI with a quad-span card, or if they were using SIP trunks to a provider, Hangup(17) will send the correct busy message back to the carrier.

Submitted by George on Tue, 08/18/2009 Permalink

FYI I have a 1.4 server installed using the current TL MTE ISO and its not working on that server either..

Submitted by eeman on Tue, 08/18/2009 Permalink

exten => s,n(enabled),GotoIf($["${TL_ENABLE_MAXCALLS_CHECK}" != "1"]?allclear)

looks like its ENABLE_MAXCALLS_CHECK

Submitted by dannas@triadte… on Wed, 08/19/2009 Permalink

Do you know how I would go about changing the busy response? Currently, if all lines are used, the next inbound call gets the 'no longer in service message'. I would much rather return a SIP BUSY as you mentioned above.

- Don

Submitted by eeman on Wed, 08/19/2009 Permalink

manually you can edit each one in inbound.include but every save of the inbound route from the GUI will overwrite it. This particular fix requires it to be made in the webmin module which is encrypted.

Submitted by dannas@triadte… on Thu, 08/20/2009 Permalink

And he anticipates having an updated webmin module within 1 week to fix this issue. Thank you Erik.