RE: [Speermint] Location Function in SPEERMINT
"James McEachern" <jmce@nortel.com> Fri, 26 May 2006 16:34 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfH8-0006c5-8w; Fri, 26 May 2006 12:34:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfH6-0006bw-MZ for speermint@ietf.org; Fri, 26 May 2006 12:34:56 -0400
Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfH5-0004wQ-Q0 for speermint@ietf.org; Fri, 26 May 2006 12:34:56 -0400
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4QGTkf12309; Fri, 26 May 2006 12:29:47 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Location Function in SPEERMINT
Date: Fri, 26 May 2006 12:34:46 -0400
Message-ID: <F1A1D21DA394814E824AC89F5A005BA30B46784F@zcarhxm0.corp.nortel.com>
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301848109@xmb-rtp-20b.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Speermint] Location Function in SPEERMINT
Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9AAGrFeAACZ2pfQABju7wACHfcEAAAbB9IAAK1HH6AAC9BtAAAGOAdAAAMvVgACTEanAAAMf18AAA1j4AAAEyrIAAAVK4MA==
From: James McEachern <jmce@nortel.com>
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>, speermint@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 197d13e6eff8b01fadb94b62c6f788ce
Cc:
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org
Fair enough - I think I may be losing track of "it" myself. Let me take a stab at it, and then perhaps we can agree if "it" is a requirement or not. Possible SPEERMINT requirement: The ability to selectively discover a specific instance of a proxy/interconnect point for peering. The criteria used to select the appropriate proxy include: (here I think we need to make a specific decision for each potential criterion.) - peer identity or affiliation (federation) - location (or distance, or some other suitable related attribute) - other??? Jim -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] Sent: Friday, May 26, 2006 11:51 AM To: McEachern, James [CAR:5N00:EXCH]; speermint@ietf.org Subject: RE: [Speermint] Location Function in SPEERMINT I think I have lost track of what "it" is. I don't think "it" is the ability to identify a proxy that a peer should use based on location. "It" may be the ability to identify a proxy that a peer should use based on the peer identity or affiliation (federation). "Location" has geographic baggage when perhaps selective "discovery" is really what is meant. Please correct me as I may have gotten disoriented with the different mail threads. Mike > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com] > Sent: Friday, May 26, 2006 11:16 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Location Function in SPEERMINT > > So are you saying that it should be a requirement? > > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, May 26, 2006 10:52 AM > To: McEachern, James [CAR:5N00:EXCH]; Reinaldo Penno; Stastny > Richard; timothy.dwight@verizon.com; > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; > Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > 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:jmce@nortel.com] > > Sent: Friday, May 26, 2006 10:44 AM > > To: Reinaldo Penno; Stastny Richard; > > timothy.dwight@verizon.com; Michael Hammer (mhammer); > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q [CTO]; David Meyer; speermint@ietf.org > > 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:rpenno@juniper.net] > > Sent: Thursday, May 25, 2006 5:00 PM > > To: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); timothy.dwight@verizon.com; Brian Rosen; Francois D. > > Menard; Khan, Sohel Q [CTO]; David Meyer; speermint@ietf.org > > 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:Richard.Stastny@oefeg.at] > > > Sent: Thursday, May 25, 2006 1:52 PM > > > To: Reinaldo Penno; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > 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:rpenno@juniper.net] > > > Gesendet: Do 25.05.2006 22:37 > > > An: Stastny Richard; timothy.dwight@verizon.com; Michael Hammer > > (mhammer); > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. Menard; Khan, > > Sohel Q > > > [CTO]; David Meyer; speermint@ietf.org > > > Betreff: RE: [Speermint] Location Function in SPEERMINT > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Thursday, May 25, 2006 1:26 PM > > > > To: timothy.dwight@verizon.com; Michael Hammer (mhammer); > > > > timothy.dwight@verizon.com; Brian Rosen; Francois D. > Menard; Khan, > > > Sohel Q > > > > [CTO]; David Meyer; speermint@ietf.org > > > > 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:timothy.dwight@verizon.com] > > > > Gesendet: Do 25.05.2006 20:17 > > > > An: 'Michael Hammer (mhammer)'; > > timothy.dwight@verizon.com; Stastny > > > > Richard; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, > > Sohel Q [CTO]'; > > > > 'David Meyer'; speermint@ietf.org > > > > 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:timothy.dwight@verizon.com] > > > > > Sent: Wednesday, May 24, 2006 6:19 PM > > > > > To: 'Stastny Richard'; timothy.dwight@verizon.com; > > > > > timothy.dwight@verizon.com; Michael Hammer (mhammer); 'Brian > > Rosen'; > > > > > 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > > > > speermint@ietf.org > > > > > 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:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 4:38 PM > > > > > To: timothy.dwight@verizon.com; timothy.dwight@verizon.com; > > Michael > > > > > Hammer (mhammer); Brian Rosen; Francois D. Menard; > > Khan, Sohel Q > > > > > [CTO]; David Meyer; speermint@ietf.org > > > > > 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:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 23:00 > > > > > An: Stastny Richard; timothy.dwight@verizon.com; > > 'Michael Hammer > > > > > (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; > 'Khan, Sohel Q > > > > > [CTO]'; 'David Meyer'; speermint@ietf.org > > > > > 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:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, May 24, 2006 11:16 AM > > > > > To: timothy.dwight@verizon.com; Michael Hammer > (mhammer); Brian > > > > > Rosen; Francois D. Menard; Khan, Sohel Q [CTO]; David Meyer; > > > > > speermint@ietf.org > > > > > 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:+43xxxx@sbc4711.provider.net 2. > > > > > Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net > > > > > (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:name@provider.net > > > > > > > > > > regards > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Tim Dwight [mailto:timothy.dwight@verizon.com] > > > > > Gesendet: Mi 24.05.2006 16:46 > > > > > An: Stastny Richard; 'Michael Hammer (mhammer)'; > 'Brian Rosen'; > > > > > 'Francois D. > > > > > Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; > > speermint@ietf.org > > > > > 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 > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint
- [Speermint] Location Function in SPEERMINT Stastny Richard
- RE: [Speermint] Location Function in SPEERMINT Reinaldo Penno
- Re: [Speermint] Location Function in SPEERMINT Stastny Richard
- RE: [Speermint] Location Function in SPEERMINT Reinaldo Penno
- RE: [Speermint] Location Function in SPEERMINT James McEachern
- RE: [Speermint] Location Function in SPEERMINT James McEachern
- RE: [Speermint] Location Function in SPEERMINT Michael Hammer (mhammer)
- RE: [Speermint] Location Function in SPEERMINT Patrick Melampy
- RE: [Speermint] Location Function in SPEERMINT James McEachern
- Re: [Speermint] Location Function in SPEERMINT Stastny Richard
- RE: [Speermint] Location Function in SPEERMINT Brian Rosen
- RE: [Speermint] Location Function in SPEERMINT Patrick Melampy
- RE: [Speermint] Location Function in SPEERMINT Tim Dwight
- RE: [Speermint] Location Function in SPEERMINT Brian Rosen