Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

["Asveren, Tolga" <[e-mail]>]

Henning,

I had some high level queries/comments, which I sent back beginning of April. Here it is again for easier access:


What are the main use cases?
1) Communicating spam related information between network elements for a particular call
Various network elements may have a prediction whether a call is spam. It could be useful to send all that info in a chain and then the ultimate decision what needs to be sent to UE would be on the last-hop authorative entity. A "0-100 spam score" indicator may be useful in this context, or at least something more than just "likely to be spam" indicator.
The identity of the entity providing spam score needs to be part of the provided information.
More than one spam score/identity pair needs to be supported.
Support for signed identity should be there.
I am not sure whether "type" would be useful here, I tend to think not. How/Why would it be used?

2) Communicating spam related information between network and end-user
I think here what is needed is just a "likely to be spam" indicator as far as network prediction is concerned. End-user would see a visual indicator if the indicator is present. Anything more than that is just "information overdose" IMHO and wouldn't have much practical value for an average user. Another indicator stating "calling identity can't be verified" could be useful but this IMHO is something different.

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

From: sipcore [mailto:[e-mail]] On Behalf Of Henning Schulzrinne
Sent: Tuesday, July 18, 2017 3:51 PM
To: [e-mail]
Subject: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities


I'm finally addressing Christer's helpful comments in



https://www.ietf.org/mail-archive/web/sipcore/current/msg07851.html



and have submitted a new draft.



Christer noted that I used the term "SIP entities" several times. What I meant to say is "SIP proxies and B2BUAs that face the [end customer] user agent and are associated with a registrar" (as opposed to some random SBC in the core of the network). After all, only those elements should remove any untrusted call-info information in this case. If there's a better way than the current short-hand "SIP proxy or B2BUA", I'll gladly take suggestions.



I think I addressed all the comments pending, but if I missed anything, please remind me. Otherwise, this should be ready.



Henning