Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?'

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 7 Nov 2013 22:38:02 +0000

I believe that SIP messages routed to telephone numbers today are mostly frequently dropped to the PSTN, and may eventually re-enter the Internet or not. In cases where requests targeting telephone numbers do travel end-to-end over the Internet, various flat files and private databases are consulted to forward requests hop-by-hop until they reach a destination. The relationships of those mechanisms to numbering authorities can be tenuous today, precisely because of the absence of the authority architecture this working group is considering.

There's no free lunch here.

Jon Peterson
Neustar, Inc.

Sent with Good (www.good.com)

-----Original Message-----
From: Wolfgang Beck [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 07, 2013 05:23 PM Eastern Standard Time
To: Peterson, Jon
Cc: [email-masked]
Subject: RE: [stir] new SIP Method DYPTC 'Did You Place This Call?'

Would you agree that such a SIP message would arrive at an element of a party that has delegated the number to its current user? Solving the problem 'who owns this number?' seems easier to me inside the system than in a separate one.

Am 07.11.2013 13:26 schrieb "Peterson, Jon" <[email-masked]<mailto:[email-masked]>>:
Various "callback" mechanisms along these lines have been considered, and there are known limitations of these mechanisms, most of which result from the fact that placing a call from a number does not guarantee that a returned call would reach the same endpoint instance. Gateways, call centers, users with multiple concurrently registered devices, all of our "doctor's office" use cases and related configurations show why approaches along these lines are insufficient.

Jon Peterson
Neustar, inc.

Sent with Good (www.good.com<http://www.good.com>)

-----Original Message-----
From: Wolfgang Beck [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard Time
To: [email-masked]<mailto:[email-masked]>
Subject: [stir] new SIP Method DYPTC 'Did You Place This Call?'

Here's a half-baked idea: when a call c1 arives from <a>, I send a DYPTC SIP request message outside of this call back to <a>. The DYPTC request carries some headers that describe c1, eg. the original from and to.

- if the receiving UA is indeed <a>, it responds with 200 OK. The origin of call c1 is now verified.

- if <a> was spoofed by somebody, the request will arrive at a UA that does not know about the call described by DYPTC. It responds with 404 Not Found

- if <a> was spoofed and there is no UA reachable, the request will time out or the network will generate a 404 Not found.

Whenever I dont receive a 200 OK on a DYPTC, the calling number could not be verified.

So far all methods to determine a party that can verify a number seem to boil down to one of the two groups:

1. create a new database, replicated from the telcos' databases, that can be accessed by end devices. That's what iMessage, whatsapp, and VIPR try to do. Accurately replicating a fairly dynamic database without its cooperation is a challenge.

2. create a way so that end devices can directly query the telcos' databases. DNS is an obvious candidate for this.

However, accessing the database itself is not enough. The end device would have to replicate all routing decisions the telcos make. All discussions about PBXs and number portability are essentially about the routing inside the telcos.

Why not just use the existing platform to verify calling numbers?

Wolfgang Beck

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 7 Nov 2013 18:19:21 -0500

In general I have to agree with Jon here with some exceptions.  The level of SIP end to end in the US network is actually quite high and with the advent of VoLTE in the next 2 years it will easily top 50% of all voice minutes.

That said most of these transactions use IP technology and not necessarily BGP routed “Internet”.  These transactions I have usually charactized as Voice USING IP not Voice Over IP. 

Jon is correct that the current database methodologies in use for VuIP are rather “tenuous” to say the least.. try Excel spreadsheets.  That said it is clear also clear that a restructure of the national numbering databases will have to occur to facilitate end to end SIP across carrier boundaries and whatever STIR mechanism is ultimately chosen.  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Thursday, November 07, 2013 5:38 PM
To: 'Wolfgang Beck'
Cc: [email-masked]'
Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?'

Jon Peterson
Neustar, Inc.

Sent with Good (www.good.com <http://www.good.com> )

-----Original Message-----
From: Wolfgang Beck [[email-masked] <mailto:[email-masked]> ]
Sent: Thursday, November 07, 2013 05:23 PM Eastern Standard Time
To: Peterson, Jon
Cc: [email-masked] <mailto:[email-masked]> 
Subject: RE: [stir] new SIP Method DYPTC 'Did You Place This Call?'

Am 07.11.2013 13:26 schrieb "Peterson, Jon" <[email-masked] <mailto:[email-masked]> >:

Jon Peterson
Neustar, inc.

Sent with Good (www.good.com <http://www.good.com> )

-----Original Message-----
From: Wolfgang Beck [[email-masked] <mailto:[email-masked]> ]
Sent: Thursday, November 07, 2013 04:18 PM Eastern Standard Time
To: [email-masked] <mailto:[email-masked]> 
Subject: [stir] new SIP Method DYPTC 'Did You Place This Call?'

Wolfgang Beck

---

From: Wolfgang Beck <[email-masked]>
Date: Fri, 8 Nov 2013 01:12:07 +0100

VIPR, whatsapp, iMessage all use the phone network for verification. Public
ENUM registrars used it. The principle seems to be working for sufficiently
large number of cases.
Am 07.11.2013 14:38 schrieb "Peterson, Jon" <[email-masked]>:

>
> I believe that SIP messages routed to telephone numbers today are mostly
> frequently dropped to the PSTN, and may eventually re-enter the Internet or
> not. In cases where requests targeting telephone numbers do travel
> end-to-end over the Internet, various flat files and private databases are
> consulted to forward requests hop-by-hop until they reach a destination.
> The relationships of those mechanisms to numbering authorities can be
> tenuous today, precisely because of the absence of the authority
> architecture this working group is considering.
>
> *From: *Wolfgang Beck [[email-masked]]
> *Sent: *Thursday, November 07, 2013 05:23 PM Eastern Standard Time
> *To: *Peterson, Jon
> *Cc: [email-masked]
> *Subject: *RE: [stir] new SIP Method DYPTC 'Did You Place This Call?'
>
> Would you agree that such a SIP message would arrive at an element of a
> party that has delegated the number to its current user? Solving the
> problem 'who owns this number?' seems easier to me inside the system than
> in a separate one.
> Am 07.11.2013 13:26 schrieb "Peterson, Jon" <[email-masked]>:
>
>> Various "callback" mechanisms along these lines have been considered, and
>> there are known limitations of these mechanisms, most of which result from
>> the fact that placing a call from a number does not guarantee that a
>> returned call would reach the same endpoint instance. Gateways, call
>> centers, users with multiple concurrently registered devices, all of our
>> "doctor's office" use cases and related configurations show why approaches
>> along these lines are insufficient.
>>
>> Jon Peterson
>> Neustar, inc.
>>
>>
>>
>> *From: *Wolfgang Beck [[email-masked]]
>> *Sent: *Thursday, November 07, 2013 04:18 PM Eastern Standard Time
>> *To: [email-masked]
>> *Subject: *[stir] new SIP Method DYPTC 'Did You Place This Call?'
>>
>>    Here's a half-baked idea: when a call c1 arives from <a>, I send a
>> DYPTC SIP request message outside of this call back to <a>. The DYPTC
>> request carries some headers that describe c1, eg. the original from and to.
>>
>> - if <a> was spoofed by somebody, the request will arrive at a UA that
>> does not know about the call described by DYPTC. It responds with 404 Not
>> Found
>>
>> - if <a> was spoofed and there is no UA reachable, the request will time
>> out or the network will generate a 404 Not found.
>>
>>  1. create a new database, replicated from the telcos' databases, that
>> can be accessed by end devices. That's what iMessage, whatsapp, and VIPR
>> try to do. Accurately replicating a fairly dynamic database without its
>> cooperation is a challenge.
>>
>>  2. create a way so that end devices can directly query the telcos'
>> databases. DNS is an obvious candidate for this.
>>
>>  However, accessing the database itself is not enough. The end device
>> would have to replicate all routing decisions the telcos make. All
>> discussions about PBXs and number portability are essentially about the
>> routing inside the telcos.
>>