[Freeswitch-dev] mod_enum and ordering / prefference

Thu Nov 13 17:00:49 MSK 2014

Good too see im on the right page then :)
this IS for inside a carrier network, my own carrier network :P

Yea I want the randomising just to share load round gateways.
( but dont want to bother with a real load balancer... hopefully
randomising enum results will be fine for what I want )

yea .. I just dont think relying on the DNS server to randomise the order
is the right way to go.

So, who is willing to take a look at this with me ??
I would really like some suggestions on the best way to order the results.

guessing an ordered array of pointers to the records would be most
efficient,
but does someone more familiar with this have any time to work on it ?

Jay

On 13 November 2014 23:48, Lawrence Conroy <lconroy at insensate.co.uk> wrote:

> Hi Jay, folks,
>  Ahem -- the current ENUM spec is RFC6116. This obsoletes RFC3761, which
> in turn obsoleted RFC2716. I know this, '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.
> As for the NAPTR spec, RFC2915 was obsoleted in RFC3403. That's within the
> set of specs RFC3401-RFC3405 (but I'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 "historical only".
>
> TL:DR; yup -- MUST be sorted on order/pref. Dealing with them "as they
> come" in the DNS response is a hangover from the original * client/hack --
> it's wrong.
>
> Longer: Strictly, should sort, then check the "best" one in the sorted
> list, see if that works, and then go on to the next if it doesn't (i.e.,
> doesn't exists, is invalid, or your client app doesn't support the URI or
> it doesn't understand the enumservice tag within that NAPTR).
>
> Note that the esteemed muppets in the SIP clique got the definition for
> the service field arse about face from the way it'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.
>
> Note that Non-terminal NAPTRs may mean that one chases "down" 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'm aware, is domains within the .tel TLD. (What's
> used within Carriers' internal nets is another story, but you shouldn't see
> those, ever).
>
> The specific bit in the ENUM spec that spells this out is in section 5.2
> of RFC6116, which says:
> "   ENUM clients MUST sort the records of a retrieved NAPTR RRSet into
>    sequence using the ORDER and PREFERENCE fields of those records.  The
>    ORDER is to be treated as the major sort term, with lowest numerical
>    values being earlier in the sequence.  The PREFERENCE/PRIORITY field
>    is to be treated as the minor sort term, with lowest numerical values
>    being earlier in the sequence.
> "
>
> BTW, as regards what to do with NAPTs with identical ORDER/PREF fields,
> 5.2 also says:
> "   ENUM clients SHOULD accept all NAPTRs with identical ORDER and
>    identical PREFERENCE/PRIORITY field values, and process them in the
>    sequence in which they appear in the DNS response.  (There is no
>    benefit in further randomizing the order in which these are
>    processed, as intervening DNS Servers might have done this already).
> "
> That's only a SHOULD, so knock yourself out with further randomisation if
> wanted -- it's not an error (but it is not really needed -- anyone
> publishing these must not care which is chosen).
>
> all the best,
>   Lawrence
>
> On 13 Nov 2014, at 08:34, jay binks <jaybinks at gmail.com> wrote:
> > so both http://tools.ietf.org/html/rfc2915 &
> http://tools.ietf.org/html/draft-daniel-naptr-00
> > say the the client MUST do the ordering.
> >
> > Interesting to note is that
> http://tools.ietf.org/html/draft-daniel-naptr-00 talks about the client
> randomly selecting if order & pref are all the same.
> > however the RFC does not explicitly mention this for NAPR.  ( which is a
> little unfortunate )
> >
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: jay binks <jaybinks at gmail.com>
> > Date: 13 November 2014 17:40
> > Subject: mod_enum and ordering / prefference
> > To: freeswitch-dev at lists.freeswitch.org
> >
> >
> > 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.
> > ldns_resolver_query is called, and parse_naptr is called for each result.
> > parse_naptr parses the result row then calls add_result, which adds it
> to the array of enum_record.
> > ( appears to always add it to the end )
> >
> > 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.
> >
> > Can someone else take a look over this for me, and tell me if im wrong.
> :)
> >
> > In addition to this,   I was hoping to find a way to make FS randomly
> select a row if the order & preference are identical.
> >
> > 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 :)
> >
> > just after some thoughts on this one...
> >
> >
> > ( if you happen to decide to patch the above issue... then consider this
> also... otherwise ill attempt a patch for both depending on feedback )
> >
> > --
> > Sincerely
> >
> > Jay
> >
> >
> >
> > --
> > Sincerely
> >
> > Jay
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://wiki.freeswitch.org
> > http://www.cluecon.com
> >
> > FreeSWITCH-dev mailing list
> > FreeSWITCH-dev at lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> > http://www.freeswitch.org
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>

-- 
Sincerely

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20141114/8e4ec26a/attachment-0001.html 