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

Jonathan Rosenberg <jdrosen@jdrosen.net> Fri, 18 June 2010 01:08 UTC

Return-Path: <jdrosen@jdrosen.net>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8803A6877 for <dispatch@core3.amsl.com>; Thu, 17 Jun 2010 18:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxl5skx8fsEH for <dispatch@core3.amsl.com>; Thu, 17 Jun 2010 18:08:47 -0700 (PDT)
Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [173.205.124.201]) by core3.amsl.com (Postfix) with ESMTP id 2B3643A6874 for <dispatch@ietf.org>; Thu, 17 Jun 2010 18:08:47 -0700 (PDT)
Received: from pool-173-63-40-38.nwrknj.fios.verizon.net ([173.63.40.38] helo=[192.168.1.7]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <jdrosen@jdrosen.net>) id 1OPQ4I-0000Uy-2g; Thu, 17 Jun 2010 21:08:26 -0400
Message-ID: <4C1AC71F.8070206@jdrosen.net>
Date: Thu, 17 Jun 2010 21:08:47 -0400
From: Jonathan Rosenberg <jdrosen@jdrosen.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Roni Even <Even.roni@huawei.com>
References: <DB6CA94F-0EC9-4E27-A190-D12029CA61AE@cisco.com> <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> <E31AEB83-56E5-4695-B2E0-9D2922C6319C@cisco.com> <030501cb0e6e$babab220$30301660$%roni@huawei.com>
In-Reply-To: <030501cb0e6e$babab220$30301660$%roni@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jdrosen.net
Cc: 'DISPATCH list' <dispatch@ietf.org>
Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2010 01:08:49 -0000

Roni,

The key requirement of the solution is that:

1. it be possible to validate the mapping of phone number to a domain 
which is "responsible" for that number, based on the definition Cullen 
has provided, and that

2. such validation be possible using only access to publicly available 
open interfaces to the PSTN, so that the validation can be performed by 
any domain wishing to participate.

At the moment, the only publicly open interface to the PSTN is the 
ability to make a call. If you are aware of other open and publicly 
available interfaces by which we can perform validation, I'd love to 
hear about them :)

Thanks,
Jonathan R.

Roni Even wrote:
> 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] 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
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    Mobile: +1 (732) 766-2496
Skype                                          SkypeIn: +1 (408) 465-0361
jdrosen@skype.net                              http://www.skype.com
jdrosen@jdrosen.net                            http://www.jdrosen.net