Re: [sipx-users] "forward calls external" permission

Sun, 21 Feb 2010 13:53:50 -0800

Please don't address me as an idiot. I know how things work on these lists just as you do. I was inquiring for the purpose of determining what the next step would be to begin the process of reviving an old feature.

Also, please don't presuppose that every organization has the option for unlimited domestic long distance. As a local govt. entity in Texas we are required to use whoever wins the state contract AND/OR the incumbent telco for phone service. We pay relatively low per-minute charges via TEX-AN: http://www.dir.state.tx.us/store/tsd/rates/longdistance.htm#longdistance but those costs still have to be accounted for and if my employer would offer long distance calling passthrough as a "perk" for it's employees you'd see citizens with pitchforks and torches outside the courthouse!!

Additionally I didn't mean for this to sound like an 11th hour request. As of right now this is not a necessity but there is a legitimate need to block this functionality for those of us that aren't "blessed" with unlimited LD.

Responses like that cause me to lose respect for you. You're what I'd like to call a "senior member" of these lists so I take what you post seriously but in my opinion that was uncalled for.

Tony Graziano wrote:
On Sun, Feb 21, 2010 at 10:23 AM, [email protected] <[email protected]> wrote:
On 2/21/2010 7:49 AM, Raymond Dans wrote:
> I wonder if maybe introducing a User, time based set of permissions
> might help in this situation.  So for example user A has long distance
> permissions between the hours of 7 a.m. to 6 p.m. but not after that
> time.  Not sure of the complexity involved in implementing this, just
> throwing out the idea off the top of my head.
>
Wouldn't it need to be blocked in the personal auto attendant as well?
That would seem like a better place for the thief to set this up. They
could have multiple numbers that they could transfer out to, and it
would be harder for them to get caught. We had someone doing this
(different company, different phone system) and the volume wasn't high
enough to raise any flags. The only way they got caught was because
their boss called their desk after hours to leave a VM, and was
surprised when they reached the employees mother at her home instead. I
have no idea if blocking LD privileges at a certain time would affect
how the personal attendant worked as well.
_______________________________________________
sipx-users mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/


Thief? Ok, whatever you say.  What we find is the "opposite". We have customers who intentionally setup International calling for certain regions of the world with the intent that their employees are able to use it to contact family (as a perk, or benefit).

With the exception of International Dialling, all of our customers have unlimited domestic long-distance, so as long as there is no abuse during working hours that keeps people from doing their job, they don't really care. With the work force becoming so mobile, controlling it becomes an impedance to getting work done, and so on. So it seems I would look at your request as legitimate, but not on the same priority as you need.  Realize this could have been addressed "first", and it sounds like you jumped in without addressing this and other issues as an 11th hour need.

It would be proper to set an expectation based on what the system does, instead of what it can do "if someone changed the code". In that spirit, realize there are changes that would have to be made in order to add this to sipxconfig in order to satisfy the management goal of the project, whether it is schedule based or a plain permission. The changes have to involve sipxconfig too, and I suggest you open an enhancement request to see if it can be scheduled for an upcoming version, so you can set the proper expectations for your "boss".

Regards,

Tony

_______________________________________________
sipx-users mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/




_______________________________________________
sipx-users mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to