[asterisk-bugs] [Asterisk 0009668]: devicestate.c:__ast_device_state_changed_literal can't cope with iax (and sip?) peer names containing "-"

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=9668 
====================================================================== 
Reported By:                stevedavies
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   9668
Category:                   Addons/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     confirmed
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 62263 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             05-04-2007 14:31 CDT
Last Modified:              09-07-2007 08:24 CDT
====================================================================== 
Summary:                    devicestate.c:__ast_device_state_changed_literal
can't cope with iax (and sip?) peer names containing "-"
Description: 
__ast_device_state_changed_lieral does this:

        device = buf;
        if ((tmp = strrchr(device, '-')))
                *tmp = '\0';

With this result in my environment:

[May  2 09:19:12] DEBUG[11129] devicestate.c: Notification of state change
to be queued on device/channel IAX2/swenitech-2
[May  2 09:19:12] DEBUG[11129] devicestate.c: No provider found, checking
channel drivers for IAX2 - swenitech
[May  2 09:19:12] DEBUG[11129] chan_iax2.c: Checking device state for
device swenitech
[May  2 09:19:12] DEBUG[11129] devicestate.c: Changing state for
IAX2/swenitech - state 4 (Invalid)
[May  2 09:19:14] DEBUG[11129] devicestate.c: Notification of state change
to be queued on device/channel IAX2/swenitech-1
[May  2 09:19:14] DEBUG[11129] devicestate.c: No provider found, checking
channel drivers for IAX2 - swenitech
[May  2 09:19:14] DEBUG[11129] chan_iax2.c: Checking device state for
device swenitech
[May  2 09:19:14] DEBUG[11129] devicestate.c: Changing state for
IAX2/swenitech - state 4 (Invalid)
[May  2 09:19:15] DEBUG[11129] devicestate.c: Notification of state change
to be queued on device/channel IAX2/vpntech-1
[May  2 09:19:15] DEBUG[11129] devicestate.c: No provider found, checking
channel drivers for IAX2 - vpntech
[May  2 09:19:15] DEBUG[11129] chan_iax2.c: Checking device state for
device vpntech
[May  2 09:19:15] DEBUG[11129] devicestate.c: Changing state for
IAX2/vpntech - state 4 (Invalid)

etc etc.

I guess that truncating at the last "-' is to do with cleaning up things
like Zap/1-1 and similar.

But the result breaks devicestate for any iax2 or sip peer with a dash in
the name.

Perhaps it would be possible to queue the devicestate for both the
complete and the truncated version in order to deal with this issue?

Steve
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0009782 hints don't work
====================================================================== 

---------------------------------------------------------------------- 
 Corydon76 - 09-07-07 08:24  
---------------------------------------------------------------------- 
The issue, as I understand it, is that you can pass either form of a
channel name to devicestate and it should work.  That means all of the
following should work correctly:

SIP/123-ABCD1234
SIP/123
SIP/foo-bar-ABCD1234
SIP/foo-bar
(IAX has the same style formats as SIP)

Essentially what you're proposing is to make '-' an invalid character in a
channel name, which is the same as oej's workaround.  Note that this would
probably cause a flag day event, whereas we'd be passing the encoded form
to remote hosts (and could cause its own set of issues).

What we might could do, instead, is to first do a lookup on the name as
passed, and if the state is invalid, only then do we zero the final '-',
and do a second lookup on the name.  This would ensure that both forms of
names would work correctly, although there still might be a problem with
two SIP hosts of the
following forms:
SIP/foo
SIP/foo-bar

What do we think of this approach?  In the general case, it should not be
much slower than the existing system. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-07-07 08:24  Corydon76      Note Added: 0070093                          
======================================================================