Skip to main content

Add and Assign

Posted by George on Mon, 04/12/2010

It would be great if when adding a new DID or more so a set a DID's to be able to click on Add and Assign to a tenant OR in the current tenant..

Thanks
George


Submitted by moshe on Mon, 04/12/2010 Permalink

I give my vote for it as well

If you go for more options in the tenant creation window there should be a csv field where one should be able to add and assign to that tenant DID's

Submitted by brian on Tue, 04/13/2010 Permalink

+1 for add and assign - was thinking the same thing this evening as I was adding a new DID's for a tenant or even after you submit the new DID's if they showed up and allowed you to assign at this point. Sometimes you need to add 2 did's for a customer. You add the DID's and you just get the full list of DID's again. You then need to search for the DID's you just added and then assign them..

Submitted by eeman on Tue, 04/13/2010 Permalink

i have to agree.. I dont think there was ever a time I added a DID and didnt immediately have to go assign it. I suppose someone might be loading a whole list of DID but not me :-). Paying a per did per month fee; I'm not going to buy 500 unused DID and load them up ahead of time.

Submitted by George on Tue, 04/13/2010 Permalink

We do both, singles AND we have services were we buy DID's in blocks of 20-25, the MRC is only pennies a month so its not a big deal having then BUT doing this 2-4 times a month plus all the singles gets to be a real pain in the butt.

That being said it gets real over either way you do it there are a lot of unneeded steps you have to do..

How about it Alex..?

Thanks
George

Submitted by thirdlane on Tue, 05/18/2010 Permalink

As you may know - this was added in .81. Any other suggestions regarding DID management?

Would it be useful to "type" DIDs so that the type is tied to services customer purchases (this would be also reflected in inbound routes and we would have to map scripts to these types)? Like DID for extension, for IVR, conference room, etc?

Submitted by eeman on Tue, 05/18/2010 Permalink

absolutely not.. that would just screw up the ability to change the role of a DID without deleting and re-adding the damn thing just because you want to change the script. That would totally shit-can useful troubleshooting for example when you need to re-direct a infrequently used DID of a customer to their daytime IVR for late-night testing.

Submitted by eeman on Wed, 05/19/2010 Permalink

unbelievable.. after all the complaining about how the UI is slow you want to fill it full of reference material and turn it into a CRM? they are mutually exclusive goals. Use a CRM.

I don't want to hear from anyone about the slow UI if this gets implemented. I'll just direct everyone to this post and let them scream at you instead of me. In fact I think I'll follow up on some of those threads now. One step forward, two steps back. worst idea ever.

Submitted by George on Wed, 05/19/2010 Permalink

unbelievable :)

first - I haven't said anything about the reload speed..

second - its a pain to manage 2 lists as we are doing now PLUS having customers with hundreds of numbers (400-600+) in its current form managing numbers in MTE SUCKS !!! ALL OF IT!!

DID management is the worst part of MTE, if you only have a couple numbers per tenant I can see how you wouldn't understand..

third - This would have nothing to do with the extremely slow reloads..

Thanks
George

Submitted by kenlee on Wed, 05/19/2010 Permalink

Adding non phone system related record keeping at the cost of web page load times would be a step in the wrong direction. If anyone other than sysadmin's are expected to use the web interface without creating animosity towards thirdlane, and the service provider, the page load times need to go down. I would consider that a much higher priority than adding non functional reference fields to DIDs.

Submitted by George on Wed, 05/19/2010 Permalink

if that's the case then ALL DID information should be removed from MTE and have your gateway server do the pointing to the tenant, this will help speed up the reloads..

hey while your at it lets removed ALL admin, tenant, huntlist, call groups, conference rooms, extension, routing in and outbound, scripts - in general ALL descriptions from the system.

Hey who needs descriptions anyway its pointless, useless, worthless information anyway RIGHT??

DID information is just as important as a phone, extension, scripts and everything else I listed above.. Again if all you have in tenants with 1-2 numbers your not going to see the point, with large customers having hundreds of DID's under 1 tenant it is..

Submitted by eeman on Wed, 05/19/2010 Permalink

hosted edition is not the same thing as MTE .. theres some things to really pay attention to..

1) across all the dom-U's (guest domains) you can only have a grand total of 200 concurrent calls

2) the minimum requirements are not enough to run but a couple of dom-U's

3) the theorectical maximum number of dom-U's they predict is just 20 tenants per server. this is with no call recording, 64gig of ram, dual quad-core xeon 5540's blade servers. This is approximately $5000 per blade. The reality is actually about 10 dom-U's per blade. Thats $500 per tenant with 10 times the hardware and 10x the power/cooling to host the same number of tenants. Comparably MTE can accommodate 1000 tenants on a single $4000 box which is $4 per tenant instead of $500.

4) There's still timing issues for virtual boxes despite all the recent hacks to dahdi.

5) MTE just has to carve out different contexts for the tenant while only running 1 kernel, 1 instance of asterisk, 1 ftp server, 1 sql server, etc etc. dom-U's have to replicate copies of everything which is much less efficient and why the yield is so much lower.

forgot a big one
6) aside from the $500 per tenant in hardware cost there is still switchvox licensing on top of that for each dom-U and per seat. While MTE has a licensing cost, its much lower when you aggregate it across all the tenants/seats that the machine can accommodate.

