Can't register in sip.conf

Asterisk Asterisk Support
1

I apologise in advance if this issue has an answer - I’ve been googling all morning and found scant references - so I’m trying the forums. I’m also a noob. :wink:

I’ve compiled and installed asterisk-1.2.0-rc2.tar.gz on my current (fully patched / updated) FC4 system. There were no compile or installation errors. The sample configuration works fine with no apparent problems.

I have created a sip trunk in sip.conf (making no changes to any of the other sample config files) as follows:
[color=darkred][sip_proxy]
context=from-fwd
host=fwd.pulver.com
type=friend
username=ACCOUNT
secret=PASSWORD[/color]

When I do a “sip reload”, I get the following error
[color=darkred]firewall*CLI> sip reload
Reloading SIP
== Parsing ‘/etc/asterisk/sip.conf’: Found
Nov 14 14:01:10 WARNING[31966]: acl.c:244 ast_get_ip_or_srv: Unable to lookup ‘’
== Parsing ‘/etc/asterisk/sip_notify.conf’: Found[/color]

Note that the hostname is blank. Does this error ring any bells for anybody???

I went looking inside the source code and doing some hacks to log what’s going on…
I can see that [color=darkred]ast_get_ip_or_srv[/color] calls [color=darkred]ast_get_srv[/color] which calls [color=darkred]ast_search_dns[/color].

In [color=darkred]ast_get_ip_or_srv[/color], I can see that it is initially called with “value” equal to the host - that is fwd.pulver.com.

[color=darkred]ast_search_dns[/color] returns “1” but does not change the “context” structure.

This means that [color=darkred]ast_get_ip_or_srv[/color] sets the string “value” from “fwd.pulver.com” back to to Null, (as the local variable “host” is not initialised to anything ie is blank). Hence, the error message shows telling me that it can’t do the lookup shows the hostname as a blank.

For all intensive purposes, my computer seems to be fully connected to the Internet. I can resolve addresses just fine. e.g. This note is being prepared and posted to the forums from the same computer.

In fact, when I set up an iax trunk to my FWD account by adding the appropriate lines to iax.conf, it all works fine and connects.

The sourcec code I mention looks suspiciously faulty but its “self-documenting” nature doesn’t help me trying to understand what its supposed to be doing.

Help anybody? Either identifying the bug or telling me what (stupid) configuration error I’ve made.

2

As far as i can see, you haven’t actually said what your problem is! Unless of course the error message is your problem. If you want to get rid of that, you could try including the following in sip.conf

srvlookup=no

3

[quote=“WillKemp”]As far as i can see, you haven’t actually said what your problem is! Unless of course the error message is your problem. If you want to get rid of that, you could try including the following in sip.conf

srvlookup=no[/quote]

Sorry for not mentioning the specific problem… it is that I cannot make any SIP registrations using asterisk as a SIP client. It seems independent of the address that is being registered.

Setting srvlookup=no makes no difference. The error is identical.

The only symptom that is obvious is the warning message noted above. With two attempted registrations (eg FWD and SIPPHONE), the output is as follows…

[color=darkred]firewallCLI> sip reload
Reloading SIP
== Parsing ‘/etc/asterisk/sip.conf’: Found
Nov 15 08:16:19 WARNING[23400]: acl.c:244 ast_get_ip_or_srv: Unable to lookup ''
Nov 15 08:16:19 WARNING[23400]: acl.c:244 ast_get_ip_or_srv: Unable to lookup ‘’
== Parsing ‘/etc/asterisk/sip_notify.conf’: Found
firewallCLI>[/color]

The warning is strange - because the host names (ie fwd.pulver.com and proxy01.sipphone.com) don’t actually appear in the warning - as I found yesterday, ast_search_dns seems to return successfully (1 return code) but does not update the context structure as it seems it should. The consequence is that the hostname is nulled and the warning that appears is ambiguous.

So there’s two problems really: 1. I can’t register SIP clients, 2. The warning message code is somehow broken, perhaps as a consequnce of a bug elsewhere.

I’ll spend some more time digging through the code to find out why it’s failing today, but has anybody any hints about what might be wrong / where to look?