Re: [sipcore] Rejected Result Code (middle box version of Unwanted)

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

Hi Eric,

Inline...

Thanks,
Tolga

From: Eric Burger <[e-mail]> 
Sent: Wednesday, July 4, 2018 6:10 PM
To: Asveren, Tolga <[e-mail]>
Cc: [e-mail]
Subject: Re: [sipcore] Rejected Result Code (middle box version of Unwanted)

In this call flow, the (target) UAC never gets the call. The proxy or B2BUA, before routing the call to the (target) UAC asks the analytics engine what to do with the call request. The analytics engine is what determines the call is likely to be illegal or strongly unwanted, as illegal clearly is jurisdiction-dependent.
[TOLGA] I think you meant UAS and mea culpa for the typo in my original message. It should have been UAS indicating "illegal". I agree that this is something in the domain of RFC8197 but is not defined yet AFAICS. So, my question was "Should "illegal" be mentioned considering that currently UAS has no way of signaling it?".



How human users mark something as likely illegal (or strongly unwanted) is a 607 thing and out of scope for Rejected.

It is unlikely for there to be a human sitting on the (originating) UAC. One could imagine (hint) that a SIP UI would display something. One could also imagine (hint) that if you pop out of SIP world, like you go through a gateway into a Feature Group-D network, someone will play an intercept like “Rejected by network; contact mumble-foo if you think this is in error.” That all said, should we be proposing something in this draft, or should that be an exercise for the reader or regulator?
[TOLGA] I am not sure whether we can assume that no human is the actual user on UAC. It could be that their AoR is blacklisted mistakenly or maybe even as a result of an attack which spoofed their AoR (I think we will continue to have some Robocall DBs based on, at least partially, on non-STIR verified originating AoRs for some time). So, IMHO it is imperative that an indication is provided to UAS even if it doesn’t support this new response code. An announcement seems the most likely approach to me.
This brings up another issue though:
Support for 608 should be indicated by a feature tag during registration
Originating network can play announcement if feature tag is not used and 608 is received
What would happen if originating network doesn’t support 608 either? Rejecting element in the terminating network wouldn’t know that UAC/Originating-Network don’t support 608 and therefore can’t play announcement. And always playing announcement does not seem like a good idea as it would be redundant/annoying if 608 is supported.



Note that one might imagine in most jurisdictions, the complaints won’t be going to the regulator but to the intermediary. There are existing mechanisms for callers unfairly being blocked to contact their regulator.

With this all said, do you or anyone else think I need to put some more language in the draft to make it clear who is saying what to whom, when?
[TOLGA] IMHO we should have  some text/explanation/suggestions in the draft for this issue.




On Jul 4, 2018, at 4:26 PM, Asveren, Tolga <mailto:[e-mail]> wrote:

A few questions after a quick read:

i- How can the UAC indicate that the call is "illegal" (v.s. "unwanted" which is signaled with 607)? Is the assumption that this would be conveyed by "out of band" mechanisms, e.g. through a web portal?

ii- Shouldn’t the case of non-supporting UACs be considered, somehow, if conveying "blocked by the network intermediary" is mandated by regulation/jurisdiction?  

iii- "Upon receiving a 608 response, UACs perform normal processing for 6xx responses."
It may be valuable to mention that 608 should ideally cause an indication to be rendered to the UAC enduser (the human). This indication probably should include also some instructions, e.g. where/how to contact relevant authorities. Otherwise, how can he be aware of the situation and file a complaint if the call is blocked as a result of a false positive?

Thanks,
Tolga


-----Original Message-----
From: sipcore <mailto:[e-mail]> On Behalf Of Eric Burger
Sent: Wednesday, July 4, 2018 2:31 PM
To: mailto:[e-mail]; mailto:[e-mail]
Subject: [sipcore] Rejected Result Code (middle box version of Unwanted)

Apologies for posting late - I’ll get these into the ID system when it opens
again on the 14th.  In the mean time, for your reading pleasure is a draft that
describes a protocol mechanism that is excruciatingly similar to Unwanted
(607), but different enough that it needs its own result code.

I am cross-posting to the STIR list because STIR folks will be the most
interested in this code. However, for sanity please keep the discussion,
flames, and +1’s to the SIPCORE list.

https://standardstrack.com/ietf/stir/draft-burger-sipcore-rejected-00.txt
https://standardstrack.com/ietf/stir/draft-burger-sipcore-rejected-00.html
https://standardstrack.com/ietf/stir/draft-burger-sipcore-rejected-00.pdf

Thanks, and I hope to make it to Montréal this time.

- Eric