Summary:ASTERISK-17886: autodomain in sip.conf should be smart enough to detect alternate port from udpbindaddr or similar setting
Reporter:aeg (aeg)Labels:
Date Opened:2011-05-19 03:14:47Date Closed:
Versions:1.8.4 13.18.4 Frequency of

today I spent almost 3-4 hrs trying to troubleshoot this issue for two reasons:

a) I assumed that the setting "autodomain=yes" only works on usage of the standard bind port. If one was to bind the SIP server on an alternate port like 5062, it needs to be explicitly added to sip.conf config, like any other peer i.e.


b) the message that one receives on the console was misleading as it kept accepting the call but would say "NOTICE[1613]: chan_sip.c:21581 handle_request_invite: Call from 'boxA' to extension '2222' rejected because extension not found in context 'Test'." when the extension WAS in fact present in the given context.

So for the longest time I kept focussing on that when it has NOTHING to do with the extensions file or the configuration of contexts or anything else.

I only figured it out when I turned on debug and went through the log file and saw the message:

[May 19 11:21:58] DEBUG[1613] chan_sip.c: Got SIP INVITE to non-local domain ''; refusing request.

when I added this to domain= keyword, it worked

So I reckon two things need to be fixed.

a) autodomain should be smart-er
b) the message being printed on the console should be what was printed in the log file as opposed to sending someone on a wild goose chase of contexts and extensions :)

Kind Regards
Comments:By: aeg (aeg) 2011-05-19 14:38:42

Sorry, I created that ticket at 3am, so everything in it sounds confusing. So just wanted to clarify the following points

a) I assumed that setting "autodomain=yes" would include all IPs and Ports that are being listened on for SIP connections, UDP/TCP/TLS etc. and be added to the internal ACL, which they're not...only the standard port is. So autodomain=yes could be made smarter to know ALL IPs and Ports the Asterisk server is binding/listening to for connections

b) Perhaps even more important is the message that's printed on the Console. If this message was the message that was in fact printed in the debug log, point a) is less important as one could simply just make the configuration change (or in this case manually add the IP and alternate ports to the domain= setting) and be on their way. But accepting the call and then talking about a context and extensions totally threw a novice like me on a wild goose chase of dialplans and extensions :(