Then if your job requires internatuonal calling privileges your best toll is a reporting one. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431
Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: [email protected] <[email protected]> To: Tony Graziano <[email protected]> Cc: sipx-users <[email protected]> Sent: Sun Feb 21 13:24:30 2010 Subject: Re: [sipx-users] "forward calls external" permission I don't have customers. I have users. This was an employee purposely stealing from the company so he didn't have to pay to call his mother in africa. Yes, in my situation, it was a thief. Sent via BlackBerry from T-Mobile -----Original Message----- From: Tony Graziano <[email protected]> Date: Sun, 21 Feb 2010 13:04:56 To: [email protected]<[email protected]> Cc: sipx-users<[email protected]> Subject: Re: [sipx-users] "forward calls external" permission 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/
