[Home]

Summary:ASTERISK-03407: Outgoing SIP unable to lookup SRV record host name
Reporter:Jon Brüel (jb)Labels:
Date Opened:2005-02-01 05:28:19.000-0600Date Closed:2011-06-07 14:09:59
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When you in the extensions.conf use a DIAL command to an alias defined in sip.conf, it does not work when the host name after the "host=" entry in sip.conf is a SRV record.

If you include the SRV name in the DIAL command, it works fine.

Unfortunately you need to dial to an alias when passwords are required.

This is of major severity having in mind that a SRV is an important measure to establish the level of reliability required to make Internet telephony a winner technology.
Comments:By: Brian West (bkw918) 2005-02-01 09:42:52.000-0600

SRV lookups are not on by default you MUST turn them on.  This is also NOT a major bug.  Please read sip.conf.sample for how to turn SRV lookups on.
By: Mark Spencer (markster) 2005-02-01 18:01:36.000-0600

If you want to go with the SRV record, why are you using a peer declaration at all?  The whole point of creating one is to avoid having to do such rediculous lookups.

SRV records just add another level of abstraction and another thing to go wrong, but they are in the spec and if you want them you can turn them on.
By: Mark Spencer (markster) 2005-02-01 21:09:19.000-0600

Actually, looking at the code for CVS head, it *should* already perform an SRV lookup on the peer unconditionally.  Are you sure you're doing this with CVS head?  I don't even know of a place that has an SRV record for me to test against.
By: Mark Spencer (markster) 2005-02-03 00:00:52.000-0600

Hello, can you please confirm you are actually running against CVS head and confirm that this problem is really there?  Also, can you please supply a test location for which an SRV record actually exists so I can try to duplicate your problem should it still be there.
By: Mark Spencer (markster) 2005-02-07 10:17:00.000-0600

Bug placer appears to have lost interest.
By: Jon Brüel (jb) 2005-03-10 10:18:36.000-0600

The bug was closed because of "lack of interest". This is not the case, the reason was that I used E-mail to communicate back not the bug note. Anyhow I add my answers:

Before testing (date: 01-02-2005), I did a "cvs checkout -r v1-0", "cleaned" and "made" and restarted Asterisk, so I suppose the answer is yes, I do run against CVS HEAD.

Testsite info for SRV:

Username = 36938043
Secret = 36938043
No prefix is required for dialing. There is international access. Country where the gateway is: Denmark. PSTN number is Denmark 36938043.

Host name with SRV-record:

Sipsrv.v2tel.net (same priority to two ip addresses: 212.130.0.205 and 217.116.243.235)

Host name with normal A-record:

Sip.v2tel.net (points to 217.116.243.235)

Regards Jon Bruel
By: Olle Johansson (oej) 2005-03-10 11:10:28.000-0600

jb: In fact, we do an SRV lookup *once* only when we read the configuration of Asterisk. Could you please provide me with a SIP debug output of a failed transaction, so I can see what is happening? Thank you for your persistance in this matter.
By: Jon Brüel (jb) 2005-03-11 04:13:33.000-0600

Things go wrong at an early stage: when the system is started or when I do a "SIP reload". This is the message given:

blade1*CLI> sip debug
SIP Debugging Enabled
blade1*CLI> sip reload
Reloading SIP
Mar 11 11:01:46 NOTICE[28998]: config.c:764 __ast_load: Loading Config sip.conf via odbc engine
 == Parsing '/etc/asterisk/res_config_odbc.conf': Found

//Here it goes wrong for the peer registration. This message is given for each peer defined in sip.conf:
Mar 11 11:01:47 WARNING[28998]: acl.c:197 ast_get_ip: Unable to lookup 'sipsrv.v2tel.net'

//The incoming lines use SRV as well, and as seen below this works:
   -- parse_srv: SRV mapped to host ser2.v2tel.net, port 5060
11 headers, 0 lines
Reliably Transmitting:
REGISTER sip:sipsrv.v2tel.net SIP/2.0
Via: SIP/2.0/UDP 212.130.0.200:5060;branch=z9hG4bK38b5ac3a
From: <sip:36926313@sipsrv.v2tel.net>;tag=as0a36d211
To: <sip:36926313@sipsrv.v2tel.net>
Call-ID: 59a3281342c412545fc27a183f8e171e@212.130.0.200
CSeq: 102 REGISTER
User-Agent: Asterisk PBX
Expires: 3000
Contact: <sip:K0000000336926313@212.130.0.200>
Event: registration
Content-Length: 0
By: Mark Spencer (markster) 2005-03-12 12:36:51.000-0600

Clearly you are not running latest CVS head as this line:

Mar 11 11:01:47 WARNING[28998]: acl.c:197 ast_get_ip: Unable to lookup 'sipsrv.v2tel.net'

Cannot be created from CVS head since the function which has that erorr is now ast_get_ip_or_srv and not ast_get_ip.  Please update to CVS head!
By: Mark Spencer (markster) 2005-03-12 12:42:38.000-0600

This is definitely a configuration issue.  I was able to configure a peer as follows:

[bug3482]
host=v2tel.net
type=peer
context=default


and register with:

register => bug3482@bug3482


and see the appropriate, expected activity.  If you continue to have trouble after actually upgrading to CVS head, please see a bug marshall before reopening this issue.
By: Russell Bryant (russell) 2005-03-27 23:50:28.000-0600

By the way ...

By CVS HEAD, they mean the development branch from CVS, not the v1-0 branch.

To check out Asterisk from the dev branch, you simply omit the "-r v1-0" from the checkout command.

cvs checkout asterisk