Summary:	ASTERISK-08138: [patch] Add accuracy range to incoming distinctive ring match
Reporter:	Steve Suehring (ssuehring)	Labels:
Date Opened:	2006-11-15 16:45:19.000-0600	Date Closed:	2006-11-16 16:33:21.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_zap
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_zap_changes.patch.txt ( 1) chan_zap.c_singlerange.patch
Description:	Incoming distintive ring tones are being detected with some level of inaccuracy, whether due to a bug in the driver or sloppiness on the part of the PSTN.  This means that dringN settings don't always match and therefore don't go to the correct context.  The current chan_zap.c code uses a hard-coded factor of +10 or -10 for each of the three values.  Additionally, sometimes the dring pattern is being detected woefully incorrect for the last two values when in practice only the first value is important. This patch adds a new configuration pair in zapata.conf called dringNrange which accepts an integer to be the factor by which each distinctive ring is matched.  If the value is not used, the default of +10/-10 is used.  Also, the ability to use a value of -1 for the dring pattern is included in the patch.  Using a value of -1 means that distMatches will automatically match regardless of what was detected.  This patch is especially helpful for when the ring is reported incorrectly.
Comments:	By: Jason Parker (jparker) 2006-11-16 13:39:49.000-0600 I'm a little confused about this. Why is range an int[3]?  When parsing the dringXrange param, you set range[0], and none of the others are ever set, but in the counter loop, you check range[counter].  Can you explain? Also, please note that this cannot go into 1.4 - this can only go into trunk.  I would be happy to put this into trunk, if you can explain the above - I like this feature. By: Steve Suehring (ssuehring) 2006-11-16 15:47:07.000-0600 Thanks for the feedback.  Sorry, I didn't explain it better.  The int[3] is for future support for the ability to do separate ranges for each of the three values in a dring match. Trunk is fine though admittedly I'll need to backport from trunk until the next version.  Is 1.4 feature-frozen? By: Jason Parker (jparker) 2006-11-16 15:51:57.000-0600 Okay, that helps clear things up.  Would you like to make that change before this gets committed?  If not, future patches can just go ahead and make it an int[3].  I'm a little worried about having a pattern that always matches on all three parts. Yes, 1.4 is feature frozen. By: Steve Suehring (ssuehring) 2006-11-16 16:22:17.000-0600 Let's just use the single range for now.  If there's a clamor to have even finer-grained control over the matches then I can add it later.  I've uploaded a patch to supersede the original patch that just uses int range now. Steve By: Jason Parker (jparker) 2006-11-16 16:33:21.000-0600 Added to svn trunk, in revision 47771. Thanks! Please feel free to open a new bug report for the next part of this, if you feel the need.