Subject: [Enum] SIP AoR, tel and ENUM

From: "Stastny Richard" <[email-masked]>
Date: Tue, 6 Dec 2005 10:54:12 +0100

Folks,

This post is primarily to SPEER, but since it also concerns ENUM and SIP
I cross-post it.

I need (urgently) some guidance on the question what SIP URIs to
use in Infrastructure ENUM.

User ENUM as defined in RFC 3761 provides a mapping from E.164 numbers
to SIP URIs for primarily for end-users. So what you get back is the
AoR pointing to the destination SIP server.

If you get something back on the ENUM query such as
sip:[email-masked],
this is definetely an AoR. Because of privacy reasons, more and more
people
start using SIP URI such as
sip:[email-masked] or (an AoR)
sip:[email-masked];user=phone (IMHO not an AoR) or even
sip:[email-masked]

IMHO the last one should not be used, and some guidance
is also needed here. but it only concerns the destination
server and if the destination servers can deal with it, fine.

Now with Infrastructure ENUM (and especially in combination
with private ENUMs) the situation is different.

The purpose of Infrastructure ENUM is according to the
re-chartered ENUM WG "to discover points of interconnection necessary to
terminate communications sessions identified by a E164 number,
in addition to identifying end point protocols and services."

This translates to: Infrastructure ENUM does not necessarily contain
end-point information (AoR), but routing information. Routing, in my
definition here, is basically to provide you with the information what
the next hop is.

A very common scenario is the following one: a walled garden network
is using private ENUM to detect the border element for a given number,
Some border element may lead to another private (extranet), using
a federated ENUM for this number, another may be connected to the 
Internet using public Infrastructure ENUM for another number.
Public Infrastructure ENUM is giving back the ingress border
element, which in turn uses private ENUM again to find the
SIP server hosting the user with this number.

In addition, again for privacy reasons, in most cases the above
mentioned SIP URIs containing E.164 numbers are used.

This raises two issues, an architectural one and a BCP one:

To principally different scenarios are possible

Scenario A

ENUM is providing ONLY the mapping from the E.164 number
to an AoR. (= name to address mapping)
The above described routing between the networks
to find the destination network is done via the AoR. How this
is done is completely within the scope of SPEER.

Note: this is the only future proof way, because a user may
use the AoR in the first place and then the routing MUST work
anyway. So any additional routing information in ENUM would
be duplicated and therefore error-prone.

I propose in addition to use in this case a SIP in the format
sip:[email-masked], to clearly indicate that this
has no relationship to an E.164 number.

Scenario B:

This is the scenario proposed in most current implementations
and also in the RFI on ENUM popping up everywhere. The reason
is that most scenarios currently concentrate solely on
the peering with E.164 numbers and completely forget the
peering with SIP URIs

The ENUM entry is giving you the next hop: This is in case
of the walled garden originating network either the server
hosting the end-user or the egress border element (e.g. IBCF,
THIG, or whatchamacallit). This element is again querying another
kind of ENUM, getting back the ingress border element of the
destination network (or even of a "transit" L5 network), and so
on. The ingress border element is the again calling its private ENUM
to finally find the hosting server.

Note: I have a sub-question here: Some implementations are
even proposing here to skip the SRV query and directly pointing
to the SIP server(s) in ENUM. Does this make sense?

If this scenario is used, I propose to use only SIP URIs
in the format
sip:[email-masked];user=phone or better
SIP:[email-masked]; user=phone

to clearly indicate that this is still basically a 
tel: URI combined with a routing info and that it may 
be used in another ENUM query.

My questions to the crowd are the following:

1. is this proposed use of SIP URIs within the context
of ENUM ok?

2. What should be the preferred scenario for
VoIP peering? 
Is some kind of combination between the scenarios
feasible? 
And what are the arguments pro and con?

I consider the outcome of this discussion as
substantial input to the deliverables of SPEER,
but some first guidance is urgently required now,
because many entities are making basic decisions
in this direction NOW.

Please also excuse and correct incorrect use of terminology.

Regards
Richard Stastny

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 6 Dec 2005 10:21:19 -0500

Richard et al,

Before going down this path too far, can we ask where the results of the
ENUM queries will go in the SIP message to control routing?
Hypothetically, the egress and ingress gateways could be identified in
Route headers rather than in the Request-URI.  An external ENUM dip and
an internal ENUM dip might lead to something along the lines of:

