[Home]

Summary:DAHLIN-00147: Dial() command do not detect hangup during extension call
Reporter:Francis Brosnan Blázquez (francis brosnan)Labels:
Date Opened:2009-09-22 09:01:47Date Closed:2009-09-28 10:42:14
Priority:MinorRegression?No
Status:Closed/CompleteComponents:wctdm
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If we receive a call from the analogic device (TDM410P), it gets answered correctly, but if the caller hangups during Dial() command is ringing to default extension, this hangup is not detect and local extension keeps on ringing until someone pick up the phone (or pick the extension) or timeout is reached.



****** ADDITIONAL INFORMATION ******

Given the following dialplan piece. When a call gets incoming contexts, the caller gets the welcome message, and asterisk calls to default extensions (SIP/sip3 and SIP/sip4). During Dial() command is working (for 30 seconds) if the outside caller hangups, Dial() do not stop.

[incoming]
; relevant information
exten => s,1,Answer()
exten => s,n,Playback("../custom-sounds/bienvenido-aspl")
exten => s,n,Dial(SIP/sip3&SIP/sip4,30,m)

Other relevant information for this case is that this do not happens with our ISDN lines (B410P) installed on the same machine.

We have checked if this has to do with hangup detection but this do not happens if we initialize the call (using the analog interface). In this case, hangup is properly detected.


Comments:By: David Woolley (davidw) 2009-09-22 09:15:22

Why do you believe this is an Asterisk, Dial application problem, rather than a problem with Dahdi, or maybe chan_dahdi?
By: Leif Madsen (lmadsen) 2009-09-22 09:23:46

This probably still has something to do with the hangup detection -- I mean, this is an analog line, and thus there is only so much disconnect supervision that can be done here.

It doesn't happen with the ISDN line because it is a digital circuit.

As I'm not 100% sure how to debug these kinds of issues (since I'm more into SIP and such), I don't know what I need to ask for.

Lets start with a console output, along with some additional debugging information such as the configuration for your hardware and such.

The console output should have debugging enabled per logger.conf along with 'core set debug 10'
By: Francis Brosnan Blázquez (francis brosnan) 2009-09-22 09:52:38

>> Why do you believe this is an Asterisk, Dial application problem, rather than
>> a problem with Dahdi, or maybe chan_dahdi?

Hi David. I believe it is a problem with Dial application because it continues dialing even having the line hanged up. Maybe it is not Dial() cmd itself but how our hardware is detected.

>> The console output should have debugging enabled per logger.conf along with
>> 'core set debug 10'

Hi. We are using zaptel (1.4.12.1), libpri (1.4.10.1). Not dahdi. Our /etc/asterisk/zapata.conf content is:
[channels]
context=incoming
language=es
usecallerid=yes
hidecallerid=no
callwaiting=no
threewaycalling=yes
transfer=yes
echocancel=yes

signalling=fxs_ks

; we have checked the following two options but no success
; hanguponpolarityswitch=yes
; busydetect=yes
------------

channel => 1

Our /etc/zaptel.conf configuration is:

# Span 1: WCTDM/0 "Wildcard TDM410P Board 1" (MASTER)
fxsks=1
# channel 2, WCTDM/0/1, no module.
# channel 3, WCTDM/0/2, no module.
# channel 4, WCTDM/0/3, no module.
loadzone        = es
defaultzone     = es

Setting "core set debug 10" produces the following log when a call is received:

   -- Starting simple switch on 'Zap/1-1'
   -- Executing [s@incoming:1] GotoIfTime("Zap/1-1", "09:00-14:00|mon-fri|*|*?label_abierto") in new stack
   -- Executing [s@incoming:2] GotoIfTime("Zap/1-1", "15:00-18:00|mon-fri|*|*?label_abierto") in new stack
   -- Goto (incoming,s,4)
   -- Executing [s@incoming:4] Answer("Zap/1-1", "") in new stack
   -- Executing [s@incoming:5] Playback("Zap/1-1", ""../custom-sounds/bienvenido-aspl"") in new stack
   -- <Zap/1-1> Playing '../custom-sounds/bienvenido-aspl' (language 'es')
   -- Executing [s@incoming:6] Dial("Zap/1-1", "SIP/sip3&SIP/sip4|30|m") in new stack
   -- Called sip3
   -- Called sip4
   -- Started music on hold, class 'default', on Zap/1-1
   -- SIP/sip3-09c3b068 is ringing
   -- SIP/sip4-09c4b5a0 is ringing

