On Sat, 2009-03-07 at 13:36 -0500, Hadriel Kaplan wrote: > There *are* failure responses already which have the semantic of > "don't bother rerouting": the 6xx series. It's just that they're > rarely sent. The reasons they aren't sent would be the same reasons > any new response code with those semantics wouldn't be sent, no? The semantics of 6xx is (are?) deeply broken, because sending a 6xx back to mean "don't bother rerouting" may also prevent forks to alternative destinations that are not alternative routes to the failed destination. I once wrote an I-D on the subject. > Also, separating it into "response from proxy" vs. "response from UA" > is not that simple, and won't fix that much. There are plenty of > proxies that represent the ONLY path to get to that UA, and plenty of > UA's which do NOT represent the only path to get to the user. I think > what you really want to know is if the request got to the domain > responsible for the AoR and it got routed within that domain to the > UA, or not. Right? ISTM the real hard part there is due to the scope > of the AoR - if it's an E.164 username, the domain is not relevant and > the scope is bigger than SIP (it's semantically a tel URI), so the > domain reached doesn't always know if it's really solely authoritative > for that user or not globally. It's true that the problem in the fully general case is hard. I allude to this in the paragraph saying "It can be complicated to determine what exactly is a set of alternative routes to the same destination." In practice, a solution to my stated problem is made useful by the fact that a major case is the "redundant gateways to the PSTN" problem. It's also eased by the fact that what we *really* are trying to avoid is retrying ring-no-answer calls. Failures that return immediately are a waste of effort but do not annoy the users. (Amusing anecdote: In the system in which we first noticed this problem, many, many calls to busy PSTN phones were made through the redundant gateways. First the call was routed out gateway 1, which received an ISDN busy indication, which was reflected as a 486, then the proxy sent the call to gateway 2, which did the same sequence. So there was a wasted ISDN call, but everything happened so fast the caller never noticed.) Analyzing this situation correctly requires identifying not only the "splitting point" (the proxy that has to decide whether to try the alternate path) but also the "joining point" (e.g., the UA where the two alternate paths rejoin). But given that PSTN failure codes carefully distinguish endpoint failures from network failures suggests that segregating failure codes is useful. Currently, SIP does a bad job of that. In the -00 version of the draft, I identified 6 response codes with this problem. And it appears to be just a matter of sloppiness or not considering the problem, not an intrinsic problem with the protocol. Dale _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
