DTMF results in Unlink and Bridge events on AMI

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?


  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

  9. Event: Bridge

  10. Privilege: call,all

  11. Bridgestate: Link

  12. Bridgetype: core

  13. Channel1: SIP/3064-00002444

  14. Channel2: SIP/Unotel-00002445

  15. Uniqueid1: 1293534389.10719

  16. Uniqueid2: 1293534389.10720

  17. CallerID1: 12345678

  18. CallerID2: 80808080

  19. Event: Unlink

  20. Privilege: call,all

  21. Channel1: SIP/3064-00002444

  22. Channel2: SIP/Unotel-00002445

  23. Uniqueid1: 1293534389.10719

  24. Uniqueid2: 1293534389.10720

  25. CallerID1: 12345678

  26. CallerID2: 80808080

  27. Event: Bridge

  28. Privilege: call,all

  29. Bridgestate: Link

  30. Bridgetype: core

  31. Channel1: SIP/3064-00002444

  32. Channel2: SIP/Unotel-00002445

  33. Uniqueid1: 1293534389.10719

  34. Uniqueid2: 1293534389.10720

  35. CallerID1: 12345678

  36. CallerID2: 80808080

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

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

Is this normal behavior?

Hi jjblitz.

Nice to hear I’m not the only one.

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

Are you using asterisknow?

It is not AsteriskNow.

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.

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?

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.

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.

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.

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.