No, it shouldn't be able to crash ser. ser survives bad uris.
It does not crash but it causes SER to send stateless 500 back to the client and does not stand the transaction which in term does not start the accounting.
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?
Check AT LEAST if the returned URI from NAPTR lookup has a valid scheme that SER support (e.g sip: sips:) h323 tel etc should be checked in the enum lookup function
This will happen any way at the first forward attempt that takes uri into account (the forward will fail).
In case of ser, I would do the URI parsing in the ENUM module, or maybe generate a dedicated function/module for checking SIP URIs inside the routing logic. Thus, I can also check the result of exec calls.
This could be easily done, but as I said above, if the uri is bad forwarding will fail anyway.
Failing parsing the URI is not bad, exiting the routing logic leaving behind unaccounted transactions is.
Andrei
Adrian