Subject: Re: [VIPR] Creating an alt-root for E.164

From: Daryl Malas <[email-masked]>
Date: Fri, 1 Apr 2011 02:33:49 -0600

Hadriel,

Using your analogy, is there any reason why the IP/PBX could not perform
VIPR on behalf of it's registered UAs? So, regardless of who the TN is
ultimately assigned to, the IP/PBX ultimately is the associated UA for the
VIPR exchanges and IP/Internet path?  The draft refers to SIP endpoints,
and in the real world an IP/PBX (B2BUA) is a SIP endpoint -- whether we
like it or not.

Regards,

Daryl 

On 3/31/11 4:36 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>Howdy,
>I apologize if this has been hashed out already - if so please tell me to
>RTFM and I'll try and find the thread. (I did google already without luck)
>
>I have a question about why we're ok with creating an alt-root for ITU's
>ownership of E.164 in an IETF protocol.  By that I mean that for however
>long the vipr client is willing to believe the vipr-resolved URI
>represents the E.164, it is not querying the authoritative database (ie,
>the PSTN).  The truth of the matter is your phone does not own and is not
>authoritative for the E.164 phone number - afaik only the ITU is truly
>authoritative for it (but yes assigns them out downhill).
>
>So for example, right now if you dial the E.164 +1-781-328-4428, it
>resolves to my desk phone (well, actually to voicemail since I never
>answer my desk phone).  Let's pretend my desk phone did vipr.  If I get
>fired or quit tomorrow, my employer would re-allocate my number
>immediately - most likely to a receptionist for some period of time, and
>ultimately to a new employee.  From my employer's perspective, they "own"
>+1-781-328-4428, and should have the right/power to reallocate it at
>their leisure/whim.  Yet VIPR moves the ownership time decision to the
>caller, for whatever duration time it wants to use.
>
>In the IETF we have a long-standing concern with creating an alt-root for
>DNS.  So to put this in terms people here may grok, imagine if we have
>vipr resolve email addresses instead of E.164 numbers.  I send an email
>through my email server to "[email-masked]".  My email server
>subsequently uses a vipr model to learn a "direct" URI of
>"mail:[email-masked]" or even "mail:[email-masked]", and sends all my
>subsequent emails for "mail:[email-masked]" to the "direct" one.  Would
>that be ok?  Would it be ok to use vipr to resolve-cache from
>"mail:[email-masked]" to "mail:[email-masked]" for the next 6 months?
>
>-hadriel
>
>_______________________________________________
>VIPR mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/vipr

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 1 Apr 2011 05:30:48 -0400

Yeah I should have been clearer - while there's no debate the IP-PBX could be the VIPR agent on both caller and called sides, and indeed that's how I think most people think of it, it should also be clear that any UA could be the VIPR agent - and there is no way to prevent it.  For example if you use a PC-softclient or mobile app, it could reasonably expect to be able to do VIPR (if this thing becomes popular of course).  And if both are running it as the server side there's a 50/50 chance you'd get the UA.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Apr 2011 22:06:00 -0600

Normally I try not to feed trolls but just because you and I have already had this discussion many times ...

When you send email to [email-masked], that resolves to an IP that via DNS. That result is cached in many places and future emails can recuse that. Of course the TTL of the cached data is important to proper function. The TTL of DNS addresses is typically lower than the TTL of E.164 but the TTL is still just as important. 

On Mar 31, 2011, at 8:36 AM, Hadriel Kaplan wrote:

> Howdy,
> I apologize if this has been hashed out already - if so please tell me to RTFM and I'll try and find the thread. (I did google already without luck)
> 
> I have a question about why we're ok with creating an alt-root for ITU's ownership of E.164 in an IETF protocol.  By that I mean that for however long the vipr client is willing to believe the vipr-resolved URI represents the E.164, it is not querying the authoritative database (ie, the PSTN).  The truth of the matter is your phone does not own and is not authoritative for the E.164 phone number - afaik only the ITU is truly authoritative for it (but yes assigns them out downhill).

Yah, sure and this work does not change that. If the the E.164 number get's assigned to someone by the ITU-T, this tracks that.  We all agree there needs to be a TTL. 

> 
> So for example, right now if you dial the E.164 +1-781-328-4428, it resolves to my desk phone (well, actually to voicemail since I never answer my desk phone).  Let's pretend my desk phone did vipr.  If I get fired or quit tomorrow, my employer would re-allocate my number immediately - most likely to a receptionist for some period of time, and ultimately to a new employee.  From my employer's perspective, they "own" +1-781-328-4428, and should have the right/power to reallocate it at their leisure/whim.  Yet VIPR moves the ownership time decision to the caller, for whatever duration time it wants to use. '

uh and a SIP call would still go to your enterprises PBX and get routed to the receptionist. I don't see the problem. 

> 
> In the IETF we have a long-standing concern with creating an alt-root for DNS.  So to put this in terms people here may grok, imagine if we have vipr resolve email addresses instead of E.164 numbers.  I send an email through my email server to "[email-masked]".  My email server subsequently uses a vipr model to learn a "direct" URI of "mail:[email-masked]" or even "mail:[email-masked]", and sends all my subsequent emails for "mail:[email-masked]" to the "direct" one.  Would that be ok?  Would it be ok to use vipr to resolve-cache from "mail:[email-masked]" to "mail:[email-masked]" for the next 6 months?

The alt-root problem has to do with creating to different authorities for a single namespace. That's not what is happening here. ITU-T and it delegates remain the authority for namespace.

---

From: Ken Fischer <[email-masked]>
Date: Tue, 26 Apr 2011 07:45:16 -0600

I will toss my 2 cents in below.

On 4/25/11 10:06 PM, "Cullen Jennings" <[email-masked]> wrote:

>When you send email to [email-masked], that resolves to
>an IP that via DNS. That result is cached in many places and future
>emails can recuse that. Of course the TTL of the cached data is important
>to proper function. The TTL of DNS addresses is typically lower than the
>TTL of E.164 but the TTL is still just as important.
>
>
>> I apologize if this has been hashed out already - if so please tell me
>>to RTFM and I'll try and find the thread. (I did google already without
>>luck)
>> 
>> I have a question about why we're ok with creating an alt-root for
>>ITU's ownership of E.164 in an IETF protocol.  By that I mean that for
>>however long the vipr client is willing to believe the vipr-resolved URI
>>the PSTN).  The truth of the matter is your phone does not own and is
>>not authoritative for the E.164 phone number - afaik only the ITU is
>>truly authoritative for it (but yes assigns them out downhill).
>
>Yah, sure and this work does not change that. If the the E.164 number
>get's assigned to someone by the ITU-T, this tracks that.  We all agree
>there needs to be a TTL.

The ITU is authoritative about which licensed carriers are assigned which
numbers.  They are not authoritative about which enterprise (your company)
or which user (you) is currently assigned a number.   I think the
discussion has been clear that that ViPR is not about building an
alternate PSTN, and as such, it leaves the ITU and the carrier matters to
the side.

>>ultimately to a new employee.  From my employer's perspective, they
>>"own" +1-781-328-4428, and should have the right/power to reallocate it
>>at their leisure/whim.  Yet VIPR moves the ownership time decision to
>>the caller, for whatever duration time it wants to use. '
>
>uh and a SIP call would still go to your enterprises PBX and get routed
>to the receptionist. I don't see the problem.

As far as the PTSN (and ViPR) are concerned, the E.164 number does not
really resolve to your desk phone.  It resolves to your company's PBX
which is what the draft refers to as the Call Agent.  What ever your PBX
administrator decided to do with your number would have the same effect
whether the call arrives via the PSTN, or via the SIP URI.  Also, most
enterprises actually have a decay policy that mimics carriers, putting
numbers into the bottom of the pool to be re-used last.  I left my last
company in October of 2007.  Until December of 2010, you could still hear
the voice mail I left stating that I had left the company when you dialed
my old number.  If you call today, Frank answers it.  If someone in the
callers domain had continued to call my number at least once every time
period (say 30 days), then eventually ViPR would send you to Frank instead
of my voice mail, but that is exactly the same experience you would get
with that behavior if you used the PSTN.

Also, don¹t forget that the "Called" enterprise can choose not to
participate in ViPR.  If I were the administrator of the phone system at
your company, and we were so tight on numbers that we gave them away days
after an employee was fired or quit, I would not enable ViPR on my IP_PBX
because I would anticipate the problem you describe.  By not enabling it,
your number would never validate, and as such the callers Call Agent would
not have a ViPR route for your phone number.  A more simple way might be
to simply refuse to accept calls on the SIP URI, forcing the calling CA to
chose its 2nd option (the PSTN), which still gets the call to the same CA
that ViPR would have

> 
>
>> 
>> In the IETF we have a long-standing concern with creating an alt-root
>>for DNS.  So to put this in terms people here may grok, imagine if we
>>have vipr resolve email addresses instead of E.164 numbers.  I send an
>>email through my email server to "[email-masked]".  My email server
>>"mail:[email-masked]" or even "mail:[email-masked]", and sends all
>>my subsequent emails for "mail:[email-masked]" to the "direct" one.
>>Would that be ok?  Would it be ok to use vipr to resolve-cache from
>The alt-root problem has to do with creating to different authorities for
>a single namespace. That's not what is happening here. ITU-T and it
>delegates remain the authority for namespace.
>
>> 
>> -hadriel
>>