>I don't think that the suggested resolution belongs in the MIB >or the alarm.
The email notifications of the alarms contain suggested resolution. The email body of one of the alarms is as follows: ----- Message from sipXecs Alarm: SPX00012 Reported on: scssde1.asiapac.nortel.com Reported at: 2009-11-17T07:30:34.282227Z Severity: CRIT Alarm Text: Emergency dial rule 'Emergency (Emergency dialing plan)' was invoked by '<sip:[email protected]>' contact sip:[email protected]:40279;x-sipX-nonat Suggested Resolution: A user has dialed a number which is configured as an Emergency number. The user name and contact address of the phone is given. ------ So it looks like suggested resolution might be a desired alarm attribute in the SNMPv2 trap notifications. Please advise on this. >Why does the design diagram show a trap receiver in sipXconfig? We don't need it or want it. There was some initial confusion regarding the 2nd requirement mentioned in the issue XX-6870(http://track.sipfoundry.org/browse/XX-6870). It was misunderstood as a need for trap receiver functionality in sipXconfig. This has been clarified after discussions. Trap receiver functionality will not be part of sipXconfig. > "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. Looks like the description in the proposal is not very clear on this. This will clarify some of the doubts: The Alarm Server will be generating the SNMPv2 traps by using TrapNotifier::handleAlarm. The implementation will be similar to sending alarm notifications via email using EmailNotifier from the Alarm Server. TrapNotifier will in turn make use of the net-snmp APIs/libraries to send SNMPv2 traps. Regards Goutham B G -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Lawrence, Scott (BL60:9D30) Sent: Monday, November 16, 2009 11:10 PM To: Campbell, Alfred (BL60:9D30) Cc: [email protected] Subject: Re: [sipX-dev] SNMP Trap Proposal 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/ _______________________________________________ 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/
