<div>On Thu, Oct 8, 2009 at 10:45 AM, Emiliano Agustin <span dir="ltr"><<a href="mailto:emilianoar@msn.com">emilianoar@msn.com</a>></span> wrote:</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
Good work!!!<br>But Moises, why this work? It shouln't be tdmv_dchan=16 always for CAS?<br>What is de efect of changing the dchan to 0?<br><br></div></blockquote><div><br></div><div><div>No easy answer unless we dive into the driver for a couple of hours, and things may differ from one driver version to another.</div>
<div><br></div>The dchan setting never made sense for CAS spans neither in zaptel.conf/chan_dahdi.conf or in wanpipex.conf<div><br></div><div>The dchan setting basically should enable the HDLC engine at the driver level (just as hardhdlc=16 enables the HDLC engine at the hardware level), given that in CAS spans the bits in channel 16 are used raw and for multi frame alarms and may be some other tiny bits of information here and there, is just silly to set dchan=16 or TDMV_DCHAN=16 for CAS spans, because when you work on E1's and you have CAS signaling, channel 16 is used for the ABCD bits and not for HDLC data. Even some zaptel versions refused to accept dchan=16, but later was accepted again, not sure why, we would need to dig into the zaptel driver to check it out, but I bet behavior may differ from version to version.</div>
<div><br></div><div>As of wanpipe, TDMV_DCHAN=16 may be a left over as well. I believe usually the driver is smart enough to figure out that in CAS mode the hdlc engine should be turned off regardless of the user configuration, but sometimes not and that may mess with the abcd bits signaling and/or other signaling in cas spans. <br>
<br></div></div><div><br></div></div>-- <br>Moises Silva<br>Software Developer<br>Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada<br>t. 1 905 474 1990 x 128 | e. <a href="mailto:moy@sangoma.com">moy@sangoma.com</a><br>
</div>