INVITE tel:+17775551111 SIP/2.0
...
Route: <sip:egress11.provider3.com;lr>
Route: <sip:ingress39.provider17.com;lr>
...

I am also suggesting that the ENUM result be an AoR, since one might
want some reliability in choosing which server in the gateway cluster to
go to based on further DNS queries, load balancing, etc.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stastny Richard
> Sent: Tuesday, December 06, 2005 4:54 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Sip] SIP AoR, tel and ENUM
> 
> Folks,
> 
> This post is primarily to SPEER, but since it also concerns 
> ENUM and SIP I cross-post it.
> 
> I need (urgently) some guidance on the question what SIP URIs 
> to use in Infrastructure ENUM.
> 
> User ENUM as defined in RFC 3761 provides a mapping from 
> E.164 numbers to SIP URIs for primarily for end-users. So 
> what you get back is the AoR pointing to the destination SIP server.
> 
> sip:[email-masked], this is definetely an AoR. Because 
> of privacy reasons, more and more people start using SIP URI 
> such as sip:[email-masked] or (an AoR) 
> sip:[email-masked];user=phone (IMHO not an AoR) or 
> even sip:[email-masked]
> 
> IMHO the last one should not be used, and some guidance is 
> also needed here. but it only concerns the destination server 
> and if the destination servers can deal with it, fine.
> 
> re-chartered ENUM WG "to discover points of interconnection 
> necessary to terminate communications sessions identified by 
> a E164 number, in addition to identifying end point protocols 
> and services."
> 
> This translates to: Infrastructure ENUM does not necessarily 
> contain end-point information (AoR), but routing information. 
> Routing, in my definition here, is basically to provide you 
> with the information what the next hop is.
> 
> A very common scenario is the following one: a walled garden 
> network is using private ENUM to detect the border element 
> for a given number, Some border element may lead to another 
> private (extranet), using a federated ENUM for this number, 
> another may be connected to the Internet using public 
> Infrastructure ENUM for another number.
> In addition, again for privacy reasons, in most cases the 
> above mentioned SIP URIs containing E.164 numbers are used.
> 
> ENUM is providing ONLY the mapping from the E.164 number to 
> an AoR. (= name to address mapping) The above described 
> routing between the networks to find the destination network 
> is done via the AoR. How this is done is completely within 
> the scope of SPEER.
> 
> is that most scenarios currently concentrate solely on the 
> peering with E.164 numbers and completely forget the peering 
> with SIP URIs
> 
> The ENUM entry is giving you the next hop: This is in case of 
> the walled garden originating network either the server 
> THIG, or whatchamacallit). This element is again querying 
> another kind of ENUM, getting back the ingress border element 
> of the destination network (or even of a "transit" L5 
> network), and so on. The ingress border element is the again 
> calling its private ENUM to finally find the hosting server.
> 
> even proposing here to skip the SRV query and directly 
> pointing to the SIP server(s) in ENUM. Does this make sense?
> 
> If this scenario is used, I propose to use only SIP URIs in 
> the format sip:[email-masked];user=phone or better 
> tel: URI combined with a routing info and that it may be used 
> in another ENUM query.
> 
> 1. is this proposed use of SIP URIs within the context of ENUM ok?
> 
> 2. What should be the preferred scenario for VoIP peering? 
> Is some kind of combination between the scenarios feasible? 
> I consider the outcome of this discussion as substantial 
> input to the deliverables of SPEER, but some first guidance 
> is urgently required now, because many entities are making 
> basic decisions in this direction NOW.
> 
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 
> Use [email-masked] for new developments on the application of sip
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 6 Dec 2005 13:24:08 -0500

Hmmm...  should I have said?:

Route: <sip:egress-farm-11.provider3.com;lr>

