Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Mar 2014 13:19:37 -0500

> I think we should have this be optional.  

I think it should be optional to use/check the received golden-copy (or
whatever we call the copy in the Identity-X header), but not optional to
send it.

Imho, debugging and proof-of-failure is going to be really important, if we
ever hope to actually reject failed call requests.

[RS> ]  This is an excellent point.  I might point out that in various
national regulatory contexts the verification service (aka the terminating
carrier) cannot now drop the call under any circumstances.  This is the law.
The intersection of the STIR method and refinements to NRA regulations will
need sufficient proof the verification method is sound.  This is telephony
and not "the Internet".   It is regulated in every nation state. 

It is increasingly clear that the WG needs to consider two additional
constraints. Can it actually be deployed in contexts where there is a great
deal of SIP already out there?  This goes to Jon points and Hadrial's
rebuttal in the meeting about "Well its shouldn't be too hard to deal with
canonicalization in FROM:"  Ya right. 

And costs.  I'm spending a great deal of time trying to find any reasonable
data on what the theoretical costs of a RPKI mechanism for phone numbers
would look like.  The data is all over the place and if anyone has any hints
and resources they would pass along to me I'd appreciate it. We have some
models out there SIDR certainly, 509 in chip and pin credit cards, HMDI
video interfaces, we know the problems in SSL etc. Certs can go from .01
cent to $200.  

It's one thing to give a cert to the 1500 US carriers or 500 Canadian it's
another thing if this drills down into a requirement that each phone number
be directly signed.  As an exercise in scale I typically use 2.5 times total
population to estimate numbers allocated and available for service so that
generally looks like 700M or so in the US,  120 M or so in the UK  and 90 or
so million for Canada. I agree with Alex that the probable first use case
for STIR is carrier to carrier where the SBC is probably both the
Authentication service at the Originating carrier and Verification Service
at the Terminating carrier.  It is probably easier to support the mechanism
there than at the CSCF.  I just don't see this being deployed directly on
smartphones for the foreseeable future, Cullen may be right and I'm often
wrong but that is what I think. I'd certainly like to see an effort on an
enhanced CNAM display mechanism from the mobile operators and handset
manufacturers first but I'm told 3GPP is looking at this but maybe I'll have
a problem statement ready by Toronto. 

Design decisions drive costs and there are limits on what, I believe, the
global telecom industry or consumers of phone numbers will tolerate.  For
instance I'm not sure some consumers will appreciate a PKI line item on
their phone bills.  There are three moving parts here first the actually
mechanism on the wire and modifications to the SBC here, second the actually
cost of the PKI infrastructure and last but not least the OSS/BSS systems
used in telecom systems worldwide.  Anyone who know what I'm talking about
will realize that that is where the sink hole of money will ultimately fall
into.   The additional cost must be fractional to the existing cost of
National Number administration and above all LNP etc. 

I might point out we are at a relatively unique point here especially with
regards to the underlying national numbering databases.  The PSTN Transition
is forcing  the issue of URI/NS record inclusion and clearly it would be
helpful if the STIR mechanism could be grafted in as well. 

Also effect on post dial delay.  This is not email this is real-time.  The
SIP headers should be renamed the SIP short story since the size is now
roughly similar if History-Info is included.  I just don't know here and in
the immortal words of Donald Rumsfield it's the "unknown unknowns"  that
worry me. 

-hadriel

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

---

From: Michael Hammer <[email-masked]>
Date: Tue, 4 Mar 2014 18:42:30 +0000

Given the computational power of smartphones and the economy  of scale of
smart phones 
[cost=($development+$reasonable profit)/#smartphones) = pennies],
it would be short-sighted to not have Internet-scale solutions as a primary
solution, 
along with network-based legacy-oriented solutions.
Else we are just designing for my grandfather's telephone network, that may
soon be gone.
The longer this goes on, network-based will be the exception not the rule.

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, March 04, 2014 1:20 PM
To: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Tue, 4 Mar 2014 18:43:50 +0000

This is the IETF, and we’re not really into business models.

We do want our work deployed, so we need to believe that it could happen, and thus usually we tolerate a bit of discussion on how it would work.

I personally favor a “peering requirement” model.  Here, a service provider puts a new requirement in its peering relationship agreements that provide a date/percentage goal.  By such-and-such a date, good signed calling party number must be provided for X percent of calls sent.  If the peer can’t meet this requirement, peering won’t be allowed.

This takes at least a regulatory interpretation, maybe more. IANAL.  But a carrier can impose a number of requirements on peering (protocol, number of trunks, …) already.  

The really interesting characteristic of this model is that it’s not real time.  You can run statistics later over the log.

Over time, we’ll certainly want to get to real time checking, but we don’t need to be there to get a whole lot of usefulness.  It doesn’t even take any changes at all in the terminating carrier other than letting the new header through and logging it.  The originating carrier has to put the header on, of course.

We’re all agreeing that the service provider can decide how many certs it has.  The number can range from one per service provider to one per TN.  So, cost per cert is probably meaningless.
We do want to get to a cert on each device.  But we can ease into that too.

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Mar 2014 14:27:02 -0500

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Tuesday, March 04, 2014 1:43 PM
To: [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Given the computational power of smartphones and the economy  of scale of
smart phones [cost=($development+$reasonable profit)/#smartphones) =
pennies], it would be short-sighted to not have Internet-scale solutions as
a primary solution, along with network-based legacy-oriented solutions.

[RS> ] Well we will just have to disagree wont we. If you actually believe
an "internet scale solution" needs to be put in place first before you "run
up the flag" IMHO the effort is doomed to failure.   I seem to recall
another effort at some "internet scale solution" involving telephone
numbers. .. e164.arpa.  I think we know what happened to that.  If you can
apply the solution inside a national carrier network under its CC, which I
think is possible and would have the support of the NRA's then Brian Rosen
may be correct that you can apply some "Forest Guide" for international
traffic.    I just don't understand how you think a "internet scale"
solution would work. Some almighty golden apex run by Geneva?   Oh that's
not going to happen either.  I know everyone hates ATT VZ BT DT etc but they
are a fact of life. 

Else we are just designing for my grandfather's telephone network that may
soon be gone.

[RS> ] Well it's certainly transforming but its not going away and since the
first part of this effort involves real E.164 then there are some
constraints national law tends to impose.  You can talk all you want about
URI based realtime but for now I have not seen SIP:[email-masked] on the
side of any delivery trucks. 

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, March 04, 2014 1:20 PM
To: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Mar 2014 14:59:52 -0500

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Tuesday, March 04, 2014 1:44 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

This is the IETF, and we're not really into business models.

[RS> ] Oh Brian ..please. Don't patronize me. Its beneath you.

We do want our work deployed, so we need to believe that it could happen,
and thus usually we tolerate a bit of discussion on how it would work.

[RS> ] Bit??  Well the IETF has a mixed record on PKI at scale.  DNSSEC come
to mind? SIDR?  It's certainly worth noting what has been done to avoid the
mistakes of the past and the SSL issues certainly come to mind. But you
cannot ignore costs to deploy. 

I personally favor a "peering requirement" model.  Here, a service provider
puts a new requirement in its peering relationship agreements that provide a
date/percentage goal.  By such-and-such a date, good signed calling party
number must be provided for X percent of calls sent.  If the peer can't meet
this requirement, peering won't be allowed.

[RS> ] Certainly voluntary agreements are preferred as we have seen now
rolling out in the US but you are not going to make that decision. The
carriers will and under the terms of applicable law which means SIP peering
using E.164 may or may not come under the auspices of say 47 USC 251 (c) the
CRTC actually imposes a single uniform voice Interconnection agreement as a
counter example.  That sticky wicket of "this is not the internet" keeps
coming back to haunt us doesn't it.  

This takes at least a regulatory interpretation, maybe more. IANAL.  But a
carrier can impose a number of requirements on peering (protocol, number of
trunks, .) already.  

The really interesting characteristic of this model is that it's not real
time.  You can run statistics later over the log.
[RS> ] Huh   I don't understand. 

Over time, we'll certainly want to get to real time checking, but we don't
need to be there to get a whole lot of usefulness.  It doesn't even take any
changes at all in the terminating carrier other than letting the new header
through and logging it.  The originating carrier has to put the header on,
of course.

We're all agreeing that the service provider can decide how many certs it
has.  The number can range from one per service provider to one per TN.  So,
cost per cert is probably meaningless.

[RS> ]  Meaningless compared to what LNP in the US?  <sorry>  Ok then you
are at least targeting a range of acceptability.  There would be a big
difference between trying to impose 120M pounds on UK number holders or 1
pound per TN per year vs .05 pence would imply an operational cost of 6 M
pounds a year if in fact that is what it could cost.  Excluding startup
costs and plunder the OSS vendors will impose.  Now you can at least make
rational design decisions based on what the customer here..the TN number
holder and by inference the NRA is prepared to accept.  Again the numbers
are "owned" by the nation state.  

We do want to get to a cert on each device.  But we can ease into that too.
[RS> ]  I agree. Though I'm skeptical. 

Brian

On Mar 4, 2014, at 6:19 PM, Richard Shockey <[email-masked]> wrote:

> I think it should be optional to use/check the received golden-copy 
> (or whatever we call the copy in the Identity-X header), but not 
> optional to send it.
> 
> Imho, debugging and proof-of-failure is going to be really important, 
> if we ever hope to actually reject failed call requests.
> 
> The intersection of the STIR method and refinements to NRA regulations 
> will need sufficient proof the verification method is sound.  This is
telephony
> constraints. Can it actually be deployed in contexts where there is a 
> great deal of SIP already out there?  This goes to Jon points and 
> Hadrial's rebuttal in the meeting about "Well its shouldn't be too 
> hard to deal with canonicalization in FROM:"  Ya right.
> 
> And costs.  I'm spending a great deal of time trying to find any 
> reasonable data on what the theoretical costs of a RPKI mechanism for 
> phone numbers would look like.  The data is all over the place and if 
> anyone has any hints and resources they would pass along to me I'd 
> appreciate it. We have some models out there SIDR certainly, 509 in 
> chip and pin credit cards, HMDI video interfaces, we know the problems 
> in SSL etc. Certs can go from .01 cent to $200.
> 
> It's one thing to give a cert to the 1500 US carriers or 500 Canadian 
> it's another thing if this drills down into a requirement that each 
> phone number be directly signed.  As an exercise in scale I typically 
> use 2.5 times total population to estimate numbers allocated and 
> available for service so that generally looks like 700M or so in the 
> US,  120 M or so in the UK  and 90 or so million for Canada. I agree 
> with Alex that the probable first use case for STIR is carrier to 
> carrier where the SBC is probably both the Authentication service at 
> the Originating carrier and Verification Service at the Terminating 
> carrier.  It is probably easier to support the mechanism there than at 
> the CSCF.  I just don't see this being deployed directly on 
> smartphones for the foreseeable future, Cullen may be right and I'm 
> often wrong but that is what I think. I'd certainly like to see an 
> effort on an enhanced CNAM display mechanism from the mobile operators 
> and handset manufacturers first but I'm told 3GPP is looking at this but
maybe I'll have a problem statement ready by Toronto.
> 
> Design decisions drive costs and there are limits on what, I believe, 
> the global telecom industry or consumers of phone numbers will 
> tolerate.  For instance I'm not sure some consumers will appreciate a 
> PKI line item on their phone bills.  There are three moving parts here 
> first the actually mechanism on the wire and modifications to the SBC 
> here, second the actually cost of the PKI infrastructure and last but 
> not least the OSS/BSS systems used in telecom systems worldwide.  
> Anyone who know what I'm talking about will realize that that is where the
sink hole of money will ultimately fall
> I might point out we are at a relatively unique point here especially 
> with regards to the underlying national numbering databases.  The PSTN 
> Transition is forcing  the issue of URI/NS record inclusion and 
> clearly it would be helpful if the STIR mechanism could be grafted in as
well.
> 
> Also effect on post dial delay.  This is not email this is real-time.  
> The SIP headers should be renamed the SIP short story since the size 
> is now roughly similar if History-Info is included.  I just don't know 
> here and in the immortal words of Donald Rumsfield it's the "unknown 
> unknowns"  that worry me.
> 
> 
> 
> 
> -hadriel
>

---

From: Michael Hammer <[email-masked]>
Date: Tue, 4 Mar 2014 21:38:04 +0000

Richard,

I was reacting to the notion that the solution had to be expensive and that
everything would be done in nodes like SBC and CSCF.
I am not saying that carriers won't be involved, or that this won't involve
E.164 numbering resources, and associated authority delegations.
Or, that proxies for dumb phones won't be needed.
But, let's not make this so that phones must be dumb in the STIR design.

This just started to feel like an ITU-T meeting than an IETF discussion.  :)

Didn't mean to stir up a hornets nest,  but also don't fall into old habits.

Mike

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, March 04, 2014 1:20 PM
To: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

-hadriel

---

From: Alex Bobotek <[email-masked]>
Date: Tue, 4 Mar 2014 14:09:34 -0800

> cannot ignore costs to deploy. 
+1

Large scale certificate management presents operational issues that may delay, complicate and prevent deployments, and post-deployment system issues that may degrade call completion.  

Which candidate mechanisms have operational experience that supports their operability?  

DKIM deployments (public keys in DNS) have been successful, but there, even scheduled key rotation has been surprisingly more operationally complex than expected.

One model that may reduce operational complexity that I've been pondering involves leveraging ENUM for public key storage and/or selection in schemes where the originating service provider authenticates and signs.  Based on the assumption that ENUM is more secure than DNS, this may provide adequate security with less onerous operational complexity.

Regards,

Alex

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Mar 2014 17:53:05 -0500

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Tuesday, March 04, 2014 4:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Richard,

[RS> ] Well then I should apologize.  I certainly didn't mean that, only
that given the realities and the extreme pressure NRA's and the legislative
types are looking at from real people looking for real answers to real and
literally life threating scenarios  its entirely probable that it is within
carriers networks where it would be deployed first. I could be wrong. 

[RS> ] Of course not.  It would eventually help to see the "Usual Suspects"
Apple Samsung etal and 3GPP weigh in on this but there is time enough for
that. Certainly on the display CNIT side. 

[RS> ]  Well been there done that as you well know.  Some of it is actually
inevitable.  Its real telephony now, not the "Internet" there are real laws
involved and real delegated authority against the namespace in question.
The Public SIP Telephone Network.  I do spend a fair amount of time actually
trying to explain to regulatory legal types the difference between VoIP and
VuIP Voice Using IP.  These are actually different constructs due to the
nature of the service and the public policy issues and requirements
associated with them. 

[RS> ] It's inevitable. It can't be avoided now any more than when I was
Co-Chairing ENUM. It's the nature of the beast at this point. That said this
work MUST be done and done correctly and in a manner that can actually be
explained to both number holders and the regulators. Of that I have no
doubt.   As a side bar to a NRA, this is simply one of a series of tools
they have to look at.  

Look at the UK .. the UK tabloids are still pumping out stories of caller ID
spoofing to hack voice mail boxes.  Inquiries Commissions etc. You don't
think OFCOM has noticed?  :-)  

