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

[Eric Burger <[e-mail]>]

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.

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?

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?


> On Jul 4, 2018, at 4:26 PM, Asveren, Tolga <[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 <[e-mail]> On Behalf Of Eric Burger
>> Sent: Wednesday, July 4, 2018 2:31 PM
>> To: [e-mail]; [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