Re: [Enum] Why not re-use interim procedures for infrastructure ENUM?

Richard Shockey <richard@shockey.us> Mon, 06 February 2006 19:03 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BeR-0002wY-U0; Mon, 06 Feb 2006 14:03:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BeQ-0002vY-L2 for enum@megatron.ietf.org; Mon, 06 Feb 2006 14:03:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12839 for <enum@ietf.org>; Mon, 6 Feb 2006 14:02:09 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Bqe-0007K2-QR for enum@ietf.org; Mon, 06 Feb 2006 14:16:30 -0500
Received: from [10.31.13.216] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k16J45Kr023988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2006 11:04:06 -0800
Message-ID: <43E79D81.3000809@shockey.us>
Date: Mon, 06 Feb 2006 14:03:29 -0500
From: Richard Shockey <richard@shockey.us>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM?
References: <32755D354E6B65498C3BD9FD496C7D462C4814@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4814@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, lconroy <lconroy@insensate.co.uk>
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Sender: enum-bounces@ietf.org
Errors-To: enum-bounces@ietf.org

Stastny Richard wrote:
>> (i) Requirements first - that should be fun. What's the schedule 
>> for ITU SG2
>>       meetings after January 2007?
> 
> good question
>  
> BTW, talking about doing requirements first:
> 
> I just got asked here at the ETSI TISPAN meeting, why then the 
> enumservice pstn is closing WGLC already, because this is
> definitely for Infrastructure ENUM.

Its actually a valid point and this is the third question I've had on 
that subject this morning since I issued the request for publication.

We had WGLC on this and if anyone had asked a question we certainly 
could have responded with the business case in more detail.

As we pointed out in various fora Enumservice PSTN may or _may not_ 
integrate with Infrastructure ENUM. How it is integrated is a "national 
matter" based on local policy involving LNP and who has access to that 
data under the relevant national policy.

The proposed RFC, today, has a great deal to do with the desire of some 
operators _right now_  to query a well known database about LNP data in 
IP friendly ( aka NO TCAP ) query response format.

If the softswitch/proxy can query for LNP data at call origination it 
can then signal the media gateway at the VoIP network edge what is the 
true route path is and thus eliminate an unnecessary and expensive TCAP 
queries and SS7/C7 PRI links.

TCAP - BAD   DNS - GOOD!

I do have hats these days btw.

The "well known database" is presumably "private" as we described in the 
draft however it may be a form of highly localized cached DNS server ( 
the IP-SCP if you want to call it that) inside the service providers 
network as well as a network based server.

Using high performance internal cacheing servers eliminates, in the 
opinion of some, considerable time in call setup operations. Vital 
milliseconds, especially in some IMS operations.

How that "well known database" is provisioned was outside the scope of 
this document.

This proposed RFC solves genuine network problems for VoIP softswitches 
today as well as tomorrow.



>  
> There was also a mumbling about "quod licet jovi, not licet bovi"
>  
> Just asking ;-)
> 

-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum