<div dir="ltr">Good too see im on the right page then :)<div>this IS for inside a carrier network, my own carrier network :P</div><div><br></div><div>Yea I want the <font face="arial, sans-serif">randomising just to share load round gateways.</font></div><div><font face="arial, sans-serif">( but dont want to bother with a real load balancer... hopefully randomising enum results will be fine for what I want )</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">yea .. I just dont think relying on the DNS server to randomise the order is the right way to go.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">So, who is willing to take a look at this with me ??</font></div><div><font face="arial, sans-serif">I would really like some suggestions on the best way to order the results.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">guessing an ordered array of pointers to the records would be most efficient, </font><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">but does someone more familiar with this have any time to work on it ?</font></div><div><font face="arial, sans-serif"><br></font></div><div class="gmail_extra">Jay</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 November 2014 23:48, Lawrence Conroy <span dir="ltr">&lt;<a href="mailto:lconroy@insensate.co.uk" target="_blank">lconroy@insensate.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jay, folks,<br>
 Ahem -- the current ENUM spec is RFC6116. This obsoletes RFC3761, which in turn obsoleted RFC2716. I know this, &#39;cos I wrote it :). I strongly recommend you give 6116 a go, as we REALLY tried to make it useful and fix the bugs in the earlier specs.<br>
As for the NAPTR spec, RFC2915 was obsoleted in RFC3403. That&#39;s within the set of specs RFC3401-RFC3405 (but I&#39;d suggest care, as your head will bleed if you try to read them all, and they all cross-refer). For ENUM, RFC2915 is a false friend -- it looks OK, but is &quot;historical only&quot;.<br>
<br>
TL:DR; yup -- MUST be sorted on order/pref. Dealing with them &quot;as they come&quot; in the DNS response is a hangover from the original * client/hack -- it&#39;s wrong.<br>
<br>
Longer: Strictly, should sort, then check the &quot;best&quot; one in the sorted list, see if that works, and then go on to the next if it doesn&#39;t (i.e., doesn&#39;t exists, is invalid, or your client app doesn&#39;t support the URI or it doesn&#39;t understand the enumservice tag within that NAPTR).<br>
<br>
Note that the esteemed muppets in the SIP clique got the definition for the service field arse about face from the way it&#39;s used in ENUM, so beware of non-ENUM SIP NAPTRs (a la RFC3263) when developing a parser. They were told, and we still ended up with RFC3824 -- sigh.<br>
<br>
Note that Non-terminal NAPTRs may mean that one chases &quot;down&quot; to another domain and looks there for NAPTRs, and Compound NAPTRs may mean that there are two choices in one record. Only place that uses either of them on the open Internet, as far as I&#39;m aware, is domains within the .tel TLD. (What&#39;s used within Carriers&#39; internal nets is another story, but you shouldn&#39;t see those, ever).<br>
<br>
The specific bit in the ENUM spec that spells this out is in section 5.2 of RFC6116, which says:<br>
&quot;   ENUM clients MUST sort the records of a retrieved NAPTR RRSet into<br>
   sequence using the ORDER and PREFERENCE fields of those records.  The<br>
   ORDER is to be treated as the major sort term, with lowest numerical<br>
   values being earlier in the sequence.  The PREFERENCE/PRIORITY field<br>
   is to be treated as the minor sort term, with lowest numerical values<br>
   being earlier in the sequence.<br>
&quot;<br>
<br>
BTW, as regards what to do with NAPTs with identical ORDER/PREF fields, 5.2 also says:<br>
&quot;   ENUM clients SHOULD accept all NAPTRs with identical ORDER and<br>
   identical PREFERENCE/PRIORITY field values, and process them in the<br>
   sequence in which they appear in the DNS response.  (There is no<br>
   benefit in further randomizing the order in which these are<br>
   processed, as intervening DNS Servers might have done this already).<br>
&quot;<br>
That&#39;s only a SHOULD, so knock yourself out with further randomisation if wanted -- it&#39;s not an error (but it is not really needed -- anyone publishing these must not care which is chosen).<br>
<br>
all the best,<br>
  Lawrence<br>
<div><div class="h5"><br>
On 13 Nov 2014, at 08:34, jay binks &lt;<a href="mailto:jaybinks@gmail.com">jaybinks@gmail.com</a>&gt; wrote:<br>
&gt; so both <a href="http://tools.ietf.org/html/rfc2915" target="_blank">http://tools.ietf.org/html/rfc2915</a> &amp; <a href="http://tools.ietf.org/html/draft-daniel-naptr-00" target="_blank">http://tools.ietf.org/html/draft-daniel-naptr-00</a><br>
&gt; say the the client MUST do the ordering.<br>
&gt;<br>
&gt; Interesting to note is that <a href="http://tools.ietf.org/html/draft-daniel-naptr-00" target="_blank">http://tools.ietf.org/html/draft-daniel-naptr-00</a> talks about the client randomly selecting if order &amp; pref are all the same.<br>
&gt; however the RFC does not explicitly mention this for NAPR.  ( which is a little unfortunate )<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ---------- Forwarded message ----------<br>
&gt; From: jay binks &lt;<a href="mailto:jaybinks@gmail.com">jaybinks@gmail.com</a>&gt;<br>
&gt; Date: 13 November 2014 17:40<br>
&gt; Subject: mod_enum and ordering / prefference<br>
&gt; To: <a href="mailto:freeswitch-dev@lists.freeswitch.org">freeswitch-dev@lists.freeswitch.org</a><br>
&gt;<br>
&gt;<br>
&gt; So im looking over mod_enum in relation to something Im trying to do ( will discuss later in the email ), and after looking through the code, it seems the mod_enum does not order the results at all, and it is assumed that ldns or the DNS server will order the results correctly.<br>
&gt; ldns_resolver_query is called, and parse_naptr is called for each result.<br>
&gt; parse_naptr parses the result row then calls add_result, which adds it to the array of enum_record.<br>
&gt; ( appears to always add it to the end )<br>
&gt;<br>
&gt; Its not that this is failing for me, but this seems to be a little dangerous and I would have expected FS to interpret the order and preference values its self.<br>
&gt;<br>
&gt; Can someone else take a look over this for me, and tell me if im wrong.  :)<br>
&gt;<br>
&gt; In addition to this,   I was hoping to find a way to make FS randomly select a row if the order &amp; preference are identical.<br>
&gt;<br>
&gt; Obviously this would need to be a config value because some people may NOT want this, but can anyone see any issues here ??   if the order / pref are identical your already going to run the risk of something jumbling the order around so you cant rely on the order of your zone file... having FS randomise this simple means that it will defiantly be random :)<br>
&gt;<br>
&gt; just after some thoughts on this one...<br>
&gt;<br>
&gt;<br>
&gt; ( if you happen to decide to patch the above issue... then consider this also... otherwise ill attempt a patch for both depending on feedback )<br>
&gt;<br>
&gt; --<br>
&gt; Sincerely<br>
&gt;<br>
&gt; Jay<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Sincerely<br>
&gt;<br>
&gt; Jay<br>
</div></div>&gt; _________________________________________________________________________<br>
&gt; Professional FreeSWITCH Consulting Services:<br>
&gt; <a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
&gt; <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
&gt;<br>
&gt; Official FreeSWITCH Sites<br>
&gt; <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
&gt; <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
&gt; <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
&gt;<br>
&gt; FreeSWITCH-dev mailing list<br>
&gt; <a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
&gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
&gt; UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
&gt; <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Sincerely<br><br>Jay</div>
</div></div>