RE: [Speermint] Location Function in SPEERMINT

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

So are you saying that it should be a requirement?

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[e-mail]] 
Sent: Friday, May 26, 2006 10:52 AM
To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny Richard; [e-mail]; [e-mail]; Brian Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; [e-mail]
Subject: RE: [Speermint] Location Function in SPEERMINT

Distance is dead IF the proxy does not have strong ties to a media
anchor point.  If there is such a media anchor point, then choosing ones
that are close to calling and called parties will aid in finding
shortest routes between parties.

However, I am not advocating for or against such media anchors, just
simply recognizing that they may exist depending on a domain's
architecture.

There may be other reasons that peers are directed to one proxy over
another.  It is useful for the domain to designate which proxies peers
should use.

Mike


> -----Original Message-----
> From: James McEachern [mailto:[e-mail]] 
> Sent: Friday, May 26, 2006 10:44 AM
> To: Reinaldo Penno; 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
> 
> >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