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