[asterisk-bugs] [JIRA] (DAHLIN-131) [patch] DTMF-CallerID support for FXS ports

[Keith Morgan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/DAHLIN-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Keith Morgan closed DAHLIN-131.
-------------------------------

    Resolution: Won't Fix

> [patch] DTMF-CallerID support for FXS ports
> -------------------------------------------
>
>                 Key: DAHLIN-131
>                 URL: https://issues.asterisk.org/jira/browse/DAHLIN-131
>             Project: DAHDI-Linux
>          Issue Type: New Feature
>          Components: NewFeature
>            Reporter: Josef Seger
>         Attachments: DTMF_1.6.1.1.patch, DTMF_DAHDI-LINUX_2.2.0.1.patch, DTMF_DAHDI-TOOLS_2.2.0.patch
>
>
> 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 



--
This message was sent by Atlassian JIRA
(v6.2#6252)