[asterisk-bugs] [DAHDI-linux 0007787]: [patch] DTMF Caller-ID support.

[Asterisk Bug Tracker]

The following issue has been ASSIGNED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=7787 
====================================================================== 
Reported By:                ehsnils
Assigned To:                jpeeler
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   7787
Category:                   NewFeature
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             2006-08-23 03:28 CDT
Last Modified:              2009-06-01 13:15 CDT
====================================================================== 
Summary:                    [patch] DTMF Caller-ID support.
Description: 
This should resolve Bug 3866.

This patch enables the ability for Asterisk to generate DTMF Caller-ID
on FXS ports as used in Scandinavia and the Netherlands.

This patch contains of two parts, one for Asterisk and one for Zaptel.

Code changes:
-------------
Be aware that the default of using 'bell' cidsignalling no longer exists,
this patch changes it to no signalling at all.

Several changes has been performed both to the Zaptel driver and to
chan_zap.

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. (Tested)

This patch is not intended to solve all ETSI defined caller-id
variants. (mostly due to lack of testing equipment)

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 zapata.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. (I have been lazy here) but that
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'. (but 'v23' isn't implemented
for FXS as far as I know)

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.

 - V23 caller-ID isn't supported.

 - 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.

---
Patch by Nils Hammar, Teleca Sweden West.

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0003866 [patch] Sending Polarity/DTMF Caller ID...
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-01 13:15 russell        Status                   feedback => assigned
2009-06-01 13:15 russell        Assigned To              tzafrir => jpeeler  
======================================================================