RE: [Speermint] Location Function in SPEERMINT

["Reinaldo Penno" <[e-mail]>]

I believe it is enough. You could refine it but I might sure of the
benefits. Maybe this problem was already solved somewhere and I'm not
aware. 

For example, The UAs would care.

>From RFC3263

;;          Priority Weight Port   Target
       IN SRV  0        1      5060   server1.example.com
       IN SRV  0        2      5060   server2.example.com

This tells you the SIP proxy to be contacted. It does not tell you if
this the closest Sip Proxy handling @example.com users. It also does not
tell you if it is the closest proxy to the callee.

In the case of a carriers providing VoIP service to a user, if this
provider A peers with provider B in two different locations, which one
to choose to send to forward the call?

Regards,

Reinaldo

> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]]
> Sent: Thursday, May 25, 2006 1:52 PM
> To: Reinaldo Penno; [e-mail]; Michael Hammer
(mhammer);
> [e-mail]; Brian Rosen; Francois D. Menard; Khan,
Sohel Q
> [CTO]; David Meyer; [e-mail]
> Subject: Re: [Speermint] Location Function in SPEERMINT
> 
> Reinaldo said:
> >That's maybe one of the most important issues. This could be
complicated
> >by the geographically dispersed networks with several entry points.
> >Although this might be an interesting problem it might be a rathole.
> 
> So you say RFC 3263 is not enough, something is missing?
> e.g. the geographic location of originating and terminating  --- what?
> 
> -SIP proxy? who cares
> -SBC?
> -UA?
> 
> So we are again dealing with SBCs, in this case the geo-location of
these
> -- rats, holes ;-)
> 
> Richard
> 
> 
> ________________________________
> 
> Von: Reinaldo Penno [mailto:[e-mail]]
> Gesendet: Do 25.05.2006 22:37
> An: Stastny Richard; [e-mail]; Michael Hammer
(mhammer);
> [e-mail]; Brian Rosen; Francois D. Menard; Khan,
Sohel Q
> [CTO]; David Meyer; [e-mail]
> Betreff: RE: [Speermint] Location Function in SPEERMINT
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Stastny Richard [mailto:[e-mail]]
> > Sent: Thursday, May 25, 2006 1:26 PM
> > To: [e-mail]; Michael Hammer (mhammer);
> > [e-mail]; Brian Rosen; Francois D. Menard; Khan,
> Sohel Q
> > [CTO]; David Meyer; [e-mail]
> > Subject: [Speermint] Location Function in SPEERMINT
> >
> > Hi all,
> >
> > sorry, but I am only able to reply with a short statement, because I
> am
> > on vacation and have only limited time and bandwitdh (GPRS)
> >
> > First, I consider this discussion regarding Infrastructure ENUM,
LERG
> and
> > LNP
> > important, but in the wrong WG. It should be discussed in ENUM. WG
and
> > not in SPEERMINT
> >
> > SPEERMINT is only dealing with Call Routing Data (CRD), which is
> defined
> > as the OUTPUT of ENUM or some other means.
> >
> > This implies, that the location function (LF) defined in the
> > achitecture draft happens AFTER an ENUM query and therefore
> > cannot be the part of the LF.
> >
> > The LF can only involve the location of the destination "network"
> > as defined in SPEERMINT by the use of CRD (which
> > is basically a SIP URI because we are currently talking only SIP
> > in SPEERMINT)
> >
> > Of course SPEERMINT needs to define what it considers CRD,
> > and AoR or the ingress point of a network.
> >
> > BUT then SPEERMINT needs also to define how the ingress
> > point of a "network" is LOCATED given a SIP AoR.
> [[Reinaldo]]
> 
> That's maybe one of the most important issues. This could be
complicated
> by the geographically dispersed networks with several entry points.
> Although this might be an interesting problem it might be a rathole.
> 
> 
> >
> > Richard
> >
> >
> > ________________________________
> >
> > Von: Tim Dwight [mailto:[e-mail]]
> > Gesendet: Do 25.05.2006 20:17
> > An: 'Michael Hammer (mhammer)'; [e-mail]; Stastny
> > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]';
> > 'David Meyer'; [e-mail]
> > Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF -
OF
> - SF
> >
> >
> >
> > Michael Hammer said:
> >
> > > Tim,
> > >
> > > The LERG and LNP databases are intrinsically tied to the operation
> of
> > the
> > TDM
> > > infrastructure.  Any design that perpatuates these systems when
> their
> > reason
> > > for being (TDM) goes away is a faulty design.
> >
> > OK with me.  I only meant to point out that right now I have these
> > capabilities, so recreating them isn't a high priority.
> >
> >
> > >
> > > DNS and ENUM provides the equivalent information and mechanisms to
> do
> > what
> > is
> > > needed in the IP domain.  As such, a design that makes
dependencies
> on
> > legacy
> > > systems is deficient.  I wouldn't support such a kludge.
> >
> > Fine.
> >
> > I'm a big fan of IP-domain solutions.  Specifically Infrastructure
> ENUM
> > looks really handy; my point before was that it's moreso when used
in
> what
> > Richard called "option 1".  The alternative ("option 2") only
> replicates
> > the
> > "kludge" to which I already have access.
> >
> > And to be fair to Richard, he did point out (subtly) that the latter
> claim
> > is a bit myopic.  There are existing means by which VSPs can gain
> access
> > to
> > number portability information relative to national destinations.
> They
> > don't have such access, at least not easily and not universally, to
> number
> > portability information relative to international destinations.  If
> that
> > could be provided by Infrastructure ENUM (either "option 1" or
"option
> 2")
> > it would be useful and would not simply replicate existing
> capabilities.
> >
> > Bottom line, both options defined by Richard, would add value.
Option
> 1
> > adds more value but is specific to destinations identified by E.164
> > numbers
> > or URIs with imbedded E.164 numbers.  Which is the problem closest
to
> > hand.
> >
> >
> > >
> > > That said, if there are backward compatibilities during the
> transition,
> > where
> > > some information just happens to be known by external systems,
such
> as
> > you
> > suggest
> > > below, I don't see that as a problem.  I am just wary of ending up
> with
> > two
> > > systems in the end when one would do.
> >
> > Isn't it inevitable that for some time, both will exist?  Just as
the
> GSTN
> > and VoIP will coexist for some time, so will their supporting
> > infrastructure.
> >
> > Don't get me wrong.  I'm not saying "because I have an SS7 -based
> solution
> > to LNP I don't need an IP -based solution".  All I'm saying is that
> when
> > given the option of using Infrastructure ENUM to recreate (and in
the
> case
> > of international destinations, extend) the capability I already
have,
> and
> > using it to do that and more, I'm inclined to prefer the latter.
> >
> >
> > >
> > > Mike
> >
> >
> > > -----Original Message-----
> > > From: Tim Dwight [mailto:[e-mail]]
> > > Sent: Wednesday, May 24, 2006 6:19 PM
> > > To: 'Stastny Richard'; [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
> > >
> > > 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
> >
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/speermint

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