I'm running asterisk as root.<br><br>I've done something interesting. I have modified the chan_ss7 in order to work with zaptel HDLC. I mean dchan and hardhdlc in zaptel.conf.<br><br>The modification is on mtp.c replacing the read_su where it is doing the fast_hdlc and crc test, etc.
<br><br>With dchan option, appears some <span style="font-weight: bold;">ZT_EVENT_BADFCS</span> and <span style="font-weight: bold;">ZT_EVENT_ABOR</span>T errors after doing a <span style="font-weight: bold;"><span style="font-weight: bold;">
"</span>ioctl(fds[i].fd, ZT_GETEVENT, &x)"</span> <br><br>Another test I did also was changing dchan by hardhdlc in zaptel.conf, and with hardhdlc, it works without problem.<br><br>Just one thing happened to me with hardhdlc and only one time, I hope it be the last. I'm running and IBM x346 with a Wildcard TE410P (3rd Gen), and at the first test with hardhdlc, my server rebooted with and error "Uhhuh. NMI received for unknown reason 35 on CPU 0."
<br><br>After this reboot, it doesn't appear again.<br><br>I'm still testing....<br><br><br><br>On 06 Nov 2006 08:03:16 +0100, Kristian Nielsen <<a href="mailto:knielsen@mysql.com">knielsen@mysql.com</a>> wrote:<br>
> "Robert Kenton" <<a href="mailto:robert.kenton@gmail.com">robert.kenton@gmail.com</a>> writes:<br>> <br>> > I've tested with just 60 channels, and even when the 60 channels are<br>> > not fully used, appears too much "
mtp.c: MTP2 bitstream frame format<br>> > error, entering octet counting mode..." and after that some of these<br>> > messages, the link goes down.<br>> <br>> Did you start Asterisk as user root, so it can use real-time priorities?
<br>> <br>> The chan_ss7 architecture splits the work-load in two parts, only one of which<br>> has real-time requirements, and runs the critical part at a high real-time<br>> priority to make sure it gets sufficient CPU. However, Linux real-time
<br>> priorities require root privileges.<br>> <br>> BTW, doing 60 calls within a single second, you might want to calculate<br>> whether you have sufficient bandwidth on your signalling link. But even so, it<br>
> should not cause the MTP2 layer to drop.<br>> <br>> - Kristian.<br>> <br>> _______________________________________________<br>> --Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com
</a> --<br>> <br>> asterisk-ss7 mailing list<br>> To UNSUBSCRIBE or update options visit:<br>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-ss7">http://lists.digium.com/mailman/listinfo/asterisk-ss7
</a><br>> <br>