Subject: [Enum] Response codes and multiple paths to a destination

From: [email-masked]
Date: Tue, 13 Mar 2007 12:24:20 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 14:09:05 -0400

Dale,

I'm sympathetic to the general issue you are raising. But I think some 
of the codes you have issue with can be explained away as non-issues:

402: does it really matter who needs to be paid? If the UAC is willing
and able to pay, then go ahead and try that. If not, then go ahead and 
try the pstn. (Maybe you will get lucky and its free on the pstn and 
only charged via sip. (NOT))

420: again - does it really matter? Either way you can't talk via sip, 
but still have a chance via the pstn.

422: There is no reason for a UAC to ever *request* a session timer. So 
assume it didn't. In that case a proxy on the path presumably did, and 
then the UAS or some other proxy along the path didn't like it. The pstn 
is a viable option in this case.

	Paul

---

From: [email-masked]
Date: Thu, 15 Mar 2007 15:17:14 -0500

From: Paul Kyzivat <[email-masked]>

Or we could just say that since the implementation of 402 is reserved
for future standardization, handling this problem for the 402 response
is reserved for that same standardization.

That's true if one path is SIP and the other path is PSTN.  But there
is also the case where both paths are SIP.  If one SIP path rejects
you based on the failure of a Proxy-Require, you want to try the other
path.  But there's no point in retrying if the failure is due to
Require.

OTOH, as long as the Require and the Proxy-Require options do not
duplicate names, the Unsupported header in the response will
distinguish the two cases

   422: There is no reason for a UAC to ever *request* a session timer.

OK, I was not aware of that.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Mar 2007 18:31:34 -0400

> OK, I was not aware of that.

The session timer is there so a proxy in the middle can ask one of the 
UAs to do reinvites, so that the proxy can tell the session is still active.

The UAC can send its own reinvites any time it wants - it doesn't have 
to set up a session timer to do so. The only advantage would be to 
convince the UAS to do the reinvites, rather than the UAC doing its own. 
What kind of advantage is that?

	Paul