M. Ranganathan wrote: > On Wed, Sep 3, 2008 at 10:23 AM, Scott Lawrence > <[EMAIL PROTECTED]> wrote: >> On Wed, 2008-09-03 at 09:51 -0400, M. Ranganathan wrote: >>> Hello, >>> >>> The AT&T test suite calls for the ability to add PSTN numbers to hunt >>> groups. Would it make sense to add such a capability? If so I can open >>> a feature request. The current workaround seems to be quite inelegant >>> ( see discussion on user list). >> In order to allow an arbitrary hunt group to call an outside number, the >> hunt group itself would need to have an identity so that it could have >> the required permission. At that point, in effect you've created a >> user, so I think that the current workaround is sufficient. > > So I can be clear in my understanding (correct me if I am wrong). > When the PSTN number is dialed the identity will be the identity of > the hunt group. If that hunt group has the permission to dial (long > distance for example), then you should be able to dial the number. If > not it will fail on a security error. >
Huntgroups do have identities starting in 3.10: http://track.sipfoundry.org/browse/XCF-2021 There is no UI to assign arbitrary permissions but by default they have Long Distance enabled: so they will work for any dial rule that requires that permission. >> I can't see making a change that distorts our security model just to be >> able to check a box on test suite without documenting a workaround >> (which is already in wide use). > > > Hardly the reason for me proposing a new feature .... Let me explain. > > Each PSTN number you want to be able to add to a hunt group must have > a (pseudo) user. I feel this can be a user inconvenience. Perhaps one > should associate a pseudo user with a dial plan ( just thinking out > loud). May be less inconvenient. > There seems to be a misunderstanding here: fallback destinations to external number work without any tricks with pseudo users or dial plans. > Of course, usability is not my domain so I'll leave it at that. > Not being an expert never stopped anyone from anything - so let's not mention it any more ;-) D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
