Adrian Georgescu writes:
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.
there is not yet enough date why ser sent back 500. perhaps the uri
returned from enum was too long for ser to handle. this would need to
analyzed more carefully.
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.
that kind of check cannot be done, because ser.cfg may decide to send
302 reply back to the ua instead of forwarding the request. the us may
very well support h322 ot tel uris.
Failing parsing the URI is not bad, exiting the
routing logic leaving
behind unaccounted transactions is.
i agree, but most likely this has nothing to do with enum, but could
happen whichever way the same uri was added to destination set.
-- juha