RE: [Speermint] Location Function in SPEERMINT

["James McEachern" <[e-mail]>]

>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.

Is the ability to "identify the closest proxy" a requirement for Speermint?  Many people have pointed out that distance is dead, or at least should be, so it isn't clear to me that we really care. The Requirements and Terminology draft doesn't explicitly say, but my reading of section 5.2 implies this is not a requirement. 

That having been said, I don't necessarily have strong views either way.  I'd just like to be clear on whether or not it is a requirement.

Jim


-----Original Message-----
From: Reinaldo Penno [mailto:[e-mail]] 
Sent: Thursday, May 25, 2006 5:00 PM
To: Stastny Richard; [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

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


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