Subject: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts)

From: Anton Tveretin <[email-masked]>
Date: Thu, 06 Oct 2016 16:25:41 +0500

Hello Dale, Henning, and all,
First, I do not agree with draft-worley-6xx-considered-harmful approach. I think that callee should be able to report either "fail this call", or "deflect this call to... with reason given", or "Fail, but I don't care if the call is deflected". To indicate "rejected by user", we have 603. 3GPP defines 403 as equivalent to 603; not in RFCs. RFC 3261 has a good example of this.
But "spam" means something more than just an undesired call; it suggests that other users would consider the same call undesired.
Second, IIRC 6xx codes are not valid for Reason:; only 4xx and 5xx are. So, we still need a 4xx code. In practice, it seems that 5xx codes are not used, see the example above (Decline), where the condition is clearly UAS-side.
Regards,
Anton.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 6 Oct 2016 12:45:07 +0000

I don't see the Reason restriction you mention. Indeed, RFC 3326 has an example that seems to contradict that contention:

Reason: SIP ;cause=600 ;text="Busy Everywhere"

Henning

________________________________
From: Anton Tveretin <[email-masked]>
Sent: Thursday, October 6, 2016 7:25 AM
To: Henning Schulzrinne; Dale R.Worley
Cc: DISPATCH list
Subject: 4xx vs 6xx (was Re: Two new VoIP spam drafts)

---

From: Brett Tate <[email-masked]>
Date: Thu, 6 Oct 2016 08:55:42 -0400

RFC 3326 section 2 also indicates “Any SIP status code MAY appear in the
Reason header field of a request”.

*From:* dispatch [mailto:[email-masked]] *On Behalf Of *Henning
Schulzrinne
*Sent:* Thursday, October 06, 2016 8:45 AM
*To:* Anton Tveretin
*Cc:* DISPATCH list
*Subject:* Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts)

I don't see the Reason restriction you mention. Indeed, RFC 3326 has an
example that seems to contradict that contention:

Henning
------------------------------

*From:* Anton Tveretin <[email-masked]>
*Sent:* Thursday, October 6, 2016 7:25 AM
*To:* Henning Schulzrinne; Dale R.Worley
*Cc:* DISPATCH list
*Subject:* 4xx vs 6xx (was Re: Two new VoIP spam drafts)

Hello Dale, Henning, and all,
First, I do not agree with draft-worley-6xx-considered-harmful approach. I
think that callee should be able to report either "fail this call", or
"deflect this call to... with reason given", or "Fail, but I don't care if
the call is deflected". To indicate "rejected by user", we have 603. 3GPP
defines 403 as equivalent to 603; not in RFCs. RFC 3261 has a good example
of this.
But "spam" means something more than just an undesired call; it suggests
that other users would consider the same call undesired.
Second, IIRC 6xx codes are not valid for Reason:; only 4xx and 5xx are. So,
we still need a 4xx code. In practice, it seems that 5xx codes are not
used, see the example above (Decline), where the condition is clearly
UAS-side.
Regards,
Anton.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 6 Oct 2016 17:48:11 +0000

I like the idea of a unique non-overloaded code point that 

can be used to drive some peg-counts or big data analysis of calls 

to highlight the numbers and rates in real-time, so that 

systems could proactively tag next calls to say to called user 

that this next call had 100,000 users saying it was a robo-call.

Michael Hammer

[email-masked] <mailto:[email-masked]> 

+1 408 202 9291

© 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality notice. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

From: dispatch [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: Thursday, October 06, 2016 8:56 AM
To: Henning Schulzrinne <[email-masked]>; Anton Tveretin <[email-masked]>; DISPATCH list <[email-masked]>
Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts)

RFC 3326 section 2 also indicates “Any SIP status code MAY appear in the Reason header field of a request”.

From: dispatch [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Henning Schulzrinne
Sent: Thursday, October 06, 2016 8:45 AM
To: Anton Tveretin
Cc: DISPATCH list
Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts)

Henning

  _____  

From: Anton Tveretin <[email-masked] <mailto:[email-masked]> >
Sent: Thursday, October 6, 2016 7:25 AM
To: Henning Schulzrinne; Dale R.Worley
Cc: DISPATCH list
Subject: 4xx vs 6xx (was Re: Two new VoIP spam drafts)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 6 Oct 2016 14:33:32 -0400

> that this next call had 100,000 users saying it was a robo-call.