It is political.  People are pissed off and the message has been
circurlated. 

Mike

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, March 04, 2014 1:20 PM
To: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

-hadriel

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 4 Mar 2014 23:11:21 +0000

Mike,

While smartphones are mini computers, the dialer app is one of the secure apps on a phone, and therefore  unlikely to have an API access to it.

So, please explain to me how a smartphone solution would work, across all phones?

Thank you,

Martin

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Tuesday, March 04, 2014 4:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Richard,

Mike

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, March 04, 2014 1:20 PM
To: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 4 Mar 2014 23:16:00 +0000

As far as I know, for one fairly common OS [Android], there is an API for the dialer, as that's used for the various filtering apps that you can download today from Google Play. It doesn't get access to SIP headers at the moment and obviously doesn't work on all phones, but Mike mentions "proxies for dumb phones", so I suspect nobody is contemplating this as the only solution.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Tuesday, March 04, 2014 6:11 PM
To: Michael Hammer; [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Mike,

Thank you,

Martin

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Tuesday, March 04, 2014 4:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Richard,

I was reacting to the notion that the solution had to be expensive and that everything would be done in nodes like SBC and CSCF.

Mike

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, March 04, 2014 1:20 PM
To: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

-hadriel

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 4 Mar 2014 23:39:43 +0000

That is why I asked all phones, and did not highlight the one that leads the industry in malware. There is a good reason why the dialer app is secure on MOST phones. And isn't ironic that the least secure has an API for the dialer....Hmmm

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Tuesday, March 04, 2014 6:11 PM
To: Michael Hammer; [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Mike,

Thank you,

Martin

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Tuesday, March 04, 2014 4:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Richard,

Mike

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, March 04, 2014 1:20 PM
To: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 5 Mar 2014 00:00:57 +0000

Martin et al,

My concern about fighting the last war comes from things like:
"WhatsApp's global success has been nothing short of epic, of course, 
By now, the app is hitting 450 million monthly active users."

Now bought by Facebook:  
Total number of monthly active Facebook users 1,310,000,000 
Total number of mobile Facebook users 680,000,000 
Increase in Facebook users from 2012 to 2013 22 %

As to how it would work across all smartphones?
Mobile operators are very good about ensuring that mobile platforms support 
the features needed to make their service offering better than an OTT
application.
If they do this better than FB, then they will have a leg up.

I am just hoping that the infrastructure to serve the analog line market is
minimal.
(I count on recent FCC allowed trials to make that throw-away.)

Mike

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]] 
Sent: Tuesday, March 04, 2014 6:40 PM
To: Henning Schulzrinne; Michael Hammer; [email-masked]; [email-masked]
Subject: RE: [stir] Canonicalization vs. Comparison & now Costs

