It not only happens on INVITE or BYE but also happens when a 18x is received (180 Ringing or 183 Session Progess at least) so it&#39;s not directly related where the Dial command is executed in the dialplan, isn&#39;t it? It looks more as a SIP channel internal stuff...<br>
<br>It looks like there is some gethostbyname (or similar) call whenever a SIP message (request or response) is received that triggers the DNS query. <br><br>Shall I try to post in dev list?<br><br>Best regards,<br>Samuel.<br>
<br><br><div class="gmail_quote">2008/11/7 John Todd <span dir="ltr">&lt;<a href="mailto:jtodd@digium.com">jtodd@digium.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br>
On Nov 7, 2008, at 8:29 AM, samuel wrote:<br>
<br>
&gt; Hi folks,<br>
&gt;<br>
&gt; I&#39;ve been using * for quite a few years and everyday it surprises me<br>
&gt; more.<br>
&gt;<br>
&gt; I was recently analysing some captures with ethereal/wireshark and<br>
&gt; found out that * was doing DNS A queries for domain names like<br>
&gt; <a href="http://channel.mydomain.com" target="_blank">channel.mydomain.com</a> where channel is the typical string of the<br>
&gt; dstchannel or channel field in the CDR entries.<br>
&gt;<br>
&gt; Obviously those queries returned with negative answer because it<br>
&gt; does not exists such domainname. My question is why is * asking the<br>
&gt; DNS for the A entry of the channel? It looks like it does the DNS<br>
&gt; query upon receiving a SIP message but none SIP header contains the<br>
&gt; channel string in the SIP headers so it must be something internal,<br>
&gt; maybe some end-point check?<br>
&gt; Considering how delicate is * to DNS failures I would like to know<br>
&gt; whether this behaviour can be disabled in the config files because<br>
&gt; it makes * block easier and charges the DNS server of senseless<br>
&gt; queries.<br>
&gt;<br>
&gt; I don&#39;t know about * internals so it &#39;s far beyond my knowledge<br>
&gt; following the reception and treatment of SIP message throughout the<br>
&gt; sip_channel.c code so I would really appreciate any hint about this<br>
&gt; issue.<br>
&gt;<br>
&gt; The capture was done on a 1.4.18 version but I&#39;ve checked same<br>
&gt; behaviour (ngrep port 53) on other 1.4 and 1.2 installations. Does<br>
&gt; anyone knows if this has changed in 1.6?<br>
&gt;<br>
&gt; Any help would be really appreciated.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Samuel.<br>
&gt;<br>
<br>
<br>
</div></div>That&#39;s an interesting discovery, but I suspect it has something to do<br>
with a Dial command on a SIP channel. &nbsp;Do you have any idea where in<br>
your dialplan these events are occurring?<br>
<br>
JT<br>
<br>
---<br>
John Todd<br>
<a href="mailto:jtodd@digium.com">jtodd@digium.com</a> &nbsp; &nbsp; &nbsp; &nbsp;+1-256-428-6083<br>
Asterisk Open Source Community Director<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
 &nbsp; <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div><br>