Subject: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00

From: Russ Penar <[email-masked]>
Date: Sat, 13 Jun 2020 00:01:31 +0000

Based on early feedback, I updated the name and proposed code number.
Please review the newly named draft, I welcome everyone's perspective, thank you!

https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/

From: Russ Penar
Sent: Friday, June 12, 2020 2:55 PM
To: [email-masked]' <[email-masked]>
Subject: please review and comment on draft-penar-ietf-sipcore

Hi All,
Please take a look at my proposed draft regarding a 1xx message letting caller know their call is rated poorly/ambiguously.
One early feedback is 184 may be too close to progress messages associated with ringback, and I'd love to get more perspectives.
https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/
Best regards,
Russ

---

From: Cary FitzGerald <[email-masked]>
Date: Sun, 14 Jun 2020 12:42:19 -0700

I’m not a fan of the use case.  Sharing details about per-call spam ratings with potential spammers seems unwise.

In the real world, calls marked “spam likely” that come to my phone are answered by voice mail.  Most spammers won’t even bother with the airtime to leave a message.  The pharmacy from the introduction would do that, presumably.  It’s unlikely they’d do more in order to reach a single callee.  Fixing large scale problems (inter-SP) is larger problem.

This mechanism is value-neutral:  legitimate callers are not distinguishable from bad actors.  Bad actors *might* abandon the field if they see they are marked as spam, or they might try to adjust their attack to lower their scores.  I can’t think of a similar mechanism for email beyond managing one’s reputation.

Fixing the analytics SP’s logic for legitimate caller would certainly include the caller's assertion of identity.  I see a conceptual difference between STIR and this approach, but I’m not sure I see a significant advantage to making the assertion after the fact.

The most obvious metric for an "analytics service provider” is reputation and identity is the key.  Asking out of ignorance, are there market-driven requirements calling for something more?

Cary.

> On Jun 12, 2020, at 5:01 PM, Russ Penar <russp=[email-masked]> wrote:
> 
> Please review the newly named draft, I welcome everyone’s perspective, thank you!
>  
> https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/ <https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/>
>  
> From: Russ Penar 
> To: [email-masked] <mailto:[email-masked]>' <[email-masked] <mailto:[email-masked]>>
> One early feedback is 184 may be too close to progress messages associated with ringback, and I’d love to get more perspectives.
> https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/ <https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/>
> Best regards,
> Russ
> _______________________________________________
> sipcore mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 14 Jun 2020 20:25:32 -0400

I don't know of this question is related to this draft, but reading
about this draft brings it to mind:  It seems like an ideal system would
allow the potentially-spam caller A to put some sort of token in the
INVITE which would be recorded with the voicemail message to the callee
B.  Then if B wanted to contact A, B could send an INVITE that includes
the token, thus allowing A to process B's call as a continuation of the
original call.  Similarly, B's call-back could include a token that A
could attach to future INVITEs to B as evidence that the call was
approved by B and thus avoid being spam-filtered.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Jun 2020 08:40:35 +0000

Hi,

If needed, why can't the called party proxy forward the call to an announcement server, instead of relying on the fact that there is an SBC somewhere that supports the mechanism and is able to play the announcement?

Regards,

Christer

From: sipcore <[email-masked]> On Behalf Of Russ Penar
Sent: lauantai 13. kesäkuuta 2020 3.02
To: [email-masked]
Subject: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00

https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/<https://protect2.fireeye.com/v1/url?k=4dcf1ee2-136fdd4b-4dcf5e79-86959e472243-cd907fc35f62598e&q=1&e=69e944ee-aaf7-4ef4-b29e-8686b9f94a10&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-penar-sipcore-ratingprovided%2F>

From: Russ Penar
Sent: Friday, June 12, 2020 2:55 PM
To: [email-masked]' <[email-masked]<mailto:[email-masked]>>
Subject: please review and comment on draft-penar-ietf-sipcore

Hi All,
Please take a look at my proposed draft regarding a 1xx message letting caller know their call is rated poorly/ambiguously.
One early feedback is 184 may be too close to progress messages associated with ringback, and I'd love to get more perspectives.
https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/<https://protect2.fireeye.com/v1/url?k=68873da9-3627fe00-68877d32-86959e472243-560669ce1d9831c4&q=1&e=69e944ee-aaf7-4ef4-b29e-8686b9f94a10&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-penar-ietf-sipcore%2F>
Best regards,
Russ

---

From: Russ Penar <[email-masked]>
Date: Mon, 15 Jun 2020 12:46:17 +0000

Hi Christer,

I'm reconsidering the announcement idea, I'm not sure it makes sense outside of a failure context.
Given there's no failure, caller either gets no answer and cancels the request or reaches voicemail/announcement.

What do you think?

Best regards,
Russ

From: Christer Holmberg <christer.holmberg=[email-masked]>
Sent: Monday, June 15, 2020 1:41 AM
To: Russ Penar <[email-masked]>; [email-masked]
Subject: [EXTERNAL] RE: please review and comment on draft-penar-sipcore-ratingprovided-00

Hi,

Regards,

Christer

From: sipcore <[email-masked]<mailto:[email-masked]>> On Behalf Of Russ Penar
Sent: lauantai 13. kesäkuuta 2020 3.02
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00

https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D4dcf1ee2-136fdd4b-4dcf5e79-86959e472243-cd907fc35f62598e%26q%3D1%26e%3D69e944ee-aaf7-4ef4-b29e-8686b9f94a10%26u%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-penar-sipcore-ratingprovided%252F&data=02%7C01%7Crussp%40microsoft.com%7C3b7369ecdac64865c16108d81107cbbf%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637278072470272980&sdata=1IsyxDOhQ2mT2mGxezLlvusMkVRJFhyn7H%2BW2t6E3oc%3D&reserved=0>

From: Russ Penar

Hi All,
Please take a look at my proposed draft regarding a 1xx message letting caller know their call is rated poorly/ambiguously.
One early feedback is 184 may be too close to progress messages associated with ringback, and I'd love to get more perspectives.
https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D68873da9-3627fe00-68877d32-86959e472243-560669ce1d9831c4%26q%3D1%26e%3D69e944ee-aaf7-4ef4-b29e-8686b9f94a10%26u%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-penar-ietf-sipcore%252F&data=02%7C01%7Crussp%40microsoft.com%7C3b7369ecdac64865c16108d81107cbbf%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637278072470272980&sdata=XFpSoX7ZebaGNB6eVYsg7L18Ug0hJ4iE5J0TSPwgqtA%3D&reserved=0>
Best regards,
Russ

---

From: Russ Penar <[email-masked]>
Date: Tue, 16 Jun 2020 23:29:05 +0000

Thank you for sharing the perspective Cary,

I think the additional observability and awareness of remediation ‘front door’ is worth the risk of spammers using the mechanism to tune their attacks.

I envision the mechanism being used by originating service providers as signal for problematic calling corridors or newly ported numbers or value-add ‘protection’ service for large call center customers, as a few examples.

The end result should be improved analytics, improved throughput of wanted calls, and better user experience.

When FCC asked for public comment on mislabeled calls, multiple voice providers and industry associations complained saying the issue needs addressed.  One solution may be to impose liability on terminating carrier for performance/accuracy of analytics used when delivering calls.  Perhaps the proposed per-call mechanism would allow FCC to avoid such an approach?

Best regards,
Russ

From: sipcore <[email-masked]> On Behalf Of Cary FitzGerald
Sent: Sunday, June 14, 2020 12:42 PM
To: Russ Penar <russp=[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00

Cary.

On Jun 12, 2020, at 5:01 PM, Russ Penar <russp=[email-masked]<mailto:russp=[email-masked]>> wrote:

https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-penar-sipcore-ratingprovided%2F&data=02%7C01%7Crussp%40microsoft.com%7Cbff156482d394e0afafa08d8109b0c3c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637277605401696697&sdata=3jOQCdQanbv4Ebwh9ltK1kJpt8XxCwyu1PGc%2BLO9Tiw%3D&reserved=0>

From: Russ Penar
Sent: Friday, June 12, 2020 2:55 PM
To: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>
Subject: please review and comment on draft-penar-ietf-sipcore

Hi All,
Please take a look at my proposed draft regarding a 1xx message letting caller know their call is rated poorly/ambiguously.
One early feedback is 184 may be too close to progress messages associated with ringback, and I’d love to get more perspectives.
https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-penar-ietf-sipcore%2F&data=02%7C01%7Crussp%40microsoft.com%7Cbff156482d394e0afafa08d8109b0c3c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637277605401696697&sdata=EFC66LXtulP2V1IlMbc%2BeHhgDfYgndZlWlypiYWypuc%3D&reserved=0>
Best regards,
Russ
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=02%7C01%7Crussp%40microsoft.com%7Cbff156482d394e0afafa08d8109b0c3c%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637277605401696697&sdata=nXwS4EuRRjS9rgkJuwEwRjVujmoqcVpZlv3HcBgh1VQ%3D&reserved=0>

---

From: Russ Penar <[email-masked]>
Date: Tue, 16 Jun 2020 23:51:28 +0000

That is an interesting idea Dale thank you,  

The spirit of my proposal is something to help out specifically in the current call analytics environment, and is hopefully lightweight to implement.  That said, as I read through your email a couple questions came to mind.

".. token in the INVITE which would be recorded with the voicemail message to the callee B."

Should there be any assumption about unanswered calls 'always' going to voicemail?  Perhaps its an exception case, but curious on folks' perspective on the assumption. 

"...B's call-back could include a token that A could attach to future INVITEs to B as evidence that the call was approved by B and thus avoid being spam-filtered."

Assuming there are many one-way calling relationships would storage/search requirements for the tokens eventually outweigh the benefit?

Best regards,
Russ

-----Original Message-----
From: sipcore <[email-masked]> On Behalf Of Dale R. Worley
Sent: Sunday, June 14, 2020 5:26 PM
To: [email-masked]
Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-sipcore-ratingprovided-00

I don't know of this question is related to this draft, but reading about this draft brings it to mind:  It seems like an ideal system would allow the potentially-spam caller A to put some sort of token in the INVITE which would be recorded with the voicemail message to the callee B.  Then if B wanted to contact A, B could send an INVITE that includes the token, thus allowing A to process B's call as a continuation of the original call.  Similarly, B's call-back could include a token that A could attach to future INVITEs to B as evidence that the call was approved by B and thus avoid being spam-filtered.

Dale

_______________________________________________
sipcore mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&amp;data=02%7C01%7Crussp%40microsoft.com%7C13a9320a54304ae3094c08d810c2a591%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637277775480546881&amp;sdata=06yb8PXAxBL1jja6QM2P67vV6m5V7VcjYzxonGo6uS4%3D&amp;reserved=0

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 16 Jun 2020 21:50:45 -0400

Russ Penar <russp=[email-masked]> writes:
> Assuming there are many one-way calling relationships would
> storage/search requirements for the tokens eventually outweigh the
> benefit?

I think that storage would not be a problem, because in many cases
tokens would not need to be stored.  There is a trick which has been
used in varous situations (and proposed in many SIP scenarios) where
some sort of token is generated by some device that contains within the
token a signature that attests that it was generated by that device.  If
a message is presented to the device that has a purported token, the
device can verify the signature, rather than having to have a record of
the tokens it has generated.

For example, in this case, the callee could have a secret, large random
string, and the token is the hash of the caller's From URI and the
random string.  The callee can give the token to the caller, and later
the callee can verify that the token was the one it generated for this
particular caller.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jun 2020 22:28:38 -0400

> Should there be any assumption about unanswered calls 'always' going to voicemail?  Perhaps its an exception case, but curious on folks' perspective on the assumption.

I think there are all variety of ways that people handle unanswered 
calls, even if the default for most service providers is voicemail. And 
in any case there are *many* people who have full mailboxes and so don't 
have additional calls recorded.

So I don't think you should assume you can count of voicemail to deliver 
an announcement.

(Nor do I think there is any obligation to deliver announcements to 
callers who have not made any effort to learn of them.)

	Thanks,
	Paul

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 17 Jun 2020 15:36:57 +0600

In India no Cell provider provides voice mail services. An
announcement is provided "Callee is not answering." and call is
disconnected.
ThanksSamir

On 6/17/2020 at 5:21 AM, "Russ Penar"  wrote:That is an interesting
idea Dale thank you,  

The spirit of my proposal is something to help out specifically in the
current call analytics environment, and is hopefully lightweight to
implement.  That said, as I read through your email a couple questions
came to mind.

".. token in the INVITE which would be recorded with the voicemail
message to the callee B."

Should there be any assumption about unanswered calls 'always' going
to voicemail?  Perhaps its an exception case, but curious on folks'
perspective on the assumption. 

"...B's call-back could include a token that A could attach to future
INVITEs to B as evidence that the call was approved by B and thus
avoid being spam-filtered."

Best regards,
Russ

-----Original Message-----
From: sipcore  On Behalf Of Dale R. Worley
Sent: Sunday, June 14, 2020 5:26 PM
To: [email-masked]
Subject: [EXTERNAL] Re: [sipcore] please review and comment on
draft-penar-sipcore-ratingprovided-00

I don't know of this question is related to this draft, but reading
about this draft brings it to mind:  It seems like an ideal system
would allow the potentially-spam caller A to put some sort of token in
the INVITE which would be recorded with the voicemail message to the
callee B.  Then if B wanted to contact A, B could send an INVITE that
includes the token, thus allowing A to process B's call as a
continuation of the original call.  Similarly, B's call-back could
include a token that A could attach to future INVITEs to B as evidence
that the call was approved by B and thus avoid being spam-filtered.

Dale

_______________________________________________
sipcore mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=02%7C01%7Crussp%40microsoft.com%7C13a9320a54304ae3094c08d810c2a591%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637277775480546881&sdata=06yb8PXAxBL1jja6QM2P67vV6m5V7VcjYzxonGo6uS4%3D&reserved=0

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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Jun 2020 05:41:37 +0000

Hi,

>Given there's no failure, caller either gets no answer and cancels the request or reaches voicemail/announcement.

Something like that, I guess.

The called party proxy can choose to do whatever with a call that has been "badly rated", including forwarding it to an announcement server.

Regards,

Christer

From: Christer Holmberg <christer.holmberg=[email-masked]<mailto:christer.holmberg=[email-masked]>>
Sent: Monday, June 15, 2020 1:41 AM
To: Russ Penar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] RE: please review and comment on draft-penar-sipcore-ratingprovided-00

