[Home]

Summary:ASTERISK-15328: [patch] DTMF CallerID detection without polarity reversal
Reporter:Sebastian Gutierrez (sum)Labels:
Date Opened:2009-12-17 08:55:50.000-0600Date Closed:2010-04-29 18:13:32
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ciddetectionv1.patch
( 1) issue16460_v1.6.2.patch
( 2) issue16460.patch
Description:This is related to closed bug 9096, the patch is working fine but there are some cases where the callerid is not detected due to  DTMFCID timed out waiting for ring. Exiting simple switch
This happends when I connect a telular base to a TDM400P, convencional lines has no problems.
The thing is that the callerid is detected, but it seems to have a problem detecting the ring after the callerid is setted, sometimes it hangsup the channel and it starts again a simple switch, this time the channel detects the ring but it misses the callerid. I have a small fix but maybe this is not the best way to do it.

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

The patch intends to not hangup the line of there is a timeout wainting for ring if a callerid is already detected.
Comments:By: Leif Madsen (lmadsen) 2009-12-17 09:00:13.000-0600

Did you say you have a patch you were planning on attaching?
By: Sebastian Gutierrez (sum) 2009-12-17 09:04:20.000-0600

you didn't give me the time to upload it :)

Sometimes I have some false Prering state on the lines, the code as it was prevents to get the channels in congestion hangin up the channels that are prering but no a real call. They also appear when the line is hanged.

this seems to fix the problem of the detection and it doesn't break the hability to hangup those channels.
The patch as it is is working but there may be a better solution.
By: Leif Madsen (lmadsen) 2009-12-17 09:43:54.000-0600

Heh, I didn't realize I commented only 5 minutes after you opened the issue :)  It was just in my queue of New issues to look at, and didn't look at the submission time :)
By: Sebastian Gutierrez (sum) 2009-12-28 14:34:56.000-0600

any comment on this issue? is working fine in a production environment for 1 week, is a small site.


By: Leif Madsen (lmadsen) 2010-01-04 14:04:19.000-0600

At this point the issue is ready for testing, and as soon as a developer has the time, they will review and then possibly commit this. I'd suggest asking the asterisk-users and/or asterisk-dev mailing lists for people to test this issue and to provide feedback on it.

Otherwise, the issue will be moved forward as time and resources permit. Thanks!
By: Richard Mudgett (rmudgett) 2010-04-08 17:56:27

The original patch will only work for a specific format DTMF caller id.  Specifically, those that are framed by the A and C DTMF digits.

I have attached a different patch that may resolve your issue without sacrificing the other DTMF caller id formats.  I increased the timeout from 2 seconds to 4 seconds.
By: Sebastian Gutierrez (sum) 2010-04-08 18:10:25

is this patch for trunk? could you add one for 1.6.2 branch, this is the only way I can test it right now, so we can move this issue as fast as possible. Thanks! (I know the patch will be commited only in trunk, but at the moment is the best I can do to test it)
By: Richard Mudgett (rmudgett) 2010-04-09 18:15:33

The issue16460.patch was against 1.4.

I have attached a 1.6.2 version.
By: Leonardo Cardozo Vargas (lcvleo) 2010-04-11 21:20:12

In my case, the patch don't work.
I use Asterisk 1.6.2.6 with a Brazil's Net Phone via Embratel PSTN line and I must use:
cidsignalling=dtmf
cidstart=polarity
Without it, Caller ID don't work.
By: Sebastian Gutierrez (sum) 2010-04-16 23:36:18

the patch works like a charm!! is in production already with 1.6.2.1 tomorrow I'll put it on 1.6.2.6 in production too, I will let you know more in some days to see that the beheavior is as expected, so we can close this issue!
By: Sebastian Gutierrez (sum) 2010-04-17 11:18:39

tested on 1.6.2.6 working ok, I have just one issue that I can't figure out why happens, when a hangup occurrs I get this

Example:

 -- DAHDI/5-1 answered SIP/1001-0000004b
   -- Hungup 'DAHDI/5-1'
== Spawn extension (salientes, 4187645, 6) exited non-zero on 'SIP/1001-0000004b'
 == MixMonitor close filestream
-- Starting simple switch on 'DAHDI/5-1'
[Apr 17 14:09:40] WARNING[5417]: chan_dahdi.c:8399 ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch
   -- Hungup 'DAHDI/5-1'

Like a false incoming call, do you think some configuration? dtmfcidlevel? or something like that?

Sometimes that happens on a line without a call

Example:

  -- Starting simple switch on 'DAHDI/5-1'
[Apr 17 14:10:44] WARNING[5424]: chan_dahdi.c:8399 ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch
   -- Hungup 'DAHDI/5-1'
   -- Starting simple switch on 'DAHDI/5-1'
[Apr 17 14:11:22] WARNING[5425]: chan_dahdi.c:8399 ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch
   -- Hungup 'DAHDI/5-1'

any ideas?

as an extra comment: this happens on lines with and without polarity reversal.


By: Sebastian Gutierrez (sum) 2010-04-17 11:37:37

lcvleo: this configuration is for

cidsignalling=dtmf
cidstart=dtmf
dtmfcidlevel=200

if your provider sends dtmf callerid without polarity reversal as the start of the dtmfs this should work for you.
By: Leonardo Cardozo Vargas (lcvleo) 2010-04-17 18:05:13

[Apr 17 20:04:02] DEBUG[22303] chan_dahdi.c: Monitor doohicky got event Polarity Reversal on channel 2
[Apr 17 20:04:04] DEBUG[22303] chan_dahdi.c: Monitor doohicky got event Polarity Reversal on channel 2
[Apr 17 20:04:04] DEBUG[22303] chan_dahdi.c: Monitor doohicky got event Ring Begin on channel 2
[Apr 17 20:04:06] DEBUG[22303] chan_dahdi.c: Monitor doohicky got event Ring/Answered on channel 2
[Apr 17 20:04:06] VERBOSE[22344] chan_dahdi.c:     -- Starting simple switch on 'DAHDI/2-1'
[Apr 17 20:04:08] WARNING[22344] chan_dahdi.c: DTMFCID timed out waiting for ring. Exiting simple switch
[Apr 17 20:04:08] DEBUG[22344] chan_dahdi.c: dahdi_hangup(DAHDI/2-1)
[Apr 17 20:04:08] DEBUG[22344] chan_dahdi.c: Hangup: channel: 2 index = 0, normal = 30, callwait = -1, thirdcall = -1
[Apr 17 20:04:08] DEBUG[22344] chan_dahdi.c: Set option TDD MODE, value: OFF(0) on DAHDI/2-1
[Apr 17 20:04:08] DEBUG[22344] chan_dahdi.c: Updated conferencing on 2, with 0 conference users
[Apr 17 20:04:08] VERBOSE[22344] chan_dahdi.c:     -- Hungup 'DAHDI/2-1'
By: Sebastian Gutierrez (sum) 2010-04-17 19:06:33

are you sure the callerid is DTMF without polarity reversal?
your config? dtmfcidlevel could be diferent also but I don't know if this is the case, if you increase the debug level on that channel we may see if the dtmf digits are coming. you could send a mail to the asterisk list and I can help you contacting you directly off list.
By: Leonardo Cardozo Vargas (lcvleo) 2010-04-17 20:24:34

Sum,

Thank you so much for all help, but to say the truth, I don't really know if my PSTN's operator sends the CID without polarity reversal, and here in Brazil, the service is so bad that they don't know nothing.

Anyway, I thank you very much. You're very nice! ;)
lcvleo@live.com
By: Leif Madsen (lmadsen) 2010-04-19 14:15:46

So this looks like it is ready for review then.
By: Digium Subversion (svnbot) 2010-04-29 17:11:47

Repository: asterisk
Revision: 260195

U   branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines

DTMF CallerID detection problems.

The code handling DTMF CallerID drops digits on long CallerID numbers and
may timeout waiting for the first ring with shorter numbers.

The DTMF emulation mode was not turned off when processing DTMF CallerID.
When the emulation code gets behind in processing the DTMF digits it can
skip a digit.

For shorter numbers, the timeout may have been too short.  I increased it
from 2 seconds to 4 seconds.  Four seconds is a typical time between rings
for many countries.

(closes issue ASTERISK-15328)
Reported by: sum
Patches:
     issue16460.patch uploaded by rmudgett (license 664)
     issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
Tested by: sum, rmudgett

Review: https://reviewboard.asterisk.org/r/634/

JIRA SWP-562
JIRA AST-334
JIRA SWP-901

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=260195
By: Digium Subversion (svnbot) 2010-04-29 17:44:15

Repository: asterisk
Revision: 260231

_U  trunk/
U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_analog.c

------------------------------------------------------------------------
r260231 | rmudgett | 2010-04-29 17:44:14 -0500 (Thu, 29 Apr 2010) | 33 lines

