Dialplan starts before the call happens

Hi,

I am working on a simple telephonic solution that involve us creating a callout file from our system that will be then move to the Asterisk’s spool directory with the channel as DAHDI/3/123456789. We have a context in our dialplan that is dedicated for the call.

Hence when a call is setup for the DAHDI/3/123456789, our dialplan is executed with the context as per callout file.

However the problem is that, the dialplan starts right after Asterisk pick up the call file from the spool before even the phone (with number 123456789) rings.

My /etc/asterisk/chan_dahdi.conf file is

[trunkgroups]
[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
group=1
callgroup=1
pickupgroup=1

usecallerid = yes
hidecallerid = no
callwaiting = yes
threewaycalling = yes
transfer = yes
echocancel = yes
echocancelwhenbridged = yes
rxgain = 0.0
txgain = 0.0

; FXS Modules
group = 1
signalling = fxo_ks
context = Internal_Phone
channel = 1-2

; FXO Modules
group = 2
echocancel = yes
signalling = fxs_ks
callerid = "HipLink Test" <4209211>
context = Internal_PSTN
waitfordialtone=yes
immediate=no
;busydetect = yes
;busycount = 10
;ringtimeout=8000
pulsedial=yes
channel = 3-4

Also I am deploying this solution in Pakistan, and there is no tone zone/profile define in the DAHDI tools/zonedata.c file. So I have created one as listed below

 {
                .zone = 46,
                .country = "pk",
                .description = "Pakistan",
                //.ringcadence = { 400, 200, 400, 2000 },
                .ringcadence = { 2000, 4000 },
                .tones = {
                        /* Reference: http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf */
                        { DAHDI_TONE_DIALTONE, "450" },
                        { DAHDI_TONE_BUSY, "400/500,0/500" },
                        { DAHDI_TONE_RINGTONE, "400/1000,0/2000" },
                        { DAHDI_TONE_CONGESTION, "400/250,0/250" },
                        /* CALLWAIT - not specified */
                        { DAHDI_TONE_CALLWAIT, "400/200,0/100,400/200,0/7500" },
                        /* DIALRECALL - not specified */
                        { DAHDI_TONE_DIALRECALL, "!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,350+440" },
                        /* RECORDTONE - not specified */
                        { DAHDI_TONE_RECORDTONE, "1400/500,0/15000" },
                        /* INFO - not specified */
                        { DAHDI_TONE_INFO, "!950/330,!1400/330,!1800/330,0/1000" },
                        /* STUTTER - not specified */
                        { DAHDI_TONE_STUTTER, "!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,350+440" },
                },
                .dtmf_high_level = -10,
                .dtmf_low_level = -8,
                .mfr1_level = -10,
                .mfr2_level = -8,
        },

I have recompile the DAHDI driver, tools, and install the modified one. And I have use the “pk” as the value of loadzone and defaultzone. And after starting the DAHDI, the issue remains as before.

The tone profile above is not complete, and the ringcadence value is again taken from the US profile.

So my question is, the issue that I am having is due to the incomplete or incorrect tone profile? Or there is some thing missing in my configuration? Or for DAHDI calls, there is something extra that needs to be done in the dialplan? The dialplan is running fine with SIP calls.

Kindly help me out.
Thanks.

It’s due to chan_dahdi.conf saying that the line has no answer supervision. If that is true, you will need to talk to your PSTN operator. If the line does have answer supervision, you need to modify chan_dahdi.conf to identify the type in use.

You need to look for options beginning with “answeron”.

If you really are on a pulse dial line, I would suggest that the chances of having answer supervision are rather small.

Thanks.

After I follow your advise, my /etc/asterisk/chan_dahdi.conf now looks like

[trunkgroups]
[channels]
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
group=1
callgroup=1
pickupgroup=1

; General options
usecallerid = yes
hidecallerid = no
callwaiting = yes
threewaycalling = yes
transfer = yes
echocancel = yes
echocancelwhenbridged = yes
rxgain = 0.0
txgain = 0.0

; FXS Modules
group = 1
signalling = fxo_ks
context = Internal_Phone
channel = 1-2

; FXO Modules
group = 2
echocancel = yes
signalling = fxs_ks
callerid = "HipLink Test" <4209211>
context = Internal_PSTN
waitfordialtone=yes
immediate=no
busydetect = yes
busycount = 10
;ringtimeout=8000
answeronpolarityswitch=yes
;hanguponpolarityswitch=yes
pulsedial=yes
channel = 3-4

After adding answeronpolarityswitch=yes, now my dialplan starts after I accept the call on my phone. Means Asterisk is now waiting for the phone to accept the call. But now when I accept the call, the dialplan is taking the call as failed with following message in the Asterisk console

localhost*CLI>
    -- Attempting call on DAHDI/3/123456789 for 100@hlcallout:1 (Retry 1)
    -- Hanging up on 'DAHDI/3-1'
    -- Hungup 'DAHDI/3-1'

        // My dialplan FAILED extensions output

[Mar  7 23:36:29] NOTICE[17656]: pbx_spool.c:360 attempt_thread: Call failed to go through, reason (3) Remote end Ringing

In my dialplan failed extensions, I am getting the value of variable ${REASON} as 3.

I have tried with several combinations in which I commented the following parameters in my chan_dahdi with the new one always enabled,

  • waitfordialtone=yes
  • immediate=no
  • busydetect = yes
  • busycount = 10
  • ringtimeout=8000
  • hanguponpolarityswitch=yes
  • pulsedial=yes
    but again the end result is the same.

The parameter answeronpolarityswitch=yes has made Asterisk to wait till I accept the call, but now the call is always failed with REASON 3.

Any idea that what is happening, and what is still required to be changed in the chan_dahdi.conf file.

You need to get a technical specfication for the line from you network operator, or use low level debugging to determine the actual line states being seen.

If you are using Digium hardware, also see the first sticky posting on the forum.

I donot know whether my telco can be of any help to me. Can you please guide me through how I can deduce the actual settings and tonezone profile through debugging on my line. Kindly detail the procedure.

Also if there is post on the forum or a link to a online tutorial that can help me, then please send me these also.

My stack is comprises of the following

  • OS -> CentOS 5.7
  • LibPRI 1.4.12
  • DAHDI Linux complete 2.6.0+2.6.0
  • Asterisk 10.1.3

I am using Digium TDM422E card that has 2 FXO and 2 FXS with hardware echo cancelling module.

Thanks.

As you have Digium hardware, you should be using Digium’s commercial support.

Although I can’t rule it out, I don’t think tonezone causes many real problems.

I don’t know about your country, but BT, in the UK publish technical specifications for their products.

Note that answeronpolarity only works if the network provides line reversal answer supervision. If they don’t, you have to order a line that does, or use heuristics (voice detection) to recognize when a human has answered.

If you enable it on a line that doesn’t support it, the call will never appear to be answered.

First, thanks for the replies.

You are talking about voice detection. How can I do that in the dialplan? Use AMD application in the dialplan or use WaitForSilence or other application or any combination of them. I am already using AMD to detect voicemail or answering machine, but again its result are not so appreciating. Is there is another way of doing voice detection to detect human/machine on the DAHDI call.

My existing dialplan which is perfectly in use for the VoIP (SIP) calls; I want to reuse it for the PSTN (DAHDI) calls too. In my existing dialplan, I am assuming that when my dialplan starts execution then either the target accepts or rejects the call, or some error has occurred. Hence it won’t start when the target phone is still ringing. However on DAHDI calls, the dailplan starts right after Asterisk places the call, and the phone is ringing. However if DAHDI requires some extra in my dialplan, I will happily implement that, but I need to know these extra work. Can you provide help for that.

The solution will deploy in Pakistan, Karachi city. The tonezone settings I mentioned in my first post was for the Pakistan. In Pakistan, there is only one Telco called PTCL.