Summary:ASTERISK-15793: When a context is defined in [general] section of sip.conf, other contexts are ignored
Reporter:hugolivude (hugolivude)Labels:
Date Opened:2010-03-11 20:47:40.000-0600Date Closed:2011-06-07 14:04:47
Versions:Frequency of
Environment:Attachments:( 0) sip.conf
( 1) SIPDebug.txt
Description:Cent OS 5.0

When a context is defined in the general section of sip.conf, contexts defined in other sections are ignored.

Set up sip.conf this way:


Calls from my voip-provider should go to “ValidIncoming”, but Asterisk attempts to send them to “incoming-bogus-calls”

I’ve had sip.conf set up this way for a long time. The idea was recommended to thwart DOS attacks. It worked in Version 1.4 (and previous versions) but when I upgraded to 1.6, all calls were sent to incoming-bogus-calls regardless of source.  I suppose allowguest can be used now to achieve the desired effect, but the current behaviour is not backwards compatible.
Comments:By: Leif Madsen (lmadsen) 2010-03-15 10:21:43

Additional information is required. Perhaps there is something else causing the incoming calls to not match on your peer, and it's not actually the issue you're seeing that is the problem.

For example, I have the exact same setup that you do (in terms of using context=default in my [general] section) but that has not stopped me from using context=incoming_calls in my peer definitions.

Please provide the following:

* Full sip.conf configuration file with passwords removed or obfuscated.
* a SIP trace from the Asterisk console showing the problem you are having

I'm thinking there is likely a configuration issue here since it sounds like you upgraded from 1.4 to 1.6.1.x

By: hugolivude (hugolivude) 2010-03-20 00:27:12

I've attached the requested files.  Yes I upgraded from 1.4 to 1.6.1.  Having context=incoming-bogus-calls in the [general] section worked in 1.4 but I had to remove it in 1.6.1.

By: Leif Madsen (lmadsen) 2010-03-24 10:00:34

Your SIP debug is showing the INVITE matching on peer 6132885759-sw2 but I don't see that in your sip.conf file.

By: hugolivude (hugolivude) 2010-04-04 08:21:57

Yes I always thought that to be a bit strange, however this is how the VoIP provider for that number instructs its users to set up sip.conf.  I cut and pasted sip.conf from a web page they provide.  I re-confirmed that the DiD 6132885759-sw2 does not appear in any form (including 6132885759-sw2) in the sip settings they recommend.  

I spent several days troubleshooting this w/ them, so If you still feel their set ups are incorrect or they are not generating the appropriate SIP signaling for the set up they are recommending, please let me know and I'll re-open the trouble ticket I created w/ them.

Please note however that the setup I provided worked fine in 1.4.  It's also working in 1.6, but I had to remove context=incoming-bogus-calls from the [general] section.  It's the backward compatibility that prompted me to open this case.

By: Leif Madsen (lmadsen) 2010-04-15 10:31:46

Well I'll Acknowledge this for now until another developer can look at this. However I don't believe this is an issue with Asterisk, but the fact something worked in 1.4 and not in 1.6.x is troubling. It could be a configuration problem still though based on some change in UPGRADE.txt or CHANGES.

By: Erik Smith (eeman) 2010-05-11 07:31:57


1. if you are using insecure=port,invite to match on IP, then type=peer not friend
2. if you are trying to thwart unauthorized access to your box, consider allowguest=no in your [general] section
3. your asterisk box is running from an RFC1918 address, you should be declaring an externip and localnets in [general]

externip =

By: Tilghman Lesher (tilghman) 2010-05-13 10:28:15

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.6.0 and 1.6.1 branches has ended. For continued maintenance support please move to the 1.6.2 branch.

More information on this change can be found in the release announcement: http://www.asterisk.org/node/49924

By: Tilghman Lesher (tilghman) 2010-05-18 13:43:12

No response from reporter.