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

From: Eric Burger <[email-masked]>
Date: Wed, 4 Jul 2018 14:31:21 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 4 Jul 2018 15:19:44 -0400

Eric,

> 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 e…

I quickly read over this draft. It seems in pretty good shape to me. I 
did notice one terminology issue:

The following in section 3:

    A SIP User Agent Server (UAS) MAY issue the 608 code in a failure
    response for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog
    SIP [RFC3261] request to indicate that an intermediary rejected the
    offered communication as unwanted by the user.  A UAS, particularly
    in a back-to-back user agent or proxy MAY issue the 608 as the value
    of the "cause" parameter of a SIP reason-value in a Reason header
    field [RFC3326].

This is conflating UAS and Proxy. Specifically:

    A UAS, particularly in a back-to-back user agent or proxy MAY ...

A UAS isn't "in" a proxy. Proxies and UAs are different animals, even 
though B2BUAs often act much like proxies. I suggest instead:

    An intermediary (proxy or B2BUA) MAY ...

	Thanks,
	Paul

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 4 Jul 2018 20:26:48 +0000

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 <[email-masked]> On Behalf Of Eric Burger
> Sent: Wednesday, July 4, 2018 2:31 PM
> To: [email-masked]; [email-masked]
> 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.
>

---

From: Eric Burger <[email-masked]>
Date: Wed, 4 Jul 2018 18:02:21 -0400

Good catch! Easy to fix. Thanks.

> On Jul 4, 2018, at 3:19 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Eric,
> 
> I quickly read over this draft. It seems in pretty good shape to me. I did notice one terminology issue:
> 
> A UAS isn't "in" a proxy. Proxies and UAs are different animals, even though B2BUAs often act much like proxies. I suggest instead:
>

---

From: Eric Burger <[email-masked]>
Date: Wed, 4 Jul 2018 18:10:19 -0400

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 <[email-masked]> wrote:
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 8 Jul 2018 07:56:00 +0000

Hi Eric,

Inline...

Thanks,
Tolga

From: Eric Burger <[email-masked]> 
Sent: Wednesday, July 4, 2018 6:10 PM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked]
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?".

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.

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:[email-masked]> wrote:

Thanks,
Tolga

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

- Eric

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Jul 2018 08:00:56 +0000

Hi,

I have a few comments on the draft. Nothing technical, but issues where I
think some additional text might be needed.

Q1:

The introduction says:

"This document describes a new SIP response code, 608, which allows
   calling parties to learn their call was rejected by an intermediary."

That seems like 608 can be used by an intermediary for whatever reason.
However, the rest of the document talks about more specific use-cases
where 608 is used. If 608 is to be used only for specific use-cases, I
think you should e.g., enhance the sentence above and describe that.

Q2:

An out-of-dialog request may reach the called user using different paths
(due to Outbound, forking etc), which means different requests may
traverse different intermediaries. I think it would be good to have some
consideration/guidance text regarding that.

Q3:

Section 3 says:

"Unless there are indicators the calling party will use the contents
   of the Call-Info header for malicious purposes (see Section 6), if a
   UAS issues a 608 code, the UAS MUST include a Call-Info header in the
   response.²

Elsewhere in the document you talk about intermediaries sending the 608.
While an intermediary obviously implement the UAS role, I think you should
have consistent terminology.

Q4:

Section 3 says:

"UACs MUST be prepared to receive a full vCard.²

You should clarify that this applies to UACs supporting the 608 code.

Regards,

Christer

On 04/07/18 22:19, "sipcore on behalf of Paul Kyzivat"
<[email-masked] on behalf of [email-masked]> wrote:

>> 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.
>
>>flames, and +1¹s to the SIPCORE list.
>> 
>>

---

From: Eric Burger <[email-masked]>
Date: Tue, 10 Jul 2018 14:20:50 -0400

How backwards compatible do we need to be? I am of two minds here. The purist in me says we need to make sure we have a great user experience for people placing calls from all existing PSTN nodes. I am doing the research now on how many carriers are still connected to the PSTN using FG-D or other R2, non-digital modes. So, that would indicate a mechanism like the below, where a 608-aware UAC sends their INVITE with a sip.608 capability. Intermediaries that would reject the call that did not also receive a sip.608 capability would play an intercept along with the 608, whilst INVITES with the sip.608 capability just get the 608.

The pragmatist in me says that most legitimate callers are or shortly will be using native SIP to place calls, or are using carriers that use SIP. What this means is legitimate bulk callers will be able to handle 608 natively or their carrier will be able to generate an announcement. In this scenario, if you are a legitimate bulk caller with a FG-D interconnect, you will only get fast busy.

Is it OK to say “Oh Well” for the latter bulk caller case? Do we need to complicate the protocol to support 30+ year old networks?

If you are a residential consumer, presumably your local carrier will know what to do with 608. The average residential consumer will have no clue what to do, whether via data or an announcement.

> From: Eric Burger <[email-masked] <mailto:[email-masked]>>
> [snip]

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 10 Jul 2018 18:49:05 +0000

I hadn’t planned to chime in, but I had the same concern about what non-supporting SIP UAS will do.  There are will continue to be large quantities of non-supporting elements.  For example, many carriers operate large quantities of older softswitches, SBCs, IVRs, et cetera, where new development is extremely limited or no longer occurs.  And that’s just carriers and their platforms and says nothing of older enterprise and user equipment which is no longer supported and cannot be upgraded.  But, if you ask Customer Care or Operations organizations, “Do we need to complicate the protocol to support 30+ year old networks?” you may get a surprising quantity of affirmative responses.

I’m not saying don’t move forward with 608 as is, although Tolga’s feature tag during registration suggestion was interesting.

I assume the masses of non-compliant systems will simply interpret the 608 message as a 6xx system error.  6xx as a class has had surprisingly unfortunate interpretations too, but your point about questioning support for old networks is valid.

Pierce

From: sipcore [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Tuesday, July 10, 2018 1:21 PM
To: [email-masked]
Subject: [sipcore] Rejected Result Code: How backwards compatible?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Jul 8, 2018, at 3:56 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

From: Eric Burger <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 4, 2018 6:10 PM
Subject: Re: [sipcore] Rejected Result Code (middle box version of Unwanted)

[snip]

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 11 Jul 2018 16:58:25 +0000

My motivation for backward compatibility is not for the sake of purism but for practical reasons: I think using network based blocking may be disallowed for certain cases if backward compatibility is not addressed properly.

Scenario:
Jurisdiction mandates that an indication needs to be provided to all/any UAC if the call is blocked by network.
Not all UACs support 608
No procedures/guidance are defined to provide “call blocked by network indication” for UACs not supporting 608
==> Call blocking by network not allowed

Thanks,
Tolga

From: sipcore <[email-masked]> On Behalf Of Gorman, Pierce A [CTO]
Sent: Tuesday, July 10, 2018 2:49 PM
To: Eric Burger <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Rejected Result Code: How backwards compatible?

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Pierce

From: sipcore [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Tuesday, July 10, 2018 1:21 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] Rejected Result Code: How backwards compatible?

[snip]