This post is at: ForumFeatures Wanted
4 posts / 0 new
Last post
isrighthere
isrighthere's picture
Joined: 2008/02/14
Points: 0

Hi,

I have a feature request for you to take a look at if you have the time. We have the need to allow tenant to tenant calls on our MTE thirdlane using the tenants DID’s. taking a poke around I have found that if I edit the outbound.include file and add the following line into the [outgoing-$tenant] context my requirement works e.g.

[outgoing-thirdlane]
#include inbound.include

However there are potentially 2 issues with this method (I’m sure you can think of many more )…
1) This file could get overwritten on a config change
2) I don’t know what the resource impact of doing this would be, because as I see it the file include command presumably eats up memory for every tenant so the bigger your tenant list/DDI list the worse the server gets effected.

An alternative idea that I think would be safer from a resource perspective would be to do the following:

1) Outbound.include
Edit the build template to add the line:
include => inbound-include

2) inbound.include
Add a context reference to the top of the file:
[inbound-include]

This method would obviously need any other files that reference #include inbound.include to be change to use include => inbound-include

What do you think? Is this a viable option would the context idea work for inbound.include ? this way I think you could also add logic for a “allow tenant to tenant DID calls” check box somewhere under the tenant or global PBX settings and do some test logic for that value. Let me know if this is something you would consider adding in the future..

Many thanks.

eeman
eeman's picture
Joined: 2007/11/06
Points: 290

you forgot an even bigger issue... variable call length invoked by the user... ie 11 digit, 7 digit, 10 digit, E.164 (11 digit with a leading + ) . This is why I have a gateway infront of MTE and every call that travels across that gateway is done in E.164 so that some dope dialing 555-1212 gets transalated to +18125551212 and had a 100% change of matching my +18125551212 on my inbound list of numbers. Whereas your inbound.include might show

8125551212

and if your user just dialed 5551212 or 18125551212 its just not going to match at all.

Erik Smith
dCAP
Thirdlane/Asterisk Support available
esmith.bgnv@gmail.com

isrighthere
isrighthere's picture
Joined: 2008/02/14
Points: 0

Hi Erik,

This will not be an issue for us as all our inbound.include numbers are of the format 01189881xxx and we have outgoing dial-plans that convert the numbers accordingly. so for example:

_NXXXXXX then prefixes the local area code e.g. 0118

Our experience shows it's a 50/50 mix of people who dial local calls without the area code. e.g. 01189881xxx versus 9881xxx almost nobody would bother dialing +441189881xxx to dial a UK regional number from within the UK, but if they do I am happy for that to be bounced up to our ISDN gateway appliance and back down again to the PBX as it would be so infrequent.

It just seems pointless to pass the call outside of the pbx-mte if you don't need to, if some calls get missed and have to be bounced back, then that's fair enough as long as 99% of the time we catch it.

:)

eeman
eeman's picture
Joined: 2007/11/06
Points: 290

but you do realize that just because NXXXXXXX adds the extra digits doesnt mean shit for your

#include inbound.include

statement. That ship has already sailed by the time your macro is adding extra extensions. Those include statements only give a crap based on what the phone sent. The only way around that is to send _NXXXXXXX back into the same context.. like..

exten => _NXXXXXX,1,Goto(0188${EXTEN},from-inside-redir,1)

otherwise some 7 digit pattern isnt going to match your 011 pattern because you didnt dial it, regardless if you stick it on there in the end, the pattern already matched. So instead of 6 patterns all invoking your sip trunk, you have 1 pattern that invokes your sip trunk and 5 others that just loop adding translations.

Erik Smith
dCAP
Thirdlane/Asterisk Support available
esmith.bgnv@gmail.com