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. >
(In my role as a former, failed SNMP guru:) Is it reasonable to add entirely new sipXecs specific MIB for alarms notification? I suspect many of those alarms have already analogues in standard MIB. It seems to me like the type of the trap that alarm should generate should be a part of alarm definition. (In my role as a sipXconfig coordinator:) 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. 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. D. _______________________________________________ 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/