Submitted by mattdarnell on Wed, 05/19/2010 Permalink

I think the GUI needs to remain as quick and responsive as possible.

Non phone system related information should be stored elsewhere.

-Matt

Submitted by ajinderisngh on Thu, 08/12/2010 Permalink

1. we should be able to remove AND list it by country and cities ( area codes )
2. Admin should have rights to put a DID on hold that a customer does not want so it goes to some one else
3. hosted PBX means DIDs ( DID inventory is very important )

Also the code for the people or company to sign up should be not encrypted so we can change the look and feel or at least the wordings

Submitted by eeman on Thu, 08/12/2010 Permalink

ajinderisngh, it was explained clearly why area codes are not a specific match to country and city. It was explained why area code is not even in the same place in every country. It was explained that in some countries a 2 digit area code span several cities. Even in the land of NANPA area codes span several cities.

Maybe you should RTFM when your stupidity exceeds the ability to grasp what has already been explained in a forum thread about parsing a number to determine origin.

first read how the NANPA numbers are allocated

http://www.nanpa.org

then read how other countries do not use these standards at all

http://en.wikipedia.org/wiki/Telephone_numbering_plan#Standards

You're asking for a complex feature that has nothing to do with a switch. Perhaps you've seen someone else's interface and were so inept you did not realize that:

  • they wrote the whole thing themselves
  • it involved hundreds and hundreds of programming hours to build
  • they didn't not try to insist on all their challenges be done for them for free
  • it applied to a single country
  • the very expensive SONUS equipment or Broadsoft equipment does not come with this

If you want these features that bad, do what every other major carrier does, write your own portal database for DID sorting using programming logic for what ever country you came from. This has no place in your switch. The job of the switch is to process calls, not to be your CRM, or your customer signup portal, or your billing platform.

Also the code for the people or company to sign up should be not encrypted so we can change the look and feel or at least the wordings

there is no code for people or companies to sign up.. are you even on the right forum? I know that you never bothered to comprehend anything else written, so perhaps you have a reading disorder and assumed that this was also the website for your billing software?

Submitted by eeman on Thu, 08/12/2010 Permalink

The evidence just keeps pouring in. Nice grammar by the way, did mommy have to go to work leaving you all alone to compose those sentences all by yourself? It is YOU that clearly lacks the faculties to understand, not the inverse. If you don't want to be treated as someone who is stupid then do not make the mistake of asking the exact same questions multiple times on the forums when you have already been given the exact reason why your request is invalid. That behavior will get you banned from the forums.

Submitted by ajinderisngh on Thu, 08/12/2010 Permalink

Its not 1000 of lines of code, its for easy of the customer or partition holders to get a idea what number they are pulling

there are too many area codes in north america and world , when we add a did if there is one more column to add country and city thats all

all though its not today but i am sure when this product matures futher more, this will be added

its like first and last name with a extension ( if some person does not get what I am talking about - DO NOT answer THIS question )

why do we need to add first and last name with extension

SO

why not have country and city with a DID

Submitted by eeman on Thu, 08/12/2010 Permalink

the field is already there.. its just not called country/city its called Description. Fill it out. IF you want to organize your Description field by Country/City then do so. there is no reason to ask for more sortable fields when that field works perfectly well. You will have to fill this out for each and every DID you add to the system.

Submitted by ajinderisngh on Thu, 08/12/2010 Permalink

by my name u should know I am not English native, keep ur answers limited to professional and not personal

do not kindly include family members, remarks that make you and your company look very bad

keep things simple ,, if there is confusion ask for person phone to talk to them ,, get to know people ,, we are here helping each other and not correcting grammar and making remarks on some one's mother

have a wonderful day again

Submitted by George on Thu, 08/12/2010 Permalink

see what I mean ajinderisngh, they don't get it.. is separate sections you would be able to sort search and so mush more.. it would make DID management a dream not the disaster it is now..

hehehehe like I said there are ALOT of agree and others that clearly don't get it.. thier arguments are weak..

good luck maybe you can explain better then I did..

Submitted by eeman on Thu, 08/12/2010 Permalink

Here's something you can chew on... If i have to write a portal that can identify every number on the planet and determine what city and country that number is in... you will pay $10,000 per license key not $3000. Of that I can promise you. Why? Because a feature like that is worth $10,000. If you are going to be making the sort of $$ that a portal like that can bring in then its only fair you pay $10k annually. Unless you are willing to commit to that price increase there is no point in beginning the code.

I know exactly what platforms already do these sort of things and which ones require you to write your own. Of the ones that do this, I know exactly how much they charge annually and its well north of $10k USD. The exception to this is user contributions. User contributed code and data structure is added without impacting the licensing cost of TL. So you always have the option of developing the code yourself and contributing it for free to the MTE platform to keep the cost down for everyone.

Considering the fact that most of the customers of MTE didn't bother to put the numbers into MTE in E.164 format in the first place, they are going to have an uphill battle re-doing every single DID already installed on their system. Most have either left the country code off entirely, or inserted the 00 on their DID numbers which is not actually part of their number. The only way you are going to have a universal system is to enter every number in E.164 format. this still does not resolve the issue of variable lengths of country and area. A simple parser will not work. Instead the same programming tools used to rate international calls have to be used to identify location.