On Mon, 2009-11-16 at 10:59 -0500, Alfred Campbell wrote:
> Recently we have had several large customer requests for SNMP traps
> within sipXecs. In order to try and accommodate this some of our newly
> participating folks in Ntec India have put this proposal together:
> http://sipx-wiki.calivia.com/index.php/SNMP_Traps
>
> Would love for any feedback, suggestion or comments before this proceeds
> any further.
I would retitle this 'SNMP Monitoring' since no one proposes that we
ever support any writes through SNMP.
The proposal says that "There should be provision to enable/disable the
SNMP agent" - the default state of this should be 'disabled'.
On the MIB:
* The sipxecsAlarmTime should specify that the time is always in
Universal Time
* I don't think that the suggested resolution belongs in the MIB
or the alarm.
Why does the design diagram show a trap receiver in sipXconfig? We
don't need it or want it.
What traps is it proposed that we support from MIB-II ? (my preference:
none)
Damian responded:
> There is some wording in this proposal that suggests that all services
> would have to be modified to send SNMP traps:
>
> "This involves identifying the scenarios and code locations where these
> alarms are generated and implementing the code for sending SNMP traps if
> the SNMP agent is enabled in sipXconfig. New files (TrapNotifier.h and
> TrapNotifier.cpp) implementing the class TrapNotifier has to be introduced
> to send traps containing alarm description and resolution to configured
> trap receivers. Further investigation is required on this."
>
> I might be just misreading this. But just to clarify: I think it would be
> best if alarm server were to be responsible (directly or indirectly) for
> sending traps when alarm is raised. All existing services should just
> continue using current alarm XML/RPC API.
+1 - no component of the system should generate SNMP traps except the
existing alarm service in sipXsupervisor.
> I suspect sipXconfig implementation would be simpler if sipXalarms were to
> be separated from sipXsupervisor. At the moment we have a special case for
> configuring alarms in the sipXconfig code and it has already caused several
> issues (recently: http://track.sipfoundry.org/browse/XX-6970).
> It's not directly related to adding alarm functionality but it seems we
> would be adding even more config files for alarm service, which is trivial
> if this is a 'normal' service and complicated if it's a sipXsupervisor.
I don't see what the problem is with the above; integrating the alarm
monitor into sipXsupervisor. The particular issue you cite seems easy
to me - the replication of that file happens through sipXsupervisor
anyway; it should be able to notice that fact and reload the definitions
without any other prompting.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