Mike

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Tuesday, December 06, 2005 10:47 AM
> To: Michael Hammer (mhammer); [email-masked]
> Subject: Re: [Sip] SIP AoR, tel and ENUM
> 
> Mike wrote:
> 
> >Before going down this path too far, can we ask where the results of 
> >the ENUM queries will go in the SIP message to control routing?
> Correct,
> Jonathan proposed this some time ago, but this thread 
> somewhere stranded
>  
> So basically an interneal ENUM entry of
> 
> sip:[email-masked];user=phone
>  
> would result in
> 
> an the external ENUM entry would be
> sip:[email-masked]
>  
> result in
> This is basically what I am after
> ...
> 
> >want some reliability in choosing which server in the 
> gateway cluster 
> >to go to based on further DNS queries, load balancing, etc.
>  
> Now this is in contradiction to the above
>  
> Richard
> 
> >Mike
> 
> Behalf Of 
> > Stastny Richard
> > I need (urgently) some guidance on the question what SIP 
> URIs to use 
> > in Infrastructure ENUM.
> >
> what you get 
> > back is the AoR pointing to the destination SIP server.
> >
> of privacy 
> > reasons, more and more people start using SIP URI such as 
> also needed 
> > here. but it only concerns the destination server and if the 
> > destination servers can deal with it, fine.
> >
> > Now with Infrastructure ENUM (and especially in combination with 
> > private ENUMs) the situation is different.
> >
> > The purpose of Infrastructure ENUM is according to the re-chartered 
> > ENUM WG "to discover points of interconnection necessary to 
> terminate 
> > communications sessions identified by a E164 number, in addition to 
> > identifying end point protocols and services."
> >
> > end-point information (AoR), but routing information.
> > Some border element may lead to another private (extranet), using a 
> > federated ENUM for this number, another may be connected to the 
> > Public Infrastructure ENUM is giving back the ingress 
> border element, 
> > which in turn uses private ENUM again to find the SIP 
> server hosting 
> > the user with this number.
> >
> an AoR. (= 
> > name to address mapping) The above described routing between the 
> > networks to find the destination network is done via the 
> AoR. How this 
> > Note: this is the only future proof way, because a user may use the 
> > AoR in the first place and then the routing MUST work 
> anyway. So any 
> > additional routing information in ENUM would be duplicated and 
> > therefore error-prone.
> >
> > sip:[email-masked], to clearly indicate that this has no 
> > relationship to an E.164 number.
> >
> > Scenario B:
> >
> > This is the scenario proposed in most current 
> implementations and also 
> > in the RFI on ENUM popping up everywhere. The reason is that most 
> > scenarios currently concentrate solely on the peering with E.164 
> > numbers and completely forget the peering with SIP URIs
> >
> > The ENUM entry is giving you the next hop: This is in case of the 
> > walled garden originating network either the server hosting the 
> > end-user or the egress border element (e.g. IBCF, THIG, or 
> > whatchamacallit). This element is again querying another 
> kind of ENUM, 
> > getting back the ingress border element of the destination 
> network (or 
> > even of a "transit" L5 network), and so on. The ingress 
> border element 
> > is the again calling its private ENUM to finally find the hosting 
> > server.
> >
> > Note: I have a sub-question here: Some implementations are even 
> > proposing here to skip the SRV query and directly pointing 
> to the SIP 
> the format 
> > tel: URI combined with a routing info and that it may be used in 
> > another ENUM query.
> >
> input to the 
> > deliverables of SPEER, but some first guidance is urgently required 
> > now, because many entities are making basic decisions in this 
> > direction NOW.
> >
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> >
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 6 Dec 2005 18:23:47 -0500

My looking glass is smudged today.

What does one call a provider of service?  
I don't understand the aversion to service provider. 

I thought it was only the "carrier" word that invoked regulatory burdens
(or PATS!).  I'd rather leave legal word games to lawyers and lobbyists.

