fields added to DIDs

any comment on this feature request..?

Adding the ability to put more information in the like - rate centers - States - DID Type and having the ability to lookup and sort by this information..

I wanted to check to see how this enhancement was coming since it seems the SQL poart is moving along..

with all the DID, from different rate center, cities, states, we have requested more fields be added to the line items for DID, making then easier to see and locate by for example

DID - Rate Center - Type - City - State to name a few.. being able to sort by any of the current and lsited fields..

what would you like to see here..

Erik, by a posting I saw your customer base is about 25% larger then our, how are you dealing with DID management.?

everything in a single list, very limited to no ability to break them down my City, State or area code rate center is becoming a major problem..

how are you dealing with that..

ALSO

how are you handling time stamps for customers in a different time zone other then the one the server(s) are located in..? we get a LOT of complaints about the missed call, voice mail time stamps being off by hours..

Any input you can provide would be great..

Thanks and Thanks for all the support you provide here

George

Persident / CEO

AxisInternet, Inc.

www.axint.net

in voicemail.conf.sample

; Users may be located in different timezones, or may have different

; message announcements for their introductory message when they enter

; the voicemail system. Set the message and the timezone each user

; hears here. Set the user into one of these zones with the tz= attribute

; in the options field of the mailbox. Of course, language substitution

; still applies here so you may have several directory trees that have

; alternate language choices.

As far as the DIDs are concerned, I just add them at the time I bring on a new tenant. Out of the pool of DIDs I have, only a small amount is part of a residential pool loaded into MTE. If I bring on a new tenant, I inevitably am porting their current numbers which requires a manual add of those DID anyway. Another aspect of our business might differ from yours as well. We dont subscribe to the more traditional voip model where every handset has a DID number assigned to it. When we bring on a tenant they might only need 1 or 2 DID for the entire virtual pbx entity. Our pricing is based on a small $10 monthly recurring per extension pricing plus a $25 per month per call path price. Its entirely possible for a tenant to have 10 handsets, just 3 DID numbers and 5 call paths. If they need more DID than they have call paths we can do that too, by selling a block of 10 DID numbers for $30. Its structured more the way a company w/ PBX and a PRI connection would experience.

Our single-tenant solutions work similarly (without the per extension fee). We sell them trunked IAX2 connections and they pay us for call paths and DIDs in addition to T1 internet service. Using the right balance of codec and trunking you could stack more than 150 call paths on a single T1, though I would encourage redundancy if they were doing 150 simultaneous calls. I have had a lot of success with no overhead using G.726 + iax2 trunking over T1 links.

Thanks for the replay Erik,

I'm not a programmer but am working with our guy to see the simplest way to handle this. we have quite a few customer in other states and several have remote offices all over the country.

It would be MUCH simpler and VERY useful if thie could also be set on the tenant level and on the extension level with out having to do into the script to make these changes..

Thanks

George

Thanks again Erik,

our design is very simular to yours with the exception of we stock about 100 numbers in several cities around the country, as a result with the limited DID management it is a constent problem and slows looking up and sorting DID's down and with out knowing the area code of a city makes it hard for our people to get quick results for our new customers looking for numbers. Currently we have to keep a seperate data base with numbers , city and state information, but the problem is if someone forgets to update it we wind up offering numbers that have already been taken..

I was hoping you have something you could recommand..

Guess we're just going to have to wait for Alex :(

Thanks again for the responce..

George

Erik,

I took your advice, it worked, well kinda

here are the problems that I'm running into

1) set the time zone for the user (ext) in the voicemail.conf when playing the message back on the phone or by dialing into the system the time stamp is correct. great!

BUT if you go to the user portal the time stamp is set to the server time, TL is only reading from the stamp file not taking into account the user is in a different time zone.

2) the time stamp in the e-amail attachment is also wrong, it shows the servers time zone.

3) if a user makes ANY change at all to their voice mail settings TL over writes your settings and removed the tz= attribute

of course what comes next , RING the customer calls all pissed off that AGAIN that our stupid system is screwed up AGAIN and we have to go back into the voicemail.conf file and re-add the tz= attribute back in again..

not to mention everytime we provision a phone (linksys) that goes to a different time zone, we are constently manualy editing files that should be set in the user (ext) config..

this is one of my biggest customer complains from CA, IL, FL to NY everyone not in our time zone.

