[Home]

Summary:ASTERISK-12610: wrong SRV query
Reporter:pj (pj)Labels:
Date Opened:2008-08-18 13:16:34Date Closed:2008-09-30 17:11:20
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug13337.patch
( 1) dns-srv.pcap
( 2) sip.conf
( 3) srv-dns.png
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


****** ADDITIONAL INFORMATION ******

attached packed capture, from sip call processing to +420222745120 that points to hudba@nic.cz
Comments:By: pj (pj) 2008-08-27 12:20:59

blitzrage, why do you think, that this issue is 'minor', is there any workaround to overcome this? this issue is blocking use enum for calling, because eg. enum lookup to +420 222 745 120 give result "sip:hudba@nic.cz"
and because of this bug, it fails to call...
By: Jeff Peeler (jpeeler) 2008-09-04 16:19:49

Can you attach your sip.conf file or at least the relevant parts of it?
By: pj (pj) 2008-09-05 01:14:04

posting my sip.conf, but I don't think you find here something special. If you can't find source of issue, I can go back some revisions and try to find rev. when this issue starts appearing.
By: pj (pj) 2008-09-16 13:36:38

I found some incorrect memory handling in enum.c,
when invoke ENUMLOOKUP() function, I got following warnings in mmlog:
WARNING: Freeing unused memory at (nil), in ast_get_enum of enum.c, line 897
WARNING: Freeing unused memory at (nil), in ast_get_enum of enum.c, line 897
WARNING: Freeing unused memory at (nil), in ast_get_enum of enum.c, line 897
WARNING: Freeing unused memory at (nil), in ast_get_enum of enum.c, line 897
WARNING: Freeing unused memory at (nil), in ast_get_enum of enum.c, line 897

it's probably not directly related to this issue,
so tell me, if I should open separate bugreport or if it's so trivial, that can be fixed immediatelly.
By: Jeff Peeler (jpeeler) 2008-09-16 15:31:47

I do not know how trivial that will be to fix, but it doesn't appear to be related. Open a new bug report.
By: Jeff Peeler (jpeeler) 2008-09-18 18:10:39

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.
By: pj (pj) 2008-09-19 00:58:53

I have suspiction, that this issue is caused by commit 125891 (add multiple arguments to transport=), that causes also other issues like ASTERISK-12417, actually causes tcp/tls to be useless now.
By: Jeff Peeler (jpeeler) 2008-09-30 12:00:32

Try this patch. My tests indicate the problem did indeed start with rev 135126.
By: pj (pj) 2008-09-30 14:16:14

SVN-trunk-r145121 + bug13337.patch
it seems, that it works as before, thanks!

asterisk currently supports only _sip._UDP records and not _sip._TCP nor _sip._TLS records? it's not implemented or it's some other bug?


By: Jeff Peeler (jpeeler) 2008-09-30 17:05:15

I just tested the SRV lookups and they seemed to resolve properly when specifying the other transports.
By: Digium Subversion (svnbot) 2008-09-30 17:11:19

Repository: asterisk
Revision: 145249

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r145249 | jpeeler | 2008-09-30 17:11:18 -0500 (Tue, 30 Sep 2008) | 6 lines

(closes issue ASTERISK-12610)
Reported by: pj
Tested by: pj

Set transport to SIP_TRANSPORT_UDP mode if not specified which fixes calls to get_transport returning UNKNOWN.

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=145249