[asterisk-bugs] [Asterisk 0017040]: [patch] Explicit context set in SIP peer overridden by default domain context

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Apr 28 17:34:16 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17040 
====================================================================== 
Reported By:                pprindeville
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17040
Category:                   Core/Configuration
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     confirmed
Asterisk Version:           1.6.2.6 
JIRA:                       SWP-1305 
Regression:                 No 
Reviewboard Link:           https://reviewboard.asterisk.org/r/565/ 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-03-16 12:19 CDT
Last Modified:              2010-04-28 17:34 CDT
====================================================================== 
Summary:                    [patch] Explicit context set in SIP peer overridden
by default domain context
Description: 
I'm running a couple of different internal domains in a multi-tenant
configuration.  SIP phones (SPA-942's and PAP2T's) register in their
respective domains, but have explicit contexts set per peer-definition (for
instance, the Fax hanging off the PAP2T can only 7 and 10-digit dial... it
has no international and no internal extensions).

In trying to support E.164 (ENUM) dialling, we tried to enable incoming
SIP calls to the domains by specifying a default context for each domain,
e.g.

domain=redfish-solutions.com,redfish-internet

in the configuration snippet below.  Unfortunately, doing this also puts
all of the internal SIP phones registering in that domain into the
redfish-internet context as well, which is neither desirable nor intuitive.

I posit that the proper behavior is to always use the "context=..."
specified in a [peer] SIP definition when present, and fallback on the
domain-associated context only when it isn't present.

Summary:

If "domain=redfish-solutions.com,redfish-internet" is commented out, then
calls made by "lab_1" use the [redfish-internal] context.  If it's
uncommented, then "lab_1" uses the [redfish-internet] context (making it
indistinguishable from an outside SIP caller [or hacker]).

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

---------------------------------------------------------------------- 
 (0121135) svnbot (reporter) - 2010-04-28 17:34
 https://issues.asterisk.org/view.php?id=17040#c121135 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 259957

U   trunk/channels/chan_sip.c
U   trunk/channels/sip/include/sip.h

------------------------------------------------------------------------
r259957 | mmichelson | 2010-04-28 17:34:15 -0500 (Wed, 28 Apr 2010) | 11
lines

Don't override peer context with domain context.

(closes issue https://issues.asterisk.org/view.php?id=17040)
Reported by: pprindeville
Patches:
      asterisk-1.6-bugid17040.patch uploaded by pprindeville (license 347)
Tested by: pprindeville

Review: https://reviewboard.asterisk.org/r/565/


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

http://svn.digium.com/view/asterisk?view=rev&revision=259957 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-28 17:34 svnbot         Checkin                                      
2010-04-28 17:34 svnbot         Note Added: 0121135                          
======================================================================




More information about the asterisk-bugs mailing list