Hi,

Regards,

Christer

https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/<https://protect2.fireeye.com/v1/url?k=85bbdace-db1b7403-85bb9a55-86073b36ea28-276fd8d74e946245&q=1&e=326fc7a1-8bf6-4ffb-a2d2-d61bbe26d25f&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fprotect2.fireeye.com%252Fv1%252Furl%253Fk%253D4dcf1ee2-136fdd4b-4dcf5e79-86959e472243-cd907fc35f62598e%2526q%253D1%2526e%253D69e944ee-aaf7-4ef4-b29e-8686b9f94a10%2526u%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fdraft-penar-sipcore-ratingprovided%25252F%26data%3D02%257C01%257Crussp%2540microsoft.com%257C3b7369ecdac64865c16108d81107cbbf%257C72f988bf86f141af91ab2d7cd011db47%257C0%257C0%257C637278072470272980%26sdata%3D1IsyxDOhQ2mT2mGxezLlvusMkVRJFhyn7H%252BW2t6E3oc%253D%26reserved%3D0>

From: Russ Penar

Hi All,
Please take a look at my proposed draft regarding a 1xx message letting caller know their call is rated poorly/ambiguously.
One early feedback is 184 may be too close to progress messages associated with ringback, and I'd love to get more perspectives.
https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/<https://nam06..safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D68873da9-3627fe00-68877d32-86959e472243-560669ce1d9831c4%26q%3D1%26e%3D69e944ee-aaf7-4ef4-b29e-8686b9f94a10%26u%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-penar-ietf-sipcore%252F&data=02%7C01%7Crussp%40microsoft.com%7C3b7369ecdac64865c16108d81107cbbf%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637278072470272980&sdata=XFpSoX7ZebaGNB6eVYsg7L18Ug0hJ4iE5J0TSPwgqtA%3D&reserved=0>
Best regards,
Russ