Summary:	ASTERISK-14185: [patch] v.110 dialin support for ISDN channels
Reporter:	David Woodhouse (dwmw2)	Labels:	patch
Date Opened:	2009-05-22 03:04:20	Date Closed:	2018-01-02 08:49:50.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_v110_td.c ( 1) app_v110.c ( 2) app_v110.c ( 3) app_v110.c.backwards ( 4) app_v110.c.trunk-rev-196585 ( 5) app_v110-rev-221968.patch
Description:	Many years ago I wrote app_v110.c for use with mISDN channels. It was included in the Beronet app_bundle which I thought they were going to submit after chan_mISDN was merged: http://www.asteriskguru.com/archives/asterisk-dev-re-chanmisdn-in-asterisk-beta-2-vt60496.html#170458 Someone's now made it work with Zap channels too, and is asking why it didn't get merged. I'll attach my original code for reference and state that I have a disclaimer on file. Hopefully I can let the person who ported it to Zap take care of submitting an up to date version which is tested with current Asterisk code.
Comments:	By: Moises Silva (moy) 2009-05-22 11:05:07 I will upload the new patch asap, I am cleaning up the mod since has several hard coded stuff I added while trying to make it work for DAHDI. By: Moises Silva (moy) 2009-05-25 11:03:11 uploaded up-to-date patch. One of the changes needed to make it work with dahdi was bit swapping, it seems mISDN or the fact that David this on ppc made the application depend on certain bit (not byte) order. If anyone can point me to a current bit swapping routine inside asterisk I will use it instead of the one I included. By: David Woodhouse (dwmw2) 2009-05-26 04:02:53 I have a vague recollection that when I first wrote app_v110, I was having to flip the bits too. I think they come in from the hardware "backwards", which is actually the way we want them for app_v110. And chan_mISDN was reversing them to be "correct". I think that it was the 'MISDN_DIGITAL_TRANS' variable we set before accepting the call which disables the bit-flipping. This is probably all different now that chan_mISDN is deprecated by chan_lcr. I don't know whether app_v110 is still working with LCR. (I did make a new box to take over from my ancient Asterisk installation, but got sidetracked after realising that chan_misdn no longer exists and I have to set up LCR to run in parallel with Asterisk.) I optimised the bit manipulation routines to cope with 'backward-bit-endian' data; there will be more efficient ways to handle normal data than just bit-flipping all input and output from the existing code. By: David Woodhouse (dwmw2) 2009-05-26 04:08:35 Attached 'app_v110.c.backwards' I found lying around on my old box. This version shares some code with the Linux kernel's v.110 implementation, and thus isn't suitable for inclusion in Asterisk. It's merely an example of how things could be done better for 'normal-ordered' bits. (The later version, which I originally uploaded here, was completely rewritten and is all my own work, covered by my disclaimer). By: Moises Silva (moy) 2009-05-27 21:47:26 Additional code needed in chan_dahdi.c and libpri q931.c, I am preparing the patches. By: Leif Madsen (lmadsen) 2009-09-18 08:50:35 Setting this to feedback while awaiting patches from moy. Thanks! By: Moises Silva (moy) 2009-09-18 09:23:30 Waiting Feedback from one tester. I no longer have access to v.110 line so cannot test myself. If anyone can give me access to the line I can take a look and complete this feature. By: Thomas Dackweiler (tomzack) 2009-10-01 07:06:29 I'm currently working on a ISDN-dialin solution, so I could try. At the moment it doesn't compile correctly neither on asterisk-BE nor on asterisk-open-source. I will try it with mISDN By: Thomas Dackweiler (tomzack) 2009-10-02 11:14:02 what is about app_pppd ? By: Moises Silva (moy) 2009-10-02 11:36:34 tomzack: you did not say which app_v110.c version you tried. Also, you must test with Asterisk trunk svn. I don't plan adapting this for other Asterisk version than trunk. I just attached a new patch, whith a fix in chan_dahdi.c to by-passing ast_dsp_process call when the call is digital, that seemed to be what was breaking the v.110 stream badly. You should try with patch app_v110-rev-221968.patch I discussed the by-passing of ast_dsp_process with kpfleming on IRC and he thinks is reasonable, so that little fix should not break anything else. I don't know anything about app_pppd. By: Thomas Dackweiler (tomzack) 2009-10-02 12:03:10 I tried app_v110.c.trunk-rev-196585 against asterisk-be-C.2.1.2 (this is almost a modified asterisk 1.6x I think) I adapted added some debug, but the STDOUT doesnot map to STDIN of pppd (can pppd handle piping ? Or must you provide an pseudo-TTY?) I added the source app_v110_td.c    -- Executing [21@isdnNT/4:2] V110("mISDN/7-u1", "/usr/sbin/pppd call isdn") in new stack [Oct  2 18:57:38] NOTICE[27067]: app_v110.c:293 echo_v110: /usr/sbin/pppd call isdn (null) <pseudoTTY> got for execution on call[Oct  2 18:57:38] NOTICE[27067]: app_v1e [Oct  2 18:57:38] NOTICE[27067]: app_v110.c:322 echo_v110: data structure allocated[Oct  2 18:57:38] NOTICE[27067]: app_v110.c:327 echo_v110: tech-type mISDN detected[n [Oct  2 18:57:38] NOTICE[27067]: app_v110.c:334 echo_v110: V.110 activated trace file /var/log/ram/v110_trace-trace_raw_out [Oct  2 18:57:38] NOTICE[27067]: app_v110.c:335 echo_v110: V.110 activated trace file /var/log/ram/v110_trace-trace_data_in [Oct  2 18:57:38] NOTICE[27067]: app_v110.c:336 echo_v110: V.110 activated trace file /var/log/ram/v110_trace-trace_data_out [Oct  2 18:57:38] NOTICE[27067]: app_v110.c:338 echo_v110: trace enabled [Oct  2 18:57:38] NOTICE[27067]: app_v110.c:384 echo_v110: calling external program [Oct  2 18:57:38] NOTICE[27067]: app_v110.c:407 echo_v110: Accepting V.110 call indali*CLI> Oct  2 18:57:38 localhost pppd[27069]: no device specified and stdin is not a tty By: Moises Silva (moy) 2009-10-02 12:10:53 tomzack, even when your problem does not seem related to versioning, in any case you should using latest patch and asterisk trunk. By: Leif Madsen (lmadsen) 2009-10-05 11:53:14 Asterisk BE C-2.1.2 is based on 1.4. There are no BE versions based on 1.6.x afaik. As stated, test against trunk, which this patch is created against. This will not work against 1.6.x or lower. By: Leif Madsen (lmadsen) 2009-10-05 11:55:42 Marking this as Confirmed. If there are actually patches here fully ready for testing, let me know and I can upgrade the status on this issue. Thanks! By: Ferenc Felhoffer (silveraid) 2010-01-11 11:45:15.000-0600 Sorry for the long sleep, but I am the missing tester. So I tested the app_v110-rev-221968 on my box today, and it worked perfectly. Some details about the environment: Hardware: Intel SR2500 server, 8GB DDR2, 1x E5410 CPU, Sangoma A108de (v40 firmware) Software: Debian Lenny, Dahdi 2.2.0.2+2.2.0, LibPRI 1.4.10.2, Wanpipe 3.5.9, Asterisk 1.6.2.0 The patch fits, the compilation was flawless. I tested the stuff between an E1 and a GSM provider. It worked well, but sometimes if I killed the originator end the asterisk died with sigsegv. By: Moises Silva (moy) 2010-01-11 13:03:40.000-0600 I need a full backtrace of Asterisk when dying. Please follow the instructions at: http://www.voip-info.org/wiki/view/Asterisk+debugging#Backtracingacoredumpfileintmp In order to attach (DO NOT PASTE IT AS A COMMENT) the full back trace txt file. By: Leif Madsen (lmadsen) 2010-01-11 14:23:56.000-0600 Oops, I missed -- setting to "ready for testing" By: Ferenc Felhoffer (silveraid) 2010-05-28 05:30:33 I tested again with the latest software packages and there was not any problem. Hardware: Intel SR2500 server, 8GB DDR2, 1x E5410 CPU, Sangoma A108de (v41 firmware) Software: Debian Lenny, Dahdi 2.3.0+2.3.0, LibPRI 1.4.11, Wanpipe 3.5.11, Asterisk 1.6.2.7 It works perfectly for me :-). By: David Woodhouse (dwmw2) 2011-08-23 12:31:00.190-0500 This is an updated version of app_v110.c, tested with Asterisk 1.8 and Dahdi on an ISDN BRI card. I've fixed up the bit-reversing code so that it works more efficiently. Just flipping the whole input/output buffers was a bit simplistic. I've also removed the debugging trace stuff which was causing crashes (just a use-after-free but it could die anyway). I've optimised it so that when it is sending multiple empty V.110 frames (a common occurrence if the line is ever idle) it doesn't recalculate the whole Asterisk frame. This gives a big decrease in CPU time. By: Corey Farrell (coreyfarrell) 2017-12-14 13:59:27.654-0600 Are you interested in pursuing this further?  If so your code will likely need to be updated to work with current versions of Asterisk then submitted to gerrit for review. ---- Thanks for the contribution! If you'd like your contribution to be included faster, you should submit your patch for code review by the Asterisk Developer Community. To do so, please follow the Code Review \[1\] instructions on the wiki. Be sure to: * Verify that your patch conforms to the Coding Guidelines \[2\] * Review the Code Review Checklist \[3\] for common items reviewers will look for * If necessary, provide tests for the Asterisk Test Suite that verify the correctness of your patch \[4\] When ready, submit your patch and any tests to Gerrit \[5\] for code review. Thanks! \[1\] https://wiki.asterisk.org/wiki/display/AST/Code+Review \[2\] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines \[3\] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist \[4\] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation \[5\] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage By: Asterisk Team (asteriskteam) 2018-01-02 08:49:50.861-0600 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines