ASTERISK-20556: When the remote peer hangs first asterisk detects a false hangup on FXS: breaks hints and answers subsequent calls without user intervention

[Home]

Summary: ASTERISK-20556: When the remote peer hangs first asterisk detects a false hangup on FXS: breaks hints and answers subsequent calls without user intervention

Reporter: Niccolò Belli (darkbasic) Labels:

Date Opened: 2012-10-12 02:51:40 Date Closed: 2012-10-18 13:47:23

Priority: Critical Regression?

Status: Closed/Complete Components: Channels/chan_dahdi

Versions: 10.8.0 Frequency of
Occurrence

Related
Issues:

Environment: Attachments:

Description: Hi,
I have a problem with asterisk 10.8, hints and fxs dahdi phones: if a remote peer and an fxs phone gets connected and the remote peer hangsup, then asterisk sends the "Idle" state to notify the watcher before you hangup the fxs phone! Such a way if the user forgets to hangup the fxs phone (which is a cordless for example) then the operators will keep sending calls to him because the light on their function keys switched off! Card is Sangoma A200 and this is my chan_dahdi.conf:

[channels]
;SUONI IN ITALIANO
language=it
;CALLER ID NON TRONCATO
nationalprefix=0
internationalprefix=00
;HANGUP DETECION
busydetect=yes
;FAX DETECION
faxdetect=incoming
context=default
usecallerid=yes
hidecallerid=no
;ATTIVA AVVISO DI CHIAMATA
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no

I made a *VIDEO* of the bug: http://files.linuxsystems.it/files/dahdi_hints_bug.webm

I will follow exactly what I did in the video.

1) Start point
# wanpipemon -i w3g1 -c astats -m 3

------- Voltage Status (FXS,port 2) -------

TIP : - 5.6400 Volts
RING : -54.1440 Volts
VBAT : -63.5440 Volts

2) Now I press the the green button in the cordless
-- Starting simple switch on 'DAHDI/9-1'
== Extension Changed 101[phones-metano] new state InUse for Notify User 103
== Extension Changed 101[phones-metano] new state InUse for Notify User 106
# wanpipemon -i w3g1 -c astats -m 3

------- Voltage Status (FXS,port 2) -------

TIP : - 5.6400 Volts
RING : -13.1600 Volts
VBAT : -21.8080 Volts

3) Now I press the red button in the cordless
-- Hanging up on 'DAHDI/9-1'
-- Hungup 'DAHDI/9-1'
== Extension Changed 101[phones-metano] new state Idle for Notify User 103
== Extension Changed 101[phones-metano] new state Idle for Notify User 106
# wanpipemon -i w3g1 -c astats -m 3

------- Voltage Status (FXS,port 2) -------

TIP : - 5.6400 Volts
RING : -54.1440 Volts
VBAT : -63.1680 Volts

4) Now I will call the cordless from the SIP phone
== Using SIP RTP CoS mark 5
-- Executing [101@phones-metano:1] Macro("SIP/106-00000001", "chiama,DAHDI,9") in new stack
-- Executing [s@macro-chiama:1] Set("SIP/106-00000001", "DYNAMIC_FEATURES=automixmon") in new stack
-- Executing [s@macro-chiama:2] Dial("SIP/106-00000001", "DAHDI/9,60,tTxX") in new stack
-- Called DAHDI/9
-- DAHDI/9-1 is ringing
== Extension Changed 106[phones-metano] new state InUse for Notify User 103
== Extension Changed 101[phones-metano] new state Ringing for Notify User 103
== Extension Changed 101[phones-metano] new state Ringing for Notify User 106
-- DAHDI/9-1 is ringing
-- DAHDI/9-1 is ringing
# wanpipemon -i w3g1 -c astats -m 3

------- Voltage Status (FXS,port 2) -------

TIP : - 5.6400 Volts
RING : -54.1440 Volts
VBAT : -63.1680 Volts

