DTMF results in Unlink and Bridge events on AMI

Asterisk Asterisk Support
1

Does anyone know why an Unlink event and a Bridge event is sent to the AMI, every time a user sends a DTMF-tone on an existing call? The calls are working fine and are not disconnected. But I have an application monitoring calls, and it thinks that the calls are disconnected, as it listens for unlink events.
It is new to me - but is it supposed to behave like this?
Running 1.6.2.14.

AMI:

  1. Event: Unlink

  2. Privilege: call,all

  3. Channel1: SIP/3064-00002444

  4. Channel2: SIP/Unotel-00002445

  5. Uniqueid1: 1293534389.10719

  6. Uniqueid2: 1293534389.10720

  7. CallerID1: 12345678

  8. CallerID2: 80808080

  10. Event: Bridge

  11. Privilege: call,all

  12. Bridgestate: Link

  13. Bridgetype: core

  14. Channel1: SIP/3064-00002444

  15. Channel2: SIP/Unotel-00002445

  16. Uniqueid1: 1293534389.10719

  17. Uniqueid2: 1293534389.10720

  18. CallerID1: 12345678

  19. CallerID2: 80808080

  21. Event: Unlink

  22. Privilege: call,all

  23. Channel1: SIP/3064-00002444

  24. Channel2: SIP/Unotel-00002445

  25. Uniqueid1: 1293534389.10719

  26. Uniqueid2: 1293534389.10720

  27. CallerID1: 12345678

  28. CallerID2: 80808080

  30. Event: Bridge

  31. Privilege: call,all

  32. Bridgestate: Link

  33. Bridgetype: core

  34. Channel1: SIP/3064-00002444

  35. Channel2: SIP/Unotel-00002445

  36. Uniqueid1: 1293534389.10719

  37. Uniqueid2: 1293534389.10720

  38. CallerID1: 12345678

  39. CallerID2: 80808080

2

I am having the same issue. Trying to use ## as the blind transfer code, and when you dial ## on the phone device, you get an unlink, bridge, unlink on the AMI. Changing back to a single # (the default) gives just one unlink event. I also tried using #8 and still get the unlink, bridge, unlink event series.

Using Asterisk ver 1.6.1.12.

Don’t have access to a 1.4 server to see if it shows the same results.

Is this normal behavior?

3

Hi jjblitz.

Nice to hear I’m not the only one.

But I am almost certain that this didn’t happen in version 1.6.2.12. I will try to downgrade after work hours tonight and run some tests.

Are you using asterisknow?

4

It is not AsteriskNow.

5

The bridging code can do very little other than forward packets. If anything unusual happens, like expected DTMF, it drops out to let the more general code handle the situation.

6

david55, I am not sure I follow. “Bridging code”, “forward packets” you say? It is events on the AMI. I have an application monitoring these events, and if the application sees an Unlink-event, it assumes the call has been disconnected.

“If anything unusual happens, like expected DTMF, it drops out to let the more general code handle the situation.” - what drops out? What general code and what situation?

7

The simple answer is that is how it works.

I’m afraid, if you don’t understand my short description, you are probably going to need an extended tutorial on Asterisk internals, and I don’t have time to provide that.

Maybe one point to note is that AMI events are dictated by the internal processing. The internal processing isn’t organised to produce particular events.

8

Okay, no matter if I understand it or not - are you saying that this is normal behaviour? Two unlink and two bridge events, every time a key is pressed on a phone during a call.

9

I’m saying I wouldn’t be surprised.

I’d also expect it to depend on whether Asterisk needs to react to DTMF digits, e.g. features.conf option, etc., i.e. the details of your dialplan may affect it. Certainly, it wouldn’t happen if there were a successful SIP re-invite for the call, because the bridge code wouldn’t see the DTMF.

10

The only thing I have in features.conf is this:
pickupexten = 8;

How would it look if it was to react on DTMF?

I will try to debug it and see if a SIP re-invite is sent.