[asterisk-bugs] [Asterisk 0014505]: Resolve remaining issues left over from 'kill-the-user'

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14505 
====================================================================== 
Reported By:                lmadsen
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   14505
Category:                   Channels/chan_sip/General
Reproducibility:            N/A
Severity:                   block
Priority:                   high
Status:                     assigned
Target Version:             1.6.1
Asterisk Version:           1.6.1-rc1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-02-19 08:42 CST
Last Modified:              2009-02-26 16:56 CST
====================================================================== 
Summary:                    Resolve remaining issues left over from
'kill-the-user'
Description: 
(From Russell Bryant to the asterisk-dev mailing list)

Greetings,

It's getting to the point that Asterisk 1.6.1 is nearing release.  I'd 
like to cover what we have left to address before Asterisk 1.6.1 can be 
released.

First, the following page shows what mantis issues are marked as 
blocking the release of 1.6.1.  Currently, merging some updates to the 
timing API is the only thing on this list.

http://bugs.digium.com/roadmap_page.php

The other big thing on my list is to ensure that we are happy with the 
state of the chan_sip user/peer/friend situation.  Oej's kill-the-user 
patch went in for this release.  Some issues came up, and a number of 
issues have already been fixed.  We need to determine if there is 
anything left to do in this area before 1.6.1.

Oej has written a document that describes how user/peer/friend matching 
should work here:

http://svn.digium.com/view/asterisk/team/oej/sip-compliance/sipobjects.txt?view=markup

I think that what is written here sounds good to me.  Does anyone else 
have any comments?  Also, do we have code to write to get this to be the 
reality in the 1.6.1 code base?

====================================================================== 

---------------------------------------------------------------------- 
 (0100855) lmadsen (administrator) - 2009-02-26 16:56
 http://bugs.digium.com/view.php?id=14505#c100855 
---------------------------------------------------------------------- 
OK I have found another matching issue. This time it seems to deal with the
way the objects remain in memory after a 'sip reload'.

I have for example the following sip.conf:

[jimmy-friend]                         ; match jimmy first
type=friend
context=incoming
host=dynamic
nat=yes
secret=welcome

[sam-user]                              ; match sam first
type=user
nat=yes
secret=welcome

[sam-peer]                              ; match this IP?
type=peer
host=dynamic
context=incoming
nat=yes
secret=welcome

[ip-catchall]              ; get calls have no matching username
type=peer
host=216.19.xxx.xxx
nat=yes
insecure=invite
secret=welcome
context=incoming


------------------------------------

I had previously made a call with jimmy-friend. It was the first call I
made on this system. The device had registered with Asterisk. All calls are
coming from the same IP address, from the same device, regardless of which
user (multi-line softphone).

After this registration, the astdb contained a SIP/Registry family with
the jimmy-friend key and some information as normal.

Calls then that did not match on a user, would continue to match on this
peer object, even though ip-catchall has the host defined statically, and
is listed closer to the bottom of the file.

Deleting the SIP/Registry/jimmy-friend key did not change this behaviour.
Either did removing it and then reloading chan_sip. I also commented out
the jimmy-friend entry.

However, performing a restart of the system allowed the incoming call to
match on the ip-catchall user as intended. Upon restart, then jimmy-friend
entry continued to be commented out. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-26 16:56 lmadsen        Note Added: 0100855                          
======================================================================