This would be nice. But it depends on more than a unique response code. 
It also needs for users to only use that code for the semantic you want 
to tag it with. This depends as much on the UI provided to users as it 
does on the existence of the code(s).

Of necessity the UI will be simple, with few choices for how to reject a 
call. (I guess one or possibly two.) Those can then be mapped to 
particular response codes. But it will be hard to get users to use those 
buttons for precisely the semantics we want to ascribe to the codes. (Do 
we we want the button to mean "unwanted robo-call", "call from undesired 
caller", "objectionable call content", or what?)

Even though the IETF doesn't "do" UIs, it might be better to discuss the 
likely UI before fully defining the code(s).

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 6 Oct 2016 18:46:32 +0000

Without getting into UI engineering, the email spam experience may be helpful. From what I can tell, most email clients have a single "spam" button, without any categorization, and that seems to work reasonably well. It does tend to conflate, for email, the reaction to offers by Nigerian princes with email where the receiver does not remember that they signed up for (or just fat-fingered). Since this is a statistical measure, a bit of noise seems tolerable.

________________________________
From: dispatch <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Thursday, October 6, 2016 2:33 PM
To: [email-masked]
Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts)

        Thanks,
        Paul

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

---

From: <[email-masked]>
Date: Thu, 6 Oct 2016 20:21:10 +0000

Hello Anton,

I would like to correct the fact that in 3GPP 403 is not equivalent to 603. When you have a barring service, it is a 603 response that is sent to the calling party and never a 403.
The Reason header defines a protocol value and once you are using one protocol value, you can use any value created by this protocol.
In RFC3326 it is mentioned "SIP: The cause parameter contains a SIP status code."

BR,
Marianne

-----Message d'origine-----
De : dispatch [mailto:[email-masked]] De la part de Anton Tveretin
Envoyé : jeudi 6 octobre 2016 13:26
À : Henning Schulzrinne; Dale R.Worley
Cc : DISPATCH list
Objet : [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Michael Hammer <[email-masked]>
Date: Fri, 7 Oct 2016 15:33:01 +0000

Paul,

Understand.  But, this is chicken or egg issue.
An app developer can't do the UI without the protocol element to make it
useful.

Agree with thought that a single "spam" button may be enough of an
indicator.
Operator would have to decide at what statistical level to start tagging new
calls with "possible spam" label.

________________________________
Michael Hammer
[email-masked]
+1 408 202 9291

© 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality
notice. This message is private and confidential. If you have received this
message in error, please notify us and remove it from your system.

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, October 06, 2016 2:34 PM
To: [email-masked]
Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts)

This would be nice. But it depends on more than a unique response code. 
It also needs for users to only use that code for the semantic you want to
tag it with. This depends as much on the UI provided to users as it does on
the existence of the code(s).

Of necessity the UI will be simple, with few choices for how to reject a
call. (I guess one or possibly two.) Those can then be mapped to particular
response codes. But it will be hard to get users to use those buttons for
precisely the semantics we want to ascribe to the codes. (Do we we want the
button to mean "unwanted robo-call", "call from undesired caller",
"objectionable call content", or what?)

	Thanks,
	Paul

---

From: Richard Shockey <[email-masked]>
Date: Fri, 07 Oct 2016 15:18:38 -0400

Right .. and if you want to see some preliminary thinking on what a UI might look like you can look at this.

http://www.nanc-chair.org/docs/mtg_docs/Sep16_Robocall_Spoofing_Concepts.pdf

I can assure you that there is a whole mob starting to zero in on the UI issue. 

Trending Film at 11. 

We need the protocol element.  The STIR/SHAKEN construct is useless without consumer signaling.  Some of us have been kicking around similar ideas in the back channel for months.

I totally support adoption of Henning’s drafts.  Hopefully there is consensus that we don’t need a new WG for this.  I do NOT support a new WG.  The need is so critical and the potential for immediate adoption is so great we need to move this along perhaps in some other way.  

Personally I’m totally in favor of 666.  I thought that might work for a proposed Psuedo-ANI code for identifying international call gateways.

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

On 10/7/16, 11:33 AM, "dispatch on behalf of Michael Hammer" <[email-masked] on behalf of [email-masked]> wrote:

    Paul,

    

    -----Original Message-----
    From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
    Sent: Thursday, October 06, 2016 2:34 PM
    To: [email-masked]
    Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts)

    

    	Thanks,
    	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 7 Oct 2016 16:32:54 -0400

> We need the protocol element.  The STIR/SHAKEN construct is useless without consumer signaling.  Some of us have been kicking around similar ideas in the back channel for months.

I agree - one is needed. The problem will arise if the meaning implied 
by the UI is different from the meaning specified for the response code. 
Most people don't read a user guide, much less an RFC, to learn the 
meaning of a UI element. They intuit the meaning, or have it informally 
explained to them by somebody. So the intuitive meaning had better align 
with the response code. That may mean we have to define the code point 
while waffling on its precise semantics.

	Thanks,
	Paul

---

From: Richard Shockey <[email-masked]>
Date: Fri, 07 Oct 2016 17:04:10 -0400

RS>  I totally understand but we are not the protocol police much less the UI police.  If we define the response code precisely then we simply have to trust the UE to respond correctly.  Plus some of the current thinking is Validated might be could be commonly represented within the industry as a green check but I’m willing to grant the carriers and the PBX vendors some slack on how they might add some value here. This debate is going on right now. What could be industry wide consented in the UE Display vs value add.

That said this had better be damn simple and we can’t try and solve every corner case in the initial deployments.  That is my argument on rings of defense. 

The problem with spoofing and robocalls is that the totality of the problem has made consumers feel helpless and that is not a good thing. I ran across this recently and it is totally appropriate to this context.  

https://www.nist.gov/news-events/news/2016/10/security-fatigue-can-cause-computer-users-feel-hopeless-and-act-recklessly

I’d really like to hear your views on how to rapidly move this concept along.  The IETF does not have a particularly good track record recently on swift and decisive action.  What I can testify to (and recently have) is there is commitment to deploy and a rather unique alignment of industry and regulatory objectives. 

    	Thanks,
    	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 9 Oct 2016 09:58:34 +0000

Couldn’t agree more with the "this is urgently needed" statement. I hope all reasonable concerns can be addressed ASAP and the document can move forward.

Thanks,
Tolga

> From: dispatch [mailto:[email-masked]] On Behalf Of Richard
> Shockey
> Sent: Friday, October 07, 2016 5:04 PM
> To: Paul Kyzivat <[email-masked]>; Michael Hammer
> <[email-masked]>; [email-masked]
>     > http://www.nanc-
> chair.org/docs/mtg_docs/Sep16_Robocall_Spoofing_Concepts.pdf
>     >
>     > We need the protocol element.  The STIR/SHAKEN construct is useless
> without consumer signaling.  Some of us have been kicking around similar
> ideas in the back channel for months.
> 
> RS>  I totally understand but we are not the protocol police much less the UI
> police.  If we define the response code precisely then we simply have to
> trust the UE to respond correctly.  Plus some of the current thinking is
> Validated might be could be commonly represented within the industry as a
> green check but I’m willing to grant the carriers and the PBX vendors some
> slack on how they might add some value here. This debate is going on right
> now. What could be industry wide consented in the UE Display vs value add.
> 
> That said this had better be damn simple and we can’t try and solve every
> corner case in the initial deployments.  That is my argument on rings of
> defense.
> 
> The problem with spoofing and robocalls is that the totality of the problem
> has made consumers feel helpless and that is not a good thing. I ran across
> this recently and it is totally appropriate to this context.
> 
> https://www.nist.gov/news-events/news/2016/10/security-fatigue-can-
> cause-computer-users-feel-hopeless-and-act-recklessly
> 
> 
> I’d really like to hear your views on how to rapidly move this concept along.
> The IETF does not have a particularly good track record recently on swift and
> decisive action.  What I can testify to (and recently have) is there is
> commitment to deploy and a rather unique alignment of industry and
> regulatory objectives.
> 
> 
> 
> 
>     	Thanks,
>     	Paul
> 
>     > I totally support adoption of Henning’s drafts.  Hopefully there is
> consensus that we don’t need a new WG for this.  I do NOT support a new
> WG.  The need is so critical and the potential for immediate adoption is so
> great we need to move this along perhaps in some other way.
>     >
>     > Personally I’m totally in favor of 666.  I thought that might work for a
> proposed Psuedo-ANI code for identifying international call gateways.
>     >
>     >
>     > —
>     > Richard Shockey
>     >
>     > Shockey Consulting LLC
>     >
>     > On 10/7/16, 11:33 AM, "dispatch on behalf of Michael Hammer"
> <[email-masked] on behalf of
> [email-masked]> wrote:
>     >
>     >     Paul,
>     >
> to
> particular