this is a maintance nightmare

George

George, there is absolutely nothing you can do about unix timestamps on a multi tenant box. It is the same issue someone experiences with their webstats when different customers exist in different time zones. Thats why many websites run their servers on UTC and leave it up to the customers to use a little trick I like to call 'math'. To address some of your issues, here are some ideas

2) edit your voicemail.conf and remove ${VM_DATE} from your emailbody= configuration. Honestly, this sounds like a bunch of overly unnecessary whining from the customer. The email message itself has a date/time stamp in UTC that is automatically timezone adjusted by the email client. Remove ${VM_DATE}, since they are aparently too lame to understand this concept, and force them to look at their email date/time stamp if they want to know the time. This problem extends beyond the body of their email, however. I have news for them, their CDR is also in the timezone formatted for the unix machine and their schedules are based on the timezone the server is set to. This leaves you with 2 choices

a) put your unix server on UTC time and make everyone do the conversion.. hey such are the consequences of globalization. Believe it or not but when I buy software in europe I have to pay in.... gasp... Euro's! not American dollars. Its a 1980s mentality to expect every timezone and country to conform to a small group of people. Even in the US doing business with companies involves adjusting your communications based on their timezones. Gone are the days where the whole world conducts business based on EST and the US Dollar. We just arent the center of the universe any more.

b) set up 4 MTE servers one for each timezones to appease the whiners. This is the only way to make CDR and scheduling match timezones. This represents a rather costly financial impact for you but would most certainly solve your problem as long as you don't take on customers from nova scotia, hawaii or alaska.

3) until tz= can be added to MTE for a tenant setting to append to voicemail settings, I would remove 'Manage Voicemail Settings' from the user portal option entirely. Honestly, changes in this area are different than the other user portal settings. This is the only menu screen that triggers a 'reload' of asterisk and I guess I have an issue with letting end users reload my pbx at whim.

4) If linksys doesnt let you specify timezones in their config files I would pick a more flexible phone. I am not familiar enough with them to say one way or another. But if they dont support config file provisioning I would jump ship. Why? Because, PBX manager in MTE allows for tenant level config file customization. Not only can you customize in user_provisioning/ but you can make tenant specific customizations in user_provisioning/tenantname/ . For polycom phones this means being able to use a specific local-settings file for each tenant so instead of a single local-settings.cfg file I have models.txt create:

output_2=${TENANT}-settings.cfg

Which lets me provision every tenant uniquely. Some might want their logo on the backsplash etc.

Erik,

Asterisk does support time zone settings for mailboxes in the voicemail.conf file for a reason and it does work just fine. The ONLY issues we have is that the Thirdlane interface ...

1) Does not support setting it in the voicemail settings

and

2) When we do manually set it, the Thirdlane interface overwrites and eliminates our settings.

So, looking at this all, it is VERY clear that the issue is NOT 'whining customers', but rather the lack of support in the Thirdlane interface for time zones.

Linksys does support setting the time zone in the config files, again same problem applies, lack of support in Thirdlane interface. It also needs to be set manually for each phone or set of phones sent out, and edited again one at a time if there is a configuration change of any kind..

This is a necessary setting on every version of Thirdlane single (remote users) and MTE

Lastly we have customers with offices all over the country, doing what you do on the tenant level doesn't work either, this needs to be set on the user (ext) level.

Thanks

George

but your CDR and schedules are not multi-regional. What gets logged to the cdr is the time based on the timezone the server is set to. It sounds like your customers are likely to take issue with that also. Having thirdlane dress up the timezones only helps you with the user portal, the VM_DATE is not localized, even though it was requested on the forum multiple times. If all you want is a localized setting of each 'user' that logs in, thats an easy javascript. However, this doesnt sove the VM_DATE or CDR or scheduling problems.

Scheduling is easy, set it to the tenant, or clone several for different offices in different time zones.. not sure why you keep bringing it up, its not only not relevant but not a problem.

CDR, not sure there is a way around that.. plus multiple offices or remote offices in different time zones isn't going to be pretty unless its all on one time zone anyway..

On the other hand checking voice mails and getting time stamps hours ahead or behind the correct time stamp of the message being left is NOT acceptable on any level..

And this is something that can be easily correct..

George

i have created the in bound routes but the in comming calles are not landing according the caller id number it is landing on any did any cid