[Home]

Summary:DAHLIN-00131: [patch] DTMF-CallerID support for FXS ports
Reporter:Josef Seger (doda)Labels:
Date Opened:2009-08-01 19:22:03Date Closed:2019-05-31 09:49:00
Priority:MajorRegression?No
Status:Closed/CompleteComponents:NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) DTMF_1.6.1.1.patch
( 1) DTMF_DAHDI-LINUX_2.2.0.1.patch
( 2) DTMF_DAHDI-TOOLS_2.2.0.patch
Description:This patch is an updated patch of issue 7787 by ehsnils.

This should resolve Bug 3866.

This patch enables the ability for Asterisk to generate DTMF Caller-ID
on FXS ports as used in Scandinavia(Sweden, Finland and Denmark) and the Netherlands.
This patch should also work for other countries where DTMF is used for Caller-ID signalling?

This patch contains of three parts, one for Asterisk, one for DAHDI-linux and one for DAHDI-tools.

The patches are made on the following releases:
Asterisk rev 1.6.1.1
DAHDI-linux rev 2.2.0.1
DAHDI-tools rev 2.2.0

Code changes:
-------------
If no CallerID is setup in configuration(chan_dahdi.conf) file 'bell' signalling will not be sent out after this
patch. The default behaivour is changed to no signalling at all. This is done to support multiple CallerID choices
from the configuration file.

Several changes has been performed both to the dahdi-linux driver and to chan_dahdi.

The most important change is that the hook control ioctl call now passes a
struct instead of a single int. The struct now contains control not
only over the hook, but also over the polarity switching and has the
ability to pass the DTMF caller-ID string, which is then used by the
Zaptel driver to generate the caller-ID.

This patch actually allows the generation of both the DTMF
pre-ring caller-ID:s and the US style post-ring caller-ID:s
simultaneously.

There are a few differences in caller-ID supported by this patch.
Some equipment only listens to DTMF caller-ID:s starting with a
DTMF 'A' other only with DTMF 'D'. It is possible to select
either 'A' or 'D' for a single line, but not both since they conflict.

Special code for the Danish version of caller-ID is also added, but not
tested. The basic logic for the Danish caller-ID is the same as for
Sweden but the DTMF sequence is different and no polarity change is
done before the caller-ID transmission. (The idea is that the polarity
change shall wake up the equipment listening for caller-ID.)

To allow for combination configurations in the code some defines
has been changed from sequences to bitmasks.

Configuration:
--------------
Changes have been made to the configuration file chan_dahdi.conf:

The 'cidsignalling' now takes more options and also accepts a
comma-separated list of options. No spaces are permitted
in the list of options. Same as from patch 7787, should
be a minor problem.

The 'cidsignalling' can only have one of the dtmf options
'dtmf', 'dtmf_astart' or 'dtmf_dk'. This may or may not be combined
with one of either 'bell' or 'v23'.

Examples of correct 'cidsignalling' lines:
cidsignalling=bell
cidsignalling=dtmf_dk
cidsignalling=bell,dtmf
cidsignalling=dtmf_astart,bell

As you can see, order does not matter.

Examples of incorrect 'cidsignalling' lines:
cidsignalling=bell, dtmf
cidsignalling=dtmf_astart , dtmf ,bell

If more than one line is encountered the last one is the one
used.

The 'cidstart' takes one or two arguments:
'ring' and/or 'polarity'. Both may be used at the same time
and may be entered in any order. Same restrictions regarding
spacing exists for 'cidstart'.

Bugs:
-----
There are probably some bugs present, I will be surprised if not.

- One 'bug' is that the time delays around the DTMF string is regulated
  by the 'w' dial-string instruction. The delays caused by this may
  be excessive but testing has given that it's no big problem.

- It seems like the transmission of the caller-ID is interrupted if
  another line is answered resulting in a partial caller-ID on the
  equipment display on the unanswered device.

- Behavior on non-numeric caller-ID strings is not tested.
  This is generally not a problem.

---
Thank you Nils Hammar for providing this patch.

Updated by Doda from Asterisk 1.2.x to Asterisk 1.6.1.1
Comments:By: R.deAndres (maturs) 2009-09-01 20:30:49

