Subject: Re: [stir] Out-of-band vs. in-band

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Jul 2013 06:38:19 -0700

It might help to clarify my position here...

>From a technical perspective, most of the stuff on a smartphone is an app,
including the dialer.

>From a user's perspective, the dialer is something built into the phone..
If we build something that requires the user to replace their dialer with
something they download, that's not going to be very successful.

>From the perspective of what we can build, however. since we know the
dialer is just general purpose code running on the phone, and we know
that downloadable apps can do DB lookups as calls come in,
we know that there's no major technical obstacle to the smartphone
vendor building a dialer that does such lookups. This of course does
not mean that they will, but means that a design that depends on
it is feasible technically.

Hope that helps.
-Ekr

On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla <[email-masked]> wrote:

>
>
>
> On Sun, Jun 30, 2013 at 1:20 PM, DOLLY, MARTIN C <[email-masked]> wrote:
>
>>  Eric,****
>>
>> ** **
>>
>> My mother picks up her phone and she dials a number…no app, even though
>> she has a smart phone. This is the user we have to protect… do you agree?
>>
>
> I'm not sure you and I have the same definition of "app". On a smartphone,
> the dialer
> is often (always?) a program that runs on the phone and that has access to
> the
> mobile dialer functionality. That's an app. Now, apps come in a number of
> flavors,
> depending on whether:
>
> - They are shipped with the phone or installed by the user.
> - What level of privileges they have.
>
> But I think Henning's point is that there is nothing particularly
> difficult about
> the smartphone manufacturer adding this sort of functionality to the
> builtin
> dialer app. It's not an architectural change to the phone, just a new
> feature
> to a program. Is that something you disagree with?
>
> -Ekr
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 1 Jul 2013 13:44:31 +0000

I agree on the less-desirable user option. In the Android eco system, there are probably three parties that could do this without user involvement: Google; the smartphone manufacturer (HTC, Samsung, etc.) and the carrier. They already routinely modify key components of the OS. One would hope that any such feature is user-configurable. Based on recent discussion at a conference in Europe, the prevalence of robocalls appears to be highly country-specific. Living in a small country with a somewhat-obscure language (Finnish, Croatian) affords some protection.

________________________________
From: Eric Rescorla [[email-masked]]
Sent: Monday, July 01, 2013 9:38 AM
To: DOLLY, MARTIN C
Cc: Henning Schulzrinne; Richard Shockey; [email-masked]
Subject: Re: [stir] Out-of-band vs. in-band

including the dialer.

Hope that helps.
-Ekr

On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Jun 30, 2013 at 1:20 PM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

My mother picks up her phone and she dials a number…no app, even though she has a smart phone. This is the user we have to protect… do you agree?

I'm not sure you and I have the same definition of "app". On a smartphone, the dialer
is often (always?) a program that runs on the phone and that has access to the
mobile dialer functionality. That's an app. Now, apps come in a number of flavors,
depending on whether:

But I think Henning's point is that there is nothing particularly difficult about
the smartphone manufacturer adding this sort of functionality to the builtin
dialer app. It's not an architectural change to the phone, just a new feature
to a program. Is that something you disagree with?

-Ekr

---

From: John Barnhill <[email-masked]>
Date: Mon, 1 Jul 2013 13:46:43 +0000

sorry I can't be in Berlin. You could sell tickets to this.

Thanks,

jb

John Barnhill
Office of the CTO

On 7/1/13 9:44 AM, "Henning Schulzrinne" <[email-masked]>
wrote:

>I agree on the less-desirable user option. In the Android eco system,
>there are probably three parties that could do this without user
>involvement: Google; the smartphone manufacturer (HTC, Samsung, etc.) and
>the carrier. They already routinely modify key components of the OS. One
>would hope that any such feature is user-configurable. Based on recent
>discussion at a conference in Europe, the prevalence of robocalls appears
>to be highly country-specific. Living in a small country with a
>somewhat-obscure language (Finnish, Croatian) affords some protection.
>
>On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla
><[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
>On Sun, Jun 30, 2013 at 1:20 PM, DOLLY, MARTIN C
><[email-masked]<mailto:[email-masked]>> wrote:
>Eric,
>
>My mother picks up her phone and she dials a numberŠno app, even though
>she has a smart phone. This is the user we have to protectŠ do you agree?
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir
>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 1 Jul 2013 12:17:24 -0400

NO this does not help at all.  Irrespective of what may or may not be
possible on handsets it's irrelevant to the problem.

You ignore that nearly 50% or more of the voice minutes are probably
landline enterprise and residential. Where no solution is possible unless
its network based. This includes nearly all Enterprise Voice ( aka SIP
Trunking)  and Digital voice over a broadband connection aka FIOS, uVerse
and other DSL derivatives in Europe and elsewhere.  The data indicates that
SIP Trunking will pass T1 enabled circuits/sessions by 2016 in the US and
Canada. 

If a network based solution could be designed and implemented, and I think
it's possible, then the handset problem goes away as well in VoLTE/IMS
operations and we know that CDMA and HSPA+ system which still use TDM
switching will be retired sooner rather than later.  . I have zero
confidence that some crowd source reputation based system would work and I'm
very skeptical on anything that would involve an E2E like system.    It
would be useful it some people try think like a normal consumer or small
business and not the IETF'er.    Part of our task it to remove complexity
from system not inject it.

Just because iMessage is cool doesn't mean it's poised to take over the
world.  

A network solution may not be possible but it's the shortest path to success
in the short term. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rescorla
Sent: Monday, July 01, 2013 9:38 AM
To: DOLLY, MARTIN C
Cc: [email-masked]; Richard Shockey; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

including the dialer.

Hope that helps.

-Ekr

On Sun, Jun 30, 2013 at 1:32 PM, Eric Rescorla <[email-masked]
<mailto:[email-masked]> > wrote:

On Sun, Jun 30, 2013 at 1:20 PM, DOLLY, MARTIN C <[email-masked]
<mailto:[email-masked]> > wrote:

Eric,

My mother picks up her phone and she dials a number.no app, even though she
has a smart phone. This is the user we have to protect. do you agree?

depending on whether:

But I think Henning's point is that there is nothing particularly difficult
about

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Jul 2013 09:22:36 -0700

On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey <[email-masked]> wrote:

> NO this does not help at all.
>

Well, it seems to have helped clarify things.

 Irrespective of what may or may not be possible on handsets it’s
> irrelevant to the problem.****
>
> ** **
>
> Canada. ****
> it’s possible, then the handset problem goes away as well in VoLTE/IMS
> confidence that some crowd source reputation based system would work and
> I’m very skeptical on anything that would involve an E2E like system.    It
> business and not the IETF’er.    Part of our task it to remove complexity
> from system not inject it.****
>
> ** **
>
> Just because iMessage is cool doesn’t mean it’s poised to take over the
> world.  ****
>
> ** **
>
> A network solution may not be possible but it’s the shortest path to
> success in the short term. ****
>
> ** **
>
>
> Yes, I recognize that this is your position. I disagree with this analysis
for the reasons
both Jon and I have laid out. If all I got was the 50% or so of calls that
were on smartphones
that would be a huge success.

-Ekr

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 1 Jul 2013 13:00:18 -0400

On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey <[email-masked]
<mailto:[email-masked]> > wrote:

 

 A network solution may not be possible but it's the shortest path to
success in the short term. 

 

[RS> ]  Well you still ignore that any carrier using CDMA right now cannot
deploy your proposed solution since it cannot do data and Voice at the same
time. Verizon Sprint and Korea Telecom might have something to say about
that. 

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Jul 2013 10:05:40 -0700

On Mon, Jul 1, 2013 at 10:00 AM, Richard Shockey <[email-masked]> wrote:

> ** **
>
> ** **
>
> ** **
>
> On Mon, Jul 1, 2013 at 9:17 AM, Richard Shockey <[email-masked]>
> wrote:****
>
> NO this does not help at all. ****
>
> ** **
>
> Well, it seems to have helped clarify things.****
>
> ** **
>
>  ****
>
>  ****
> for the reasons****
> were on smartphones****
> that would be a huge success.****
>
> * *
>
> ** **
>
> *[RS> ]  Well you still ignore that any carrier using CDMA right now
> cannot deploy your proposed solution since it cannot do data and Voice at
> the same time. Verizon Sprint and Korea Telecom might have something to say
> about that.*
>

Well, I feel generally sad for people who have that kind of phone.

That said, I would want to double check you were correct about the
inference here, since this is at the point where the phone has an
incoming call but before it's been answered. Is data possible in
that period?

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 10:10:04 -0700

On 7/1/2013 10:00 AM, Richard Shockey wrote:
> Yes, I recognize that this is your position. I disagree with this
> analysis for the reasons
>
> both Jon and I have laid out. If all I got was the 50% or so of calls
> that were on smartphones that would be a huge success.

That style of thinking is exactly what's getting in the way of 
productive discussion here.

Taking highly specialized scenarios and then projecting best-case 
adoption and performance is an absolutely classic path towards failure 
when deploying new Internet infrastructure services.

In this case, focusing on a design that can /at best/ cover only half of 
the affected population -- but is unlikely to come close to that, 
because life rarely reaches the ideal, and certainly not anytime soon -- 
is starting with a design failure.

It's not that such scenarios cannot be made to work and it's not that 
they won't ever work.  It's that it doesn't cover the population that is 
tasked for coverage and it doesn't /ever/ develop as planned.

This group needs to define a few, basic scenarios that /must/ be covered 
and then needs to identify the critical adoption and use actions that 
will make it work.  Whatever is designed then needs to to be easy to 
understand, have reasonable adoption and use incentives, and therefore 
seem likely to work.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Jul 2013 13:27:37 -0400

I think people on this subject thread are talking past each other.  Or at least that's my impression from reading the emails this morning.

I don't think anyone's saying it's theoretically nor technically impossible to specify and implement an out-of-band solution that could allow some portion of callers to prove their caller-id to some portion of called-parties.  Of course you could.

So what?  What does the technical possibility to achieve something have to do with forming a successful IETF Working Group?

It's certainly a necessary condition that something be possible, but it's not a *sufficient* excuse for forming a WG, imo.  Specifying something in isolation, without getting the implementors and users/operators of the specification involved, is a sure way to generate more useless RFCs.  It may be a fine thing for IRTF, but not IETF.

At a minimum, I would expect to at least have multiple parties who actually plan to implement and deploy such a solution, to be present in the WG.  I know there are cloud-based companies working on source-identity stuff, but I don't see any of them are here.  I don't know what their requirements are.  I don't even know that they *want* a standard's based solution.  After all, they can each write apps for smart-phones already today, without our help.

Instead, what I hear is the people who actually need to implement and deploy a STIR solution saying they want an in-band solution.
Why are we wasting their time?

-hadriel

On Jun 30, 2013, at 4:35 PM, Eric Rescorla <[email-masked]> wrote:

> On Sun, Jun 30, 2013 at 1:27 PM, Dave Crocker <[email-masked]> wrote:
> On 6/30/2013 1:17 PM, Eric Rescorla wrote:
> On a smartphone, the dialer generally is an app. For instance:
> https://wiki.mozilla.org/Gaia/Dialer
> The lookups done by that dialer are to a /local/ contacts list, not an external one.
> That's a pretty fuzzy distinction in the face of things like sync.
> Moreover, I'm not sure I see the relevance. Henning observed that you could
> get third party applications that do a db lookup with each call and so there
> was no in principle reason why the builtin phone application couldn't do
> the same thing. Obviously, the vendors would have to be induced to do so,
> but as far as I know there is no technical reason why that would be difficult
> for them to do, provided that such a service existed.
> 
> -Ekr

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 1 Jul 2013 14:35:44 -0400

that period?

[RS> ] I doubt the interval is long enough. Frankly I don't know. But you
should ask Apple among others :)  

http://bits.blogs.nytimes.com/2012/09/13/iphone-5-calls-data/?_r=0

-Ekr

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 1 Jul 2013 18:36:20 +0000

You're studying the right trends here, but I'm not sure you're correctly assessing their salience to the out-of-band proposal.

Sure, iMessage isn't poised to take over the world, it's just a texting feature for iOS. It is however an existence proof that you can build out-of-band systems like this, that they can be built "into the dialer" more or less, that they can rely on a centralized authority, that they can be transparent to end users, and rolled out to millions. It seems that it can be operated and deployed.

I definitely agree that "landline" enterprise is responsible for a huge chunk of calls today. But how much of that is anything remotely like POTS? How many of these deployments are, in fact, exactly the devices that Cisco wanted to enable VIPR for: islands of IP phones that are forced to lose valuable signaling by traversing the PSTN. Any STIR out-of-band solution should work not just for smart phones, but for these enterprises as well. In what sense must a solution for enterprises be "only network-based?"

Finally, how much residential landline deployment will be POTS in five years? We've both seen the charts that show how rapidly that market is diminishing. What's replacing it? Unfortunately, little by way of direct IP-to-IP communication, and far more calls being dropped to the PSTN. Again, this is exactly where the out-of-band solution can help. We can argue about where the right place is to implement and operate it – and I don't think there's any consensus about that yet – but we've heard strategies that would work at endpoints (maybe ATAs) or in the network.

I'm not sure where you see "crowd source reputation" in STIR, which proposes to build just the identity part. When identity is trusted, certainly there could be reputation systems that rely on that, but that's not in the proposed scope I don't think.

Jon Peterson
NeuStar, Inc.

From: Richard Shockey <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 1, 2013 9:17 AM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>, "'DOLLY, MARTIN C'" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Henning Schulzrinne' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Out-of-band vs. in-band

NO this does not help at all.  Irrespective of what may or may not be possible on handsets it’s irrelevant to the problem.

You ignore that nearly 50% or more of the voice minutes are probably landline enterprise and residential. Where no solution is possible unless its network based. This includes nearly all Enterprise Voice ( aka SIP Trunking)  and Digital voice over a broadband connection aka FIOS, uVerse and other DSL derivatives in Europe and elsewhere.  The data indicates that SIP Trunking will pass T1 enabled circuits/sessions by 2016 in the US and Canada.

If a network based solution could be designed and implemented, and I think it’s possible, then the handset problem goes away as well in VoLTE/IMS operations and we know that CDMA and HSPA+ system which still use TDM switching will be retired sooner rather than later.  . I have zero confidence that some crowd source reputation based system would work and I’m very skeptical on anything that would involve an E2E like system.    It would be useful it some people try think like a normal consumer or small business and not the IETF’er.    Part of our task it to remove complexity from system not inject it.

Just because iMessage is cool doesn’t mean it’s poised to take over the world.

A network solution may not be possible but it’s the shortest path to success in the short term.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Monday, July 01, 2013 9:38 AM
To: DOLLY, MARTIN C
Cc: [email-masked]<mailto:[email-masked]>; Richard Shockey; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

including the dialer.

Hope that helps.
-Ekr

-Ekr

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 1 Jul 2013 15:33:44 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Monday, July 01, 2013 2:36 PM
To: Richard Shockey; 'Eric Rescorla'; 'DOLLY, MARTIN C'
Cc: [email-masked]; 'Henning Schulzrinne'
Subject: Re: [stir] Out-of-band vs. in-band

You're studying the right trends here, but I'm not sure you're correctly
assessing their salience to the out-of-band proposal.

Sure, iMessage isn't poised to take over the world, it's just a texting
feature for iOS. It is however an existence proof that you can build
out-of-band systems like this, that they can be built "into the dialer" more
or less, that they can rely on a centralized authority, that they can be
transparent to end users, and rolled out to millions. It seems that it can
be operated and deployed.

[RS> ] Fine if you have HSPA LTE devices on GSM networks.  We will have to
agree to disagree about this. But you are falling into the trap that Dave
Crocker pointed out earlier today. 

I definitely agree that "landline" enterprise is responsible for a huge
chunk of calls today. But how much of that is anything remotely like POTS?

RS> well at least 90% since TDM is the default interconnection network.  SIP
Interconnection is progressing nicely and some carriers have been able to
specifically segment their SIP from TDM traffic to permit SIP end to end in
network. You know all of this. 

How many of these deployments are, in fact, exactly the devices that Cisco
wanted to enable VIPR for: islands of IP phones that are forced to lose
valuable signaling by traversing the PSTN. Any STIR out-of-band solution
should work not just for smart phones, but for these enterprises as well. In
what sense must a solution for enterprises be "only network-based?"

RS> VIPR was DOA from the start.   PLEASE let's not go over that again.  Its
as useless as rehashing e164.arpa.  My point is still a network based, in
band solution has the best shortest path to immediate deployment and is the
best overall given PSTN Transition as it is evolving.  If people want to
work on out of band ..fine, but not until a design for in band can be
articulated.  I have total confidence that there will be no carrier
investment in existing SS7 TDM networks now and in the foreseeable future. 

Finally, how much residential landline deployment will be POTS in five
years? 

RS> Reasonable question but the real question is how does resident landline
evolve in an all IP world.  Those black phones will be B2BUA forever.
Putting my Wall Street analyst hat on you have to remember wireless in NA
and EU is at full saturation.  There is no growth in those markets.  The
largest threat to landline right now are the fascists running the Walt
Disney  Company who jack up ESPN rates to the point where families are
forced into a decision to choose between NFL and a phone.  The data also
indicates some resurgence in landline as new household formation w/ young
children puts a premium on E911 reliability of the landline vs mobile.  In
addition there is the expectation that what you think of as landline voice
only evolves into something more interesting where the TV is really the
phone and full SIP based UC based on all SIP interconnection is possible.
You are falling into the other trap of extrapolating some data points to a
conclusion where technology may  enable a different outcome.  As JM Keynes
said "in the long run we are all dead"

We've both seen the charts that show how rapidly that market is diminishing.
What's replacing it? 

RS> The data is misleading since it relies on regulatory data that looks at
"lines" vs "numbers utilized" .   Of course landline phones are declining
especially in key demographics but it is not as bad as people think.  Just
as Skype has not really damaged the interconnected voice markets. Only
eroded its margins.  The same is playing out in SMS.  The fractured silos of
IM/SIMPLE etc only enhanced the value of the crappy SMS service. WhatsAPP
etc are still E.164 based for a reason. Universal reachability actually
works and people pay for what works.  As a side bar this is the reason I
don't have a lot of confidence WEBRTC is really going to be the New New
thing.   

Unfortunately, little by way of direct IP-to-IP communication, and far more
calls being dropped to the PSTN. 

RS> Well again I have already shown that there is far more SIP 2 SIP
communication now in deployment than people realize and that is going to
accelerate. 

Again, this is exactly where the out-of-band solution can help. We can argue
about where the right place is to implement and operate it - and I don't
think there's any consensus about that yet - but we've heard strategies that
would work at endpoints (maybe ATAs) or in the network.

RS>  EKR's proposal .. no way.  Too many endpoints would never be able to
access the data given the need to deploy at least one _deployable_ solution
in a reasonable time frame.   

RS> That said now that you have had your daily dose of market reality we can
return you to your regularly schedule program...

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Jul 2013 12:44:50 -0700

> assessing their salience to the out-of-band proposal.

Do we really want to keep discussing the out-of-band topic.  The more we 
spend talking about it, a) the less we spend on the in-band one, and b) 
the more it looks like we want to include it in the initial work.

If the group wants to focus on a single, narrow deliverable as its 
initial effort, it needs to focus on that signle, narrow deliverable...

d/

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Mon, 1 Jul 2013 16:04:50 -0400

Rich, Eric,

CDMA radios use spread spectrum technology.  They can receive from multiple sources, each of which is encoded using its own pseudo-random code.  The radio has to "lock" to one input source (at a time) because it needs that code in order to recover the data.

If the 'data' source is e.g., the Internet, and the alerting source is the voice network, a single radio couldn't receive them both at the same time.

Conventional (3G) CDMA phones are single radio systems.  I think that's what Rich is referring to.

Technology changes fast in the mobile world, though.  I'm tempted to say "just assume VoLTE", which will of course support simultaneous voice and data, and which should be widely available in the timeframe that this (or any) WG can produce an RFC.  But I wouldn't swear that the rise of VoLTE means the demise of 3G.  Landline replacement services based on 3G technology, for example, are gaining traction.

Tim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Monday, July 01, 2013 1:36 PM
To: 'Eric Rescorla'
Cc: [email-masked]
Subject: Re: [stir] Out-of-band vs. in-band

[RS> ]  Well you still ignore that any carrier using CDMA right now cannot deploy your proposed solution since it cannot do data and Voice at the same time. Verizon Sprint and Korea Telecom might have something to say about that.

[RS> ] I doubt the interval is long enough. Frankly I don't know. But you should ask Apple among others :)

-Ekr

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 1 Jul 2013 20:24:20 +0000

I'm getting a bit worried that the in-band/out-of-band description sets up an artificial division that presumes certain implementation choices or particular proposals. Particularly given some of the discussion about DNS-based retrievals of certificates and/or public keys, there may well be options that query databases, regardless of whether the identifying information is delivered by SIP or some non-SIP mechanism.

In both cases, we seem to agree that three pieces of information arrive at the callee or an entity (carrier) acting on its behalf: the calling number, the called number and the time of call origination. These are, with quibbles we have labored through, available regardless of how the call reaches its destination.

We also seem to agree that there is a certificate or public key that's bound by one (per country) or possibly more (if web) trusted entities to a number and its assignees, in either "in-band" or "out-of-band" discussion.

If we suppose a database (for Hadriel, DNS), that maps the number to an authorized database, the basic query is very similar: "hey, authorized database, what's your public key/cert for this number" vs. "hey, authorized database, where's your signed fragment". 

In the latter case, the piece of data retrieved could be some version of the same signed block that would be attached to signaling ("in-band"), i.e., a signed version of the (logical) From, To and Date. It could even look textually like 4474(bis), if we wanted to. Thus, this seems more like a variation of the transport mechanism than a fundamentally different model. In that way, the non-SIP delivery  can organically build on the SIP delivery to bypass non-IP hops. The database can well be operated by gateway providers, i.e., just before the call leaves SIP land.

In both cases, we have to solve the "find database for number/call" problem, where we seem to have both explicit ("here's the URL in the header") and implicit (DNS) models as proposals.

Thus, maybe we can avoid the unproductive in-band/out-of-band distinction and see if there's an overarching model that essentially starts with the same identity-signing model, and considers three ways, in decreasing attachment strength to the call:

(1) cert is attached to the call, as a MIME multipart (as in 4474)
(2) cert/PK is referenced via a URL or implicitly by number (again, similar to 4474, plus the DNS-style proposals)
(3) fragment is implicitly referenced, which in turn then uses (1) or (2) to get the cert/PK

In the telephony space, we already have this model in CNAM, with multiple competing databases providing number-to-text lookup.

The charter presumably wouldn't want to get into this level of detail, but it may be sufficient to simply mention that both cert and call information can be delivered in various ways. I have no objection to starting with the simplest cases (#1 and #2), while keeping the larger picture in mind. This avoids, I hope, the need to create two global infrastructures that Dave is worried about.

