[asterisk-bugs] [Zaptel 0007787]: [patch] DTMF Caller-ID support.
noreply at bugs.digium.com
noreply at bugs.digium.com
Wed Dec 19 12:08:27 CST 2007
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=7787
======================================================================
Reported By: ehsnils
Assigned To: tzafrir
======================================================================
Project: Zaptel
Issue ID: 7787
Category: NewFeature
Reproducibility: N/A
Severity: feature
Priority: normal
Status: feedback
Zaptel Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 1332
Disclaimer on File?: No
Request Review:
======================================================================
Date Submitted: 08-23-2006 03:28 CDT
Last Modified: 12-19-2007 12:08 CST
======================================================================
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...
======================================================================
----------------------------------------------------------------------
tzafrir - 12-19-07 12:08
----------------------------------------------------------------------
Thanks for your prompt response.
Regarding the configuration variable: change the parsing to something of
the sort of:
int new_cidsignalling = 0
while( ... ) { /* looping over the comma-separated values
if (!strcasecmp(p1, "bell"))
new_cidsignalling |= CID_SIG_BELL;
if (!strcasecmp(p1, "v23"))
new_cidsignalling |= CID_SIG_V23;
...
}
cidsignalling = new_cidsignalling;
Next, there is the problem with v23. Why does the patch break v23?
Issue History
Date Modified Username Field Change
======================================================================
12-19-07 12:08 tzafrir Note Added: 0075724
======================================================================
More information about the asterisk-bugs
mailing list