[Users] ENUM behaviour issue

[Juha Heinanen]

Daniel-Constantin Mierla writes:

 > Maybe you can shed some light regarding the priority, what is it good 
 > for in enum case, how it should be used? In this way, can be decided if 
 > worth to implement these features. I have other things in my todo list 
 > in the next days, so I do not want to waste time at all.

the owner of enum record may have decided that he wants to be first
contacted at a given uri and, if that fails, at another one, or more
than one uris simultaneously, etc.  for that purpose enum NAPTR record
contains two fields, order and preference:

Order
      A 16-bit unsigned integer specifying the order in which the NAPTR
      records MUST be processed to ensure the correct ordering of
      rules.  Low numbers are processed before high numbers, and once a
      NAPTR is found whose rule "matches" the target, the client MUST
      NOT consider any NAPTRs with a higher value for order (except as
      noted below for the Flags field).

   Preference
      A 16-bit unsigned integer that specifies the order in which NAPTR
      records with equal "order" values SHOULD be processed, low
      numbers being processed before high numbers.  This is similar to
      the preference field in an MX record, and is used so domain
      administrators can direct clients towards more capable hosts or
      lighter weight protocols.  A client MAY look at records with
      higher preference values if it has a good reason to do so such as
      not understanding the preferred protocol or service.

      The important difference between Order and Preference is that
      once a match is found the client MUST NOT consider records with a
      different Order but they MAY process records with the same Order
      but different Preferences.  I.e., Preference is used to give weight
      to rules that are considered the same from an authority
      standpoint but not from a simple load balancing standpoint.

in my opinion, sip proxy should obey the wish of the enum record owner
as specified by these two fields.   it is the same as with q values of
registered contacts.  proxy should not mess around with them.

-- juha