Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - spam signaling

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Jul 2017 15:49:39 +0000

Tolga,

To respond to your last paragraph, as that seems to raise issues unrelated to the callinfo draft:

I think RFC 8197 (SIP Response Code for Unwanted Calls) addresses most of your last comment, except the 'post call' case. My guess is that, in almost all cases, the BYE-with-Reason described in RFC 8197 addresses the common case of "hang up with prejudice". There may be a need for providing another mechanism for post-hang-up spam indication, e.g., using SIP MESSAGE (to a designated carrier address, similar to the SMS 7726 short code), possibly with additional information. For example, this would be useful when listening to voicemail.

That mechanism could re-use the 'type' list here, but otherwise seems like a different problem beyond the scope of the draft. My suggestion would be to separate the discussion.

Henning

From: Asveren, Tolga [mailto:[email-masked]]
Sent: Wednesday, July 19, 2017 4:35 AM
To: Henning Schulzrinne <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-sipcore-callinfo-spam-01 - SIP entities

An indicator for asking the end-user to provide information about whether he considers the call as spam would be useful and should be covered IMHO. This would help Network Logic to learn/be more precise about heuristics applied for spam detection. I can see a few different scenarios here:
- Network decides to ask for feedback during initial INVITE, indicator can a be a parameter in Call-Info
- Network decides to ask for feedback after the call is setup, e.g. because it detects that the call could be spam by speech analysis. Indicator can be sent in BYE, if the call is terminated by the calling party. Otherwise -if BYE is sent by called party-, network can still send BYE with the indicator toward calling party before 200 for the BYE received from it. I think this should work. In either case, end-user could see a visual indicator asking whether the call was spam. If he honors the request, 200(BYE) would have the 666-unwanted. I am not sure what would be the best way to handle the situation that the end-user hangs-up and then notices the indicator and decides to send feedback. UE can cache the Call-Id but conveying Call-Id/this was(n't) a spam information to the network probably would require a new event package. Alternatively, UE can buffer 200(BYE) for a while after user hangs up -to give the user the opportunity to notice the indicator and act- but that may have issues from billing perspective (maybe a "delayed = x sec" parameter added to 200(BYE) could help).

Thanks,
Tolga