<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    As suggested by Michael I am raising this on the mail lists. This
    has been verified on asterisk 10.4.0<br>
    <br>
    Currently asterisk expected behaviour when a sip provder has
    multiple A records for a sip user/peer, is that asterisk uses just
    the first one returned by the dns lookup. This leads to issues of
    calls from other ips being treated as anonymous instead of matched
    against configured users/peers. This can be undesirable behaviour,
    since to get the calls you have to accept anonymous calls, something
    that you might not have necessarily wanted. Those calls are not
    following any other settings for user/peer which you may have
    wanted.<br>
    <br>
    You can set up multiple trunks, using hard coded ips instead of host
    names to cover all your providers ips (a bit of a pain if there are
    lots) but can be done. Or you can rely on round robin effect of dns
    and set up as many trunks as there are ips but still use
    host=providers sip server hostname, since dns will hand out each ip
    in turn (or it can be made to with a local caching name server like
    bind for instance).<br>
    <br>
    However, this still does not catch the case where tomorrow, the
    provider adds another ip. When calls come in from that ip you will
    lose them or if you accept anonymous calls, they are still not
    matched to user/peer settings you specifically set for the provider.<br>
    <br>
    So far I have found two providers that have multiple ips but
    googling there are more. As providers increase their size this is
    likely to become more and more an issue.<br>
    <br>
    Does any one have some insight into why asterisk would only take the
    first A record, whether it would make to change or not change this
    behaviour. <br>
    <br>
    If it does not make sense to change it, is there a way of
    configuring that would avoid the pitfalls of the workarounds I
    mentioned above. <br>
    <br>
    If it would make sense to change it, and assuming that someone would
    volunteer to make a patch, any thoughts on were that change could be
    made? Would it make sense that the structure of sip users and peers
    could store multiple ip addresses to be read from dns at
    configuration reload or periodically refreshed, then on an incoming
    call each ip would be checked?<br>
    <br>
    John<br>
    <br>
    <br>
    -------- Original Message --------
    <table class="moz-email-headers-table" border="0" cellpadding="0"
      cellspacing="0">
      <tbody>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th>
          <td>[JIRA] Commented: (ASTERISK-19846) sip users/peers not
            matched on incoming invite when there are multiple A records
            in DNS</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
          <td>Sun, 6 May 2012 21:54:19 -0500 (CDT)</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
          <td>Michael L. Young (JIRA)
            <a class="moz-txt-link-rfc2396E" href="mailto:noreply@issues.asterisk.org">&lt;noreply@issues.asterisk.org&gt;</a></td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
          <td><a class="moz-txt-link-abbreviated" href="mailto:john@gufonero.com">john@gufonero.com</a></td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    <pre>    [ <a class="moz-txt-link-freetext" href="https://issues.asterisk.org/jira/browse/ASTERISK-19846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=192504#comment-192504">https://issues.asterisk.org/jira/browse/ASTERISK-19846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;focusedCommentId=192504#comment-192504</a> ] 

Michael L. Young commented on ASTERISK-19846:
---------------------------------------------

This is the current expected behavior.  The first A record returned is what gets used.

A patch to add this feature of handling multiple A records would be needed and would be welcomed.

Features requests are no longer submitted to or accepted through the issue tracker without a patch. Features requests are openly discussed on the mailing lists [1] and Asterisk IRC channels and made note of by Bug Marshals.

[1] <a class="moz-txt-link-freetext" href="http://www.asterisk.org/support/mailing-lists">http://www.asterisk.org/support/mailing-lists</a>

&gt; sip users/peers not matched on incoming invite when there are multiple A records in DNS
&gt; ---------------------------------------------------------------------------------------
&gt;
&gt;                 Key: ASTERISK-19846
&gt;                 URL: <a class="moz-txt-link-freetext" href="https://issues.asterisk.org/jira/browse/ASTERISK-19846">https://issues.asterisk.org/jira/browse/ASTERISK-19846</a>
&gt;             Project: Asterisk
&gt;          Issue Type: Bug
&gt;      Security Level: None
&gt;          Components: Channels/chan_sip/General
&gt;    Affects Versions: 10.4.0
&gt;         Environment: centos 6.2, asterisk 10.4.0
&gt;            Reporter: John Fawcett
&gt;            Severity: Minor
&gt;
&gt; when a sip provider has multiple A records, for example sip.sipnl.net and a sip user is setup with host=sip.sipnl.net. If an INVITE arrives from an ip which is different to the one registered/stored, then it is not matched against the sip user. So the calls are treated as anonymous even though they would match the host name specified. Seems asterisk checks only a single A record of the specified host.
&gt; One workaround is to have a sip user per IP address (with the IP address configured instead of host name), but this is not maintainable, if the provider changes or adds ips, the system will change behaviour without warning and is undesirable for a production system.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: <a class="moz-txt-link-freetext" href="http://www.atlassian.com/software/jira">http://www.atlassian.com/software/jira</a>
</pre>
  </body>
</html>