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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 7 Nov 2013 21:26:25 +0000

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)

-----Original Message-----
From: Wolfgang Beck [[email-masked]<mailto:[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 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: "Holmes, David W [NTK]" <[email-masked]>
Date: Thu, 7 Nov 2013 21:58:38 +0000

Maybe this has been considered before, but surely a "callback" approach could be made to work based on a the returned "callee" ID (called TN) in the "callback" message being used to route the returned call beyond the "callback" number (i.e. like a firewall/NAT function) - which is another description of Wolfgang's idea below?  The callee would receive only the gateway/call center/doctor's office TN/ID, and the callee-based routing translation would only have a limited life, TBD by the originating server.  I know this has implications for routing the call in some cases (e.g. doctor's call to patient must route through doctor's office), but these may allow additional advantages beyond simple TN verification.  ~ David

________________________________
From: [email-masked] [[email-masked]] on behalf of Peterson, Jon [[email-masked]]
Sent: Thursday, November 07, 2013 1:26 PM
To: 'Wolfgang Beck'; [email-masked]'
Subject: Re: [stir] new SIP Method DYPTC 'Did You Place This Call?'

Jon Peterson
Neustar, inc.

-----Original Message-----
From: Wolfgang Beck [[email-masked]<mailto:[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?'

Wolfgang Beck

________________________________

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: Wolfgang Beck <[email-masked]>
Date: Thu, 7 Nov 2013 23:23:07 +0100

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.
>