Subject: [dispatch] VIPR Charter

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 10 Jan 2011 14:19:05 -0800

On the advice of the DISPATCH chairs, I am reposting below the latest version of
the VIPR charter for additional feedback.

They are not considered as candidates for WG documents under this charter, but
FYI the ViPR drafts were last updated in October 2010, and will probably be
updated again before Prague:

http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-overview-04.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-reload-usage-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip-antispam-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap-03.txt

Thanks.

- ------------------------------------------------------------------------

VIPR Charter Proposal (Version 4)

WG Name:  Verification Involving PSTN Reachability (VIPR)

There are two globally deployed address spaces for communications used
by more than a billion people daily - phone numbers and DNS rooted
address such as web servers and email addresses. The inter-domain
signaling design of SIP is primarily designed for email style addresses
yet a large percentage of SIP deployments mostly use phone numbers for
identifying users, thus DNS lookups are not sufficient. Other approaches
such as public ENUM are not sufficient due to lack of widespread
deployment for non-technical reasons - i.e., the involvement of
government and service provider administrative entities needing to
approve and populate the registries.  Private federations have been
established to workaround the issue, however, that solution is not
scalable. The goal of this working group is to enable inter-domain
communications over the the Internet, using protocols such as SIP,
while still allowing people to use phone numbers to identify the person
with whom they wish to communicate.

The VIPR WG will develop a peer to peer based approach to finding
domains that claim to be responsible for a given phone number
to mitigate the involvement of centralized entities to avoid some of
the issues encountered by past attempts to support SIP inter-domain
communications. Validation protocols will be developed to ensure a
reasonable likelihood that a given domain actually is responsible for
the phone number. In this context, "responsible" means an
administrative domain, which is at least one of the domains, to which
a PSTN call to this phone number would be routed. Once the domain
responsible for the phone number is found, existing protocols, such
as SIP, can be used for inter-domain communications.

Some validation protocols may be based on knowledge gathered around a
PSTN call; for example, the ability to prove a call was received over
the PSTN based on start and stop times. Other validation schemes, such
as examining fingerprints or watermarking of PSTN media to show that a
domain received a particular PSTN phone call, may also be considered by
the working group. This validation will be accomplished using publicly
available open interfaces to the PSTN, so the validation can be
performed by any domain wishing to participate.  The WG will select and
standardize at least one validation scheme.

The validation mechanism requires a domain to gather and maintain
information related to PSTN calls.  This information is used by call
agents such as phones, SBCs and IP PBXs to route calls.  The WG will
define a client-server protocol between these call agents and the entity
within a domain that maintains the information.

To help mitigate SPAM issues when using SIP between domains, the WG will
define a mechanism to enable one domain to check that incoming SIP
messages are coming from a validated phone number.  A phone number is
considered validated if it is coming from a domain to which the calling
domain had previously successfully placed a PSTN call.  The working
group will define new SIP headers and option tags, as necessary, to
enable this.

The essential characteristic of VIPR is establishing authentication by
PSTN reachability when it is not possible to use a direct reference to
ENUM databases or other direct assertions of PSTN number
ownership. Elements such as public ENUM easily coexist with VIPR but no
direct interaction with ENUM will be required.  The solution set defined
by this WG will be incrementally deployable using only existing
interfaces to the PSTN.  No changes will be required to existing PSTN
capabilities, no new database access is needed nor is any new support
from PSTN service providers required.

The WG will produce the following deliverables:

1) A document describing the requirements, problem statement and
architectural approach to support SIP inter-domain communications.
2) A document describing the use of the p2psip protocol (RELOAD) as
applied to this problem space.
3) A document defining a scheme for validating the phone numbers using
publicly available open interfaces to the PSTN.
4) A document defining client-server protocol between call agents and the
entity within a domain that gathers and maintains information related to
PSTN calls.
5) A document describing a mechanism to mitigate SPAM issues.

The working group will carefully coordinate with the security area, O&M
area, as well as the appropriate RAI WGs such as sipcore and p2psip.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 12 Jan 2011 10:09:07 -0500

I still don't see how you can write a charter without dealing with the
Number Portability issue. You really need to be explicit that this proposed
methodology WILL FAIL in cases where the PSTN authority for the phone number
changes. It just needs to be called out.

