Re: [dispatch] VIPR - proposed charter version 2 - PSTN?

[Roni Even <[e-mail]>]

Hi Cullen,
I am sorry that you feel this way about me but I do not take this personally
since I am used to being blamed on lots of things.

Maybe I was not clear about my view.
Section 5.1 of the vipr overview provides the key properties that the
solution requires and I think it is a very good summary of the requirements.
I also think that dialing using E.164 numbers is better in many deployments.
(My background in H.323 has led me to it and BTW I believe that any such
solution can be applicable to H.323)

>From this point the vipr overview suggests a solution that is hinted in the
charter.

The question I have is if basing the validation of ownership of the PSTN
number can only be based on an actual PSTN call or does the charter allow
also other ways to validate the ownership of an E.164 number and can this
number be only the PSTN phone number or can it be other E.164 allocated
without an attached PSTN capability. 

The proposed charter as I read it limits the scope to the case where the
same number is used as the PSTN and SIP number. Did I understand correctly?



Roni Even

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Cullen Jennings
> Sent: Thursday, June 17, 2010 11:55 PM
> To: Roni Even
> Cc: 'DISPATCH list'
> Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN?
> 
> 
> I'm having a real hard time actually understand what you are objecting
> too. More  inline ...
> 
> On Jun 16, 2010, at 12:22 AM, Roni Even wrote:
> 
> > Hi,
> > I read the charter and the listed drafts. I have no problem with the
> first
> > two paragraph of the charter
> >
> > "There are two globally deployed address spaces for communications
> that more
> > than a billion people use on a daily basis. They are 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. The goal of this working group is to enable inter-
> domains
> > communications over the internet, using protocol such as SIP, while
> still
> > allowing people to use phone numbers to identify the person they wish
> to
> > communicate with.
> >
> > The VIPR WG will address this problem by developing a peer to peer
> based
> > approach to finding domains that claim to be responsible for a given
> phone
> > number and validation protocols to ensure a reasonable likelihood
> that a
> > given domain actually is responsible for the phone number."
> >
> > I have a concern about using PSTN infrastructure for the
> reachability. My
> > understanding so far was that SIP is trying to provide a new way for
> end to
> > end communication that will replace the existing circuit switch
> > infrastructure. This proposal says that the way to achieve end to end
> > connectivity requires to have an end to end PSTN frastructure.
> 
> No this proposal says one of the way we can make PSTN address usable in
> inter domain SIP is this. Clearly this approach would no longer be
> valid when the PSTN was gone but by that point, presumably people would
> be using more internet style address in SIP. Keep in mind the only
> thing this work is trying to solve is mapping a PSTN address to a
> internet address. When the PSTN is gone, that problem goes with it.
> However the PSTN is far from gone - if I had to bet, I would guess that
> phone numbers were around longer than v6 addresses (and than email
> style address outlive them both). The issue is phone numbers are used
> by humans which makes them very hard to transition off of while things
> like v6 addresses are easier to transition off of as they are come and
> go with the technologies that use them. My point being all these
> addresses are around for a long time and the IETF works on standards to
> help transition and interwork between them. The Telegram service was
> emulated on top of ot
>  her technologies long after it had been supplanted by fax - the PSTN
> will be similar.
> 
> >
> > The third paragraph is talking about validation using PSTN calls. I
> think
> > that we can look at validation of number ownership but should say
> that
> > requiring PSTN calls to do it is not the recommended approach.
> > This will
> > allow managing of PSTN numbers not in the scope of PSTN
> infrastructure. Even
> > the PSTN network is using external protocol like SS7 to route calls
> using
> > databases for achieving reachability so why not say we can use
> similar
> > infrastructure that will be IP based.
> 
> We did standardize and IP based database approach - it's called public
> ENUM. However, from a practical point of view the only people that
> could do the validations for ENUM are the carriers that have every
> business incentive to not do it. Regulators do not have the right
> incentives to regulate it into existence. VIPR on the other hand only
> requires carriers to route calls. Routing calls is something they do
> today, it is in their business interest so they will likely continue
> doing it, and the regulation around common carriage often require them
> to route calls. Both the existing regulations and economics favor that
> the carriers will do what is needed to enable a solution that leverages
> the PSTN for validation.
> 
> >
> > I can understand this as a temporary solution but not as a standard
> > developed by the IETF.
> 
> How temporary do you think the PSTN is? How many years?  Do you think
> we should not be doing standards for WG like MARTINI that only WG
> document limited itself to phone numbers? Should we not have standards
> about SIP / PSTN interoperability? I don't hear you objecting to any of
> the other work we do hat is "temporary" in the sense it is only useful
> as long as the PSTN is around.
> 
> Seriously, I read this and just feel like you are grasping at straws
> for something to objet to since this proposal came from Cisco.
> 
> 
> >
> >
> > Thanks
> >
> > Roni Even
> >
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch