input on script idea

yes, its called operator managed routes. You cannot use it in conjunction with schedules.. you are either going to manually change your mode or your going to use your schedule. Trying to manually change a mode inside a schedule will only irritate and confuse your customer because in his/her mind they have manually set something yet the schedule is superseding what they just changed.

I understand that.

What they are looking for is an easy way to forward all calls to their auxillary office quickly and easily in the event an emergency comes up.

Right now, if they want to forward all calls to the aux office, i forward it at the sip DID provider.

i was hoping to just change it in asterisk with a quick code sequence.

they need the schedule to remain.

any ideas?

only for single tenant. OR since the PBX is actually online, surf into their portal and just change it there.. i really doubt that both their office internet and their cell service is out at the same time. Im trying to _remove_ as many chan_local instances as I can, not add more. The damn channel causes lockups and doesn't pass enough data between the other channel drivers when bridging. So feature codes is not going to be the best way to do this.. besides this isnt 1985, we dont have to rely on DTMF to make changes to the PBX, theres a web interface.

I would suggest adding an extra schedule that has a basic forwarding rule, but put it at the end of your schedule list.. somewhere where it wont even get used..

schedule vacation schedule - vacation ivr
schedule daytime schedule - daytime ivr
schedule all hours schedule - night time ivr
schedule another-all-hours schedule - forwarding script

then its as easy as logging in, clicking the up button next to the another-all-hours schedule twice so that its in front of the daytime schedule.. click save. wait for reload.

I like your proposal however, it would be best if they could enter in a code to enable that schedule to be the high priority.

is there a way to run a cgi script that does 'Set(db/tenant/.......' which puts it in place?

They actually want a button on their Polycoms to toggle it, however this is later configurations.

even if its a php script where they browse to www.somewebsite.com and nothing but a text box to enter a number and a button that says forward.

we dont allow them to manage these things. however as of now, we handle it.

just trying to meet their expectations and keeping it as simple as possible.

even if its a php script where they browse to www.somewebsite.com and nothing but a text box to enter a number and a button that says forward.

So some generic website is OK but the admin portal (a different website) is not?

I like your proposal however, it would be best if they could enter in a code to enable that schedule to be the high priority.

Have you even considered the security risks associated with these unchallenged features? Do you realize how many stupid people there are, even on these forums, that still make IVRs and leave the 'allow calling feature codes' checked? Did you not spend time in the 80s making black boxes and red boxes? Do you have any experience at all with phone phreaking or computer hacking? Have you atleast played a multi-player online game so as to know what kind of person goes around deliberately trying to cause grief to someone in order to feel better about themselves?

Those same people dial into PBXs all the time looking for hidden 'easter eggs' as they call them. Meanwhile the clueless customer realizes after a couple hours that his calls keep getting re-routed somewhere like.. oh 911 maybe. Instead of taking responsibility for asking for such a bad idea, they instead get angry with you for 'allowing' this to happen in the first place. Why do you think my macro-tl-set-daynight script requires a passcode? To protect the customer from his/her own stupidity and to keep them from threatening to sue me for lost revenue because they let some yahoo dial in and turn on night mode some 40 times in a single day.

They actually want a button on their Polycoms to toggle it, however this is later configurations.

the very request means this isn't an occasional thing, this is exactly what operator managed routes was built for. Having an operator set day, night, and temporary modes are completely opposite of having automation do the thinking for you. To make a case for an emergency need to once in a lifetime forward calls somewhere else is not the same thing as suggesting that its so frequent they need a button on their phone because clicking something 3 times is 'just too much work'. This very request implies an almost daily event. Like it or not, they need to turn off the scheduler and just toggle their modes themselves. Just tell them to convert to operator managed routes and their life will be so much easier, just make sure the receptionist turns on night mode before leaving for the day.

That is incorrect.

I understand the security risks and that is the very reason i was getting a confirmation as i posed the risk as a question to my initial submission.

Furthermore, the scheduler is set so the client does not have to think. The phones should just work and behave.