Merged revisions 260195 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
 
 DTMF CallerID detection problems.
 
 The code handling DTMF CallerID drops digits on long CallerID numbers and
 may timeout waiting for the first ring with shorter numbers.
 
 The DTMF emulation mode was not turned off when processing DTMF CallerID.
 When the emulation code gets behind in processing the DTMF digits it can
 skip a digit.
 
 For shorter numbers, the timeout may have been too short.  I increased it
 from 2 seconds to 4 seconds.  Four seconds is a typical time between rings
 for many countries.
 
 (closes issue ASTERISK-15328)
 Reported by: sum
 Patches:
       issue16460.patch uploaded by rmudgett (license 664)
       issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
 Tested by: sum, rmudgett
 
 Review: https://reviewboard.asterisk.org/r/634/
 
 JIRA SWP-562
 JIRA AST-334
 JIRA SWP-901
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=260231
By: Digium Subversion (svnbot) 2010-04-29 17:57:17

Repository: asterisk
Revision: 260232

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_dahdi.c

------------------------------------------------------------------------
r260232 | rmudgett | 2010-04-29 17:57:16 -0500 (Thu, 29 Apr 2010) | 40 lines

Merged revisions 260231 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r260231 | rmudgett | 2010-04-29 17:44:14 -0500 (Thu, 29 Apr 2010) | 33 lines
 
 Merged revisions 260195 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
   
   DTMF CallerID detection problems.
   
   The code handling DTMF CallerID drops digits on long CallerID numbers and
   may timeout waiting for the first ring with shorter numbers.
   
   The DTMF emulation mode was not turned off when processing DTMF CallerID.
   When the emulation code gets behind in processing the DTMF digits it can
   skip a digit.
   
   For shorter numbers, the timeout may have been too short.  I increased it
   from 2 seconds to 4 seconds.  Four seconds is a typical time between rings
   for many countries.
   
   (closes issue ASTERISK-15328)
   Reported by: sum
   Patches:
         issue16460.patch uploaded by rmudgett (license 664)
         issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
   Tested by: sum, rmudgett
   
   Review: https://reviewboard.asterisk.org/r/634/
   
   JIRA SWP-562
   JIRA AST-334
   JIRA SWP-901
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=260232
By: Digium Subversion (svnbot) 2010-04-29 18:03:28

Repository: asterisk
Revision: 260233

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_dahdi.c

------------------------------------------------------------------------
r260233 | rmudgett | 2010-04-29 18:03:28 -0500 (Thu, 29 Apr 2010) | 40 lines

Merged revisions 260231 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r260231 | rmudgett | 2010-04-29 17:44:14 -0500 (Thu, 29 Apr 2010) | 33 lines
 
 Merged revisions 260195 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
   
   DTMF CallerID detection problems.
   
   The code handling DTMF CallerID drops digits on long CallerID numbers and
   may timeout waiting for the first ring with shorter numbers.
   
   The DTMF emulation mode was not turned off when processing DTMF CallerID.
   When the emulation code gets behind in processing the DTMF digits it can
   skip a digit.
   
   For shorter numbers, the timeout may have been too short.  I increased it
   from 2 seconds to 4 seconds.  Four seconds is a typical time between rings
   for many countries.
   
   (closes issue ASTERISK-15328)
   Reported by: sum
   Patches:
         issue16460.patch uploaded by rmudgett (license 664)
         issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
   Tested by: sum, rmudgett
   
   Review: https://reviewboard.asterisk.org/r/634/
   
   JIRA SWP-562
   JIRA AST-334
   JIRA SWP-901
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=260233
By: Digium Subversion (svnbot) 2010-04-29 18:13:31

Repository: asterisk
Revision: 260234

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r260234 | rmudgett | 2010-04-29 18:13:30 -0500 (Thu, 29 Apr 2010) | 40 lines

Merged revisions 260231 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r260231 | rmudgett | 2010-04-29 17:44:14 -0500 (Thu, 29 Apr 2010) | 33 lines
 
 Merged revisions 260195 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
   
   DTMF CallerID detection problems.
   
   The code handling DTMF CallerID drops digits on long CallerID numbers and
   may timeout waiting for the first ring with shorter numbers.
   
   The DTMF emulation mode was not turned off when processing DTMF CallerID.
   When the emulation code gets behind in processing the DTMF digits it can
   skip a digit.
   
   For shorter numbers, the timeout may have been too short.  I increased it
   from 2 seconds to 4 seconds.  Four seconds is a typical time between rings
   for many countries.
   
   (closes issue ASTERISK-15328)
   Reported by: sum
   Patches:
         issue16460.patch uploaded by rmudgett (license 664)
         issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
   Tested by: sum, rmudgett
   
   Review: https://reviewboard.asterisk.org/r/634/
   
   JIRA SWP-562
   JIRA AST-334
   JIRA SWP-901
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=260234