Soren (Home) wrote:
I don't really understand the advantage, but it is
something like you want
to share the locations between different instances of SER? (and not just
by sharing the database)
First of all I want to use enum for peering partners who want to route
their calls over our PSTN gateways. These entries can be inserted when
new numbers are allocated and removed when they are released by our
peering partners via a defined interface.
This is a quite straight-forward task and only requires SER to query the
database.
But theoretically I could also insert "real" locations, which could be
used for looking up numbers with phone extensions.
My current situation is that I have UACs that connect to ISDN PBX. The
UAC registers with 012345(a)1.2.3.4 and behind the PBX there exists the
phone extension 1000.
Now someone calls 0123451000(a)my.domain, a does_uri_exist() returns
false. So I have to strip down the number to the base number 012345, for
which I can look up the location. The problem is that the URI now is
sip:012345@1.2.3.4 instead of sip:0123451000@1.2.3.4
Now I could implement my own lookup-function which keeps the user-part
and replaces only the host-part with the IP of the registered base number.
But since I want to use enum anyway, I thought that I could use enum
also for this scenario, because with enum I could insert
wildcard-locations and use regexps, so that 012345.*(a)my.domain always
resolves to 012345.*(a)1.2.3.4
Locations can change rapidly, while I would think of
ENUM as "semi"-static
information. Typically DNS takes atleast some few hours to spread,
however, It could be different if you are using local DNS-server (w/o
cache) and point your resolv.conf to it.
Right, it's just a local noncaching DNS server.
Andy