They dont have a receptionist since this is not that type of business and I guarentee that the request to forward happens one night out of 1-2 months for the case when they have company meetings and they need their nyc office branch to pick up the calls.

When you replace an old phone system with a new one, being this, i would think as a provider you would do everything you can to at least give them back the same functionality as they had previously.

What ideally i would be looking for is a single website login, Yes on yours, that they can log into and forward much similar to extension logins.

the feature already exists under inbound routes.. you just aren't using it correctly.

user logs in
user goes to inbound route for specific DID
user changes behavior to desired new behavior
user clicks save

the feature exists, this is your interface. It might not be the exact same interface but that's not any different than any other aspect of life. Things evolve over time. Pulse dialing is being removed off the PSTN as we speak. Winding a generator on the phone to ring the remote operator is no longer necessary. Having to call a LD operator in order to place a LD call, no longer necessary. The PSTN is soon to become the PRTN. Analog, CDMA, and TDMA cell phones almost have no networks left to work over.

To program something different such as what you asked for is possible, but not in MTE, as I have said. If your user wants a hybrid of scheduled and operator routes _that bad_ he/she needs to purchase STE for the customizations. I am just not willing to entertain a situation where endless amount of tenants be given the ability to screw with Global variables in an environment that they can deny service to other tenants. Additionally the nature of setting Globals via a handset does not survive a reload (something MTE does hundreds of times a day potentially).

The reason for this limitation has to do with previous owners of PBX Manager. I previously requested (September 2008) the global variable section of inbound scheduled routes get replaced with DB keys but the concern of existing installations using globals as an override prevented the change. DB keys can survive a reload/reboot, they are easy to set with dialplan, they do not require giving out the keys to your system for users to make changes, they scale much better than globals, users cant accidentally mess with other globals and break everyone's setup. Fear that someone might actually be using globals to skip schedules and break what they've had running since asterisk 1.2 prevented this change. Therefore, since the existing mechanism is global variables, it is not possible due to the dynamic environment that exists with MTE.

I suppose now that there is going to be a clear division in PBX Manager where version X is going to support asterisk 1.8 and those wishing to run it must upgrade to 1.8, we could also specify that the global variable section of inbound routes will be replaced with a more appropriate DB key. It would take more than just me to convince Alex that Global's was a flawed concept from the start and that its time for it to go away. This 1.8 version will be the most likely jumping off point since most people will do a clean install in order to get these new features (some features disable themselves due to naming conflicts with existing systems, such as conference room numbering).

then its as easy as logging in, clicking the up button next to the another-all-hours schedule twice so that its in front of the daytime schedule.. click save. wait for reload.

Where is this clicking of the up arrows.

I am using asterisk 1.4.26.3

Erik,

I totally agree with you about globals - you don't have to convince me :).

It was (as many other things) inherited from single tenant where it made more sense, and then kept for backward compatibility.

On a tenant level there is a "Custom tag" field that can be used as a tenant level database variable - but clearly it is not meant for the end users.

I think at some point we would have to make a clean break where customers will have to go through migration in order to use new version with new features. I know this will make some customers unhappy, but that is what every company does - at some point products get replaced rather than upgraded. We will do our best to make this migration as painless as possible, but I doubt that it can be fully automated.

its an up button labled 'move up' its right under the 'move down' button and right above the 'remove handler' button

Got it.

I thought you were talking about the schedule tab in PBX Settings

Thanks.

Hi erik

this is off topic just reading trought this post,

schedule all hours schedule - night time ivr
schedule another-all-hours schedule - forwarding script

when ever Im doing 2 all-hours schedule or any same schedule twice Im getting notice and errors at the reload is it something i could intentionally ignore, or i should rather create multiple schedules even with same time slots this is actually how im handling till now

Thanks

i didnt say same-all-hours schedule

i said another-all-hours schedule

as in .. make a new schedule.. call it iman-idiot-allhours and set the times to * * * * *

that is how i do it, so i want to make sure it isn't a waste

thanks erik