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