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

Thu Oct 18 13:47:18 CDT 2012

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198743#comment-198743 ] 

Rusty Newton commented on ASTERISK-20556:
-----------------------------------------

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.

> When the remote peer hangs first asterisk detects a false hangup on FXS: breaks hints and answers subsequent calls without user intervention
> --------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20556
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20556
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi
>    Affects Versions: 10.8.0
>            Reporter: Niccolò Belli
>            Severity: Critical
>
> 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 at phones-metano:1] Macro("SIP/106-00000001", "chiama,DAHDI,9") in new stack
> -- Executing [s at macro-chiama:1] Set("SIP/106-00000001", "DYNAMIC_FEATURES=automixmon") in new stack
> -- Executing [s at 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ò

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira