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

[Henning Schulzrinne <[e-mail]>]

This seems to be related to the previous comment. I agree that users should have the ability to specify, either within an app or via a web interface controlling a carrier or third-party operated service, how calls are treated. As you say, this could be fairly complex in its details, such as depending on the time of day. ("Don't mind survey calls, but not after 7 pm.")


I will note that many a moon ago, we actually developed a flexible XML-based language for call handling purposes (RFC 3880, CPL). Wouldn't be hard to extend it for this purpose, but I suspect CPL is not among the commonly-implemented SIP-related RFCs...


Henning

________________________________
From: sipcore <[e-mail]> on behalf of Souma Badombena <[e-mail]>
Sent: Sunday, April 2, 2017 10:47:12 AM
To: [e-mail]
Subject: Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard


"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