Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

["Stastny Richard" <[e-mail]>]

Tim,
 
another short reply:

b) you can provide a LRN, with the pstn Enumservice
and if you can explain to me how a plain sip-proxy accesses 
e.g the OpenSER accesses the LERG and the LNP database
especially from e.g. Austria, fine

With Infrastructure ENUM this is a no-brainer
 
Richard


________________________________

Von: Tim Dwight [mailto:[e-mail]]
Gesendet: Do 25.05.2006 00:19
An: Stastny Richard; [e-mail]; [e-mail]; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [e-mail]
Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF



Richard,

Yes I know I was mixing data and mechanism-to-access-data.  Still I believe
the major point to be correct.  In many parts of the world there are already
mechanisms (associated with Local Number Portability) to determine ownership
of an E.164 number, hence use of ENUM for this purpose alone, will be
unnecessary. 

To be clear, I believe that providing access via Infrastructure ENUM to LNP
information may be very helpful;  but only if Infrastructure ENUM provides
more than just this.  If an Infrastructure ENUM query can combine (a)
determination of the entity providing service to the destination, (b)
determination of the corresponding LRN, if one exists, and (c) mapping of
the routable number (either the number originally indicated, or the LRN) to
a Layer 5 "point of ingress" specified by the entity providing service to
the destination;  then Infrastructure ENUM is quite a handy mechanism.  If
all it does is (a) then I don't need it.

But in the end this is neither here nor there.  I am not wedded to any
specific technology, I just need workable solutions to real business
problems.

Tim


-----Original Message-----
From: Stastny Richard [mailto:[e-mail]]
Sent: Wednesday, May 24, 2006 4:38 PM
To: [e-mail]; [e-mail]; Michael Hammer
(mhammer); Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David
Meyer; [e-mail]
Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

Tim,

thanx for your reply, you are raising some important issues.
Since it is already midnight here, I will reply to it in detail tomorrow

I am also working on a more detailed analysis and a draft which will require
even some more time.

Just a quick one:

>In some parts of the world the function provided by "option 2" usage of
>Infrastructure ENUM could be achieved in other ways (e.g., the LERG and
>NPDB in North America) so in those cases Infrastructure ENUM might be a
>superfluous concept;  but if that's the right technical answer so be it.

Yes and no ;-)
You are mixing up here the Registry and the ENUM DNS.
The Registry is the LERG and NPDB (or is derived from), the ENUM DNS is the
equivalent on IP of the SCP in the PSTN where the date is downloaded to.

Richard


________________________________

Von: Tim Dwight [mailto:[e-mail]]
Gesendet: Mi 24.05.2006 23:00
An: Stastny Richard; [e-mail]; 'Michael Hammer (mhammer)';
'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer';
[e-mail]
Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF



Richard,

Thank you for the clarification.  I understand the distinction you are
making.

My objective is to be able to translate a destination identifier (E.164
number of alphanumeric AoR) into the address of a Layer 5 entity designated
by the organization providing service to the called party.  With
infrastructure/carrier ENUM I could do this (as described in your Option 1),
but because ENUM is specific to E.164 numbers it would only work for E.164
-formatted destination identifiers.

In pictures, your Option 2 seems to me to imply the following:

               +----------------+                 +----------+
E.164          | infrastructure |     serving     | identify |     network
ingress
destination -->| ENUM           |---> carrier --->| ingress  |---> point
specified
identifier     | (option 2)     |     identity    | point    |     by
serving carrier
               +----------------+        ^        +----------+
                                         |
               +----------------+        |
non-E.164      | map domain in  |        |
Destination -->| URI to carrier |--------+
Identifier     | identity       |
               +----------------+

In some parts of the world the function provided by "option 2" usage of
Infrastructure ENUM could be achieved in other ways (e.g., the LERG and NPDB
in North America) so in those cases Infrastructure ENUM might be a
superfluous concept;  but if that's the right technical answer so be it.

The "identify ingress point" function would need to be defined.  I would
like it to consider the specified destination (in addition to the carrier
providing service to that destination); and I would like the procedures to
be such that the serving carrier controls (in a reasonably dynamic way) the
point at which traffic destined to a particular destination, enters his
network.  If those requirements can be met, I think this approach is
workable.

Its biggest drawback is that it precludes a solution ("option 1" usage of
Infrastructure ENUM) that is sufficient for the majority of today's needs.
It optimizes for a problem that will exist in the future at the expense of
solving problems that exist today.  I realize that solving today's problems
may not be SPEERMINT's focus, or (arguably) even within its charter, but I
would hate to see recommendations from SPEERMINT preclude or significantly
delay solving them.

Suppose we did something like this:

               +----------+     [pseudo     +----------------+
non-E.164      | identify |     or real]    | infrastructure |     network
ingress
destination -->| "pseudo" |---> E.164   --->| ENUM           |---> point
specified
identifier     | E.164    |     number      | (option 1)     |     by
serving carrier
               +----------+                 +----------------+

We could let the ENUM working group define Infrastructure ENUM as described
in your Option 1 (which is as you know already commercially available from a
few sources) and SPEERMINT could define the "identify pseudo E.164" function
that in my diagram feeds into it.  This function might be as simple as
mapping the domain part of the URI to an E.164 number uniquely associated
with the network providing service to the specified destination.  Unless
this is a lot harder than it seems, this shouldn't keep us busy too long :-)


Tim


-----Original Message-----
From: Stastny Richard [mailto:[e-mail]]
Sent: Wednesday, May 24, 2006 11:16 AM
To: [e-mail]; Michael Hammer (mhammer); Brian Rosen;
Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; [e-mail]
Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

Tim,

>> ... the basic idea of Infrastructure ENUM (which will be used for
>> service providers is to provide a domain name in a SIP URI = a
>> service provider ID
>(SPID)

>At the risk of asking an off-topic question (realizing that ENUM is not
>within scope for SPEERMINT), can I ask where the idea that
>Infrastructure ENUM queries return SPIDs, comes from?  It is my intent
>to provide a point of interconnection to be used by the requesting
>entity to hand to me a call to the specified number.  I do not intend
>that the only meaningful part of the URI returned from the ENUM query,
>be
the domain name.

thank you for raising this important point. I tried to raise this some time
ago, but got no clear answer

Currently there exist two lines of thought about the usage of Infrastructure
(and also Carrier ENUM in private trees)

1. Put in ENUM the ingress point(s) e.g. sip:[e-mail] 2.
Put in ENUM the AoR only: e.g. sip:[e-mail] (provider.net is what
I meant with SPID)

Most currently prefer option 1, especially in private ENUM trees.

IMHO this is the wrong approach:

There should be a clear separation (and it is in the charter) between ENUM
and SPEERMINT SPEERMINT peering MUST be able to work standalone and without
ENUM.

Option 1 assumes also that the user is entering ALWAYS an E.164 number as
identifier.

But what if he is entering an AoR?

SPEEMINT peering MUST be able to resolve this too so you need to find the
ingress point independant of ENUM e.g. via RFC3263.

If this MUST be possible, why not enter in (any) ENUM just the AoR, if you
must be able to resolve the AoR anyway?

Otherwise you need to manage two mappings separate 1. the E.164 to ingress
point 2. the AoR mapping to ingress point

this is not a good idea

This is the reason why I would prefer to enter in ENUM AoRs only the user
part in ENUM is always the E.164 number (for privacy reasons) the domain
part is the SPID, which is mapped later to find the ingress point

the calling user may then also use an alis AoR such as sip:[e-mail]

regards

Richard



________________________________

Von: Tim Dwight [mailto:[e-mail]]
Gesendet: Mi 24.05.2006 16:46
An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D.
Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; [e-mail]
Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF



Stastny, Richard said:

> ... the basic idea of Infrastructure ENUM (which will be used for
> service providers is to provide a domain name in a SIP URI = a service
> provider ID
(SPID)

At the risk of asking an off-topic question (realizing that ENUM is not
within scope for SPEERMINT), can I ask where the idea that Infrastructure
ENUM queries return SPIDs, comes from?  It is my intent to provide a point
of interconnection to be used by the requesting entity to hand to me a call
to the specified number.  I do not intend that the only meaningful part of
the URI returned from the ENUM query, be the domain name.

tim




_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint




_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint




_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint