RE: [Speermint] Location Function in SPEERMINT

["Brian Rosen" <[e-mail]>]

I think this is too much, or more appropriately, I think there is no point
in standardizing a protocol mechanism to exchange permitted transaction
rates or session/bandwidth quantity.  It's not that I think we don't need
this kind of limitations across a peering point, it's that I don't think
there is a protocol involved, and I don't think standardizing the mechanism
(which is just a provisioning process) gets us enough benefits to be worth
while, at least now.

I also think this is the kind of thing the terminating carrier has to
enforce, and if it does, then there is not much value in having the
originating carrier also do it; the terminating carrier can just say
"enough".  It's unlikely that the terminating carrier will trust the
originating carrier to do the limits checking.  The peering point could do
that, but then you get to "which originating carrier gets in the gate when
the line is full", and I don't think we want SPEERMINT to go there.

So, I think the terminating carrier effectively sends back busy when it
won't take any more traffic, and that is that.  You might have contracts
that specify the limits, but standardized mechanisms aren't really useful.

Brian

-----Original Message-----
From: Patrick Melampy [mailto:[e-mail]] 
Sent: Friday, May 26, 2006 10:34 PM
To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; 'James McEachern';
[e-mail]
Subject: RE: [Speermint] Location Function in SPEERMINT

I think SPEERMINT needs to help us locate and find adjacent proxies, and
attributes about those proxies. This will enable peering to be more flexible
and automatic -- as opposed to sharing lots of provisioning data and using
static proxy definitions (which is the way carriers peer today). I also
think that the attributes of proxies should include:
	Reachable domains
	Permitted transaction rates
	Permitted quantity of sessions/bandwidth

This is my opinion of course -- based on extensive practice. Any subset of
this type of information would be ok. Notice that I did not include any
media anchor's, or other methods. I do believe that you are right, this
should not be required. Also I believe that the originating network has
total control over selection of the "crossing point".

-----Original Message-----
From: Brian Rosen [mailto:[e-mail]] 
Sent: Friday, May 26, 2006 2:07 PM
To: 'Patrick Melampy'; 'Michael Hammer (mhammer)'; 'James McEachern';
[e-mail]
Subject: RE: [Speermint] Location Function in SPEERMINT

I think the question we want to ask in SPEERMINT is: do we care about any of
this?

It seems to me that the originating network, and the terminating network,
will arrange their signaling through designated peering points.  They can,
if they want, designate media peering points by using SBCs or other
mechanisms that effectively rewrite the SIP message bodies.  I think that we
can ignore that at the peering point, because when the call gets to the
peering point, it's going to have the SDP offer in the INVITE; the media
anchor has been decided.

Now, in many cases, I expect that as part of its network, the originating
network is going to do some kind of lookup (ENUM) that will tell it the
destination network, and that could influence its choice of media anchor if
it's doing things like that.  The point is that I don't think SPEERMINT
standardizes that behavior; it's a single element (some SIP proxy) making an
internal decision, and routing the call within its network appropriately.

Similarly, when the terminating network gets the call, it can make an
internal decision to direct the media to some box in its network, which will
show up in the answer SDP.  Again, that is it's proxy making an internal
routing decision.

BETWEEN networks, which where we are working, I don't think we are doing any
media routing beyond the normal SIP and IP packet stuff.

Do I have that right?

-----Original Message-----
From: Patrick Melampy [mailto:[e-mail]] 
Sent: Friday, May 26, 2006 12:23 PM
To: 'Michael Hammer (mhammer)'; 'James McEachern'; [e-mail]
Subject: RE: [Speermint] Location Function in SPEERMINT

One of the best arguments for the "composed" SBC is that if your going to
need to locate the "closest media anchor", what better way than associating
it with a proxy.

If the requirement is to NOT manage the media, but rather let natural BGP4
style internetworking mechanisms route the media optimally, then there is no
need to bother with identifying a location of a media anchor.

So the real issue here in terms of requirements is:

Will Carriers be able to use the autonomous system path (AS_PATH) for
delivery and routing of media packets from all sources (customers and
suppliers) to all sources (customers and suppliers.) Another way to say the
same thing more simply, will carriers put all of the signaled media onto the
public internet -- as it's the only internetwork available today.

If the answer is NO, then there will need to be media anchors and NAT
devices. The location of these devices will be important to the efficiency
and manageability of the service offering. The signaling and routing
components of the SIP network MUST be aware of the media path, as the
signaling plane is establishing the media path. This awareness and state
suggest that there needs to be a relationship between the signaling plane
and media anchor that is understood and close.

I'm going to suggest here that the location of the proxy (the nearest proxy)
be a substitute for the nearest media anchor point.


-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[e-mail]] 
Sent: Friday, May 26, 2006 11:51 AM
To: James McEachern; [e-mail]
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:[e-mail]] 
> Sent: Friday, May 26, 2006 11:16 AM
> To: Michael Hammer (mhammer); [e-mail]
> Subject: RE: [Speermint] Location Function in SPEERMINT
> 
> 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


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



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