[asterisk-bugs] [Asterisk 0012773]: [patch] Agent doesn't propagate device state changes from underlying device.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12773 
====================================================================== 
Reported By:                davidw
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   12773
Category:                   Channels/chan_agent
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.4.20.1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-02-2008 11:30 CDT
Last Modified:              06-25-2008 02:13 CDT
====================================================================== 
Summary:                    [patch] Agent doesn't propagate device state changes
from underlying device.
Description: 
Given a SIP phone logged in with AgentLogin, and monitored with qualify, if
you remove the power on the phone (or, presumably, unplug it from the
network) Asterisk detects that the phone has become unavailable, but the
agent continues to receive calls, resulting in callers going into a black
hole.

Ideally, I believe that the agent should detect the state change on the
underlying device and change its own state to logged off, and therefore
generate a state change to CHANUNVAIL.  This would result in correct
hinting for the agent's state.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0012771 Bogus <member> is still 'Not in U...
====================================================================== 

---------------------------------------------------------------------- 
 davidw - 06-25-08 02:13  
---------------------------------------------------------------------- 
The alternative to sanitizing is for us to raise all issues based on real
world cases as private; my feeling is that this sort of bug reporting
system works best when reports are public.

The reasons for sanitizing are:

- commercial sensitivities - I could explain these but only privately;
- UK Data Protections legislation means that we have to be very careful
with the names of living persons - that generally applies within the EU;
- potentially security; for this and other reasons, I wouldn't want
routable IP addresses.

I didn't prepare the back trace, but when I do sanitize, I make sure that
I don't change the length of strings and that distinct strings are  always
transformed in the same way.

I'll ask if our people could pre-obfuscate personal names in the test
configuration. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-25-08 02:13  davidw         Note Added: 0089201                          
======================================================================