doda, can i use this patch either with sangoma or digium?
Can you give some guidelines on configuring chan_dadhi.conf and /etc/dahdi/system.conf ???
i live in Uruguay (it is supposed that we have the same signalling as Denmark) and i'm using a Sangoma A200.

I been trying another patches but i still can't get CID.

Thanks


By: R.deAndres (maturs) 2009-09-01 21:16:58

I've tried some configurations and once i get this:
[Sep  1 20:05:47] DTMF[4552] channel.c: DTMF end 'D' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:47] DTMF[4552] channel.c: DTMF begin emulation of 'D' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:47] DTMF[4552] channel.c: DTMF begin '0' received on DAHDI/1-1
[Sep  1 20:05:47] DTMF[4552] channel.c: DTMF begin ignored '0' on DAHDI/1-1
[Sep  1 20:05:47] DTMF[4552] channel.c: DTMF end emulation of 'D' queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '0' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin emulation of '0' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin '2' received on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin ignored '2' on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end emulation of '0' queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '2' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '2' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin emulation of '2' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin '4' received on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin ignored '4' on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end emulation of '2' queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '4' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '4' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin emulation of '4' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin '0' received on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin ignored '0' on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '0' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end emulation of '4' queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '0' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin emulation of '0' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin '1' received on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin ignored '1' on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end emulation of '0' queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '1' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '1' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin emulation of '1' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin '1' received on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin ignored '1' on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end emulation of '1' queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '1' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '1' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin emulation of '1' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin '8' received on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin ignored '8' on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '8' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end emulation of '1' queued on DAHDI/1-1
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF end '8' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:48] DTMF[4552] channel.c: DTMF begin emulation of '8' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin '3' received on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin ignored '3' on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end '3' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end emulation of '8' queued on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end '3' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin emulation of '3' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin '3' received on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin ignored '3' on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end '3' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end emulation of '3' queued on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end '3' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin emulation of '3' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin 'C' received on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin ignored 'C' on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end 'C' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end emulation of '3' queued on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end 'C' received on DAHDI/1-1, duration 0 ms
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF begin emulation of 'C' with duration 100 queued on DAHDI/1-1
[Sep  1 20:05:49] DTMF[4552] channel.c: DTMF end emulation of 'C' queued on DAHDI/1-1
[Sep  1 20:05:50] VERBOSE[4552] pbx.c:     -- Executing [s@from-zaptel:2] Answer("DAHDI/1-1", "") in new stack
[Sep  1 20:05:50] VERBOSE[4552] pbx.c:     -- Executing [s@from-zaptel:3] Verbose("DAHDI/1-1", "CallerID =  ") in new stack
[Sep  1 20:05:50] VERBOSE[4552] app_verbose.c: CallerID =  


Any ideas ???
thanks
By: Josef Seger (doda) 2009-09-02 13:22:51

The patch provided works with Digium cards and should work with Sagoma.

However the patch is for sending DTMF callerid to phones attached to your Digium, Sagoma or other third party card on FXS ports.
The logg you have attached shows an incomming call with DTMF CID on an FXO port....

This patch does nothing on the incomming FXO ports. There are incomming DTMF CID related issues have you tried those patches?
By: R.deAndres (maturs) 2009-09-02 18:19:40

I been trying the 9096 issue patch with no luck.
Wich one do you recommend i should use?
Thanks
By: Leif Madsen (lmadsen) 2009-09-21 09:52:25

I will make a note that these patches should probably be updated to patch against Asterisk trunk, DAHDI-tools and DAHDI-linux trunk versions as this is a new feature. Thanks!
By: Reporter (mancy) 2010-06-14 21:05:16

what about adding wcfxo into this beside wctdm, so wcfxo holders can get this patch to work

thank you
By: Shaun Ruffell (sruffell) 2012-04-03 17:24:10.529-0500

I'm going through some of these old issues.

Is there any interest in updating these patches to the current trunk of DAHDI?  I know fxstest.c in the current trunk has support for generating DTMF callerid spills without polarity reversals, which is different than what is in these patches.