Subject: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement on Problem Statement?

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 6 Nov 2006 19:14:55 -0500

>    What would be useful is a mechanism "between" a 
> registration holding
>    NAPTRs with URIs and the lack of a domain registration.  
> In this way,
>    an entity who is responsible for E.164 numbers in a range can
>    indicate that a particular number has not been assigned to 
> anyone for
>    communications service.  For example, if a communications service
>    provider has been allocated responsibility for delivering calls to
>    endpoints identified with E.164 numbers in a block, then they may
>    have some numbers in that block that are currently unused.  These
>    E.164 numbers are not used to terminate calls to end users.

So from this, I would understand the problem as such -

A service provider has a number block of, for example, +1-215-981-XXXX,
where XXXX is -0000 to -9999.  That SP has issued 50% of these numbers
to individual subscribers and the other 50% have not been.  These are
not neatly distributed within the block, as subscribers choose their
numbers so the active numbers end up being randomly distributed in the
block. 

If the SP registers SIP URIs for all of the active TNs then those calls
will work and terminate just fine.  If a TN is not registered then,
since it is inactive, then if a person dials one of the unregistered TNs
then you have to wait for NXDOMAIN response.  In that case, most
softswitches / proxies will then do legacy lookups (LNP, LERG, etc.).
The downside is two-fold: greater post-dial delay than is necessary, and
having to rely on legacy call lookup tools (which may have associated
costs).  There should be a way instead to stop the call routing
progression immediately if you know that the TN is inactive, thus
triggering back the code for a number not in service network
announcement to a caller.

Is this a correct understanding of one of the issues the authors are
trying to identify in the problem statement?

Jason

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 7 Nov 2006 01:54:16 +0100

>trying to identify in the problem statement?

One of the issues,
yes
Richard

________________________________

Von: Livingood, Jason [mailto:[email-masked]]
Gesendet: Di 07.11.2006 01:14
An: [email-masked]
Betreff: RE: [Enum] draft-ietf-enum-void-02 --> First Question - Agreement onProblem Statement?

Jason