That is why I asked all phones, and did not highlight the one that leads the
industry in malware. There is a good reason why the dialer app is secure on
MOST phones. And isn't ironic that the least secure has an API for the
dialer....Hmmm

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Tuesday, March 04, 2014 6:16 PM
To: DOLLY, MARTIN C; Michael Hammer; [email-masked]; [email-masked]
Subject: RE: [stir] Canonicalization vs. Comparison & now Costs

As far as I know, for one fairly common OS [Android], there is an API for
the dialer, as that's used for the various filtering apps that you can
download today from Google Play. It doesn't get access to SIP headers at the
moment and obviously doesn't work on all phones, but Mike mentions "proxies
for dumb phones", so I suspect nobody is contemplating this as the only
solution.

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Tuesday, March 04, 2014 6:11 PM
To: Michael Hammer; [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Mike,

While smartphones are mini computers, the dialer app is one of the secure
apps on a phone, and therefore  unlikely to have an API access to it.

So, please explain to me how a smartphone solution would work, across all
phones?

Thank you,

Martin

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Tuesday, March 04, 2014 4:38 PM
To: [email-masked]; [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Richard,

Mike

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, March 04, 2014 1:20 PM
To: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

-hadriel

---

From: Brian Rosen <[email-masked]>
Date: Wed, 5 Mar 2014 09:00:36 +0000

> [RS> ] Huh   I don't understand. 
The signature needs to be put on the call in the way everyone understands.

However the verification can be done off line, on the log.  You have a batch process that runs through the log computing the verification.
We’re not trying to determine if an individual call verifies at the time of the call.
We’re computing the percentage of calls from a particular peer that verify on a, say, weekly basis.

I’m not suggesting this is the end solution.  I’m suggesting it’s a good first step because it doesn’t require as much infrastructure to be deployed.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 5 Mar 2014 10:47:06 +0000

Please explain this peering business model ?

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards
AT&T Standards and Industry Alliances
+1-609-903-3360
[email-masked]<mailto:[email-masked]>

On Mar 5, 2014, at 4:01 AM, "Brian Rosen" <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 5 Mar 2014 11:04:52 +0000

Service Providers have explicit peering agreements.  They don’t just take calls from anyone.  Peering agreements have terms.  The peers agree to exchange traffic under certain terms and conditions.

Any service provider could negotiate with a peer to include a requirement to have valid, signed identity on some percentage of calls.

“The parties agree that by January 1, 2017, 50% of calls presented by either party to the other will have valid, signed identity.  By January 1, 2018, 75% of calls presented will have valid, signed identity…”

Service providers who are on the receiving end of a lot of bad calls might want to impose such a requirement on its peers.  This avoids any issue of dropping calls.  It might mean that at some point an SP would be in violation of the peering agreement, and some remedy would be imposed.  It would be nice if the regulator would state that refusing to peer due to extended violation of such an agreement was acceptable.

It’s not really a “business model”, as much as a way to encourage deployment without a flat regulatory imperative.
I certainly don’t think any service provider is going to be charging any other service provider for any of this mechanism.
The database itself has some cost that has to be passed on, directly or indirectly to consumers.  Each provider has to have some element in the origination path that will insert the header.  In the peering agreement idea I’m describing, the terminating service provider needs a back-end checker that could be batch oriented, off line, non-real time, that computes the percentage of calls with validly signed identity.  Eventually, the termination side will want on line, real time checking.  The costs of deploying that infrastructure is going to be passed directly or indirectly to consumers.

Brian

On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <[email-masked]> wrote:

> [email-masked]
> On Mar 5, 2014, at 4:01 AM, "Brian Rosen" <[email-masked]> wrote:
>

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 5 Mar 2014 12:35:49 -0500

First . If we can't ultimately block the calls in real time what's the
point?   

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, March 05, 2014 6:05 AM
To: DOLLY, MARTIN C
Cc: [email-masked]; Richard Shockey
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Service Providers have explicit peering agreements.  They don't just take
calls from anyone.  Peering agreements have terms.  The peers agree to
exchange traffic under certain terms and conditions.

[RS> ] This is NOT the Internet.  Its telephony.  In my experience SIP
peering agreements are entirely different from classic IP Transit Peering.
In most cases you are not even using BGP routing. 

The call MUST go through in the TDM world and there is a huge food fight in
the US on whether SIP Peering is covered under 47 USC 251 (c)  on the
mandate to interconnect.  It's the same in other jurisdictions. I'm happy to
provide a seminar on international telecom law and rights of nation states
for their numbering plan administration but I suspect no one really wants
that.  

http://www.gpo.gov/fdsys/pkg/USCODE-2011-title47/html/USCODE-2011-title47-ch
ap5-subchapII-partII-sec251.htm

http://laws-lois.justice.gc.ca/eng/acts/T-3.4/page-16.html#s-46.1

http://www.legislation.gov.uk/ukpga/2003/21/part/2/chapter/1/crossheading/ge
neral-conditions-telephone-numbers

Any service provider could negotiate with a peer to include a requirement to
have valid, signed identity on some percentage of calls.

[RS> ]   Could maybe might . were not even close to that point. 

"The parties agree that by January 1, 2017, 50% of calls presented by either
party to the other will have valid, signed identity.  By January 1, 2018,
75% of calls presented will have valid, signed identity."

Service providers who are on the receiving end of a lot of bad calls might
want to impose such a requirement on its peers.  This avoids any issue of
dropping calls.  It might mean that at some point an SP would be in
violation of the peering agreement, and some remedy would be imposed.  It
would be nice if the regulator would state that refusing to peer due to
extended violation of such an agreement was acceptable.

It's not really a "business model", as much as a way to encourage deployment
without a flat regulatory imperative.

I certainly don't think any service provider is going to be charging any
other service provider for any of this mechanism.

The database itself has some cost that has to be passed on, directly or
indirectly to consumers.  Each provider has to have some element in the
origination path that will insert the header.  In the peering agreement idea
I'm describing, the terminating service provider needs a back-end checker
that could be batch oriented, off line, non-real time, that computes the
percentage of calls with validly signed identity.  Eventually, the
termination side will want on line, real time checking.  The costs of
deploying that infrastructure is going to be passed directly or indirectly
to consumers.

Brian

On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <[email-masked]
<mailto:[email-masked]> > wrote:

Martin Dolly

+1-609-903-3360

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

On Mar 5, 2014, at 4:01 AM, "Brian Rosen" <[email-masked]
<mailto:[email-masked]> > wrote:

However the verification can be done off line, on the log.  You have a batch
process that runs through the log computing the verification.

We're not trying to determine if an individual call verifies at the time of
the call.

We're computing the percentage of calls from a particular peer that verify
on a, say, weekly basis.

I'm not suggesting this is the end solution.  I'm suggesting it's a good
first step because it doesn't require as much infrastructure to be deployed.

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

---

From: "Gorman, Pierce A [NTK]" <[email-masked]>
Date: Wed, 5 Mar 2014 18:27:20 +0000

Interesting remark(s) Richard.  As usual.

Blocking calls has been implicitly and explicitly discussed here, but I will say I assumed that would rarely happen, other than by the consumer of the termination (just like what happens today).

Do we need to define the tangible benefits of signing calls?

Is signing a call...

*         a source of evidence when suing for relief (or in criminal prosecution)?

*         a hint of the trustworthiness of the originator?  (Can we assume people are more trustworthy if they know they can be more easily tracked and identified?)

*         a token for CNAM (see CNIT)?

Since the list likes to make assumptions about business models and regulatory enforcement I'll throw out an assumption and some questions too.

I assume capturing signatures in Call Detail Records is implied.  Are customers going to be willing to pay more for calls which are signed?  Should there be a choice?  Should the (all) government(s) mandate that customers must have signed calls? Are un-signed calls worth less?  Should signing regulations extend to carrier-based and Over-The-Top coversational applications beyond voice, such as video, text, IM?

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

From: Richard Shockey [mailto:[email-masked]]
Sent: March 05, 2014 11:36 AM
To: 'Brian Rosen'; 'DOLLY, MARTIN C'
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

First ... If we can't ultimately block the calls in real time what's the point?

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, March 05, 2014 6:05 AM
To: DOLLY, MARTIN C
Cc: [email-masked]<mailto:[email-masked]>; Richard Shockey
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Service Providers have explicit peering agreements.  They don't just take calls from anyone.  Peering agreements have terms.  The peers agree to exchange traffic under certain terms and conditions.

[RS> ] This is NOT the Internet.  Its telephony.  In my experience SIP peering agreements are entirely different from classic IP Transit Peering. In most cases you are not even using BGP routing.

The call MUST go through in the TDM world and there is a huge food fight in the US on whether SIP Peering is covered under 47 USC 251 (c)  on the mandate to interconnect.  It's the same in other jurisdictions. I'm happy to provide a seminar on international telecom law and rights of nation states for their numbering plan administration but I suspect no one really wants that.

http://www.gpo.gov/fdsys/pkg/USCODE-2011-title47/html/USCODE-2011-title47-chap5-subchapII-partII-sec251.htm

http://www.legislation.gov.uk/ukpga/2003/21/part/2/chapter/1/crossheading/general-conditions-telephone-numbers

[RS> ]   Could maybe might ... were not even close to that point.

"The parties agree that by January 1, 2017, 50% of calls presented by either party to the other will have valid, signed identity.  By January 1, 2018, 75% of calls presented will have valid, signed identity..."

It's not really a "business model", as much as a way to encourage deployment without a flat regulatory imperative.
I certainly don't think any service provider is going to be charging any other service provider for any of this mechanism.
The database itself has some cost that has to be passed on, directly or indirectly to consumers.  Each provider has to have some element in the origination path that will insert the header.  In the peering agreement idea I'm describing, the terminating service provider needs a back-end checker that could be batch oriented, off line, non-real time, that computes the percentage of calls with validly signed identity.  Eventually, the termination side will want on line, real time checking.  The costs of deploying that infrastructure is going to be passed directly or indirectly to consumers.

Brian

On Mar 5, 2014, at 10:47 AM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:

However the verification can be done off line, on the log.  You have a batch process that runs through the log computing the verification.
We're not trying to determine if an individual call verifies at the time of the call.
We're computing the percentage of calls from a particular peer that verify on a, say, weekly basis.

I'm not suggesting this is the end solution.  I'm suggesting it's a good first step because it doesn't require as much infrastructure to be deployed.

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: Henning Schulzrinne <[email-masked]>
Date: Wed, 5 Mar 2014 18:36:09 +0000

There's also the possibility of a third-party provider of caller reputation and handling services. We see beginnings of that (e.g.,) in the Nomorobo service.

A carrier can simply pass on the STIR SIP header(s) to the third party or an indication that the caller-ID has been validated (or failed validation).

Beyond blocking, such services can provide a number of other call treatments, such as CAPTCHA-style tests to separate humans from bots or redirection to voicemail or redirection to a third party (for example, maybe dubious calls to elderly parents can be sent to a child acting with power of attorney that decides whether the charity or financial services offer should be passed on to the parent).

From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A [NTK]
Sent: Wednesday, March 05, 2014 1:27 PM
To: Richard Shockey; 'Brian Rosen'; 'DOLLY, MARTIN C'
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Is signing a call...

Best regards,

Pierce Gorman
Voice Architecture
Core Planning/Sprint
913-439-4368 (Desk)

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

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 5 Mar 2014 14:41:35 -0500

From: stir [mailto:[email-masked]] On Behalf Of Gorman, Pierce A
[NTK]
Sent: Wednesday, March 05, 2014 1:27 PM
To: Richard Shockey; 'Brian Rosen'; 'DOLLY, MARTIN C'
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Blocking calls has been implicitly and explicitly discussed here, but I will
say I assumed that would rarely happen, other than by the consumer of the
termination (just like what happens today).

[RS> ]  I just don't know at this point there may be circumstances where the
network itself does the call blocking but that would take a sea change in
the regulatory environment and some new safe harbor provision the NRA would
ultimately put forward. The case in point is a TDOS against the Public
Safety infrastructure.  As we both know rural carriers in the US would go
nuts. They already have enough problems with least cost routing engines and
call completion.

Is signing a call.

*         a source of evidence when suing for relief (or in criminal
prosecution)?

[RS> ]  Sure if the legislative critters give consumers a private cause of
action for abuse as we saw for junk fax. 

*         a hint of the trustworthiness of the originator?  (Can we assume
people are more trustworthy if they know they can be more easily tracked and
identified?)

[RS> ] Again this is a display issue.  The IETF needs to so some things but
eventually this probably needs to be addressed by 3GPP and the handset
folks. Which is why it might be useful to have a BOF on CNIT in Toronto now
that we see the rough parameters of where STIR is going.  

Since the list likes to make assumptions about business models and
regulatory enforcement I'll throw out an assumption and some questions too.

I assume capturing signatures in Call Detail Records is implied.  Are
customers going to be willing to pay more for calls which are signed?  

[RS> ]  To kill off "This is Rachel from Card member services." I would
guess yes. At the very least the investment is a protection for the existing
voice revenue streams or as a competitive advantage. "Yes we sign calls and
very calls to protect you from that bitxx Rachel." See pin drop :)    

Should there be a choice?  Should the (all) government(s) mandate that
customers must have signed calls? 

[RS> ] If this situation gets any worse it wouldn't surprise me. But it has
to start somewhere. Better here than the ITU.  

http://www.mccaskill.senate.gov/?p=press_release
<http://www.mccaskill.senate.gov/?p=press_release&id=1969> &id=1969

http://media.ofcom.org.uk/2013/10/21/ofcom-joins-international-taskforce-to-
tackle-number-%E2%80%98spoofing%E2%80%99/

Are un-signed calls worth less?  Should signing regulations extend to
carrier-based and Over-The-Top coversational applications beyond voice, such
as video, text, IM?

[RS> ]  Is Facebook the new phone company?  :)  I would say if we want to
see point to point video using E.164 addressing an any access device we have
to fix this stuff and provide adequate consumer display of some verification
data. 15 character ASCII is not going to cut it. 

Best regards,

Pierce Gorman

Voice Architecture

Core Planning/Sprint

913-439-4368 (Desk)

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

 

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, March 05, 2014 6:05 AM
To: DOLLY, MARTIN C
Cc: [email-masked] <mailto:[email-masked]> ; Richard Shockey
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

 

 

 

 

Brian

Martin Dolly

+1-609-903-3360

 

 

  _____  

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: Brian Rosen <[email-masked]>
Date: Thu, 6 Mar 2014 09:23:18 +0000

Ultimately, some one can block calls. the endpoint for example.
That requires a fair amount of mechanism to be implemented, but I hope we can get there pretty soon in smartphones.

Hopefully, regulations will evolve so that unsigned or invalid calls can be rejected earlier.

I don’t need a tutorial on regulations Rich.  I don’t think most people on this list need your expositions on the subject.

Peering at the call level occurs in SIP interconnect, independent of any IP peering.  I’m referring to exchange of calls, not packets.

I’ve suggested a way to deploy stir in a manner that does not require the whole world to change.  It requires some B2BUA in the origination side to add the header and some back end batch process in the termination side to verify and compute statistics.  If you have a better idea, suggest one.  

Brian

On Mar 5, 2014, at 5:35 PM, Richard Shockey <[email-masked]> wrote:

> First … If we can’t ultimately block the calls in real time what’s the point?  
>  
>  
> The call MUST go through in the TDM world and there is a huge food fight in the US on whether SIP Peering is covered under 47 USC 251 (c)  on the mandate to interconnect.  It’s the same in other jurisdictions. I’m happy to provide a seminar on international telecom law and rights of nation states for their numbering plan administration but I suspect no one really wants that. 
>  
>  
> [RS> ]   Could maybe might … were not even close to that point.
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 6 Mar 2014 09:34:50 +0000

Inline

> Blocking calls has been implicitly and explicitly discussed here, but I will say I assumed that would rarely happen, other than by the consumer of the termination (just like what happens today).
Yes, that’s my view.  I think it will be hard for service providers to actually block calls.

> Is signing a call…
> ·         a source of evidence when suing for relief (or in criminal prosecution)?
Yes, at least the idea that if you place scummy calls, the authorities will be able to find you because you can’t hide behind a spoofed telephone number.

> ·         a hint of the trustworthiness of the originator?  (Can we assume people are more trustworthy if they know they can be more easily tracked and identified?)
Not sure how “trustworthy” some scammer that has a legitimate phone number is, but see above

> ·         a token for CNAM (see CNIT)?
Yeah, I think for phones that only have traditional CNAM, yes.  A prefix perhaps.  Hopefully SIP phones can have better displays, but I do see this as a benefit

>  
> Since the list likes to make assumptions about business models and regulatory enforcement I’ll throw out an assumption and some questions too.
>  
> I assume capturing signatures in Call Detail Records is implied. 
Yes.  That’s my idea.  Capture it in the log, and compute validity off line, none-real time, hold peering partners to a standard.

> Are customers going to be willing to pay more for calls which are signed? 
Maybe, but I think the benefits of not getting bad calls would drive consumers to service providers who don’t send them such calls.  That might be a premium service for a while at least

> Should there be a choice?
Who wants bad calls?  But, sure, there should be a choice. 

>   Should the (all) government(s) mandate that customers must have signed calls?
We might get there.  If this mechanism works, then we might get it mandated.  I don’t want to assume that happens.

> Are un-signed calls worth less?
Yes, but see above

>   Should signing regulations extend to carrier-based and Over-The-Top coversational applications beyond voice, such as video, text, IM?
Clearly a tricky subject.  I have opinions, but I don’t think they matter with respect to this discussion.  Let’s say that if you are using a delegated telephone number associated with a service, then probably whatever regulations apply to the service could be extended to cover stir at some point.

---

From: Alex Bobotek <[email-masked]>
Date: Thu, 6 Mar 2014 03:12:57 -0800

What can be done once a source of abusive calls is identified?   In other communications services a set of tools and processes is used to mitigate abusive communications.  These go beyond simple automated blocking filters, and include account restriction, end-user reporting mechanisms, reputation databases (content/fingerprint, source, service provider, ...) and feedback loops.

In voice, one might expect enforcement activities (based at least in part on calling party phone numbers) to include:

*         Call blocking by terminating telco with consent of recipient

*         Call blocking by terminating telco in extreme situations in defense of networks

*         Call blocking by 3rd party app with consent of recipient

*         Account restriction by originating telco

*         Feedback from terminating parties (end user, terminating telco, ...) to upstream telcos and security vendors

*         Civil and/or criminal enforcement action against originator and/or originating telco

It should also be noted that selective blocking of text messages (e.g., spam) and shutdown of anonymously-obtained accounts that appear to have been created with the purpose of originating abusive text messages is a common service provider practice in North America and several other regions.  This is not to suggest that voice call blocking is subject to the same policies and regulations as blocking of data calls such as text messages in many jurisdictions.

Regards,

Alex

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, March 06, 2014 1:35 AM
To: Gorman, Pierce A [NTK]
Cc: [email-masked]; DOLLY, MARTIN C; Richard Shockey
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Inline
On Mar 5, 2014, at 6:27 PM, Gorman, Pierce A [NTK] <[email-masked]<mailto:[email-masked]>> wrote:

Blocking calls has been implicitly and explicitly discussed here, but I will say I assumed that would rarely happen, other than by the consumer of the termination (just like what happens today).
Yes, that's my view.  I think it will be hard for service providers to actually block calls.

Is signing a call...

*         a source of evidence when suing for relief (or in criminal prosecution)?
Yes, at least the idea that if you place scummy calls, the authorities will be able to find you because you can't hide behind a spoofed telephone number.

*         a hint of the trustworthiness of the originator?  (Can we assume people are more trustworthy if they know they can be more easily tracked and identified?)
Not sure how "trustworthy" some scammer that has a legitimate phone number is, but see above

I assume capturing signatures in Call Detail Records is implied.
Yes.  That's my idea.  Capture it in the log, and compute validity off line, none-real time, hold peering partners to a standard.

Are customers going to be willing to pay more for calls which are signed?
Maybe, but I think the benefits of not getting bad calls would drive consumers to service providers who don't send them such calls.  That might be a premium service for a while at least

  Should the (all) government(s) mandate that customers must have signed calls?
We might get there.  If this mechanism works, then we might get it mandated.  I don't want to assume that happens.

  Should signing regulations extend to carrier-based and Over-The-Top coversational applications beyond voice, such as video, text, IM?
Clearly a tricky subject.  I have opinions, but I don't think they matter with respect to this discussion.  Let's say that if you are using a delegated telephone number associated with a service, then probably whatever regulations apply to the service could be extended to cover stir at some point.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 6 Mar 2014 11:24:56 +0000

Good list.  I think all of these are possible although, remembering that IANAL, I’m not sure how far enforcement action on originating telcos could be taken.  I suspect that if stir is widely deployed, and some small set of service providers are still sending lots of garbage calls, that it will become easier to prosecute them.

Having met some of the regulators in both the FCC and FTC who deal with this stuff, they are VERY eager to get tools to identify and prosecute the bad guys.

Brian
On Mar 6, 2014, at 11:12 AM, Alex Bobotek <[email-masked]> wrote:

> What can be done once a source of abusive calls is identified?   In other communications services a set of tools and processes is used to mitigate abusive communications.  These go beyond simple automated blocking filters, and include account restriction, end-user reporting mechanisms, reputation databases (content/fingerprint, source, service provider, …) and feedback loops. 
>  
> ·         Call blocking by terminating telco with consent of recipient
> ·         Call blocking by terminating telco in extreme situations in defense of networks
> ·         Call blocking by 3rd party app with consent of recipient
> ·         Account restriction by originating telco
> ·         Feedback from terminating parties (end user, terminating telco, …) to upstream telcos and security vendors
> ·         Civil and/or criminal enforcement action against originator and/or originating telco
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 6 Mar 2014 12:36:50 -0500

From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, March 06, 2014 6:25 AM
To: Alex Bobotek
Cc: [email-masked]; Gorman, Pierce A [NTK]; DOLLY, MARTIN C; Richard Shockey
Subject: Re: [stir] Canonicalization vs. Comparison & now Costs

Good list.  I think all of these are possible although, remembering that
IANAL, I'm not sure how far enforcement action on originating telcos could
be taken.  

[RS> ] Oh its real easy.  Look at the German Bundesnetzagentur they simply
ban the practice of Call Spoofing totally and annually take a recalcitrant
carrier fine them 15-20 M Euros and somebody gets the message. 

I suspect that if stir is widely deployed, and some small set of service
providers are still sending lots of garbage calls, that it will become
easier to prosecute them.

Having met some of the regulators in both the FCC and FTC who deal with this
stuff, they are VERY eager to get tools to identify and prosecute the bad
guys.

[RS> ]  As have I and a lot more as well. But if we can agree on anything
STIR is not the total answer. Track and Trace at the gateways using some
Pseudo ANI identifier. CNIT.  I'm not sure about *50. I'm not sure if the
code is even supported in the legacy C5's Certainly not the Nortel DMS
platforms and the UK has still got a lot of SIEMENS sitting around and if it
isn't there is no way on earth it's going to get reprogrammed.  I cant get a
straight answer about the Ericsson CSCF's.   So Brian If I recall the last
person to ever see 911 code in a 5ESS retired how many years ago? 

Brian

On Mar 6, 2014, at 11:12 AM, Alex Bobotek <[email-masked]
<mailto:[email-masked]> > wrote:

What can be done once a source of abusive calls is identified?   In other
communications services a set of tools and processes is used to mitigate
abusive communications.  These go beyond simple automated blocking filters,
and include account restriction, end-user reporting mechanisms, reputation
databases (content/fingerprint, source, service provider, .) and feedback
loops. 

In voice, one might expect enforcement activities (based at least in part on
calling party phone numbers) to include:

*         Call blocking by terminating telco in extreme situations in
defense of networks

*         Feedback from terminating parties (end user, terminating telco, .)
to upstream telcos and security vendors

*         Civil and/or criminal enforcement action against originator and/or
originating telco

It should also be noted that selective blocking of text messages (e.g.,
spam) and shutdown of anonymously-obtained accounts that appear to have been
created with the purpose of originating abusive text messages is a common
service provider practice in North America and several other regions.  This
is not to suggest that voice call blocking is subject to the same policies
and regulations as blocking of data calls such as text messages in many
jurisdictions. 

Regards,

Alex

Cc: [email-masked] <mailto:[email-masked]> ; DOLLY, MARTIN C; Richard Shockey

Inline

On Mar 5, 2014, at 6:27 PM, Gorman, Pierce A [NTK] <
<mailto:[email-masked]> [email-masked]> wrote:

Yes, that's my view.  I think it will be hard for service providers to
actually block calls.

Is signing a call.

Yes, at least the idea that if you place scummy calls, the authorities will
be able to find you because you can't hide behind a spoofed telephone
number.

Not sure how "trustworthy" some scammer that has a legitimate phone number
is, but see above

Yeah, I think for phones that only have traditional CNAM, yes.  A prefix
perhaps.  Hopefully SIP phones can have better displays, but I do see this
as a benefit

Yes.  That's my idea.  Capture it in the log, and compute validity off line,
none-real time, hold peering partners to a standard.

Maybe, but I think the benefits of not getting bad calls would drive
consumers to service providers who don't send them such calls.  That might
be a premium service for a while at least

  Should the (all) government(s) mandate that customers must have signed
calls?

We might get there.  If this mechanism works, then we might get it mandated.
I don't want to assume that happens.

Yes, but see above

  Should signing regulations extend to carrier-based and Over-The-Top
coversational applications beyond voice, such as video, text, IM?

Clearly a tricky subject.  I have opinions, but I don't think they matter
with respect to this discussion.  Let's say that if you are using a
delegated telephone number associated with a service, then probably whatever
regulations apply to the service could be extended to cover stir at some
point.