ENUM in the reSIProcate stack
- See the Uri class and the DnsResult::lookup method
Ordering of search results
- Note that ENUM suffixes are ordered in search results:
- e.g. you search the suffixes e164.arpa, e164-addr.sip5060.net, e164.org
- the stack will run the DNS queries in parallel
- it will wait for responses from ALL suffixes, and then it will use the result from the highest priority suffix
- if e164.arpa doesn't respond, and a response comes from e164-addr.sip5060.net and e164.org, it will always use the response from e164-addr.sip5060.net
ENUM support in repro
- As of release 1.8.5, There are two configuration parameters in repro.config:
# Specify a comma separate list of enum suffixes to search for enum dns resolution EnumSuffixes = e164.arpa, e164-addr.sip5060.net # # Specify the target domain(s) for ENUM logic support. When a dialed SIP URI # is addressed to +number@somedomain, # where somedomain is an element of EnumDomains, # the ENUM logic will be applied for the number # If empty, ENUM is never used EnumDomains = enum.example.org
- Notice that if one of the `EnumDomains' is also local to the repro instance, it will not be considered by the ENUM logic.
- See the note above about ordering of search results - this makes for `stacking' scenarios,
- ENUM can be used with a solution like [dlz-ldap-enum] to quickly give repro support for all the phone numbers stored in an existing LDAP server
Future possibilities for improving ENUM support in reSIProcate and repro
- should the ENUM logic be applied earlier in the request context workflow, by a monkey for ENUM?
- should it be possible to INVITE a tel: URI, all such requests would be treated as ENUM requests?
- should it be possible to trigger the ENUM logic from the dial plan?
- enabling ENUM support from the config?
- ENUM popup?