As our organization starts looking into serious ENUM implementation,
it looks like we're going to have a problem with response codes.
The most likely method for a PBX to use ENUM is as a way to route
dialogs that are being sent to outside telephone numbers. First, look
up the number in ENUM and attempt to connect to the URI using SIP. If
that fails, then send the dialog to a PSTN gateway. This gives the
right result in most cases.
The problem is that when a dialog routed using ENUM fails, what the
proxy does next needs to depend on how the dialog failed. If it
failed with a Busy, Declined, or Ring No Answer status (that is, the
call reached the UA and then failed), no attempt should be made using
the PSTN. But if the dialog failed before reaching the UA, the dialog
should attempt to connect using the PSTN.
Most response codes can be classified into "failure in transit" and
"failure at the UA" groups. Unfortunately, but several response codes
can be returned in either situation, and they make it hard for the
proxy to fail-over from ENUM/SIP to PSTN connectivity.
I've written an I-D,
http://www.ietf.org/internet-drafts/draft-worley-sip-redundancy-response-00.txt,
to enumerate the failure response codes and propose a few new ones to
allow reliably separating failures into transit and end-system
responses.
Has anyone else encountered these problems? Are there any other
solutions proposed?
I'd like to know what people think.
Dale
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum