Possible BUG using self/callee, self/caller

Asterisk Asterisk General
1

Hello.
This is the scenario.
feature test1 is use to play a message X to the client.
feature test2 execute a macro and have to be used JUST by an internal staff in my company. (My Employes)

O.K.
Incoming calls from PSTN to our company looks like this:

This part WORKS fine!

[from-pstn] exten=>s,1,Answer() exten=>s,n,set(__DYNAMIC_FEATURES=test1) ; JUST staff on company can run this features exten=>s,n,Dial(SIP/201)

HERE IS THE BUG
The employes phones (in sip.conf) are configured to use context [phones] to allow my employes (caller) to execute the feature test2 when they make a call (in features.conf)

[phones]
exten=>_1XXXXXXXXXX,1,Answer()
exten=>_1XXXXXXXXXX,n,set(__DYNAMIC_FEATURES=test2) ;JUST INTERNAL PHONES CAN EXECUTE test2 when dialing out

HERE IS THE BUG, for example my employ call a client for example to request an invoice, if staff (my internal employe) execute the feature test2 to make a Transfer, then the call is Transfered and answered to another internal phone in the our company…, at this point the CLIENT can execute the feature test2 if press 23 :S and NOT the Staff WHO answered the transfered call. O_O??

[applicationmap] test1=>22,self/callee,Macro,test1
test2=>23,self/caller,Macro,test2[/code]

I think the BUG is this:
When our employes dial a client and then, our staff press 23 to execute the feature test2 to Transfer the call, OK when the call is Transfered and answered by other of our Staff… At this POINT i think Asterisk Confuse and transform the caller as callee and the callee as caller. Why i think that? Because when the call is Transfered and answered by our internal staff, in that point the STAFF, press 23 trying to Transfer the call to other person again and NOTHING Happen (THE CLIENT HEAR THE DIGITS) and the CLIENT is allowed to ACT as the caller for that reason he can execute the feature test2 (23)

Please… I just want this work fine…
…ideas…?

2

It seems that it does not matter who does the transfer, WHO answered the transfered call is the callee.
You could park the call instead, with parkedcalltransfer = caller in features.conf (because now the one that calls at the parking lot is the caller)

I did not test it properly

3

Ok lets get teh call flow

A is employee
B is Client
C is employee

A calls B
so A is the caller and B callee
A transfers call to C
So A is the caller and C the callee
A drops off the line and B is connected.
So C is a callee and by deduction B is the caller

This needs to be tested but Def when transfered C becomes a callee.

Have you tested that B cant do it any time

and as a previous thread on this the caller/callee is NOT about who can do it its about on what channel is the action applied to

Ian

4

How can i fix that?
I don’t want to Park calls… All my clients are working like i wrote UP :S

The problem is that they don’t know that the client can run the features too…

Please write a solution for me plz

5

[quote=“ianplain”]and as a previous thread on this the caller/callee is NOT about who can do it its about on what channel is the action applied to
[/quote]
Although I think I was guilty off a mistake on the thread referred to, the parties after the / are those that determine permisions. It is the one before the / that determines who the action gets run for.

My guess is that the caller is the channel on which the thread that owns the bridge is running, which would be the target of the REFER/replaces for a real SIP transfer (which may depend on the specific phone), but I imagine is B for a features transfer.

gnu: “fix” presumes that something is broken - I don’t think that has been proved yet - and if you want someone to write you a solution, you should expect to pay for it. Also, as noted before, the use of macros in features is not officially supported.

6

Hi Ok

here are the notes of teh latest version

; The syntax for declaring a dynamic feature is any of the following:
;
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,<AppArguments>[,MOH_Class]]
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>[,"<AppArguments>"[,MOH_Class]]
;<FeatureName> => <DTMF_sequence>,<ActivateOn>[/<ActivatedBy>],<Application>([<AppArguments>])[,MOH_Class]

;
;  FeatureName   -> This is the name of the feature used when setting the
;                   DYNAMIC_FEATURES variable to enable usage of this feature.
;  DTMF_sequence -> This is the key sequence used to activate this feature.
;  ActivateOn    -> This is the channel of the call that the application will be executed
;                   on. Valid values are "self" and "peer". [b]"self" means run the
;                   application on the same channel that activated the feature.[/b] "peer"
;                   means run the application on the opposite channel from the one that
;                   has activated the feature.
;  ActivatedBy   -> This is which channel is allowed to activate this feature. Valid
;                   values are "caller", "callee", and "both". "both" is the default.
;                   The "caller" is the channel that executed the Dial application, while
;                   the [b]"callee" is the channel called by the Dial application[/b].
;  Application   -> This is the application to execute.
;  AppArguments  -> These are the arguments to be passed into the application.  If you need
;                   commas in your arguments, you should use either the second or third
;                   syntax, above.
;  MOH_Class     -> This is the music on hold class to play while the idle
;                   channel waits for the feature to complete. If left blank,
;                   no music will be played.
;
;testfeature => #9,peer,Playback,tt-monkeys  ;Allow both the caller and callee to play
;                                            ;tt-monkeys to the opposite channel
;
;pauseMonitor   => #1,self/callee,Pausemonitor     ;Allow the callee to pause monitoring
;                                                  ;on their channel
;unpauseMonitor => #3,self/callee,UnPauseMonitor   ;Allow the callee to unpause monitoring
;                                                  ;on their channel

so it means it switches unless you reset the dynamic features as you transfer to peer/callee pssibly

Ian