Pete,
Joining this conversation late - apologies if it has already been discussed.
If you are proposing using a SIP response code 603 and with a header field Decline-Type: spam, the problem with this is that in SIP, failure responses (non-2xx) are delivered hop-by-hop and not end-to-end. This means that although the first hop (proxy) will get the Decline-Type:spam header field, any future hops will not. Instead, they will just get the 603.
A different response code such as 666 will be conveyed end-to-end, so every proxy and the calling UA will get the semantics.
- Alan -
On Tue, Mar 21, 2017 at 9:51 AM, Pete Resnick <presnick@xxxxxxxxxxxxxxxx> wrote:
Just replying to the points in your message (trimming as I go along):
On 21 Mar 2017, at 11:17, Henning Schulzrinne wrote:
My take of the discussion was that a simple mechanism that reflects plausible and likely UI approaches was preferable to a more complex mechanism.
First, there is nothing complex about adding a header that says, "Decline-Type: spam" to 603. It is extremely simple, accomplishes exactly the same result, reflects the one envisioned plausible and likely UI, and has the added advantage of extensibility.
Nothing prevents adding information to the 'unwanted' status code in the future, should there be a need. As you indicate, the Call-Info labeling may well inform such an effort.
The problem there is that you then will have two different ways of expressing "spam", adding yet more ambiguity. It means that the implementer has to know whether they're talking to a 666 implementation that does or does not know about the additional parameter to understand what the behavior will be. We've constantly faced this problem in IMAP over the years and it's made for horrible implementations.
Better to do the simple thing first and not end up with two incompatible ways to do the same thing in the future.
Yes, the idea was to model the (apparently near-universal) notions of the email spam button.
Simply achievable with 603 and "Decline-Type: spam". The only additional complexity is to create the IANA registry for future decline types. I'm only suggesting this document defining the one right now.
The goal was never to create a full-fledged API for rejecting classes of calls or otherwise controlling the behavior of voice spam filters.
Nor am I proposing such an API. Sure, pieces of this (and Call-Info labeling) might be useful for such a thing later, but I have no interest in such a thing now.
In practice, users will only be willing to spend a limited amount of time on feedback for unwanted calls.
Again, the mechanism I propose does not add to that limited time. It functions, in that scenario, exactly like 666. The difference is only in extensibility (and avoids the potential pitfalls I mentioned earlier).
Adding parameters to existing status codes can be done, but that seems more a matter of design taste.
As I said quite clearly, it's not a design matter. Using a separate status code to mean "decline, with additional semantics" has side effects, because you already have a status code for decline. Please re-read my explanation.
After all, we could then dispense with all specific codes and just use 100, 200, 400, 500 and 600, each with headers attached.
No, that absolutely does not follow. A layered approach of status codes for broader semantic values and headers for specialized processing works incredibly well. The problem arises when you introduce a status code that does not give the basic processing engine enough information to go on.
What you want in this case is to have the default behavior be "decline", as per the status code, and then have some side processing to figure out whether to deposit information into a spam analysis engine, or hand it off to some other process that does different sorts of things, based on the additional semantic information in the header. That's a good division of labor.
I don't see the problem with a new status code - we routinely add them and the mechanism of handling unknown ones are quite clear.
Please see my earlier comments on this particular status code: It increases semantic ambiguity, it increases the possibility for data loss, and it limits future extensibility.
Again, it's not clear that you've fully understood and considered what I wrote.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/ >
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
sipcore mailing list
sipcore@xxxxxxxx
https://www.ietf.org/mailman/listinfo/sipcore