...at this point, if I hangup (I'm calling from a mobile), no message is found and sip3/sip4 extensions keep on ringing. At this point, after waiting a few seconds, I pickup the ringing (phantom) call from my sip extension but nothing is found. Here is the log produced when I pickup:

   -- Executing [40@phones:1] PickUp2("SIP/francissip-09c452e8", "SIP") in new stack
      > find_matching_channel: pattern='SIP' option='' state=5
      > find_matching_channel: trying channel='SIP/francissip-09c452e8' state=4 pattern='SIP'
      > find_matching_channel: trying channel='SIP/sip4-09c4b5a0' state=5 pattern='SIP'
      > find_matching_channel: found channel='SIP/sip4-09c4b5a0'
   -- Channel SIP/francissip-09c452e8 picked up ringing channel SIP/sip4-09c4b5a0
   -- Executing [40@phones:2] Hangup("SIP/francissip-09c452e8<MASQ>", "") in new stack
 == Spawn extension (phones, 40, 2) exited non-zero on 'SIP/francissip-09c452e8<MASQ>'
   -- SIP/francissip-09c452e8 answered Zap/1-1
   -- Stopped music on hold on Zap/1-1
Really destroying SIP dialog '70d10db419e391e0037960e63147589d@192.168.0.233' Method: INVITE
Really destroying SIP dialog '554526ca1f9dc7c674be5ec5529d81d3@192.168.0.233' Method: INVITE
 == Spawn extension (incoming, s, 6) exited non-zero on 'Zap/1-1'
   -- Hungup 'Zap/1-1'

If I execute "core show channels" after hang up, it is showed the following:
sturgeon*CLI>
   -- Starting simple switch on 'Zap/1-1'
   -- Executing [s@incoming:1] GotoIfTime("Zap/1-1", "09:00-14:00|mon-fri|*|*?label_abierto") in new stack
   -- Executing [s@incoming:2] GotoIfTime("Zap/1-1", "15:00-18:00|mon-fri|*|*?label_abierto") in new stack
   -- Goto (incoming,s,4)
   -- Executing [s@incoming:4] Answer("Zap/1-1", "") in new stack
   -- Executing [s@incoming:5] Playback("Zap/1-1", ""../custom-sounds/bienvenido-aspl"") in new stack
   -- <Zap/1-1> Playing '../custom-sounds/bienvenido-aspl' (language 'es')
   -- Executing [s@incoming:6] Dial("Zap/1-1", "SIP/sip3&SIP/sip4|30|m") in new stack
   -- Called sip3
   -- Called sip4
   -- Started music on hold, class 'default', on Zap/1-1
   -- SIP/sip3-09c3b068 is ringing
   -- SIP/sip4-09c4b5a0 is ringing
<...hangup call from my mobile and wait a few seconds...the run: >
sturgeon*CLI> core show channels
Channel              Location             State   Application(Data)            
SIP/sip4-09c4b5a0    s@phones:1           Ringing AppDial((Outgoing Line))      
SIP/sip3-09c3b068    s@phones:1           Ringing AppDial((Outgoing Line))      
Zap/1-1              s@incoming:6         Up      Dial(SIP/sip3&SIP/sip4|30|m)  
3 active channels
1 active call

After looking at this data, I've checked to also hangup during playback() and the problem persists so it looks like is not a problem with Dial()...

Let me know if I can provide you with more details...Thanks!
By: Francis Brosnan Blázquez (francis brosnan) 2009-09-28 06:51:46

Hi,

Just to confirm the issue is solved and can be closed. The problem was caused by a couple of problems (wrong or missing configuration) at the same time.

In one hand, adding the following two lines to /etc/asterisk/zapata.conf resolves the issue:

answeronpolarityswitch=yes
hanguponpolarityswitch=yes

In the other, for some reason, having previous lines activated, was causing to not work the following instruction (which were also incorrect):

exten => _NXXXXXXXX, 1, Dial(Zap/1/${EXTEN}&mISDN/1/${EXTEN})
; our intention was to first use Zap line available and if busy, use ISDN,

After changing previous declaration to:

exten => _NXXXXXXXX,1,Dial(Zap/1/${EXTEN})
exten => _NXXXXXXXX,n,GotoIf($[${DIALSTATUS} = BUSY]?hangup)        
exten => _NXXXXXXXX,n,Dial(mISDN/1/${EXTEN})
exten => _NXXXXXXXX,n(hangup),Hangup()

..we were able to use first Zap line and then RDSI (according to busy state) and at the same time to have polarity reverse detection mentioned above.

I hope this helps other users. Thanks for your support. Cheers!
By: Shaun Ruffell (sruffell) 2009-09-28 10:42:13

Francis Brosnan:  Thanks for closing the loop on this one.