[asterisk-bugs] [Asterisk 0013337]: wrong SRV query
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Sep 18 18:10:39 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13337
======================================================================
Reported By: pj
Assigned To: jpeeler
======================================================================
Project: Asterisk
Issue ID: 13337
Category: Channels/chan_sip/General
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 138442
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2008-08-18 13:16 CDT
Last Modified: 2008-09-18 18:10 CDT
======================================================================
Summary: wrong SRV query
Description:
asterisk (chan_sip) generates wrong service records queries to dns.
it queries to _sip._UNKNOWN.foo.bar, instead of _sip._udp.foo.bar
if this first query fails, it try second query srv by appending asterisk
server dns domain to previous query, eg. _sip._UNKNOWN.foo.bar.domain.com,
third try is to query A record for foo.bar
I think this "automatic" failover is unnecessary or even incorrect,
causing needless delays
======================================================================
----------------------------------------------------------------------
(0092685) jpeeler (administrator) - 2008-09-18 18:10
http://bugs.digium.com/view.php?id=13337#c92685
----------------------------------------------------------------------
I think this problem may be distantly related to 11843. There is a
newdialog flag in create_addr that explicitly sets the socket type to 0,
which causes the call to get_transport to return UNKNOWN. The problem is
the socket type information was not present even before being explicitly
set to 0. My trail for now has ended at sip_request_call as I'm trying to
see why the transport information isn't set to begin with.
Issue History
Date Modified Username Field Change
======================================================================
2008-09-18 18:10 jpeeler Note Added: 0092685
======================================================================
More information about the asterisk-bugs
mailing list