Plus I really take issue with the case that private federations don't scale.
There is no evidence of that at all. IN addition its really irrelevant to
discuss why ENUM in e164.apra did not deploy. Needless to say when you do
have the cooperation of governmental or service provider administrative
entities within an jurisdiction it can and does work well. 

I certainly don't have any real issue with this work going forward. I'm a
great fan of letting folks actually do things they want to so long as it is
explicit what the limitations are. I'm sure there are folks that can and
would use this technique. I only wish those who continue to oppose the
extensions of ENUM for E2MD for instance would be as charitable. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Petit-Huguenin
Sent: Monday, January 10, 2011 5:19 PM
To: [email-masked]
Subject: [dispatch] VIPR Charter

On the advice of the DISPATCH chairs, I am reposting below the latest
version of
the VIPR charter for additional feedback.

They are not considered as candidates for WG documents under this charter,
but
FYI the ViPR drafts were last updated in October 2010, and will probably be
updated again before Prague:

http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-overview-0
4.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-reload-usa
ge-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip-antisp
am-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap-03.txt

Thanks.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Jan 2011 09:32:37 -0800

> changes. It just needs to be called out.

I am not sure that I understand why the methodology would fail in this case
(there will be a transition period after porting to another ViPR enabled
provider, during which the SIP call will fail).  But for the sake of progressing
this charter, does the sentence "Validation protocols will be developed to
ensure a reasonable likelihood that a given domain actually is responsible for
the phone number" in the second paragraph covers your concern or do you require
a stronger wording?

> entities within an jurisdiction it can and does work well.

OK, would there be a consensus to rewrite the 3rd and 4th sentence of the first
paragraph as follow:

"Other approaches such as public ENUM or private federations are not sufficient
due to lack of widespread deployment."

> ------------------------------------------------------------------------
> 

- -- 
Marc Petit-Huguenin

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 12 Jan 2011 15:34:02 -0500

provider, 

What is a ViPR enabled provider?  Provider of what? 

during which the SIP call will fail).  But for the sake of progressing
this charter, does the sentence "Validation protocols will be developed to
ensure a reasonable likelihood that a given domain actually is responsible for
the phone number" in the second paragraph covers your concern or do you require
a stronger wording?

First a domain is not and never will be "responsible" for a phone number. Only the NRA authorized carrier of record is "responsible" for the number.  ViPR is only a transient mapping technique for a arbitrary name held by a domain (E.164) to a URI(s) distributed in a p2p manner. Those mappings, shall we say typically have a long "TTL". 

Once the underlying number has been ported to another PSTN authority or disconnected its underlying authority is altered.

Nope just delete the sentence.  You do not need to justify why you want to do this based on some arbitrary perception of why ENUM or private federations may or may not have been deployed.  I can assure you they have deployed. What we both know and you won't or can't say is currently those federations are controlled by the same NRA authorized carriers of record you want to route around. 

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Jan 2011 12:54:24 -0800

> Once the underlying number has been ported to another PSTN authority or disconnected its underlying authority is altered.

Sure, and VIPR will happily creates a new mappings as soon it has the
opportunity.  The WG will certainly find ways to reduce the TTL or cancel its
effect.

Would you be happy with the following sentence:

"Validation protocols will be developed to ensure a reasonable likelihood that
the phone number is actually assigned to a given domain and to detect in a
timely manner that it no longer is."

> Nope just delete the sentence.  You do not need to justify why you want to do this based on some arbitrary perception of why ENUM or private federations may or may not have been deployed.  I can as…

OK.

- -- 
Marc Petit-Huguenin

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 12 Jan 2011 16:39:59 -0500

> What is a ViPR enabled provider?  Provider of what? 

I still don’t understand what a ViPR enabled provider is. You really think a carrier would use this? <LOL> 

******

Yes that’s fine, whatever. 

I don’t think you will ever "fix" the underlying problem in ViPR which is that the model is completely divorced from the underlying authority of the name you are mapping.  ENUM's problem was political ViPR has the same issue. But fine go ahead, have a ball! 

Been there done that.

FYI I support the work for no other reason that the very existence of this WG might get some of my service provider friends to get off their (fill in blank) and actually create functional E.164 to URI mapping databases so kludges like this would not have to exist. 

I apologize if I sound deeply cynical or unusually sarcastic about this proposed work, but you understand I have some history with this subject.  

*******

OK.

- -- 
Marc Petit-Huguenin

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 12 Jan 2011 15:47:21 -0600

On 01/12/2011 02:54 PM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I think this is an improvement, but I share Richard's concern here: the 
definition of 'timely' in this context falls solely on the backs of the 
organizations that actually do own and manage the controlled resources 
(E.164 numbers). If the WG decides that 'timely' means that a VIPR node 
won't hold on to an E.164/SIP URI association for longer than X days, 
because X is 'less than half of the time that carriers will hold a 
number idle before reassigning it' (as a hypothetical example of 
course), what happens when a perfectly valid reason for reassigning 
numbers in 24-48 hours comes along?

Maybe I'm naive, but it seems to me this could result in the need for 
ViPR nodes to set very, very short TTLs on the mappings they establish, 
because they just can't know when the routing of an E.164 number is 
going to change... and delivering a call to the number's previous 
destination is both unexpected and potentially harmful. Unless quite a 
substantial number of calls are going to be delivered using that mapping 
in the window that the TTL allows, there could be very little 
opportunity for cost savings or other potential benefits.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Jan 2011 16:57:23 -0800

> I still don’t understand what a ViPR enabled provider is. You really think a carrier would use this? <LOL> 

I was talking about ViPR enabled VoIP providers.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Jan 2011 17:02:32 -0800

On 01/12/2011 01:47 PM, Kevin P. Fleming wrote:
>>> First a domain is not and never will be "responsible" for a phone
>>> number. Only the NRA authorized carrier of record is "responsible"
>>> for the number.  ViPR is only a transient mapping technique for a
>>> arbitrary name held by a domain (E.164) to a URI(s) distributed in a
>>> p2p manner. Those mappings, shall we say typically have a long "TTL".
>>>
>>> Once the underlying number has been ported to another PSTN authority
>>> or disconnected its underlying authority is altered.
>>

I think that there is solutions to the TTL problem, but there will be plenty of
time after the WG is created to discuss them.

For now is there any modifications that you think would be needed in the charter
text to be sure that this problem will be addressed, or are you OK with the text
as it is?

Thanks.

- -- 
Marc Petit-Huguenin

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 12 Jan 2011 21:38:32 -0500

<LOL tears LOL tears > Good luck. Go for it!  What are you thinking?

Sorry .. I just love this BTW you are giving me the perfect argument to smack the opponents of E2MD over the side of the head. Humm It goes like this "Look the IETF chartered this duct tape and bailing wire ViPR kludge with no rational authority model and you want to prevent us from actually making PSTN metadata work in converged SIP networks and advance the cause of SIP network interoperability in a real structured environment with a real authority model?" E2MD polluting the DNS? Give me a break!

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 12 Jan 2011 19:27:33 -0800

On 01/12/2011 06:38 PM, Richard Shockey wrote:
>>>> Number Portability issue. You really need to be explicit that this
>>>> proposed methodology WILL FAIL in cases where the PSTN authority for
>>>> the phone number changes. It just needs to be called out.
>>> 
>>> I am not sure that I understand why the methodology would fail in this
>>> case (there will be a transition period after porting to another ViPR
>>> enabled provider,
>>> 
> Sorry .. I just love this BTW you are giving me the perfect argument to smack
> the opponents of E2MD over the side of the head. 

Always happy to help!

> Humm It goes like this "Look
> the IETF chartered this duct tape and bailing wire ViPR kludge with no
> rational authority model and you want to prevent us from actually making PSTN
> metadata work in converged SIP networks and advance the cause of SIP network
> interoperability in a real structured environment with a real authority
> model?" E2MD polluting the DNS? Give me a break!
> 
> 
> 
> _______________________________________________ dispatch mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dispatch

- -- 
Marc Petit-Huguenin

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 13 Jan 2011 14:41:56 +0100

On 01/12/11 22:47, Kevin P. Fleming wrote:
> I think this is an improvement, but I share Richard's concern here: 
> the definition of 'timely' in this context falls solely on the backs 
> of the organizations that actually do own and manage the controlled 
> resources (E.164 numbers). If the WG decides that 'timely' means that 
> a VIPR node won't hold on to an E.164/SIP URI association for longer 
> than X days, because X is 'less than half of the time that carriers 
> will hold a number idle before reassigning it' (as a hypothetical 
> example of course), what happens when a perfectly valid reason for 
> reassigning numbers in 24-48 hours comes along?
It might not be a relevant comparision, but when I change mobile phone 
carriers, I expect the number reassignment to be *instant*. 24 hours is 
beyond unreasonable.

