<div class="gmail_quote">On Mon, Jul 20, 2009 at 12:06 PM, Arturo Ochoa <span dir="ltr"><<a href="mailto:arturo.era@gmail.com">arturo.era@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
AFAIK, unicall or openr2, are library's that let asterisk understand<br>
mfc-r2 signaling.... </blockquote><div><br></div><div>That is partially correct. Unicall is a general purpose telephony abstraction, not just for R2 signaling (even when in the real world it seems just R2 is being used), so in order to compare openr2, we shall compare it with libmfcr2, not unicall.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The kernel driver (zaptel or dahdi) is the one in<br>
charge of all the communication between the card and the operating<br>
system. So, every time the card detects loose signal... the driver is<br>
the one that notifies the kernel about it.....This is my<br>
understanding, please correct me, if I'm wrong...<br>
</blockquote><div><br></div><div>The kernel driver (zaptel or dahdi or wanpipe) handle low level communications and indeed they are the ones responsible for notifying userland applications (like Asterisk using libmfcr2 or openr2) when something goes wrong at the layer 1. However what to do under such conditions is responsibility of the application (Asterisk), both, libmfcr2 and openr2 just notify the user application of the condition.</div>
<div><br></div><div><div>So, first thing first, neither openr2 or Unicall/libmfcr2 do nothing else during an alarm condition than reporting to Asterisk that the alarm just occurred.</div><div><br></div><div>Having said that, the difference is between chan_zap and chan_unicall.</div>
<div><br></div><div>chan_unicall ignores alarms, you can find Steve comments in chan_unicall.c, search for UC_EVENT_ALARM, and you will find something like this:</div><div><br></div><div>/* TODO: No alarm handling is bad! */</div>
<div><br></div><div>On the other hand, chan_zap/chan_dahdi both check the alarm status each time zt_read()/dahdi_read() is called and return NULL if the line is in alarm, and the Asterisk core most likely drops the call when sees NULL as return value from those routines.</div>
<div><br></div><div>In order to be certified most likely any PBX should drop the call on alarms. In your case, if you don't care about that you can easily comment the following lines in chan_zap.c:</div><div><br></div>
<div>Search for zt_read in line 4990 in chan_zap.c and read some lines below, you will see a line saying:</div><div><br></div><div>if (p->radio && p->inalarm) return NULL; </div><div><br></div><div>Just comment out that line, or remove the p->inalarm condition.</div>
<div><br></div></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>