Asterisk SIP srvlookup

Business SIP Providers
Provider Plan Details Monthly Rate *
Vonage Business SIP Trunking
  • One provider & nationwide coverage
  • Easily integrated into your existing infrastructure
  • More uptime, flexibility and disaster recovery options
$25.00
Details

Asterisk SIP option srvlookup (sip.conf)


Synopsis:

srvlookup = yes | no

Default

srvlookup=yes (As of version 1.4.14*)
srvlookup=no (Prior to version 1.4.14)

* https://issues.asterisk.org/bug_view_page.php?bug_id=10954

If srvlookup is turned on, Asterisk supports DNS SRV lookups partially. Currently, Asterisk only reads the first SRV entry without bothering with priorities and weights. This option is NOT turned on by default!!!
A SRV lookup is only performed when the FQDN hostname is specified in the Dial() command; if instead in Dial() you specify a peername (as defined in sip.conf with host=...) a SRV lookup will not be performed!

As of Asterisk 1.4.26.3, SRV lookups appear to be performed when dialing via a peername.



Note


Enabling this option can break things in unexpected ways.

Testing on 1.2.14 If you have any "register =>" statements in sip.conf, then a SRV lookup is also performed, even if you explicitly specify both the IP address and port number.

Also, there appears to be a bug in the hints code that causes spurious DNS lookups. This may not be related to srvlookup itself, but more of a DNS issue with asterisk SIP channel.
http://bugs.digium.com/view.php?id=9057

Note that you need to have a very robust DNS service (preferably local instance of caching resolver/BIND) to accommodate all these (mostly spurious) SRV lookups, because if asterisk cannot resolve DNS requests, then the SIP service completely grinds to a halt, and subsequent registraion attempts fail, as currently asterisk's DNS lookups are blocking. (As noted in dns.h)

It seems to affect us when we have more than about 8 register => statements in sip.conf, as all of these dns requests have to time out, by which time the SIP keepalives have timed out, and then another registration attempt begins resulting in a continuous state of clients being unable to register (This is worse if you have qualify= set) for SIP handset registration entries, as asterisk sends out the qualify packets, but is then unable to process the incoming responses, and so it marks the SIP peer as UNREACHABLE.)


Attention

This option is not turned on by default (in versions prior to 1.4.14), I spend 3 days in researching for solution for this error:
ttechgroup*CLI>
Apr 13 22:03:15 NOTICE[2553]: chan_sip.c:5473 sip_reg_timeout: — Registration for '02490XXXX@nexcom.bg' timed out, trying again (Attempt #1)
Apr 13 22:03:35 NOTICE[2553]: chan_sip.c:5473 sip_reg_timeout: — Registration for '02490XXXX@nexcom.bg' timed out, trying again (Attempt #2)
ttechgroup*CLI>

When I added
[general]
srvlookup=yes

to my sip.conf, the problem was solved

Asterisk SIP option srvlookup (sip.conf)


Synopsis:

srvlookup = yes | no

Default

srvlookup=yes (As of version 1.4.14*)
srvlookup=no (Prior to version 1.4.14)

* https://issues.asterisk.org/bug_view_page.php?bug_id=10954

If srvlookup is turned on, Asterisk supports DNS SRV lookups partially. Currently, Asterisk only reads the first SRV entry without bothering with priorities and weights. This option is NOT turned on by default!!!
A SRV lookup is only performed when the FQDN hostname is specified in the Dial() command; if instead in Dial() you specify a peername (as defined in sip.conf with host=...) a SRV lookup will not be performed!

As of Asterisk 1.4.26.3, SRV lookups appear to be performed when dialing via a peername.



Note


Enabling this option can break things in unexpected ways.

Testing on 1.2.14 If you have any "register =>" statements in sip.conf, then a SRV lookup is also performed, even if you explicitly specify both the IP address and port number.

Also, there appears to be a bug in the hints code that causes spurious DNS lookups. This may not be related to srvlookup itself, but more of a DNS issue with asterisk SIP channel.
http://bugs.digium.com/view.php?id=9057

Note that you need to have a very robust DNS service (preferably local instance of caching resolver/BIND) to accommodate all these (mostly spurious) SRV lookups, because if asterisk cannot resolve DNS requests, then the SIP service completely grinds to a halt, and subsequent registraion attempts fail, as currently asterisk's DNS lookups are blocking. (As noted in dns.h)

It seems to affect us when we have more than about 8 register => statements in sip.conf, as all of these dns requests have to time out, by which time the SIP keepalives have timed out, and then another registration attempt begins resulting in a continuous state of clients being unable to register (This is worse if you have qualify= set) for SIP handset registration entries, as asterisk sends out the qualify packets, but is then unable to process the incoming responses, and so it marks the SIP peer as UNREACHABLE.)


Attention

This option is not turned on by default (in versions prior to 1.4.14), I spend 3 days in researching for solution for this error:
ttechgroup*CLI>
Apr 13 22:03:15 NOTICE[2553]: chan_sip.c:5473 sip_reg_timeout: — Registration for '02490XXXX@nexcom.bg' timed out, trying again (Attempt #1)
Apr 13 22:03:35 NOTICE[2553]: chan_sip.c:5473 sip_reg_timeout: — Registration for '02490XXXX@nexcom.bg' timed out, trying again (Attempt #2)
ttechgroup*CLI>

When I added
[general]
srvlookup=yes

to my sip.conf, the problem was solved
Created by: oej, Last modification: Thu 08 of Apr, 2010 (16:38 UTC) by euphline
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+