Mike

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Tuesday, December 06, 2005 5:30 PM
> To: Michael Hammer (mhammer); 'Thilo Salmon'; 'Klaus Darilion'
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> 'Stastny Richard'
> Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> 
> Sorry for nitpicking:
> 
> >A provider is a provider.
> 
> A provider is a business model and att/SBC may differ from 
> Google who uses a different business model (which is more 
> significant measured in $$$?).
> 
> Didn't we agree to use the term "Internet domain owner" (we 
> could shorten to IDOM or such)? 
> 
> Internet domains are well defined in the IETF. 
> Business models for VoIP are better suited for other 
> organizations, consortia or innovators who work to disrupt them :-)
> 
> Thanks, Henry
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Michael Hammer
> (mhammer)
> Sent: Tuesday, December 06, 2005 3:36 PM
> To: Thilo Salmon; Klaus Darilion
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> Stastny Richard
> Subject: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> 
> I am having trouble parsing these statements.
> 
> A provider is a provider.  I used the terms ingress and 
> egress to indicate some server that sits on the edge of a 
> provider's network and does peering to some other provider.  
> The usage below seems to mix egress with originating being 
> the network where the caller is attached.
> 
> I was noting that the called party terminal and the 
> interconnect points were different hosts and therefore may 
> have different identities.  To keep maximum flexibility, the 
> format of those identities would need to be fully under the 
> control of the domain of each provider.  However, conflating 
> all that into a single URI in the Request-URI seemed 
> constraining to me.  Having three URIs in separate headers 
> seemed the most flexible.
> 
> Splitting.  I don't understand what got split or how.  ENUM 
> -- Tel:URI in, Point-of-interconnect URI out.  Put in Route 
> header.  I only suggested that there might be two route 
> headers because the terminating provider would indicate in 
> ENUM, to get to this end-user, go to this entrance first.  
> But, to get to that entrance, the originating provider needs 
> to determine what the corresponding exit point is from his 
> network, i.e. another Route header.  The format and content 
> of that URI is up to each provider.  The advertised entrance 
> point is I think by definition the (Inter-) Carrier ENUM.  
> The internal determination of the exit point could be termed 
> (Intra-) Carrier ENUM.  Maybe peering is concerned only with 
> the inter-carrier aspect.
> 
> The Request-URI could be a normalized public identity of the 
> user totally independent of interconnect naming schemes.  I 
> was just teasing out what are the assumptions and constraints 
> in the original email.
> 
> Mike
> 
> 
> > From: Thilo Salmon [mailto:[email-masked]]
> > Sent: Tuesday, December 06, 2005 2:06 PM
> > To: Klaus Darilion
> > Cc: Michael Hammer (mhammer); [email-masked]; 
> [email-masked]; 
> > [email-masked]; Stastny Richard
> > Subject: Re: [Enum] Re: [Sip] SIP AoR, tel and ENUM
> > 
> > Richard, Klaus, et al.
> > 
> > Apparently, I have missed an important developlement lately. 
> > 
> > > What is the benefit of splitting the ENUM result (the SIP
> > URI) into a
> > > Route header and into a request URI?
> > [...]
> > > IMO there should be no semantic for the internal routing
> > (the routing
> > > from the main proxy to the egress proxy). This should be
> > out of scope
> > > of all WGs. Also the internal routing of the ingress
> > provider should
> > > be out of scope. The ingress provider should have SIP URI
> > which can be
> > > used to address its customers.
> > 
> > I absolutely second that statement. If for any reason (we all have 
> > enough a vivid enough phantasy to imagine a good reason, I 
> suppose) an 
> > ingress provider wishes to feed a different set of SIP URIs to each 
> > and every of his egress partners, he should not be stripped of this 
> > option.
> > The scenario I have in mind is one in which an ingress provider 
> > chooses to encrypt the user part of all his SIP URIs with a key 
> > uniquely assigns to his egress partner.
> > 
> > Just as Klaus I feel this complicates things and takes 
> authority over 
> > internal adressing away from the ingress provider for no reason 
> > apparent (to me).
> > 
> > Thilo
> > 
> 
> ______________________________________________________________
> ______________
> _
> List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> 
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 7 Dec 2005 14:49:05 -0500

I don't have issues with what you have said.  I was trying to discover
what was objectionable in what I had said, but thre doesn't seem to be
anything.

Mike

