A few of my cents inline
M. Ranganathan (JIRA) wrote:
[ http://track.sipfoundry.org/browse/XX-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38470#action_38470 ]
M. Ranganathan commented on XX-5601:
------------------------------------
The following alarms on the Diagnostics -->Alarms screen can be consolidated:
SPX00024 Could not send REGISTER to the ITSP account. (info)
Sending the REGISTER message failed.
Chaitra,
Following are the meanings of the alarms:
SPX00022 An ITSP account could not be found.(crit)
Bad sipx dial plan. Domain of inbound request does not correspond to any ITSP
account domain
SPX00018 The ITSP Account could not be reached (crit)
ITSP account was successfully resolved and REGISTER message was sent to it but
the ITSP never responded.
If the 'username' and 'password' are incorrect then this indicated by "Alarm
SPX00017: The ITSP disallowed an Authentication attempt"
Indicates a 403 error was returned from the ITSP. Authentication failure. Your
password is bad or username is bad.
SPX00015 SIP Trunking public address discovery failed (crit)
The STUN server is down or unresponsive.
SPX00013 Media Relay public address discovery failed (crit)
The Relay reported the STUN server is down or unresponsive ( you dont need to
colocate Bridge and Relay) but I agree 13 and 15 can be combined.
SPX00020 The STUN Address cannot be resolved. (crit)
You have a bad stun server address. Say you have an address 123.stun.com ( does
not exist). This is different from having a resolvable address but no stun
server runs there.
Isn't this typically a user misconfiguration? If yes, why do we need an
alarm for this? Typically this would happen only the first time that the
stun server is configured. If the host is not 'resolvable', then the
administrators can debug looking at the logs and set it right. IMHO it
is best to use Alarms only for systems which are running fine and get
into trouble mid-way. For SPX00020, wont it be enough to combine with
15 & 13 and give out a message which says "Public address discovery failed"
SPX00016 The STUN Server recovered (info)
SPX00014 The STUN Server recovered (info)
Here, there can be one alarm saying that the "The STUN Server recovered"
I agree 14 and 16 can be combined. Note that they are reported by SipxBridge
and SIpXRelay. Both do not need to reside on the same machine. But yes I do
agree combination of these two is possible.
In both the cases of STUN server, it is true that the two servers need
not reside on the same machine. However, when the alarm comes in, the
email would contain the host of the machine on which the failure (or
recovery) happened and that in turn would give an indication of which of
the two services failed.
Thoughts?
Rahghu
Consolidate the Alarms related to sipXbridge and ITSP
-----------------------------------------------------
Key: XX-5601
URL: http://track.sipfoundry.org/browse/XX-5601
Project: sipXecs
Issue Type: Bug
Affects Versions: 4.0
Environment: sipxproxy 4.0.0-015287 2009-04-25T00:09:21 oem-4.0-centos5
sipxconfig 4.0.0-015287 2009-04-25T00:23:20 oem-4.0-centos5
Reporter: Chaitra Sharma
The following alarms on the Diagnostics -->Alarms screen can be consolidated:
SPX00024 Could not send REGISTER to the ITSP account. (info)
SPX00022 An ITSP account could not be found.(crit)
SPX00018 The ITSP Account could not be reached (crit)
There can be only one alarm instead of the above three. In case of
misconfiguration, say the ITSP account created is incorrect /typo, there can be
one alarm which conveys the message that the ITSP account cannot be reached.
If the 'username' and 'password' are incorrect then this indicated by "Alarm
SPX00017: The ITSP disallowed an Authentication attempt"
If the server at the ITSP side is down the alarm "SPX00021: The ITSP reported a
server failure" indicates this.
SPX00015 SIP Trunking public address discovery failed (crit)
SPX00013 Media Relay public address discovery failed (crit)
SPX00020 The STUN Address cannot be resolved. (crit)
Here, there can be one alarm instead which indicates that the "Public address
discovery failed"
SPX00016 The STUN Server recovered (info)
SPX00014 The STUN Server recovered (info)
Here, there can be one alarm saying that the "The STUN Server recovered"
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
