Andrei Pelinescu-Onciul writes:
This could be fixed by limiting the ammount of time
that a dns lookup
can take in ser (e.g. a new config parameter).
that kind of parameter would indeed be a good thing. slow dns query has
nothing special to do with enum. it would affect also lookups on
request uri host.
> This may result in a failed transaction, or like
revealed at the
> ENUM plugtest in failed accounting.
accounting should succeed. failure may be result of yet another bug in
radiusclient library, not necessarily in ser. i asked more details
about this incident, but i guess adrian has been too bury to provide
it.
Thus you
can't avoid doing some URI checks against the URI received from
the ENUM lookup. Perfomance issues are no valid arguements! Once I give
control to external services (DNS, radius, exec), the perfomance
penalties due to parsing the SIP URI are much more less than due to the
ENUM lookup.
What kind of checks? Run parse_uri and if fails return an error?
This will happen any way at the first forward attempt that takes uri
into account (the forward will fail).
this is what i said too. i could try to parse every uri returned from
enum, but i have considered it waste of time, because bad uris will be
detected later anyway either by ser or, in case of 302, by sip ua.
This could be easily done, but as I said above, if the
uri is bad
forwarding will fail anyway.
exactly.
-- juha