> -----Original Message----- > From: David Schwartz [mailto:dschwartz@xxxxxxxxxxxx] > Sent: Sunday, July 12, 2009 8:22 AM > > I still think that there should be a difference between: > * I can't help you and no one can (e.g. user is not online - 404) > * I can't help you do to some temporary issue (network - 503 or otherwise > - 480) > * I can't help you but feel free to try elsewhere (e.g. cannot find a > route to the target do to one of many reasons) > > And I still feel that there should be a new response code to this last > category. > > Your thoughts? I thought that the last category *is* what a 404 is for, while the first category is a 604. (well, I assume you don't actually mean "cannot find a route to the target" for the last category - because that is what a 480 is for :) It just happens that in practice hardly anyone ever sends a 604, even though they maybe should. So if devices today send 404 for both case-1 and case-3 when they already have two different response codes for the two cases, then why would they change that behavior just because a new response code is created for one of the cases? Or am I missing the gist of the problem? -hadriel p.s. My guess is that it's not because they can't generate a 604 physically, but rather that the systems can't consistently and programmatically know when it would be correct to do so. It's kind of a bold statement to say "I know you can't reach this user by any means anywhere", when the URI is an E.164 number. For example some products only ever issue a 604 response when the ENUM server has an explicit entry for the target number, and the entry's NAPTR is the VOID/UNUSED type. But otherwise they're dealing with provisioned route tables and HLR's and such, which may simply not have an entry for a number that isn't active, vs. an actual entry which explicitly says "not-active". But that's just my personal theory. _______________________________________________ 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