5) Now I press the green button on the cordless
-- DAHDI/9-1 answered SIP/106-00000001
== Extension Changed 101[phones-metano] new state InUse for Notify User 103
== Extension Changed 101[phones-metano] new state InUse for Notify User 106
# wanpipemon -i w3g1 -c astats -m 3

------- Voltage Status (FXS,port 2) -------

TIP : - 6.0160 Volts
RING : -12.7840 Volts
VBAT : -22.5600 Volts

6) Now I hangup on the SIP phone
-- Hanging up on 'DAHDI/9-1'
-- Hungup 'DAHDI/9-1'
== Spawn extension (macro-chiama, s, 2) exited non-zero on 'SIP/106-00000001' in macro 'chiama'
== Spawn extension (phones-metano, 101, 1) exited non-zero on 'SIP/106-00000001'
== Extension Changed 101[phones-metano] new state Idle for Notify User 103
== Extension Changed 101[phones-metano] new state Idle for Notify User 106
== Extension Changed 106[phones-metano] new state Idle for Notify User 103
# wanpipemon -i w3g1 -c astats -m 3

------- Voltage Status (FXS,port 2) -------

TIP : - 5.6400 Volts
RING : -13.1600 Volts
VBAT : -21.8080 Volts

7) Now I press the red button in the cordless
(nothing in the CLI)
# wanpipemon -i w3g1 -c astats -m 3

------- Voltage Status (FXS,port 2) -------

TIP : - 5.6400 Volts
RING : -54.1440 Volts
VBAT : -63.1680 Volts

I don't think it makes sense because in 1) *as soon* as I raise the receiver pressing the green button (the phone isn't ringing and I'm not even making a call) asterisk sends an "InUse" notification in response to "-- Starting simple switch on 'DAHDI/9-1'". So in the asterisk perspective the line is busy as soon as you pickup the phone, not as soon as you answer or make a call (this is the expected behaviour). In fact when I raise the receiver in an analog telephone the line is busy and I can't receive a call, so it must notify a BUSY line.
According to this argument the line should be busy until I hang up the receiver, not until the other peer hangs up. It doesn't make sense notifying "Idle" when the line is in fact BUSY.

The real problem in my opinion is something (dahdi?) which communicates the hangup before it happened.
In 6) I see "-- Hanging up on 'DAHDI/9-1' -- Hungup 'DAHDI/9-1'" but I still didn't hang up the line because I didn't press the red button! DAHDI/9 IS STILL BUSY.

As soon as asterisk receives the hangup communication you can see it sends the "Idle" notification, but the real problem is "-- Hanging up on 'DAHDI/9-1' -- Hungup 'DAHDI/9-1'" because there was no hang up at all!

My dialplan is very simple: "exten => 101,1,Dial(DAHDI/9)" without even the Hangup() app.

I already posted my issue in the asterisk-users mailing list (http://asteriskfaqs.org/2012/10/09/asterisk-users/asterisk-sends-wrong-fxs-idle-hints.html) and nobody even answered, it seems I am the only one facing this issue...
This bug isn't big: it's HUGE. If someone forgets to hangup (my users are really that stupid) then the operators will keep to transfer calls to the busy extensions, I already lost lots of calls because of this. Also the fake hangup breaks even more things than a busy lamp field: thanks to the fake hangup if you use callwaiting=yes then analog phones automatically answer subsequent calls without user intervention (http://asteriskfaqs.org/2012/10/08/asterisk-users/how-to-avoid-automatic-answer-with-callwaitingyes-on-fxs-channels.html).

I also have a ticket with Sangoma but they blame asterisk.

Greetings,
Niccolò

Comments: By: Rusty Newton (rnewton) 2012-10-18 13:46:14.889-0500

I spoke with a few developers who work with chan_dahdi. This is a known limitation, and is expected behavior. To implement a more appropriate and complex device state for FXO signalling would be a feature request requiring very significant development effort.

This issue will be closed as there is no patch included. https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

If you or someone else can provide a patch , feel free to contact a developer in #asterisk-bugs (IRC) or E-mail me at rnewton at digium.com to have the issue re-opened.