Subject: RE: [Enum] Carreir ENUM, SIP URIs and DNS

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 24 Jun 2005 16:17:16 -0400

Richard,

What a complicated Gordean Knot we weave!

I disagree with your central premise.  The issue is not the use or
purpose of a sip: URI; it is whether ENUM can act as a global routing
mechanism if it's fundamental property "universal access" (or openness)
is undermined by walled ENUM gardens.  (Funny, I don't hear anyone
talking much about "Carrier DNS".)

Any user (including those still on TDM) MUST be able to call any other
connected user.  Metcalf's Law and the value of the VoIP network is at
stake.  Because the PSTN is part of the equation, all users MUST have
E.164 numbers for the previous statement to work.  Notice that I did not
try to categorize users as being on the Internet or within some walled
garden of a service provider.  

The routing mechanism of VoIP is based (or soon will be) on sip:URI and
the ability (using DNS) to translate that into an IP address for routing
over ANY IP-based network.  But, the assumption is that any user MUST
have the ability to translate ANY assigned E.164 number into a sip:URI.
That would imply that the resource record for any E.164 number must be
reachable universally.  That does not mean that all information
associated with a user is available, just the basic mapping from E.164
to sip:URI to further route a call.  Additional pointers can send one to
a private server that can play guard to the exclusive club.  The sip: or
other URI can lead to a walled garden policeman server (personal,
enterprise, or carrier) that only lets "approved guests" through, but
that is secondary.

As the first part of your message indicates, if a VoIP user does not
want to be reached universally, then they don't really need an E.164
number, just a sip:URI, and can stop wasting a public numbering
resource.  Sooner or later the national regulators will realize that
ENUM is broken unless the fundamental E.164-to-URI translation exists
publicly for all E.164 numbers.  (Just wait until E911 calls/call-backs
fail.)

The legacy number portability (and in US LERG) database operators will
be only too happy to extend their TDM routing mechanisms into the IP
space to fill a broken-on-arrival ENUM system.  Note that numbers can be
ported using ENUM, you just don't need all the legacy NP mechanisms and
process to do that.

Mike

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Stastny Richard
> Sent: Friday, June 24, 2005 1:50 PM
> To: enum at ietf.org
> Subject: [Enum] Carreir ENUM, SIP URIs and DNS
> 
> Dear all,
>  
> The discussion regarding User vs Carrier ENUM and where to 
> place is circling around the central point of the problem, 
> which is the future usability and purpose of a sip: URI
>  
> SIP was originally modelled along the lines of the e-mail 
> archtecture and in every presentation frem Henry and Alan at 
> the VON SIP Tutorial you see the famous SIP trapeziod:
>  
> A user is sending an invite to a proxy, containing and 
> Address-of-Record, (AoR)in the form of a SIP URI 
> sip:user at domain.foo the proxy is querying the DNS the domain 
> for SRV-records (=MX) forwarding the invite to the proxy 
> serving the domain.foo.
> The proxy has either the "user" registered" already and know 
> where in the world the user is atteched to the Internet, or 
> the proxy knows what to do with the call, e.g. connects to a voce-box.
>  
> Done.
>  
> No need for E.164 numbers.
>  
> User ENUM now started with the basic idea that if a user has 
> such a SIP URI, and he has also an E.164 number, he may hint 
> that somebody trying to establish a call in the Internet and 
> knowing only the E.164 number that he has also a SIP URI to 
> be reached also there. 
>  
> User ENUM without SIP URIs is useless
>  
> Now lets look at Carriers. Originally the carriers had only 
> E.164 numbers and where only on the PSTN. Carrier ENUM could 
> have been useful there as IN-SCP replacement for NP, holding 
> tel: records with routing numbers Nice idea, but nobody was 
> interested.
>  
> Then the carrier moved on also to VoIP. After some 
> experiements, e.g with
> H.323 they finally settled on using SIP (the same arguments 
> are BTW also valid for H323). For using sip you basically 
> need a sip URI as AoR. The best example is the 3GPP IMS 
> model. 3GPP is using two types of SIP
> URIs: the private User Identity, basically derived by some 
> algorith from the IMSI and used with registration to find the 
> home network and the Public User Identity. The Public User 
> Identity is a SIP URI which should be known also by the User, 
> because it is basically the means to establish a call:
> e.g. sip:frank at vodafone.de, or even sip:richard at stastny.com.
>  
> Now the queston comes up, how public is public. Naive 
> netheads would assome you just put an SRV record in 
> vodafone.de to point to the whatever-CSCF Not so, this is bad 
> for a number of reasons I do not want elaborate further here, 
> but there may some 3GPP and TISPAN experts out there willing 
> to explain.
>  
> So if even this is bad, you are not giving anything about 
> which user belongs to you and how many away with this, only 
> eventually the IP address of you SBC.
> But since they do not want to be reached from the Internet 
> anyway,because they do not get termination charges, this is a 
> minor problem (how public is public?)
>  
> Now we come to the real problem: every sip:frank at vodafone.de 
> has also a E.164 number attached to him, for compatibility 
> with the PSTN and also users on 3G may want to continue to 
> use E.164 for various reasons also stated many times by Rich Shockey.
>  
> Since they want to interconnect via IP and not via the PSTN 
> (really), they need a mapping from E.164 numbers to the 
> Public User IDs (SIP URIs) to route the calls properly. You 
> do not need the mapping of you own E.164 number, this is done 
> at the SIP proxy, you need the mapping of all other numbers. 
> This is done best with all call query via a global NP 
> database, giving you the E.164 to provider mapping. If you 
> get as an additioanl bonus the routing information (the IP 
> address of the proxy, One possible solution for this problem 
> is a Carrier ENUM tree. Done..Fine
>  
> One would think.
> 
> The problem is: they do not want their compet... partners 1. 
> to know how many users they have 2. who these users are - the 
> partner may just make call and alienate him
>  
> So even putting the ENUM tree in an extranet only accessible 
> by partners does not help to solve this problem, because the 
> partners are not really partners.
> 
> And in addition there are still "partners" and others, so you 
> cannot peer with them; they have their own tree, this 
> creating the ENUM forest.
>  
> Even if all decide to use the same global tree, and 
> regardless if this tree is public (e164.arpa or 
> carrier.e164.arpa) or somewhere else e164.info, it does not 
> solve the basic problem, because this is a Catch 22.
>  
> Ideas to have a ENUM tree where my entries can only be seen 
> by some others I decide to do so, is the perverting the whole 
> idea, and proves the fact that these operators do care about 
> everything, but not about their costomers. 
>  
> Can you imagine an announcement on the PSTN like this: 
>  
> "the user you are
> calling is hosted with a provider we have no interconnect 
> agreement with, so we are sorry that we cannot complete your 
> call. Tell your friend to move over to a provider we have an 
> agreement with, but be aware, we may change our interconnect 
> agreements at any time without prior notice, so tell you 
> friend to move quickly, because in one month this may have 
> changed already."
>  
> So either the carriers get their whatever together and 
> introduce an ACQ in public space  (because of the Public User
> Identities) or they forget the whole issue.
>  
> Richard
>  
>  
>  
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Tom Taylor <[email-masked]>
Date: Fri, 24 Jun 2005 16:30:12 -0400

I'm not sure you and Richard are really in conflict.  Undoubtedly it 
will be possible to resolve all E.164 numbers into default routes using 
ENUM.  What the present discussion has been all about is what happens 
after that default routing is realized.

Michael Hammer (mhammer) wrote:
Richard,

...