> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Krzeminski, Damian (BL60:9D30)
> Sent: Monday, November 16, 2009 11:53 AM
> To: [email protected]
> Subject: Re: [sipX-dev] SNMP Trap Proposal
> >
> 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.
>
Without claiming to be an SNMP guru at all - I like having alarms sent
in the same format, with all the info available to us, and let any other
mapping be done by the trap receiver. We don't want everyone who
creates a new alarm to have to understand MIBS...
At one time I saved a SmallSiteEvents.mib - could be what BCM uses. It
has four fields:
-- EventData ::= SEQUENCE {
-- eventId INTEGER,
-- eventSource DisplayString,
-- eventTime DisplayString,
-- eventDescr OCTET STRING
-- }
I didn't like this one because eventId was an INTEGER, but it came
close. Were any other existing MIBs checked for suitability?
>
> (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.
TrapNotifier will be part of the Alarm Server (same as EmailNotifier,
LogNotifier, etc). The alarm definitions would be extended to include
an snmp setting (snmp="true" or something). No changes should be
required in the "code locations where alarms are generated".
>
> 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.
The Alarm Server was made part of the supervisor because the existing
xmlrpc interface made that logical. But does sipXconfig have to model
the service that way? Could it model the Alarm Server separately, and
perhaps implement "restart" for that service by doing "reloadAlarms"
instead?
Carolyn
_______________________________________________
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/
