Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 - related draft - https://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00

[Henning Schulzrinne <[e-mail]>]

My reasoning is in analogy with spam filtering for email. I don’t think of any effects of a 666 response as being either temporary or permanent. If the response contributes to listing it on a black list of some sort, the black lister might monitor other sources of information (e.g., number porting information) and remove the number from the list when the holder of the number has changed. Or some may decide that if no caller uses the number anymore, that removing it from the list is a good idea (to limit the damage if porting and re-assignment cannot be accurately tracked). Or, as for email, there may be mechanisms for the number holder to get off the list. Thus, in many cases, this is both, but not driven by an indication from the called party, but additional outside information or heuristics that are beyond standardization.

In addition, as discussed, in many cases, any crowd-sourced “black” list may have many shades of gray, from flagging the call (“possible spam”) to CAPTCHA-like mechanisms (“press 7 if you are a human”) to redirection to voicemail to outright call rejection. Numbers may even “fade” from black to gray to white over time, or “darken” as more information becomes known.

I admit that I don’t think that having users specify time durations is likely to be helpful. At best, this commingles “do not disturb” features (which we already have, via Retry-After and various 4xx/6xx codes, such as 486 and 600) with the kind of “stop annoying me” that’s implied in this draft.

Henning

From: sipcore [mailto:[e-mail]] On Behalf Of Ranjit Avasarala
Sent: Wednesday, January 04, 2017 5:50 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 - related draft - https://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00

Hi
Sometime I had submitted an I-D based on a similar idea - to block a particular caller either temporarily or permanently -  https://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Davasarala-2Dsipping-2Dreason-2Dheader-2Ddynamic-2Dicb-2D00&d=DgMFaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=-y6AC8U6Tpg7Yeqz6e-jGo-Xv1vhpO5cMddu5CHBY20&s=jrgnLfL5G0Q1degqV3zgcv870XvCXwrlUKWvpkWxsgA&e=>
Here the SIP Reason header would be appended to the BYE request.
Now using 666 response code - is the block permanent or time based?
Regards
Ranjit

On Wed, Jan 4, 2017 at 4:35 PM, <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I have the following comments on v01:

-Section 4 - 4rd paragraph:
        The actions described here do not depend on the nature of the SIP
        URI, e.g., whether it describes a telephone number or not
but in the rest of the document only telephone numbers are mentioned. It would be good to reflect this by using "telephone number or address"?

-Section 4 - last paragraph:
        We define a SIP feature-capability [RFC6809], sip.666, that allows
        the registrar to indicate that the corresponding proxy supports this
        particular response code.
I would suggest: "This document defines a new SIP feature-capability indicator [RFC6809] value, sip.666, that ...

-Section 4 general:
IMO, it would be good to have a paragraph addressing the question of the "calling party number" (mentioned several time in the document): indeed, this calling party number can be identified by the telephone number/address in the From header or the one in the P-Asserted-Identity header that may be different. Depending on the one displayed to the called UA, the 666 could concern only one or both addresses depending on service provider choices. If we take the example of a call-center or an IPBX having the head number and a range of private numbers, the service provider could interpret the 666 from the called user only for the private number (in the From header) or for the whole pool (P-Asserted-Identity). I suggest to have a paragraph to highlight this point.

-Section 6:
calling party number / calling party address


Best regards,
Marianne


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
sipcore mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sipcore<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgMFaQ&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=-y6AC8U6Tpg7Yeqz6e-jGo-Xv1vhpO5cMddu5CHBY20&s=chrc5gKre9VV68cdzyelGPFMZtC2ABHVmdlUxYaAZD4&e=>