Summary:	ASTERISK-00893: [patch] Diff to chan_modem, three new features, dtmf inband
Reporter:	nogren (nogren)	Labels:
Date Opened:	2004-01-22 03:31:30.000-0600	Date Closed:	2004-09-25 02:42:31
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) isdn_dtmf.patch.gz ( 1) isdn_dtmf-new.patch.gz ( 2) isdn_dtmf-new2.patch.gz ( 3) isdndtmf01.diff ( 4) isdndtmf02.diff
Description:	I added three new features to my cvs checkout to chan_modem.c, chan_modem_i4l.c and vmodem.h ****** ADDITIONAL INFORMATION ****** * Config parameter to not bother about DTMF signalling received outband from ISDN-network (allowoutbanddtmf). This is because you sometimes receive garbage from ISDN network or wrong detected digits from ISDN4Linux. * Config parameter to add string/a number to the calling party id received from network (cidprefix). We receive the numbers without the leading zero here in Sweden (EuroISDN, more or less)   * Ability to generate DTMF digits inband when Asterisk sends them to ISDN network. Again, our kind of EuroISDN here in Sweden don't bother about outband DTMF, so I have to send them inband.   Patch for includes/asterisk/vmodem.h, channels/chan_modem.c and channels/chan_modem_i4l.c attached. I noticed that the latest CVS of chan_modem.c had some new stuff included, but this patch is easily added without any problem. Can anybody include this to Asterisk cvstree, maybe after a sanity check of the code?
Comments:	By: Olle Johansson (oej) 2004-03-21 15:30:40.000-0600 Is this patch still valid? Anyone else that have tested this and think it's a good thing? By: nogren (nogren) 2004-03-22 07:32:36.000-0600 I have not tried to download from cvs and patch with this patch since .. well.. a month ago, but otherwise it is still valid and needed. /Niklas By: farnwomt (farnwomt) 2004-04-07 15:16:15 Is a simple prefix for callerid numbers sufficient?  I did something similar with just regular asterisk application commands, ie: exten => s,2,SetCallerID(0${CALLERIDNUM}) However the problem I have is that international calls don't have 00 in front, and national calls lack 0, so the net result is that an international call looks like a national one.  Confusing I think!  I notice the CAPI driver doesn't have this problem, but my CAPI card isn't working right now. By: Mark Spencer (markster) 2004-04-27 02:21:50 Hrm...  Do you wanna go ahead and move chan_modem to poll instead of select while you're at it? By: Mark Spencer (markster) 2004-05-01 11:14:44 I'm surprised anyone is still working on this code even.  By the way, it should be possible to simply return "-1" from the digit routine and have asterisk generate the digit audio for you so you don't have to do it with your own code. By: Mark Spencer (markster) 2004-05-25 01:33:48 Appears to have been abandoned by the original author. By: nogren (nogren) 2004-05-25 01:57:24 I have had vacation, and to much other things going around.. But you guys are right with the CID prefix stuff, and I will look into  the dtmf-generation, and let other routines do that. I still need the configuration parameters though, especially when the dtmf detection in isdn4linux is so bad. I also have to be honest and say that I haven't triend the capi stuff yet. :-) I will submit another patch, hopefully next week. By: nogren (nogren) 2004-06-02 08:32:17 New patch added, with two config options instead, one to allow outband dtmf and another to let asterisk insert inband dtmf when sendint out to isdn network. Comments and config sample added to modem.conf-sample in patch as well. This two additions are needed at least in the Swedish ISDN network. This patch replaces the first file, dtmf-inband.patch.gz By: nogren (nogren) 2004-06-04 03:09:15 By the way, maybe markster can answer if it's possible to let Asterisk to decode the inband DTMF coming from ISDN network, instead of ISDN4Linux, that is very bad at that and inject DTMF all the time? I think I4L is using integers for detection, and Asterisk floats, right? By: Mark Spencer (markster) 2004-06-04 13:23:30 Yes, you can use the DTMF routines in dsp.c (chan_zap uses it as well).  Just let me know when you have a new patch.  If you need me I'll be in #asterisk on irc.freenode.net (kram). By: nogren (nogren) 2004-06-09 06:22:04 Alright, I have attached a dsp to a ttyI-channel now, if configured. It seems to work well when "relaxdtmf" is off here in my test environment. Please revise and merge the new diff with Asterisk HEAD if it looks alright. This patch replaces the old one, and adds four config directives to modem.conf and some info in vmodem.h, chan_modem.c, chan_modem_i4l.c and modem.conf.sample. ; Allow ISDN4Linux detection of DTMF to reach Asterisk internal ; (ISDN4Linux sometimes detects digits when no digits are pressed, ; and if DTMF controlling of asterisk is not used, this can be ; set to "0".) allowoutbanddtmf=1 ; Generate inband DTMF as well as the traditional ISDN outband DTMF ; when digits are sent out to ISDN4Linux. ; Is good to use when voip clients only send outband DTMF to Asterisk, ; but inband is required to control your telephony bank or similar. generateinbanddtmf=0 ; If Asterisk internal inband DTMF routines should be used instead ; of ISDN4Linux. Set allowoutbanddtmf=0 if this is used. detectinband=0 ; Relax the DTMF detection made with detectinband relaxdtmf=0 The defaults is set to behaviour before this patch. By: nogren (nogren) 2004-06-14 04:22:09 Sorry, placed the configuration directives wrong in modem.conf-sample. Fixed in the last file isdn_dtmf-new2.patch.gz By: Matthias Urlichs (smurfix) 2004-06-14 08:16:56 As to the 0/00 problem, EuroISDN (q.931 actually) marks the scope of the numbers in a separate protocol element, so a driver-specific scope=>prefix mapping for incoming numbers is definitely necessary. Outgoing numbers are easier since you can simply mark the numbers as "local dialling plan", send them as-is, and let the other side sort them out. By: nogren (nogren) 2004-06-21 06:08:50 Diff-file for todays cvs checkout of Asterisk. Wouldn't mind getting this into cvs head... By: Mark Spencer (markster) 2004-06-21 11:20:02 Looks like a good patch.  I do have the following suggestion though: Lets simplify all the DTMF options: ; ; Specify DTMF mode: ;    asterisk: Asterisk performs in-band detection/generation ;    i4l:      ISDN4Linux performs in-band detection/generation ; ;dtmfmode=asterisk If you really think that people will want to mix with one part doing detection and the other generation you could allow something like: dtmfmode=asterisk/i4l but i'm not sure there would ever really be a case for that. By: nogren (nogren) 2004-06-22 01:09:42 Problem is, that i4l cant do inband generation, only detection. But it will send outband dtmf. I will try to write that option, with clear comment in the sample config, to make it more simple. By: Mark Spencer (markster) 2004-06-22 01:12:45 If it doesn't send, then it's just a question of what's detecting. In any case we can do "dtmfmode=asterisk" or "dtmfmode=i4l" to select who does the dtmf detect right?  In the sample config, we should probably make the default be "dtmfmode=asterisk" By: nogren (nogren) 2004-06-22 04:13:41 Okay, new patch with a dtmfmode (for detection) and a dtmfmodegen (for generation) option. Can be asterisk (default for both), i4l (inband detection, outband generation), off or both in the case of generation. By: Mark Spencer (markster) 2004-06-22 10:31:34 Merged in CVS, but i modified the syntax slightly so it all fits within a single option.  If you have any problems just find me on IRC.  Thanks!