[asterisk-dev] Alarms on FXO channels

[Oron Peled]

Hi everybody.

1. Our driver (xpp) set RED alarm for FXO channels without battery
   to prevent asterisk from trying to dial out through them.

2. Before asterisk-1.4.8 it would work, but would produce unfriendly
   error messages from asterisk that got an event from the *channel*
   but would get a 0 (no alarm) from the *span*.

3. In asterisk >= 1.4.8 it's much better because asterisk read channel
   alarms, so its messages are clear.

4. However, I think the approach we used so far is ugly:
   A. If low-level driver have the information before asterisk
      runs, than by the time asterisk opens the channel the event
      is already lost.
   B. So we have our own span->open() and we want to send the alarm
      during open using the new zt_alarm_chan().
   C. But it cannot be used directly from span->open() because it
      would nest the channel spinlock.
   D. So I flagged the event internally and sent it a bit later from
      some code running perioudically.
   You get the picture -- this is not how it's supposed to be coded
   (shame on me, but I was tired... more excuses?)

5. Of course we could suggest a zt_alarm_chan_nolock(), but this is
   solving the wrong problem, which is:
      "Why the low-level driver should notify asterisk during open
       if zaptel already has the information?"
   Also, a generic solution would save duplicated logic in all
   low-level FXO drivers.

6. The result was http://bugs.digium.com/view.php?id=12160
   With two (tested) patches attached:

   A. alarms_zaptel.diff:
      It's a 3 lines patch (and more comments) to zaptel that notifies
      asterisk at the end of zt_specchan_open() about pending alarms.

   B. alarms_chan_zap.diff:
      An alternative approach (and cleaner than A. in our opinion).
      Since chan_zap already calls ZT_GET_PARAMS ioctl() immediately
      after opening the channel, it knows about pending alarms
      (asterisk >= 1.4.8) and should simply use this data.

   Note: an advantage of A. is that it can provide a solution to old
         asterisk versions (with the small price of unfriendly messages
         as mentioned in 2.)

   Note2: Oops, I just noticed we forgot to attach another handy
          (but not essential) patch for zaptel.
          This patch simply shows the channel alarms in /proc/zaptel/*
          so it helps a lot to anybody that work with multiple FXO
          channels (you can readily see which ones have battery,
          regardless of current configuration).

          [Tzafrir, if you can attach that patch [xpp.r5493] to the issue
           you opened it would be great, thanks]

What do you think?


-- 
Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
ICQ UIN: 16527398

"Normal people ... believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough
features ... yet." -- Scott Adams