I also don't see the models as competing - we have had multiple signaling protocols in telephony for decades, and, because the overall model is reasonably uniform, this works well enough. This may be more of a problem of "The (SIP) future is already here - it's just not very evenly distributed."

On a separate note, I do see the attraction of a race - if (say) smartphone users can block robocalls, but landline users are inundated with them, the latter may well be incented to get with the program to keep their customers.

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Monday, July 01, 2013 3:45 PM
To: Richard Shockey
Cc: 'Peterson, Jon'; 'Eric Rescorla'; 'DOLLY, MARTIN C'; [email-masked]; Henning Schulzrinne
Subject: Re: [stir] Out-of-band vs. in-band

On 7/1/2013 12:33 PM, Richard Shockey wrote:
> You're studying the right trends here, but I'm not sure you're 
> correctly assessing their salience to the out-of-band proposal.

Do we really want to keep discussing the out-of-band topic.  The more we spend talking about it, a) the less we spend on the in-band one, and b) the more it looks like we want to include it in the initial work.

If the group wants to focus on a single, narrow deliverable as its initial effort, it needs to focus on that signle, narrow deliverable...

d/

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Jul 2013 02:13:23 -0400

> If we suppose a database (for Hadriel, DNS), that maps the number to an authorized database, the basic query is very similar: "hey, authorized database, what's your public key/cert for this number"…

Are we talking about someday being on The Public DNS, or just for a restricted-access one?

Unfortunately for The Public DNS, an E.164 node in the DNS redirecting to a specific carrier's database reveals that the E.164 belongs to the carrier.  Someday that might be ok, but not anytime soon.

That's why the DNS idea only put a public-key in the E.164 node, with no information identifying the carrier.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 2 Jul 2013 17:34:23 +0000

This is probably an operational detail, but the database could well be operated by a third party or multiple third parties, just like CNAM databases. You could even have the same number appear in multiple databases, if additional obscurity is desired.

For reasons mentioned earlier by others, I suspect that this would be private DNS (or servers) regardless of the number visibility issue, but that doesn't seem like something we need to prescribe.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2013 2:13 AM
To: Henning Schulzrinne
Cc: [email-masked]'; Richard Shockey; [email-masked]; 'Eric Rescorla'; 'DOLLY, MARTIN C'; 'Peterson, Jon'
Subject: Re: [stir] Out-of-band vs. in-band

-hadriel

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Tue, 2 Jul 2013 13:44:19 -0400

Henning,

Small clarification:  (As I know you know) CNAM databases are not queried by the end user, they are queried by the terminating network.  The end user can neither query the CNAM database nor cause such a query to be performed (other than through subscription in a service that includes calling party presentation).  I agree that such a database could be operated by a 3rd party, but at least with respect to how and by whom it is accessed, it would be different.

Tim

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2013 2:13 AM
To: Henning Schulzrinne
Cc: [email-masked]'; Richard Shockey; [email-masked]; 'Eric Rescorla'; 'DOLLY, MARTIN C'; 'Peterson, Jon'
Subject: Re: [stir] Out-of-band vs. in-band

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 2 Jul 2013 17:57:28 +0000

Thanks for emphasizing this. The current CNAM-style model would indeed only apply to validation by the terminating carrier, but the basic model of having multiple intermediaries that are not carriers offer database access services seems to be more general. (In the CNAM case, it's probably less a technical reason, but rather that their business model of dip charges doesn't really work for consumer access. You could imagine various intermediary models - the app vendor contracts with the database provider and pays for bulk access based on their subscription or advertising revenue, for example.)

