To my knowledge this works in this way:
caller (The person, who initiate the call [Ex. Clients])
callee (The request person. The person with you want comunicate. [Ex. internal Employes])
The problem i have here, is that i set this for incoming calls
But the problem is that, both can use the feature *77, the client and the internal staff.
I’m using callee that means that only the request person, just the Internal Staff have to be able to sue the *77 feature. No the client!
DYNAMIC_FEATURES determines whether or not a party can use the feature. The caller/callee bit indicates which channel the application connects to when it is running, i.e. who will hear any output it produces, etc., and is not a security mechanism.
I don’t mean any security issues.
I want to make a feature that JUST allow the callee to use the feature
Just incoming calls answered by internal staff can decide if use the feature or NOT.
To be clear, i want this
Client call via PSTN to office -----> Staff answer (If the Staff want to use the feature, OK. just press *77)
But in me case, this is happening:
Client call via PSTN to office -----> Staff answer (BUT THE CLIENT IS ABLE TOO TO USE THE FEATURE, and i don’t want that.)
The point, both can use the feature, But i just want that the feature can be able JUST by the person who answer the call. to to who originate the call.
When is a security feature not a security feature.
I don’t think you can stop the calling party having this capability, if the called party does, because the only access control is the channel variable. The other way round, you might be able to use _s to limit the access.
You may be able to get somewhere by setting the variable in sip.conf, etc., rather than the dialplan.
caller => Allow access to use X feature to the person who originate the call
callee => Allow access to use X feature to the person who answer the call
But it doesn’t work!
Please, test what i’m posting then write an answer plz. Is not a security issue for the love of good.
It’s a simple way to decide who can use X feature and who NOT. is not a security case, is a functional case.
Th caller|callee in an application map it defining which channel will hear/have the application applied to.
It is not todo with restricting access to it. once defined asterisk just sits there listening for the digits.
I assume what you want is the feature changed so that access to a dynamic feature can be controlled similar to transfer and onetouch recording.
Actually there is an access control field, but it is the third field, not the second field, which means that, if you are using a version that supports it, your remaining parameters are in the wrong fields.
You should also note that:
Macro is deprecated, and its simulation by an internal Gosub may not work properly in less common cases, and this could be one of those.
There is a warning in the features.conf.sample that features like this are not run in a full PBX context. In fact, the IMPORTANT NOTE specifically says do not use it to run Macro or Gosub, or at least it does in 1.6.1.0.