> On Thu, Apr 16, 2009 at 10:37 AM, Peter Fowler <[email protected]> > wrote: >
Peter one of my favorite applications :) > > Wondering about a Auto Attendant enhancement to provide DISA as > follows: > DISA probably makes more sense in the VoiceMail User side, not the AA, > as I'll show below: > > > 1) administrator maintains a list a CLID numbers corresponding to > users that > > have DISA privileges > I'd do this with adding a DISA user privledge. > +1 > > 2) external DISA user calls into Auto Attendant (typically via cell > phone > > speed dial) > External users call into their voicemail, thus they have authenticated > themselves with a valid passcode. Callers in to AA aren't > authenticated, so thus DISA makes more sense (to me) in VM, not AA. > But if it's put in AA, then the caller would have to enter their user > extension and passcode to be validated before we would place external > calls in their name. > Maybe nice to make this a service that has its own routable extension. This way it could be reached from your own personal VM greeting or a companywide Auto Attendant. > > 3) based on CLID number, caller is given option to make an external > call > Based on DISA user privledge, not CLID. CLID is too easy to fake, and > not authenticated. > CLID is ok but I think it's a secondary part of this. > > 4) caller prompted to enter phone number (via voice prompts) > VM would then make external calls with the user's credentials. Thus > anything the user is allowed to call would be allowed, and anything > they cannot would not. > Would also be very nice if the system was kept in the Audio path. So at the end of a call you push a DTMF digit and be able to dial another call without having to authenticate again. > > 5) would need a report on DISA activity of course > Of course! > Nice but I wonder if we couldn't try to use CDR for this and somehow categorize the CDR's better. Simply add a report to the new reporting capability. I believe Martin has an issue on categorizing CDRs already. > --Woof! > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
