[Home]

Summary:ASTERISK-07316: [patch] no DTMF detection on Zap outbound calls when called device does not send proceeding
Reporter:Robert Hirschmann (roberth)Labels:
Date Opened:2006-07-10 09:04:22Date Closed:2011-06-07 14:03:20
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap+overlaprecv_1.2.11.diff
( 1) chan_zap+overlaprecv.diff
( 2) chan_zap+overlaprecv-1.2.11.diff
( 3) chan_zap+overlaprecv-SVN41258M.diff
( 4) pridebug.tar.gz
Description:When Asterisk is doing outgoing calls (e.g. with call files) no DTMF Digits will be detected.
After pri debugging (together with beronet.com) we found out that this occurs when no proceed message is sent (only alert and answer messages are sent).
This happens for example when calling mobile phones over german t-com e1 trunks.

Tested with a simple DISA context which works fine when dialing in, but not on outdials.
Changing relaxdtmf or callprogress settings in zapata.conf did not solve the problem. We also tried to change hardware dtmf support in /usr/src/zaptel-1.2.6/wct4xxp.c (static int vpmdtmfsupport = 0)

Thanks in advance for fixing that!
Robert

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

occurs on both Digium TE205P and TE210P
using all latest versions from digium
asterisk-1.2.9.1
libpri-1.2.3
zaptel-1.2.6

all compiled and running on a HP Proliant 3GHz Xeon Server with
Debian Sarge and Kernel 2.6.8-3-686-smp i686
Comments:By: Robert Hirschmann (roberth) 2006-07-11 05:12:05

after further testing I found out that it only happens when overlapdial is set to yes (which is needed on a german "Durchwahl" trunk).
setting overlapdial to no in zapata.conf fixes the problem, but then no more soft switch funcionality is available for dialins.
By: Stefano Brandimarte (stevens) 2006-08-25 19:32:01

i want to know if the overlapdial requirement is needed only for incoming calls,
calls from the network (e.g. to accept CALLINGSUBADDR), or to place an outgoing
call too.
By: Robert Hirschmann (roberth) 2006-08-28 01:21:32

afaik overlap is only needed for incoming calls, because on outbound calls it is handled by the remote side switch.
By: Stefano Brandimarte (stevens) 2006-08-28 08:34:11

hello. I've a patch to distinguish overlapdial in sending and in receiving mode.
We're using this patch and it works for us. If you want to try i can attach the
diff here or send it to Your email address. Our patch is against 1.2.11 however.
It allows to set "overlapdial" to "incoming", "outgoing", "both" or simply "yes"
or "no" (default behaviour). As a work around Your problem, You could try to set
overlapdial to "incoming" and check if it helps for Your problem.

Let me know.
By: Robert Hirschmann (roberth) 2006-08-28 08:42:06

setting overlapdial to incoming only would exactly fix the problem.
could you attach the diff here or send it to: info at feedm dot de ?
currently we're running 1.2.9 but in that case i would update to
1.2.11 this night and apply the patch.

thanks a lot for your help!
Robert
By: Stefano Brandimarte (stevens) 2006-08-28 08:56:05

i've attached that patch; however i'll be glad to apply to Your asterisk version
because of it's still in testing; so if You send to me Your chan_zap.c i'll put
there the modifications, so You can try Your current * release, just replacing
chan_zap.so with the one compiled against a patched chan_zap.c. Send it to me,
if You want, to stevens at stevens dot it.

Greetings.
By: Robert Hirschmann (roberth) 2006-08-28 09:03:34

great. my current chan_zap.c is on the way via email.
thank you,
robert
By: Serge Vecher (serge-v) 2006-08-28 09:25:03

stevens: thanks for working on this ... could you please make a note here with your disclaimer status?
By: Stefano Brandimarte (stevens) 2006-08-28 09:48:02

The patch applies to 1.2.9.1 chan_zap.c quite cleanly (just some offset warning)

vechers: the disclaimer is on file.
By: Stefano Brandimarte (stevens) 2006-08-28 14:33:00

I wish to add some comment, related to chan_zap.c:
static struct zt_pvt
contains a completely unused (and potentially confusing) flag definition:
unsigned int overlapdial:1;

