[Home]

Summary:ASTERISK-18095: Misleading "Call from 'xxx' to extension 'yyy' rejected because extension not found in context" due to missing SIP domain
Reporter:Alain Knaff (aklux)Labels:
Date Opened:2011-07-07 04:38:53Date Closed:2011-07-11 15:03:16
Priority:MajorRegression?
Status:Closed/CompleteComponents:
Versions:1.6.2.19 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:
Description:When trying to call a user without a SIP domain (i.e. sip:6001 instead of sip:6001@192.168.1.1), asterisk displays the following message:

 Call from 'user1' to extension '6001' rejected because extension not found in context 'default'.

And this, even though 6001 _is_ defined in extensions.conf and shows up allright with dialplan show 6001@default

Interestingly enough, it succeeds if a SIP domain is included, even if that domain doesn't match asterisk (i.e. sip:6001@1.1.1.1 works as well as with the real IP as the domain)

Unfortunately, by default, some versions of ekiga (such as 3.3.0) by default send numbers without a domain name.

Impact:

The message as written sends the user on a wild goose chase, verifying, and re-verifying extensions.conf

Suggested fix:

Change the error message (for this case) so that it says:

"Missing domain name in SIP Invite" or something similar.
Comments:By: David Woolley (davidw) 2011-07-07 06:33:01.096-0500

The problem is not in the message.  It might be in the code that decides to output the message, but you should first check very carefully to make sure that you do not have an excess space in the context name.

It might also be that the code that is parsing the destination address is adding an extra character, probably a space and probably to the extension name.

The fact that the message reports 6001 as the destination means that it has already tried to cope with the lack of a domain name, so Asterisk is considering that a non-error case.

The other mistake, I've seen made, is failing to define priority 1 for the extension.
By: David Woolley (davidw) 2011-07-07 06:36:39.383-0500

Also, please note that 1.6.2.19 is unsupported, so you need to reproduce this in a current 1.8.4/5 version unless you can demonstrate a security issue.  It is just possible that it will also get fixed if it was introduced very recently, e.g. as collateral damage to a security fix.