perhaps the two calls were in same room so the calls could be heard between the handsets or one of the calls was on speakerphone, so the pressed DTMF tones could be heard by the originating line as well.

But having multiple detection of the tone does not affect operation if you want an action to be triggered by a DTMF tone. The first detection would just be acted on.

It should be possible to specify a path based on 2 or more keypresses. eg:

on {XY} goto [my_new_module]

where X is one DTMF and Y is another DTMF.

but not sure you would be able to specify a path for multiple OTHER_LEG_ events.

You would need to have the first OTHER_LEG_ event make the script jump to another module, and that new module can then await the second OTHER_LEG_ event.

Please let us know if you require more assistance with this. If you can describe in more detail as to what the requirements are we can better advise the approach to take.

without call recording we don't see any dtmf signalisation on Agent line no own or other leg dtmf activity.

Please fix bug because in actual status OTHER_LEG is completely nonfunctional. We can't use OTHER LEG when no recording and with recording we can't identify dtmf side (to eliminate unexpected client dtmf activity).

1. when call is not recorded dtmf on agent line not init any activity.

2. when call is recorded DTMF on agent line is recognized as own DTMF on client side (like: 166 path {2}not found) and as OTHEL_LEG on Agent side (like: 8027LsXfer_9_WaitEndCall_OutLeg:[50:OTHER_LEG_2]0,0,0,,)