[asterisk-bugs] [Asterisk 0011959]: add address to some PeerStatus events, and add some PeerStatus Rejected events to chan_sip.c

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11959 
====================================================================== 
Reported By:                mostyn
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   11959
Category:                   Core/ManagerInterface
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 103171 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-08-2008 20:41 CST
Last Modified:              02-14-2008 22:28 CST
====================================================================== 
Summary:                    add address to some PeerStatus events, and add some
PeerStatus Rejected events to chan_sip.c
Description: 
This small patch to chan_sip.c adds the address to PeerStatus: Registered
events,
and adds PeerStatus: Rejected events which are triggered when a sip
clients' authentication fails.  
====================================================================== 

---------------------------------------------------------------------- 
 mostyn - 02-14-08 22:28  
---------------------------------------------------------------------- 
The second patch (replaces the first patch) adds the port to PeerStatus
events that also have an address property, so you can identify multiple sip
clients at the same address.  

My motivation for this patch is so that manager processes can recognise
registration failure floods, in which case I'm not sure if it's wise to
rate-limit the generation of these events.  Is there an easy way to filter
out these events if the manager isn't interested in registration failures? 
I could rename these to PeerRegistration or similar, but that will require
changing PeerStatus: Registered events. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-14-08 22:28  mostyn         Note Added: 0082298                          
======================================================================