Re: [dispatch] VIPR Charter

[Cullen Jennings <[e-mail]>]

On Jan 12, 2011, at 8:09 AM, Richard Shockey wrote:

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

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. 

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

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

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
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Marc Petit-Huguenin
> Sent: Monday, January 10, 2011 5:19 PM
> To: [e-mail]
> Subject: [dispatch] VIPR Charter
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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.
> 
> - ------------------------------------------------------------------------
> 
> 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: [e-mail]
> Professional email: [e-mail]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAk0rhdIACgkQ9RoMZyVa61c3rACeIZEoXE5f7+JlqL15Pg2ABeBP
> ImAAmQHK60c9Tcf6/tME+fSbWJRZOSe6
> =Spko
> -----END PGP SIGNATURE-----
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch