<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>19 apr 2013 kl. 12:34 skrev Jaco Kroon <<a href="mailto:jaco@uls.co.za">jaco@uls.co.za</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">Hi Olle,<br>
<br>
I can confirm your observations. For this reason I've updated
(or initiated the process) to periodically resolve the SRV
records out-of-band and generate an updated configuration file
that contains all of the hosts. I must further point out that
(last I checked) it gets even worse, if you have an A record
with multiple IPs listed, asterisk will only use one of those as
well.<br></font></div></div></blockquote>I am not sure I like supporting round-robin DNS as the official recommendation is to use SRV records. The idea with round-robin DNS is not failover, but to load balance and this works perfectly well. </div><div>After som googling last week, I do realize too many people use rr DNS so we might have some optional support for it</div><div>regardless of my personal feelings. It's not part of the current project though, my funding is only focused on SRV support.</div><div><br></div><div><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">
<br>
My scenarios only have one IP in the A RRs but I do have
multiple SRV RRs for all of _sip._udp, _sip._tcp and _iax._udp.<br>
<br></font></div></div></blockquote>That's the right way :-)</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">
To add further insult to injury, an *outbound* Dial() also won't
use secondary SRV RRs, it'll only go to the first "picked" host,
and only use that, so even if timers expires and we're unable to
contact the remote side ... the call WILL fail. One way to do
this would be to construct a list of contact points, and for SIP
at least only use the T1 timer to cycle through them with
INVITEs, first one to respond ... grabs it, if they all fail,
send to all of them at the same time with the T2 timer, first
one to respond grabs it, any other responses simply gets
CANCELed. I can see a great many number of holes in this
strategy, but it may be a starting point for someone else to
start thinking from.<br></font></div></div></blockquote>I am currently working on fixing Dial() and SRV in SIP.<br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">
<br>
This applies to both SIP and IAX/2 (and probably other protocols
that I don't even know about).<br></font></div></div></blockquote>The "other" protocol is out of scope for this project.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">
<br>
Currently my suggestion would be to deal with the outbound
situation in Dialplan(), and to generate multiple peer configs
in the config files, covering each host individually. Obviously
this implies that you have to track DNS changes external to
asterisk. My setup also utilizes the inbound ACLs for dealing
with IAX/2 authorization (so all peers will send IE
username=foo, and [foo] will deny=all,
permit=${ips_from_srv_and_a_rrs}). Still need to generate
multiple peers for outbound cases though.<br></font></div></div></blockquote>That sounds a bit messy to me. I have a more elegant solution based on the code. I don't know if it works yet, so thank you for your suggestion, I might have to revert to that if this fails ;-)</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">
<br>
If you'd like to fix this in the code - something which should
probably done, and would be a better solution than my hack, but
which I suspect is going to be rather complex - I'd be more than
willing to help test for you.<br></font></div></div></blockquote>Looking forward to your test results.</div><div><br></div><div>/O<br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">
<br>
</font>
<div class="moz-signature">Kind Regards,<br>
Jaco Kroon<br>
<span><.eml_jaco.png></span>
<map name="Map" id="Map">
<area shape="rect" coords="441,19,460,36" href="https://www.facebook.com/ultimatelinuxsolutions">
<area shape="rect" coords="441,39,458,57" href="http://news.uls.co.za/">
<area shape="rect" coords="354,62,461,73" href="http://www.uls.co.za/">
</map>
</div>
On 19/04/2013 11:48, Olle E. Johansson wrote:<br>
</div>
<blockquote cite="mid:3A866F19-F14D-45FA-9E5A-9E1FF3F14706@edvina.net" type="cite">
<pre wrap="">Friends,
Looking into the SRV record support of Asterisk I believe there's an issue with peer matching here.
If a service, like "<a href="http://edvina.org">edvina.org</a>", have multiple SRV records that points to multiple hosts IPs, maybe even dual stack, then a request FROM that service
may come from any of these IPs.
Let's assume the configuration looks like this:
register=marko:okram@edvinaservice/callback
[edvinaservice]
type=peer
host=<a href="http://edvina.org">edvina.org</a>
In this case the peer will pick one address from the SRV records and use for matching. If another server IP is used on the
server side, matching will fail.
I would like to be able to add all available IP addresses and ports for matching. Will that work with the ao2object list or will it
mess up the list to have many hash entries for the same object?
The way I would like to do this is to set up an ACL entry in the peer for the SRV record so we have a list to go through
and perform the matching on. If that list is empty, we will match as before.
Thoughts?
/O
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
</pre>
</blockquote>
<br>
</div>
<span><jaco.vcf></span>--<br>_____________________________________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><br></body></html>