Vaguely related: On the government side, we make numerous entity-related items available to the public via HTTP APIs (see http://www.fcc.gov/developers). NPAC provides a number-related API for law enforcement (http://www.npac.com/the-npac/access/law-enforcement-agencies-psaps).

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2013 1:44 PM
To: Henning Schulzrinne; 'Hadriel Kaplan'
Cc: 'Eric Rescorla'; 'Peterson, Jon'; 'DOLLY, MARTIN C'; Richard Shockey; [email-masked]; [email-masked]'
Subject: RE: [stir] Out-of-band vs. in-band

Henning,

Tim

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Tue, 2 Jul 2013 14:30:29 -0400

Agreed.  The abstraction of an API would let us resolve a number of issues, e.g., privacy and security of the underlying databases.

tim 

-----Original Message-----
From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Tuesday, July 02, 2013 1:44 PM
To: Henning Schulzrinne; 'Hadriel Kaplan'
Cc: 'Eric Rescorla'; 'Peterson, Jon'; 'DOLLY, MARTIN C'; Richard Shockey; [email-masked]; [email-masked]'
Subject: RE: [stir] Out-of-band vs. in-band

Henning,

Tim

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Jul 2013 18:13:38 -0400

I'm not in the business of providing smart-phone apps, but ISTM most of the successful ones are free.  They're often provided for free by the company that provides the "database" or service (for lack of a better term to describe the stuff on the Internet-side).  The actual money comes from other sources.

In this caller-id verification case, I would assume the money for such a "database" service either comes from callers who would be willing to pay (e.g., banks, airlines, etc.), or from the carriers.

So why would the "database" service even *want* a standard to follow?  They'll make the app themselves and give it out for free, and they'll decide how the app gets its info and what features it needs to have and so on.  They'll likely want to provide far more than a simple caller-id.  For example they would want to provide a calling name, website, email address, and other contact-card info; maybe even a picture or brand logo/icon.  We don't know what they'd want, and such a company wouldn't want to wait for a standard to tell them what/how.

Standards are only necessary and useful if more than one manufacturer/service/vendor needs and wants to interoperate with another.  So unless you get multiple of these database providers to participate in the IETF, and tell us what they want and how they want it, I don't see the point of repeating the ATOCA working group in STIR.

-hadriel

---

From: "Dwight, Timothy M \(Tim\)" <[email-masked]>
Date: Wed, 3 Jul 2013 09:54:04 -0400

Hadriel,

I thought there was from the outset some notion that compliance would be made compulsory (by regulators).  I assume that's part of what motivates standardization.

I'm not sure the invocation of this functionality has to be in an "app", by the way.  ISTM it could also be provided by the device OEM as part of the standard dialer.  The latter is more easily achieved if the API is standardized.

Both options may be viable of course.  For example some OEMs might provide this functionality in some smart phones, whereas users of older phones might need to download the functionality in the form of an app.

I do agree that it would be difficult at this stage to standardize a "fancy" app, that provided the type of additional information about the caller you list below.  IMHO if we attempt to standardize any API it should be a "minimalist" one that only supports calling party verification.  This would not of course preclude 3rd parties from wrapping that API in one of their own and augmenting the information provided to the user.

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Tuesday, July 02, 2013 5:14 PM
To: Henning Schulzrinne
Cc: [email-masked]; Dwight, Timothy M (Tim)
Subject: Re: [stir] Out-of-band vs. in-band

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Jul 2013 12:14:17 -0400

> I thought there was from the outset some notion that compliance would be made compulsory (by regulators).  I assume that's part of what motivates standardization.

Nope.  I specifically asked that question, but the answer is no there's no mandate.
That's not to say I don't think we need to do something - we do.

> I'm not sure the invocation of this functionality has to be in an "app", by the way.  ISTM it could also be provided by the device OEM as part of the standard dialer.  The latter is more easily ach…

Of course - I too would expect that.  I can imagine them getting the data in-band from the carrier, for example.

I'm not saying there isn't a market for app-based or even phone-OEM-based caller-id verification.  I'm saying trying to figure out what the deployment, protocol, API, and requirements are for such a solution is a waste of time unless we get the actual players for that involved in the IETF.

Imagine if we weren't talking about an in-band solution at all.  Instead we wanted to form STIR purely to define this out-of-band solution.  What would be our chances of success?  By "success" I mean both in producing an RFC as well as getting people to actually deploy and use it.  We don't have those people involved here.      The IETF has rarely been successful without the involvement of those who plan to use/implement/deploy the stuff.

-hadriel

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 3 Jul 2013 16:49:48 +0000

We generally don't do well attracting small software/app vendors to the IETF, but I could imagine that standards would lower the bar to entry, since not every such provider will have to get all originating providers to provide call information (and each originating provider would have to deal with multiple entities). 

I wouldn't be surprised if organizations represented on this mailing list would be interested in providing such a service, but they are not likely to step up and announce their tentative business plans.

________________________________________
From: Dwight, Timothy M (Tim) [[email-masked]]
Sent: Wednesday, July 03, 2013 9:54 AM
To: Hadriel Kaplan; Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [stir] Out-of-band vs. in-band

Hadriel,

tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Tuesday, July 02, 2013 5:14 PM
To: Henning Schulzrinne
Cc: [email-masked]; Dwight, Timothy M (Tim)
Subject: Re: [stir] Out-of-band vs. in-band

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Jul 2013 16:33:08 -0700

> For reasons mentioned earlier by others, I suspect that this would be
> private DNS (or servers) regardless of the number visibility issue,
> but that doesn't seem like something we need to prescribe.

This is an example of a core issue that keeps prompting conflicting 
statements.

What I heard early in discussion was that validation was to be possible 
by enterprises and SIP UAs.  That requires a public external service for 
retrieving validation parameters.

The larger point is that it really is important to establish a stable, 
small, clear set of basic functional requirements so that design 
discussions (and debates) can rely on them.

And to anticipate one line of logic that also has shown up a number of 
times, whatever is done initially is what's likely to stay in place 
forever.  Projections that something will be done one way at first and 
then somehow, later, be done differently, has little precedent on the 
Internet.  (Marc Anthony got it right: the evil men do really does live 
after them.)

So, for example, having the external query service be private initially 
means it will stay private.

d/

ps. One issue that I've been unclear about is how the validated 
telephone number will get used.  That is, the processing agent now has a 
validated number.  So what?  What can/will be done differently and why 
are we sure that it really will be?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 03 Jul 2013 16:44:40 -0700

On 7/2/2013 10:57 AM, Henning Schulzrinne wrote:
> Vaguely related: On the government side, we make numerous entity-related items available to the public via HTTP APIs

HTTP-based queries require a tcp open, at least one http exchange, and a 
tcp close.  I never get the count right, but that's somewhere around 5-7 
round-trip times.  Since the current requirement is for queries from 
anywhere on the net to anywhere on the net, these aggregate round-trip 
latencies can be significant.  Measured in seconds.

My understanding is that verification needs to be performed within the 
final stages of call set up.  I assume that's a window of less than a 
second, and presumably quite a bit less.

One of the functional requirements that would be helpful to specify is 
the performance window that must be met by the validation mechanism.

d/

ps. A facile response to response-time concerns is to invoke various 
optimizations such as caching connections, or the like.  That's fine, 
except when it isn't, which is frequently.  Designing for best-case 
scenarios is a tad fragile.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 4 Jul 2013 12:11:48 -0400

Excellent point and a very good reminder.  If memory serves me correctly in
SS7 based CNAM the data retrieval is performed literally between the first
and second ring on the terminating carrier networks. Less than .5 seconds. 

One of the important points here is we are trying to maintain the existing
QoS QoE consumers and enterprises have come to expect. Call set up and delay
is different in mobile networks. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Wednesday, July 03, 2013 7:45 PM
To: [email-masked]
Subject: [stir] response-time window ( was Re: Out-of-band vs. in-band

On 7/2/2013 10:57 AM, Henning Schulzrinne wrote:
> Vaguely related: On the government side, we make numerous 
> entity-related items available to the public via HTTP APIs

HTTP-based queries require a tcp open, at least one http exchange, and a tcp
close.  I never get the count right, but that's somewhere around 5-7
round-trip times.  Since the current requirement is for queries from
anywhere on the net to anywhere on the net, these aggregate round-trip
latencies can be significant.  Measured in seconds.

My understanding is that verification needs to be performed within the final
stages of call set up.  I assume that's a window of less than a second, and
presumably quite a bit less.

One of the functional requirements that would be helpful to specify is the
performance window that must be met by the validation mechanism.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 5 Jul 2013 15:19:20 +0000

There are two cases: If a carrier validates, the TCP/HTTP connection to the server will most likely be reused, i.e., no TCP or TLS overhead on a per-query basis. The query overhead would be essentially the same as a UDP-based query, i.e., one RTT. For end system validation, which is almost invariably going to occur on mobile devices (smartphones), any query overhead would add to the post-dial delay and indeed incur the setup cost you mention. As Richard alludes to, there are no standards for PDD, but I did find

http://www.niccstandards.org.uk/files/current/ND1704v1_2_2.pdf?type=pdf

It postulates a PDD of 10 seconds for mobile connections, so 1-2 seconds for the query are annoying but hardly a deal breaker. This would only likely occur for calls not in the user's address book.

Just to re-iterate: I suspect all or almost all of us would prefer an infrastructure solution. If no such solution is forthcoming, however, I suspect that there is a market for consumers who are willing to trade off increased delay for what are mostly robocalls for a bit of peace-and-quiet. There are millions that do this today, despite rather limited functionality.

Henning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, July 03, 2013 7:45 PM
To: [email-masked]
Subject: [stir] response-time window ( was Re: Out-of-band vs. in-band

> entity-related items available to the public via HTTP APIs

HTTP-based queries require a tcp open, at least one http exchange, and a tcp close.  I never get the count right, but that's somewhere around 5-7 round-trip times.  Since the current requirement is for queries from anywhere on the net to anywhere on the net, these aggregate round-trip latencies can be significant.  Measured in seconds.

My understanding is that verification needs to be performed within the final stages of call set up.  I assume that's a window of less than a second, and presumably quite a bit less.

One of the functional requirements that would be helpful to specify is the performance window that must be met by the validation mechanism.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 5 Jul 2013 15:40:12 +0000

I'm not sure I follow this generalization. 

DNS (not just for ENUM) clearly has evolved into both a private and a public service; similarly, for LDAP and (obviously) HTTP, so almost any query service seems to eventually develop both modes. I think this goes back as far as the old Unix "finger" protocol...

In some cases, support is explicit (e.g., by baking authentication/authorization into the protocol), in others, it's implicit (e.g., by various VPN, firewalling and network address filtering solutions, as in local general DNS and private ENUM), and in many cases, both. (HTTP servers restrict access both based on explicit and address-based criteria.)

If your argument is that it would be a good requirement to anticipate that both modes will invariably arise, I tend to agree.

The overall requirement is pretty simple, I think: as many authorized entities as possible should be able to assert number usage and as many entities as possible along the call path should be able to validate. As a minimum requirement, all SIP entities (UAs, proxies, SBCs and B2BUAs) should be able to act as certifier and validator. As a desirable requirement, entities that are separated by SS7 or other non-IP stretches should be able to validate. As I've been trying to argue, this can and should be part of the same overall architecture, i.e., it would be nice if neither certifier nor validator has to know about the nature of the other side. We have discussed two models to make this happen:

(1) in some cases, the SIP Identity-style information can be tunneled through SS7, via UUI, and re-inserted into the SIP call, if needed. As far as I can tell, this doesn't seem controversial. The only issue is how often this is feasible.

(2) In other cases, the SIP Identity-style information may be carried in IP mechanisms even if the call itself is not signaled that way. I suspect we need more concrete proposals here to see if this can be integrated into the overall model, satisfying the "blissful ignorance" criteria I mentioned earlier.

In all cases, the fundamental model ("number assignment authority provides certificate directly or indirectly", as well as the protection realm) is the same and the assertion ("Caller X is entitled to use number N for this call") as well.

Logically, I think this leads to 4 drafts:

(1) The certificate or cryptographic object (if not X.509) structure.

(2) The SIP headers.

(3) How to embed (2) into SS7 UUI.

(4) How to deal with non-IP stretches.

Henning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, July 03, 2013 7:33 PM
To: [email-masked]
Cc: [email-masked]'
Subject: [stir] Follow the bouncing requirements (was - Re: Out-of-band vs. in-band)

> but that doesn't seem like something we need to prescribe.

This is an example of a core issue that keeps prompting conflicting statements.

What I heard early in discussion was that validation was to be possible by enterprises and SIP UAs.  That requires a public external service for retrieving validation parameters.

The larger point is that it really is important to establish a stable, small, clear set of basic functional requirements so that design discussions (and debates) can rely on them.

And to anticipate one line of logic that also has shown up a number of times, whatever is done initially is what's likely to stay in place forever.  Projections that something will be done one way at first and then somehow, later, be done differently, has little precedent on the Internet.  (Marc Anthony got it right: the evil men do really does live after them.)

So, for example, having the external query service be private initially means it will stay private.

d/

ps. One issue that I've been unclear about is how the validated telephone number will get used.  That is, the processing agent now has a validated number.  So what?  What can/will be done differently and why are we sure that it really will be?

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 5 Jul 2013 12:24:20 -0400

As a series of phase one drafts .. I completely agree. 

>From that you naturally lead to 

A. Number Translation HTTP vs DNS 6116 

B. Certificate Discovery HTTP vs DNS 6116

C. Transport that should be relatively easy. 

Oh ... regulatory enforcement/encouragement mechanisms.    This is Tim
Dwight's point.  We can certainly build this thing but the rules as written
leave US carriers few options.   As it stands they cannot block an offending
call center. "The Call must go through". 

 What limitations of liability would the carrier be offered under these
circumstances?   Ok yes this is a US centric view and it seems that some
national jurisdictions have considerably more leeway in how to deal with bad
actors.  The Germans for instance.  We need better data on what is happening
in the EC Asia etc. 

I've certainly been convinced from the outset that any IETF solution is no
silver bullet there has to be some cooperation from the regulators since its
their namespace after all. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Friday, July 05, 2013 11:40 AM
To: [email-masked]'; [email-masked]
Subject: Re: [stir] Follow the bouncing requirements (was - Re: Out-of-band
vs. in-band)

DNS (not just for ENUM) clearly has evolved into both a private and a public
service; similarly, for LDAP and (obviously) HTTP, so almost any query
service seems to eventually develop both modes. I think this goes back as
far as the old Unix "finger" protocol...

In some cases, support is explicit (e.g., by baking
authentication/authorization into the protocol), in others, it's implicit
(e.g., by various VPN, firewalling and network address filtering solutions,
as in local general DNS and private ENUM), and in many cases, both. (HTTP
servers restrict access both based on explicit and address-based criteria.)

If your argument is that it would be a good requirement to anticipate that
both modes will invariably arise, I tend to agree.

The overall requirement is pretty simple, I think: as many authorized
entities as possible should be able to assert number usage and as many
entities as possible along the call path should be able to validate. As a
minimum requirement, all SIP entities (UAs, proxies, SBCs and B2BUAs) should
be able to act as certifier and validator. As a desirable requirement,
entities that are separated by SS7 or other non-IP stretches should be able
to validate. As I've been trying to argue, this can and should be part of
the same overall architecture, i.e., it would be nice if neither certifier
nor validator has to know about the nature of the other side. We have
discussed two models to make this happen:

(1) in some cases, the SIP Identity-style information can be tunneled
through SS7, via UUI, and re-inserted into the SIP call, if needed. As far
as I can tell, this doesn't seem controversial. The only issue is how often
this is feasible.

(2) In other cases, the SIP Identity-style information may be carried in IP
mechanisms even if the call itself is not signaled that way. I suspect we
need more concrete proposals here to see if this can be integrated into the
overall model, satisfying the "blissful ignorance" criteria I mentioned
earlier.

In all cases, the fundamental model ("number assignment authority provides
certificate directly or indirectly", as well as the protection realm) is the
same and the assertion ("Caller X is entitled to use number N for this
call") as well.

(2) The SIP headers.

Henning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Wednesday, July 03, 2013 7:33 PM
To: [email-masked]
Cc: [email-masked]'
Subject: [stir] Follow the bouncing requirements (was - Re: Out-of-band vs.
in-band)

What I heard early in discussion was that validation was to be possible by
enterprises and SIP UAs.  That requires a public external service for
retrieving validation parameters.

The larger point is that it really is important to establish a stable,
small, clear set of basic functional requirements so that design discussions
(and debates) can rely on them.

And to anticipate one line of logic that also has shown up a number of
times, whatever is done initially is what's likely to stay in place forever.
Projections that something will be done one way at first and then somehow,
later, be done differently, has little precedent on the Internet.  (Marc
Anthony got it right: the evil men do really does live after them.)

d/

ps. One issue that I've been unclear about is how the validated telephone
number will get used.  That is, the processing agent now has a validated
number.  So what?  What can/will be done differently and why are we sure
that it really will be?

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Jul 2013 00:12:23 +0000

> HTTP-based queries require a tcp open, at least one http exchange, and a tcp close.  I never get the count right, but that's somewhere around 5-7 round-trip times.  Since the current requirement is…

sort of a tangent but we are seeing solutions coming out for HTTPS transactions that work in one round trip (never mind the are called zero round trip :-)

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Jul 2013 14:34:58 +0100

On 7/20/2013 1:12 AM, Cullen Jennings (fluffy) wrote:
> sort of a tangent but we are seeing solutions coming out for HTTPS transactions that work in one round trip (never mind the are called zero round trip:-)

There have been a number of recitations of very low transaction overhead 
when using an HTTP-based mechanism.  (The 'S' just makes it sound 
sexier, while adding another layer of mechanism.)

I'm sure the recitations are accurate, but only within some significant 
operating constraints.

In this case, the essential requirement is going to be -- at the very 
least -- that the validator already has an open TCP connection and a 
working session with the server being queried.

Fast-path analysis of connection behavior gives best-case numbers and 
it's always an important part of understanding the overall mix of 
performance issues.

However it's also nearly always irrelevant to the analysis of a 
zero-context exchange.  That is, when the validator makes a first 
contact with a server.

For some very large percentage of likely traffic, maintaining a 
continuing context amongst major validators and major servers will no 
doubt give wonderful numbers.  When MajorTelcoA's validator queries the 
server for Major TelcoB.

Unfortunately, they aren't the interesting case when designing a global 
protocol.

For the current topic, the interesting case is an enterprise or 
smartphone validator querying a server for a number the validator has 
never seen before.

That's going to incur all the 5-7 round-trip latencies -- heck, maybe 
more -- with all of the significantly variable delays we see across the 
open Internet.

d/

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 20 Jul 2013 21:56:29 +0000

As discussed in a previous round of this same discussion, the likely case is that high-volume validators will cache all (domestic) records; the complete database easily fits in a single disk.

For end system validation on mobile devices, if that were to be used, the post-dial delay is already several seconds, so the additional latency is probably not a major change, particularly if you optimize by caching records for numbers in your address book and call log. In all likelihood, good calls to personal devices are already in your call log or address book, and the additional delay for an occasional legitimate automated phone call, let alone the unwanted robocall, is not likely to be significant from a user experience. After all, the dentist office appointment reminder robot doesn't care whether the call takes a few more seconds to pick up.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Dave Crocker [[email-masked]]
Sent: Saturday, July 20, 2013 9:34 AM
To: Cullen Jennings (fluffy)
Cc: [email-masked]
Subject: Re: [stir] response-time window ( was Re: Out-of-band vs. in-band

d/