my patch assumes that overlap dial for outgoing calls are handled at libpri
level ("struct pri", from libpri/pri_internal.h, contains "int overlapdial;"
and this is set to 1 when zapata.conf's "overlapdial" is true). On the other
end, overlap dial for receiving is handled by chan_zap.c, afaik. So if we need
just to overlap for incoming calls i set to 0 the "struct pri"->overlapdial int
but let's use 2 as value for "struct zt_pri"->overlapdial. This is working for
us. So we can place calls more quickly ("Sending Complete" is explicitly set in
the SETUP message, instead of waiting for the other side timeout) and at the
same time allow us to receive CALLINGSUBADDRs in overlap "receive only" mode.
By: Stefano Brandimarte (stevens) 2006-08-28 17:15:45

latest patch is agains SVN trunk 41258M.

Serge, please, remove the first file, because it contains a wrong line that i
forgot to delete after patching. The second diff, for 1.2.11, is ok.

Thanks!
By: Stefano Brandimarte (stevens) 2006-08-31 20:32:44

latest patches (for 1.2.11 and SVN trunk) add a line output to the pri show span x
cli command, to let's know the status of the new "Overlap Recv" mode. So, if it's
enabled just for "incoming" calls, the output will show "Overlap Dial: 0" but, at
the same time "Overlap Recv: Yes".
By: Paul Cadach (pcadach) 2006-08-31 23:57:30

stevens: Why you commented out/changed overlap dialing code??? As I remember fix of this is just about 2 lines of code... Could you show your Dial command, zapata configuration related to span used for outgoing call?
By: Robert Hirschmann (roberth) 2006-09-01 02:12:44

Hi,
the modified chan_zap is running on our production system since 2 days now.
It works like a charme.
We had about 7000 in/out zap calls until now without any problem.
Setting overlapdial=incoming on both system trunks within zapata.conf (using a digium TE210 card) does exactly what it should:
DTMF Detecttion on outgoing calls generated by callfiles now works well while still preserving overlap functionality on incoming calls (the German Durchwahl).

stevens: Thanks again for your help!

PCadach: here is my zapata.conf
Commented overlap settings has been used before the patch.
Until the patch outgoing callfiles only used group1 while incoming calls have been set on external side to arrive at first on group2.
This has been our temporary solution to avoid the dtmf issue...
; #### DUAL SPAN DIALPLAN TE205P
switchtype=euroisdn
pridialplan=local
prilocaldialplan=local
internationalprefix=00
nationalprefix=0
usecallingpres=yes
busydetect=no   ; not need on pri
callprogress=no ; was yes but wiki says experimatley could be produce hangups
callwaitingcallerid=yes  ; show callerid on callwaitingcalls
echotraining=no
echocancel=no
echocancelwhenbridged=no
immediate=no
callerid=asreceived
language=de
rxgain=0.0
txgain=0.0

group=1
signalling=pri_cpe
context=pri1
;overlapdial=no ;used before patch
overlapdial=incoming
channel => 1-15,17-31

group=2
signalling=pri_cpe
context=pri2
;overlapdial=yes ;used before patch
overlapdial=incoming
channel =>32-46,48-62
; END OF ZAPATA.CONF

The Dial command is not a dial command from the dialplan (here we never had problems on outgoing or bridged calls) but a callfile which causes the problems that no DTMF Digits are received (and that's not what we want on a callback solution ;)
The simple script for generating the callfile (called from the dialplan with a system command):
#!/bin/sh
# PARM1 expects Callback Destination
DESTPHONE=$1
SDATE=`date +"%Y%m%d%H%M%S"`

CALLFILE=$(cat <<-EOF1
Channel: Zap/r1/$1
CallerID: 094158600 <094158600>
MaxRetries: 1
RetryTime: 8
WaitTime: 50
Context: callbackonly
Extension: $1
Priority: 1)

echo "$CALLFILE" >/var/spool/asterisk/fbtmp/$SDATE.call
mv /var/spool/asterisk/fbtmp/$SDATE.call /var/spool/asterisk/outgoing/
# EOF

If you need further info or the dialplan parts let me know.
Best regards,
Robert
By: Stefano Brandimarte (stevens) 2006-09-01 04:52:39

Pcadach: as already posted here, my solution address my needs to make outbound
calls according to our telco carrier requirements (they're glad to see in the
SETUP message also "Sending Complete") still preserving the functionality for
incoming calls to accept overlapping calls (CALLINGSUBADDR ecc.). So this could
be considered as a work-around for the roberth problem, as already stated. On
the other way, a possibility to distinguish between overlap dial and receiving
could be a good solution for others also and it's already implemented for fax
detection.

My related comment is 0050828.
By: Paul Cadach (pcadach) 2006-09-01 06:37:43

Could you post your PRI trace of failed call for analysing of chan_zap behaviour in your case?
By: Robert Hirschmann (roberth) 2006-09-01 07:58:30

PCadach:
I will upload the traces in a few moments.
The tar has 2 tee logs (with pri debugging enabled).
I used my previous settings (span1 overlapdial=no, span2 =yes)
and switched all other calls to our failover machine, so you
will see no "trash" output from other calls.
On both tries I requested a callback to a mobile and then
entered 1234#

If you need further traces or information let me know.

Regards,
Robert
By: Robert Hirschmann (roberth) 2006-09-01 08:14:04

sorry, I did a mistake on naming the log files in the uploaded tar.
Of course it should be
overlap_span2_fail.log  
overlap_span1_success.log

instead of
overlap_span1_fail.log
overlap_span2_success.log

but you will also see the correct span in the log...
Sorry ;)
Robert
By: Robert Hirschmann (roberth) 2006-09-05 01:41:46

@PCadach :

Any news here?
Do you need additional information?
Thank you,
Robert
By: Tzafrir Cohen (tzafrir) 2006-09-10 23:08:40

Could you please add some defines to make the value of overlapdial understandable?

#define ZAP_OVERLAPDIAL_NON      0
#define ZAP_OVERLAPDIAL_INCOMING 1
#define ZAP_OVERLAPDIAL_OUTGOING 2
#define ZAP_OVERLAPDIAL_BOTH     (ZAP_OVERLAP_INCOMING|ZAP_OVERLAPDIAL_OUTGOING)
By: Stefano Brandimarte (stevens) 2006-09-11 11:50:10

tzafrir: good point, will add these defines in the next patch for svn. Thanks.
By: jmls (jmls) 2006-11-01 10:37:52.000-0600

stevens, were you able to do the next patch ?
By: Stefano Brandimarte (stevens) 2006-11-02 03:16:56.000-0600

jmls: will do in the next few days, updating it for 1.4 and svn trunk at least.
I hope it will be taken into consideration for adding onto stock * because i've
no spare time to maintain this patch for as many * versions we don't use yet. I
can confirm, however, the patch is working on production asterisks since aug.
By: Matthew Fredrickson (mattf) 2006-11-10 15:47:50.000-0600

Ok, so basically, there are two separate issues here.  For right now, it appears that there might be a bug when in overlapdial mode not turning on the DTMF detector when it is needed.

The other one (the one that the patch addresses) is a lack of distinction between overlap receiving and overlap sending mode, correct?

So my first question is about the first issue.  I just looked at chan_zap and it looks like it should be turning on the DSP when we receive a CONNECT message from the other end (PRI_EVENT_ANSWER) regardless of anything else.  Do you still have this problem with the most current version of 1.2?

Thanks�!
By: Serge Vecher (serge-v) 2006-12-11 16:13:46.000-0600

opening at the request of stevens via email, who has some information to add regarding the original problem for which mattf has requested some additional information in note 0054369.
By: Stefano Brandimarte (stevens) 2006-12-12 04:33:14.000-0600

I've tried to replicate the wrong behaviour reported by roberth and I've found
it could be a provider fault, not asterisk fault. My testings, using three
different PRI channels show that DTMF is regularly read even when the call has
been generated by a callfile.
Furthermore in the log reported by roberth I think to have found the cause of
his problem and the reason asterisk fails in that situation: in fact * expects
to be in the PROCEEDING state in order to read DTMF and if it's not the case it
simply ignores inband DTMF received. This piece of code is from chan_zap.c :

 } else if (f->frametype == AST_FRAME_DTMF) {
#ifdef ZAPATA_PRI
   if (!p->proceeding && p->sig==SIG_PRI && p->pri && p->pri->overlapdial) {
     /* Don't accept in-band DTMF when in overlap dial mode */
     f->frametype = AST_FRAME_NULL;
     f->subclass = 0;
   }
#endif

so, if p->proceeding isn't true, in overlapdial mode DTMF received get
discarded. My patch, letting the user to distinguish between incoming and
outgoing overlapdial mode actually fixes this.

I would repeat: in my opinion is the telco that lacks sending CALL_PROCEEDING
after a short timeout (to let the calling channel, in overlapdial mode, to complete the number to dial) and on my systems it happens, so asterisk set
p->proceeding to true and starts reading digits and inband info!

I think there's nothing to do, a part of putting into the code the ability to
distinguish between the two different kind of overlapping calls (IN and or OUT),
that make the piece of code as above like this:

 } else if (f->frametype == AST_FRAME_DTMF) {
#ifdef ZAPATA_PRI
   if (!p->proceeding && p->sig==SIG_PRI && p->pri &&
       ((!p->outgoing && (p->pri->overlapdial & ZAP_OVERLAPDIAL_INCOMING)) ||
        (p->outgoing && (p->pri->overlapdial & ZAP_OVERLAPDIAL_OUTGOING)))) {
     /* Don't accept in-band DTMF when in overlap dial mode */
     f->frametype = AST_FRAME_NULL;
     f->subclass = 0;
   }
#endif

so if it's an outgoing call (p->outgoing is true) but overlapdial is not enable
for outcalls the "if" statement is not true anymore and DTMF could be read and
inband info accepted immediately.
By: Stefano Brandimarte (stevens) 2006-12-12 04:36:24.000-0600

this case is now related to 0008554 that's a feature request and implementation
to let's the user distinguish between two different kind of overlapdial mode. The
patches here have been updated by the one posted there, for 1.2.13. They are the
same, a part of introducing some #define to get the code more readable.
By: Matthew Fredrickson (mattf) 2007-06-06 17:33:34

I've recently made updates to how DTMFs are processed in chan_zap.  Is the original problem still an issue with the latest version of asterisk?
By: Stefano Brandimarte (stevens) 2007-06-08 14:02:51

mattf: will try and let You know asap. Thank You.