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

Paul Kyzivat <pkyzivat@cisco.com> Wed, 16 June 2010 12:51 UTC

Return-Path: <pkyzivat@cisco.com>
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 4E7EE3A689C for <dispatch@core3.amsl.com>; Wed, 16 Jun 2010 05:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.525
X-Spam-Level:
X-Spam-Status: No, score=-9.525 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8]
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 CAu2cFlv3PDy for <dispatch@core3.amsl.com>; Wed, 16 Jun 2010 05:51:49 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3627C3A67D3 for <dispatch@ietf.org>; Wed, 16 Jun 2010 05:51:49 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.53,426,1272844800"; d="scan'208";a="122147286"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2010 12:51:53 +0000
Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5GCprtr023450; Wed, 16 Jun 2010 12:51:53 GMT
Message-ID: <4C18C8F1.90809@cisco.com>
Date: Wed, 16 Jun 2010 08:52:01 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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>
In-Reply-To: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Wed, 16 Jun 2010 12:51:50 -0000

Roni Even wrote:

> 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.
> 
> 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.
> 
> I can understand this as a temporary solution but not as a standard
> developed by the IETF.

I have had similar concerns for some time - this strategy is not an "end 
game".

BUT, at the moment there is nothing better for most phone numbers.
That will probably be true for quite some time. So I think it must be 
*part* of the solution. It is a way to bootstrap the process.

Note that this is compatible with using SIP for "PSTN" calls. Many SPs 
now have SIP Trunks, and calls over these can be used for ViPR validation.

Eventually there should be some other mechanism that doesn't depend on 
PSTN calls. Maybe ViPR will motivate the deployment of Public ENUM. Or 
maybe there will be something else.  But in any case having *something* 
in place should kickstart the process.

	Thanks,
	Paul