I wouldn't want to commit to a situation where changing SIP providers is 
significantly more disruptive than changing mobile phone carriers.

                   Harald

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 13 Jan 2011 07:50:41 -0600

> significantly more disruptive than changing mobile phone carriers.

I debated whether that scenario should be included in my note, but 
decided not to because in that case while the E.164 number in question 
is being routed to a different mobile provider, it's still terminating 
at the same person/company/etc., and if you had been providing ViPR 
mapping for that number the mapping would still be valid.

Carriers (at least in my experience) won't assign a number to a 
different customer that quickly... but that could change, or the policy 
could be different for certain types of numbers.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 13 Jan 2011 10:30:30 -0800

> could be different for certain types of numbers.

OK so far the diff of the charter v4 is as follow.  Let me know if there is more
modifications needed.  Thanks.

diff --git a/src/share/docs/vipr-charter.txt b/src/share/docs/vipr-charter.txt
index f4a3d43..7529235 100644
- --- a/src/share/docs/vipr-charter.txt
+++ b/src/share/docs/vipr-charter.txt
@@ -7,16 +7,10 @@ by more than a billion people daily - phone numbers and DNS r
 address such as web servers and email addresses. The inter-domain
 signaling design of SIP is primarily designed for email style addresses
 yet a large percentage of SIP deployments mostly use phone numbers for
- -identifying users, thus DNS lookups are not sufficient. Other approaches
- -such as public ENUM are not sufficient due to lack of widespread
- -deployment for non-technical reasons - i.e., the involvement of
- -government and service provider administrative entities needing to
- -approve and populate the registries.  Private federations have been
- -established to workaround the issue, however, that solution is not
- -scalable. The goal of this working group is to enable inter-domain
- -communications over the the Internet, using protocols such as SIP,
- -while still allowing people to use phone numbers to identify the person
- -with whom they wish to communicate.
+identifying users, thus DNS lookups are not sufficient. The goal of this
+working group is to enable inter-domain communications over the Internet,
+using protocols such as SIP, while still allowing people to use phone
+numbers to identify the person with whom they wish to communicate.

 The VIPR WG will develop a peer to peer based approach to finding
 domains that claim to be responsible for a given phone number
@@ -43,8 +37,10 @@ standardize at least one validation scheme.
 The validation mechanism requires a domain to gather and maintain
 information related to PSTN calls.  This information is used by call
 agents such as phones, SBCs and IP PBXs to route calls.  The WG will
- -define a client-server protocol between these call agents and the entity
- -within a domain that maintains the information.
+also develop mechanisms to detect in a timely manner that a given domain
+is not longer responsible for a phone number. The WG will define a
+client-server protocol between these call agents and the entity within a
+domain that maintains the information.

- -- 
Marc Petit-Huguenin

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Jan 2011 19:33:50 -0700

> changes. It just needs to be called out.

Richard, I'm not seeing the number portability problem here. Let walk through a use case for my cell phone along with the vipr drafts - I know the WG may do something totally different than these drafts but just for a concrete example I'll use them. My iphone is with AT&T but lets just hypothetically say that in one month it is going to move to Verizon. Now the VIPR address for my number is cisco.com. When I move my number from AT&T to Verizon, nothing changes, exactly what you want happens. Calls to my number still go to me. I don't get the problem. It seems like the right thing happened.

Now lets imagine a few other related cases than number portability. One is if I decided to sell my phone number to Rohan. This of course would not be legal in the US but if anyone is willing to sell me a 867-5309 in any NANP area code, I'd like to buy it and obviously it does happen. In this case, the seller would need to invalidate their VIPR record as they sold the number but that is normal. Again there is no real problem. 

The next case is I cancel my account and AT&T decides to give the number to some new customer. I talked to several large carriers around the world and found out that they actually don't instantly reuse the numbers because the new customers are irritated to get all the calls of the old customer. Instead the leave the number unused for some period of time. The shortest period I heard was two months. That implies you need to have a validation TTL of two months or less. Obviously it might be nice to have longer but the system seem perfectly usable with this constraint on the TTL. 

> discuss why ENUM in e164.apra did not deploy.

We might mean different things here. One meaning of private federation could be every large telco in the wold contracted out to some company to run a a private ENUM for them - clearly that scales. 

I suspect what people meant here was an enterprise going and manually configuring a SIP route for the ranges of numbers for other enterprises it talks to and keeping those up to date as the other enterprise changes the range of numbers that come to them. Lots of companies do this for a handful of parters they have lots of calls with but I think we would both agree this does not scale. Any idea on how to rephrase this. 

> Needless to say when you do
> explicit what the limitations are.

100% agree on you we need truth in advertising here and should clearly state the limitations

PS - You assert that SP won't use this but I don't agree with you. Imagine a SP that has a whole bunch of wide band audio enabled mobile phones or mobile phones with video. If that SP enabled ViPR suddenly every enterprise that was VIPR enabled could get wide band audio and video to theses mobile phones. That would be a pretty compelling reasons for an enterprise that used ViPR to select that mobile carrier as there provider for mobile phones. Not much downside for the mobile provider - they could still bill whatever they wanted for minutes that had video or wide band audio. Seem pretty compelling to several of Cisco's customers thought nothing happens fast in this space. 

You could also consider a large cable operator that wanted to enable video calling with enterprises doing something like this. The more you think about it, I'm not sure I see a SP that made most of it's money doing long distance doing this but when you break it up you realize that is not the majority of the revenue in the SP space so there are lots of SP that this could make sense for. 

> I'm sure there are folks that can and
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAk0rhdIACgkQ9RoMZyVa61c3rACeIZEoXE5f7+JlqL15Pg2ABeBP
> ImAAmQHK60c9Tcf6/tME+fSbWJRZOSe6
> =Spko
> -----END PGP SIGNATURE-----

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Fri, 14 Jan 2011 08:50:10 -0500

Cullen:
I think that the number portability issue is more likely to arise when
the VIPR address is associated with the carrier-of-record. When a number
ports under these circumstances to a different carrier, the VIPR address
likely becomes invalid.  North American PSTN NP TTL (the time that
carriers have to update their networks) is 15 minutes. So this is a
segment for which VIPR may not be very useful.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cullen Jennings
Sent: Thursday, January 13, 2011 9:34 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [dispatch] VIPR Charter

> Number Portability issue. You really need to be explicit that this
proposed
> changes. It just needs to be called out.

Richard, I'm not seeing the number portability problem here. Let walk
through a use case for my cell phone along with the vipr drafts - I know
the WG may do something totally different than these drafts but just for
a concrete example I'll use them. My iphone is with AT&T but lets just
hypothetically say that in one month it is going to move to Verizon. Now
the VIPR address for my number is cisco.com. When I move my number from
AT&T to Verizon, nothing changes, exactly what you want happens. Calls
to my number still go to me. I don't get the problem. It seems like the
right thing happened.

Now lets imagine a few other related cases than number portability. One
is if I decided to sell my phone number to Rohan. This of course would
not be legal in the US but if anyone is willing to sell me a 867-5309 in
any NANP area code, I'd like to buy it and obviously it does happen. In
this case, the seller would need to invalidate their VIPR record as they
sold the number but that is normal. Again there is no real problem. 

The next case is I cancel my account and AT&T decides to give the number
to some new customer. I talked to several large carriers around the
world and found out that they actually don't instantly reuse the numbers
because the new customers are irritated to get all the calls of the old
customer. Instead the leave the number unused for some period of time.
The shortest period I heard was two months. That implies you need to
have a validation TTL of two months or less. Obviously it might be nice
to have longer but the system seem perfectly usable with this constraint
on the TTL. 

> discuss why ENUM in e164.apra did not deploy.

We might mean different things here. One meaning of private federation
could be every large telco in the wold contracted out to some company to
run a a private ENUM for them - clearly that scales. 

I suspect what people meant here was an enterprise going and manually
configuring a SIP route for the ranges of numbers for other enterprises
it talks to and keeping those up to date as the other enterprise changes
the range of numbers that come to them. Lots of companies do this for a
handful of parters they have lots of calls with but I think we would
both agree this does not scale. Any idea on how to rephrase this. 

> explicit what the limitations are.

100% agree on you we need truth in advertising here and should clearly
state the limitations

PS - You assert that SP won't use this but I don't agree with you.
Imagine a SP that has a whole bunch of wide band audio enabled mobile
phones or mobile phones with video. If that SP enabled ViPR suddenly
every enterprise that was VIPR enabled could get wide band audio and
video to theses mobile phones. That would be a pretty compelling reasons
for an enterprise that used ViPR to select that mobile carrier as there
provider for mobile phones. Not much downside for the mobile provider -
they could still bill whatever they wanted for minutes that had video or
wide band audio. Seem pretty compelling to several of Cisco's customers
thought nothing happens fast in this space. 

You could also consider a large cable operator that wanted to enable
video calling with enterprises doing something like this. The more you
think about it, I'm not sure I see a SP that made most of it's money
doing long distance doing this but when you break it up you realize that
is not the majority of the revenue in the SP space so there are lots of
SP that this could make sense for. 

> updated again before Prague:
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-overvi
ew-0
> 4.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-reload
-usa
> ge-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp-03
.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip-an
tisp
> am-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap-03
.txt
> -

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Jan 2011 09:03:36 -0500

> The next case is I cancel my account and AT&T decides to give the number to some new customer. I talked to several large carriers around the world and found out that they actually don't instantly r…

To elaborate on this case. Suppose Cullen gave up his number, and later 
Richard opened a new account and was assigned Cullen's old number. No 
matter how long the waiting period before the reassignment, there will 
still be some people who still think the number belongs to Cullen and 
will try to call him on it. They will get Richard instead, and be 
surprised and perhaps annoyed. That is a limitation on the way telephone 
numbers work, without regard to ViPR. People accept and live with this 
limitation.

In similar circumstances, you would have the same phenomenon with ViPR. 
If the TTL for ViPR is longer than the delay before assignment by the 
telco then the period when callers are annoyed might be longer. But so what?

If Richard was also a ViPR user, then once the number was assigned to 
him he would try to register it with ViPR. I forget what happens in that 
case. Maybe Cullen will enlighten us.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 14 Jan 2011 08:21:12 -0600

> segment for which VIPR may not be very useful.

Right... I believe this was the essence of Richard Shockey's concern: 
number portability plus ViPR-enabled service providers could lead to 
this exact situation.

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Jan 2011 08:25:01 -0600

> segment for which VIPR may not be very useful.

I wasn't aware that carriers were the problem space VIPR was intended 
for, but let's consider what does happen in this case.

Cullen is using FooCom, and has been assigned a phone number. At some 
point, he switches over to Elbonia Telecom and ports his number. Now, 
the VIPR overlay information for Cullen's phone number still points to 
FooCom.

At this point, I call Cullen's phone number, using a system that also 
uses VIPR. Let's assume that I've called Cullen in the past, so my 
system trusts the information learned from VIPR. This means that the 
call is routed to FooCom's servers.

Let's assume that FooCom is not malicious. (With malicious carriers, we 
have far bigger problems than VIPR hiccups, so I think this is a 
reasonable assumption.) FooCom's servers will recognize that Cullen's 
number isn't one of their phone numbers, and return an error to my system.

A reasonable system (and this might be something that we actually 
specific normative as part of normal VIPR handling) would receive this 
error and treat the information for Cullen in the DHT as invalid (remove 
it from its cache), and route the call over the PSTN. Assuming 
everything works okay on that side, the call eventually reaches Elbonia 
Telecom's servers, and Cullen's phone rings. I've reached Cullen. The 
system works.

Future calls would undergo normal VIPR processing, and my system would 
store new routing information for reaching Cullen. I'll reach him over 
the IP network for these subsequent calls, just as intended by the 
design of the VIPR system.

In other words: VIPR handles this case quite gracefully, even if it is 
somewhat outside of (what I interpreted to be) its goals.

/a

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 14 Jan 2011 08:25:42 -0600

On 01/14/2011 08:03 AM, Paul Kyzivat wrote:
>> The next case is I cancel my account and AT&T decides to give the
>> number to some new customer. I talked to several large carriers around
>> the world and found out that they actually don't instantly reuse the
>> numbers because the new customers are irritated to get all the calls
>> of the old customer. Instead the leave the number unused for some
>> period of time. The shortest period I heard was two months. That
>> implies you need to have a validation TTL of two months or less.
>> Obviously it might be nice to have longer but the system seem
>> perfectly usable with this constraint on the TTL.
>

Wearing my 'former ITSP operator' hat for a moment, I can tell you the 
'what' here is annoyed customers, users, etc. If a user at an enterprise 
picks up their phone and dials a number expecting to get Richard, but 
gets Cullen instead, they'll double check the number. If the source of 
the number confirms it was in fact Richard's number, they will pick up 
their cell phone and try the call that way... and they'll get Richard, 
and not Cullen. If they got Cullen because their company's PBX (or ITSP) 
is using ViPR to deliver calls to save money/provide wideband/provide 
video/etc. and their cache entry for that number is stale, the user's 
next call will be an irate one to the people who manage the telephony 
infrastructure they are using.

Now, as Cullen has pointed out elsethread, the reassignment policies of 
carriers typically measure the delay in weeks or months, not days or 
hours, so it's reasonable to have a ViPR TTL of a few days and avoid 
this problem... but that assumes that there won't ever be a perfectly 
valid reassignment policy by some carrier, or for some class of numbers, 
that does measure in days or hours. If that exists, then the person 
providing the ViPR mapping for a number subject to such a policy has to 
be very careful that they advertise a suitably short TTL.

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Jan 2011 08:26:50 -0600

> number portability plus ViPR-enabled service providers could lead to 

Talk us through how this breaks. Tell a story about someone trying to 
make a phone call in these circumstances, and what goes wrong.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Jan 2011 09:37:37 -0500

On 1/14/2011 9:25 AM, Kevin P. Fleming wrote:
> gets Cullen instead,

How is it that they will get Cullen?
The call might be routed to the ViPR domain that formerly served Cullen, 
but he has unsubscribed for that number. So the call will presumably 
fail. This seems similar to the case Adam just outlined.

	Thanks,
	Paul

> they'll double check the number. If the source of

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 14 Jan 2011 10:16:40 -0600

> text to be sure that this problem will be addressed, or are you OK with the text

Nope; the charter points out that these issues are known and need to be 
addressed, which is adequate for its purpose.

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 14 Jan 2011 12:49:20 -0500

Yes as Cullen correctly pointed out the charter is fine so long as there is
truth in advertising. 

My point is that there is fundamental disconnect between the chain of
authority for the E.164 number and the ViPR system that no protocol can
overcome. This charter is one more piece of evidence that the entire IETF
RAI directorate had never been able to reconcile itself to the reality of
E.164 naming and addressing. 

******

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 14 Jan 2011 13:38:32 -0500

Now lets imagine a few other related cases than number portability. One is
if I decided to sell my phone number to Rohan. This of course would not be
legal in the US but if anyone is willing to sell me a 867-5309 in any NANP
area code, I'd like to buy it and obviously it does happen. In this case,
the seller would need to invalidate their VIPR record as they sold the
number but that is normal. Again there is no real problem. 

****
Actually its not legal anywhere. E.164 numbers are by treaty a global
resource.

The next case is I cancel my account and AT&T decides to give the number to
some new customer. I talked to several large carriers around the world and
found out that they actually don't instantly reuse the numbers because the
new customers are irritated to get all the calls of the old customer.
Instead the leave the number unused for some period of time. The shortest
period I heard was two months. That implies you need to have a validation
TTL of two months or less. Obviously it might be nice to have longer but the
system seem perfectly usable with this constraint on the TTL. 

****
Correct. 

> discuss why ENUM in e164.apra did not deploy.

We might mean different things here. One meaning of private federation could
be every large telco in the wold contracted out to some company to run a a
private ENUM for them - clearly that scales. 

************
And it does BTW. And the GSM Association is trying that very model though
their problems are unrelated to technology. Private federations may also be
a select subset of service providers that want to avoid PSTN termination
charges by privately peering their SIP traffic or a teleco that uses either
ENUM or SIP redirect to create its own private enterprise federations.
Sprint and Verizon both have products like this and in fact Verizon's
product is called VIPER.

http://www.verizonbusiness.com/resources/factsheets/fs_voip-ip-enterprise-ro
uting_en_xg.pdf

There are lots of business models out there for this kind of thing. ViPR may
..may be another one.  Again I have no objection to this charter but I don't
want to hear any more crap about E2MD either. :-) 

I suspect what people meant here was an enterprise going and manually
configuring a SIP route for the ranges of numbers for other enterprises it
talks to and keeping those up to date as the other enterprise changes the
range of numbers that come to them. Lots of companies do this for a handful
of parters they have lots of calls with but I think we would both agree this
does not scale. Any idea on how to rephrase this. 

*********

Why are you worrying about scale here ..the enterprise to enterprise model
is just another variation of the well established Least Cost Routing model.
It's a perfectly acceptable use case for ViPR. IMHO is probably the best use
case. I used to give talks all the time about the 40-40-20 rule of
enterprise call patterns. 40 percent of all calls are internal to the
enterprise the other 40 are "friends and family" aka suppliers or customers
and the last 20 percent is pizza or spouses. 

> explicit what the limitations are.

100% agree on you we need truth in advertising here and should clearly state
the limitations

PS - You assert that SP won't use this but I don't agree with you. Imagine a
SP that has a whole bunch of wide band audio enabled mobile phones or mobile
phones with video. If that SP enabled ViPR suddenly every enterprise that
was VIPR enabled could get wide band audio and video to theses mobile
phones. That would be a pretty compelling reasons for an enterprise that
used ViPR to select that mobile carrier as there provider for mobile phones.
Not much downside for the mobile provider - they could still bill whatever
they wanted for minutes that had video or wide band audio. Seem pretty
compelling to several of Cisco's customers thought nothing happens fast in
this space. 

***********

Well that is also the business case for Carrier ENUM as well and it is
deploying in several jurisdictions. My point is that if you are a SP you
want to bind the mapping of the E.164 number to the authority model for
numbering itself since it has some very very unique advantages.  Plus you
know SP's as well as I do .. they like their control and I've seen no
evidence that they intend to give that up. What you are absolutely right
about it that NOTHING happens fast in this space. Though the empirical data
from such sources as the FCC indicate that a critical mass for some form of
action is developing. The Class 5 infrastructure is (fill in the blank) and
that means you have to address the number translation issue if there is to
be any real new service delivery.  I'm afraid I'm all out of NO TCAP hats
however. 

You could also consider a large cable operator that wanted to enable video
calling with enterprises doing something like this. The more you think about
it, I'm not sure I see a SP that made most of it's money doing long distance
doing this but when you break it up you realize that is not the majority of
the revenue in the SP space so there are lots of SP that this could make
sense for. 

*******

HD voice .. take your pick but IMHO if it's a choice between Carrier ENUM
and ViPR I know where I'll place my bets. Fine great ..let the market decide
this one. For the Nth time Im fine with this work going forward ..but again
I won't listen to any more crap about how E2MD would pollute the DNS or the
crash internet or whatever flimsily excuse some of our mutual friends will
come up with.  

Phone numbers are here to stay for the foreseeable future and it is our
obligation to make them work in SIP specifically and with real-time
communications in general.

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Jan 2011 13:27:01 -0600

On 1/14/11 12:38 PM, Richard Shockey wrote:
> IMHO if it's a choice between Carrier ENUM and ViPR I know where I'll 
> place my bets.

There is no competition here.

Carrier ENUM is meant to be used by VoIP carriers who support peering 
with other VoIP carriers. VIPR is intended to be used by enterprises and 
end users who want to connect directly with other enterprises and end 
users. Different tools for different market segments.

You're proposing to bet on butcher knives (used by suppliers) versus 
steak knives (used by consumers) as if one is going to "win" and make 
the other go away. Sure, they both cut meat. But they're not used by the 
same people, and they're not used in the same way.

/a

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 16 Jan 2011 16:42:13 -0600

These are excellent arguments why VIPR may sometimes work and sometimes not
work. How can these issues be addressed in VIPR without horrible complexity?
If they cannot be reasonably addressed, why proceed at all?

Thanks, Henry