Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard

[Souma Badombena <[e-mail]>]

"unwanted" as opposed to "blocked" -- "unwanted" is an enhancing
functionality and allowing possible flexibility

I just wanted to mention a relevant aspect where the "Unwanted" concept
addresses a shortcoming and may be improved upon with subsequent parameters
enrichments.
For some SIP calling and messaging application there exists the concept of
"contact blocking", "user blacklisting" or "personal blocking" where a user
can select specific contacts or undersired identities (phone numbers,
usernames, aliases etc...) to be blocked and therefore allowing the
blocking user to reject calls or messages from a given blocked user. This
very method or technique consists in maintaining a resource list of blocked
contact and applying restrictive or rejection filters to them either a
local (client) level or at network level. So in a parallel with the "SIP
666 - unwanted" solution, I notice that on one hand the  "unwanted" method
may be equivalent to the method or concept of blocking, but on the other
hand it does potentially offer an extensible flexibility for particular
cases, provided that the appropriate enhancement work is done in the
future. For example in particular cases where a user may want to add more
selectivity to the how the "unwanted" call instances and originators are
treated, such as setting a time window or period for which the calls are
unwanted or associating a geolocation aspect to calls that need to be
treated as unwanted. etc.. There are several scenarios available provided
that the specification provides for further extensibility combined to
programmatic mechanisms or machine learning pattern building procedures. So
with that being said, should we agree that the proposed SIP response code
could be further extended to bear multiple contextual reason codes?


Thanks.
-- 
Souma Badombena-Wanta