On Wed, Sep 3, 2008 at 11:00 AM, Damian Krzeminski <[EMAIL PROTECTED]> wrote:
> 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.


OK.  Thanks for your answer on the user list. Makes sense.

Ranga

>
>> 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
>



-- 
M. Ranganathan
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to