> From: Klaus Darilion [mailto:[email-masked]] 
> Sent: Wednesday, December 07, 2005 3:33 AM
> To: Michael Hammer (mhammer)
> Cc: Stastny Richard; [email-masked]; 
> [email-masked]; [email-masked]
> Hi Michael!
> As there are some concerns about the terminology. Thus I will 
> use AD (adminsitrative domain, from the SPEERMINT charter) as 
> synonym for ITSP, carrier, telco, VoIP enabled enterprise .....
> 
> Michael Hammer (mhammer) wrote:
> > Klaus,
> > 
> > It has to do with the difference between re-targeting and 
> routing.  Is 
> > the point of interconnect the real target of the request or just a 
> > waypoint in the route to get to the target?  In the User 
> ENUM case, it 
> > seems as though the addresses are all about the target 
> users and their 
> > devices.  But, here it seemed a bit different.  It is a 
> route through 
> > an intermediate point.  It seems like the semantic and syntactical 
> > element would be more coherent and no more complicated.  
> Thus, I posed 
> > the question.
> 
> I can not really see a difference to user ENUM. There is only 
> one Infrastructure ENUM tree. Thus, all ADs which query this 
> tree will get the same URI back from ENUM. Thus, the ingress 
> point announced by the receiving AD is the same for all outgoing ADs.
> 
> Further, if the outgoing AD does not send the request 
> directly to the announced ingress point (maybe no peering 
> relationship), but to an intermediate point (transit 
> provider, clearinghouse, ....), this routing is different for 
> each AD. Thus, such kind of routing information can not be in ENUM.
> 
> Once the request reaches the ingress point of the receiving 
> AD, there will be further routing inside the receiving AD. 
> Maybe the route is for
> example:
>   1. ingresspoint1.ad
>   2. accountingbox.ad
>   3. mainproxy.ad
>   4. .....
> 
> Publishing such a route in ENUM makes no sense, as the route 
> is the same for all incoming requests. Thus, the route should 
> be applied by the previous hop. That means, ingresspoint1.ad 
> knows that it should formward to accountingbox.ad, and so on.
> 
> IMO, ENUM is a simple routing and re-targeting in one step. 
> If complex re-routing and re-targeting is required it should 
> be done by the receiving AD. The outoing AD is not interested 
> in the internal routing of the receiving AD.
> 
> Maybe you can give me an example of a scenario were my model 
> does not fit.
> 
> regards
> klaus
> 
> 
> 
> > 
> > Mike
> > 
> > 
> > 
> >>From: Klaus Darilion [mailto:[email-masked]]
> >>Sent: Tuesday, December 06, 2005 11:48 AM
> >>To: Stastny Richard
> >>Cc: Michael Hammer (mhammer); [email-masked]; 
> >>[email-masked]; [email-masked]
> >>Stastny Richard wrote:
> >>>>Before going down this path too far, can we ask where the
> >>
> >>results of
> >>
> >>>>Hypothetically, the egress and ingress gateways could be
> >>
> >>identified in
> >>
> >>>>Route headers rather than in the Request-URI.  An 
> external ENUM dip 
> >>>>and an internal ENUM dip might lead to something along 
> the lines of:
> >>>
> >>> 
> >>>Correct,
> >>> 
> >>>Jonathan proposed this some time ago, but this thread somewhere 
> >>>stranded
> >>> 
> >>Hi folks.
> >>URI) into a Route header and into a request URI?
> >>
> >>If this URI is sip:[email-masked] or 
> >>[email-masked], or 
> sip:[email-masked] is the 
> >>ingress provider's choice. Maybe the ingress provider also 
> allows all 
> >>of the previous SIP URIs to reach a certain user. The incoming 
> >>provider just has to make sure that these SIP URIs map to the 
> >>corresponding user (to the user's AoR).
> >>If this user also has an E.164 number which is in I-ENUM, then it's 
> >>again the ingress provider's choice which URI to put into the NAPTR.
> >>
> >>IMO there should not not be any semantics how to create a 
> request URI 
> >>and a pre-loaded route set of the SIP URI received from ENUM. The 
> >>egress proxy sends the request to the ingress proxy in the format 
> >>choosen by the ingress provider (e.g. publish via ENUM or 
> an business 
> >>cards).
> >>
> >>We should not complicate things. I do not see any problems 
> with this 
> >>simple approach. If there are some problems, please correct me.
> >>
> >>regards
> >>klaus
> >>
> >>
> >>
> >>
> >>>>I am also suggesting that the ENUM result be an AoR, since
> >>
> >>one might
> >>
> >>ENUM and
> >>>>SIP I cross-post it.
> re-chartered 
> >>>>This translates to: Infrastructure ENUM does not
> >>
> >>necessarily contain
> >>
> >>with the
> >>>>information what the next hop is.
> >>>>
> >>>>A very common scenario is the following one: a walled
> >>
> >>garden network
> >>
> >>>>is using private ENUM to detect the border element for a
> >>
> >>given number,
> >>
> >>to the SIP
> >>>>server(s) in ENUM. Does this make sense?
> >>>>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 8 Dec 2005 12:07:47 -0500

Would it be possible to leverage through reference to and adoption of the work of that other group rather than repeat the time-consuming (painful) process of defining terms in this group?

Mike

> Sent: Thursday, December 08, 2005 10:57 AM
> To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo 
> Salmon'; 'Klaus Darilion'
> Mike,
> I agree. If you want to say "service provider", the term has 
> to be defined (as you have just contributed) to include cable 
> networks, IT departments, government organizations, community 
> networks, family/home networks, etc. 
> 
> Without a definition there is ample room for different 
> meanings, technically, legally and commercial. But should 
> such a definition be done in this WG?
> 
> The technical meaning is _Internet domain_ in all cases.
> 
> Thanks, Henry
> 
>  
> 
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Thursday, December 08, 2005 8:52 AM
> To: [email-masked]; James Polk (jmpolk); Thilo Salmon; 
> Klaus Darilion
> Henry,
> An IT department of an enterprise that operates VoIP servers 
> is a service provider, albeit a private versus a public one.  
> Thus, I don't see the limit you speak of.
> 
> Adding an additional adjective "public" and you get a PATS or 
> Carrier that has narrower connotations.
> 
> Mike
> 
> 
> > Sent: Wednesday, December 07, 2005 7:10 PM
> > To: Michael Hammer (mhammer); James Polk (jmpolk); 'Thilo Salmon'; 
> > 'Klaus Darilion'
> 'Stastny 
> > Richard'
> > The VoIP calls in our offices can go directly between the two 
> > enterprise networks without any VoIP service providers 
> being involved 
> > and this is as valid VoIP peering as any other. This is one of the 
> > reasons not to limit the VoIP peering models to only one, that with 
> > VoIP service providers in the middle.
> > 
> > Sorry, I was not sure if the attached has taken this 
> > enterprise-enterprise into consideration and obviously 
> there are other 
> > user scenarios as well.
> > 
> > Thanks, Henry
> > 
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Wednesday, December 07, 2005 2:23 PM
> > To: James Polk (jmpolk); [email-masked]; Thilo Salmon; Klaus 
> > Darilion
> > Cc: [email-masked]; [email-masked]; [email-masked]; Stastny 
> > Richard
> > James,
> > This is déjà vu from the FG-NGN discussion on the exact 
> same topic.  I 
> > have no issues with making distinctions of this type.  It 
> was just not 
> > clear to me which of these various types (or the ones that Henry 
> > mentions) was in scope or not, but that seemed secondary to 
> the point 
> > being made at the time that had to do with what the X 
> entity did with 
> > an ENUM response that affected the constraints on what could be 
> > contained in such responses.
> > 
> > Mike
> > 
> > 
> > > From: James Polk (jmpolk)
> > > Sent: Tuesday, December 06, 2005 8:11 PM
> > > To: Michael Hammer (mhammer); [email-masked]; Thilo 
> Salmon; Klaus 
> > > Darilion
> > > Cc: [email-masked]; [email-masked]; 
> [email-masked]; Stastny 
> > > Richard
> > > This seems to be creeping into more than one WG at about the same 
> > > time.
> > > 
> > > ISP used to be (roughly) the company you or you employer bought 
> > > service from to gain access to the Internet.  Now that is a
> > little too
> > > generic for a lot of people's tastes as there are different
> > SPs that
> > > an individual many have now that weren't available not so
> > long ago.  
> > > Hence the recent push to separate them somehow.
> > > 
> > > Application Providers, to me, include a Vonage for Voice
> > services, and
> > > a Yahoo for IM.
> > > 
> > > Service Providers or Internet Providers, to me, connect 
> one to the 
> > > Internet for L3 access
> > > 
> > > Access Providers, to me, are the organizations like the DSL
> > and Cable
> > > and WiFi connectivity providers.
> > > 
> > > Often times, to me, the Internet Providers and the Access 
> Providers 
> > > are either the same company - while perhaps different
> > divisions, but
> > > they can be totally different companies too.
> > > 
> > > The separation I'm seeing is between the organization that
> > gives you
> > > you Internet access and the organizations that provider you
> > with all
> > > the services required for a particular application - such
> > as Voice or
> > > Video.
> > > 
> > > Everything used to be best effort, and services were 
> either at your 
> > > device or at the provider's server.  Now there's an overlay
> > at layer 7
> > > (typically) and we're struggling with how to name and describe it.
> > > 
> > > 
> > > 
> > > At 06:23 PM 12/6/2005 -0500, Michael Hammer \(mhammer\) wrote:
> > > >I thought it was only the "carrier" word that invoked regulatory 
> > > >burdens (or PATS!).  I'd rather leave legal word games to
> > > lawyers and lobbyists.
> > > >
> > > >Mike
> > > >
> > > >
> > > > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; 'Stastny
> > > > > Richard'
> > > > > A provider is a business model and att/SBC may differ
> > from Google
> > > > > who uses a different business model (which is more 
> significant 
> > > > > measured in $$$?).
> > > > >
> > > > > Didn't we agree to use the term "Internet domain owner" 
> > (we could
> > > > > shorten to IDOM or such)?
> > > > >
> > > organizations,
> > > > > consortia or innovators who work to disrupt them :-)
> > > > >
> > > > > Thanks, Henry
> > > > >
> > > > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; Stastny
> > > > > Richard
> > egress to
> > > > > indicate some server that sits on the edge of a
> > > provider's network
> > > > > The usage below seems to mix egress with originating 
> being the 
> > > > > network where the caller is attached.
> > > > >
> > interconnect
> > > > > points were different hosts and therefore may have different 
> > > > > identities.  To keep maximum flexibility, the format of those 
> > > > > identities would need to be fully under the control of
> > > the domain of
> > > > > each provider.  However, conflating all that into a
> > single URI in
> > > > > the Request-URI seemed constraining to me.  Having
> > three URIs in
> > > > > separate headers seemed the most flexible.
> > > > >
> > > > > -- Tel:URI in, Point-of-interconnect URI out.  Put in
> > > Route header.  
> > > > > I only suggested that there might be two route headers
> > > because the
> > > > > terminating provider would indicate in ENUM, to get to this 
> > > > > end-user, go to this entrance first.
> > > > > But, to get to that entrance, the originating 
> provider needs to 
> > > > > determine what the corresponding exit point is from his
> > network,
> > > > > i.e. another Route header.  The format and content of
> > > that URI is up
> > > > > to each provider.  The advertised entrance point is I 
> think by 
> > > > > definition the (Inter-) Carrier ENUM.
> > > > > (Intra-) Carrier ENUM.  Maybe peering is concerned only
> > with the
> > > > > inter-carrier aspect.
> > > > >
> > > > > The Request-URI could be a normalized public identity
> > of the user
> > > > > totally independent of interconnect naming schemes.  
> I was just 
> > > > > teasing out what are the assumptions and constraints in
> > > the original
> > > > > email.
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > > ingress provider wishes to feed a different set of
> > SIP URIs to
> > > > > > each and every of his egress partners, he should not be
> > > stripped
> > > > > > of this option.
> > > >_____________________________________________________________
> > > __________
> > > >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/

---

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 9 Dec 2005 13:07:42 -0500

Henry:
 
I think that it is the time to write an informational RFC on this because it
is confusing to use the loose words like "service providers" in the context
of the public Internet in the IETF.
 
Let us focus on the RFC what it should be like "Internet Domain Owner" and
others in the context of IETF standardization works.
 
Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Henry Sinnreich
Sent: Tue 12/6/2005 5:29 PM
To: 'Michael Hammer (mhammer)'; 'Thilo Salmon'; 'Klaus Darilion'
Cc: [email-masked]; [email-masked]; 'Stastny Richard';
[email-masked]
Subject: RE: [voipeer] RE: [Enum] Re: [Sip] SIP AoR, tel and ENUM

>A provider is a provider.

A provider is a business model and att/SBC may differ from Google who uses a
different business model (which is more significant measured in $$$?).

Didn't we agree to use the term "Internet domain owner" (we could shorten to
IDOM or such)?

Internet domains are well defined in the IETF.
Business models for VoIP are better suited for other organizations,
consortia or innovators who work to disrupt them :-)

Thanks, Henry

---

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 9 Dec 2005 13:07:42 -0500

Henry:

 
Best regards,
Radhika

  _____  

Thanks, Henry

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip