|
|
 |
Re: AW: [enum-wg] COCOM & ENUM ...
- Date: Wed, 15 Dec 2004 00:55:35 +0000
Hi Richard, Jim, folks,
OK - now I'm unhappy.
I think Jim raises the point that the distinction between a carrier and
an end
user is going to get blurred. True and an interesting nugget, but...
(i) The developer doesn't have to do anything they aren't doing
already.
If anyone makes an ENUM client with a hard coded #define for
e164.arpa
then they are dumb - everyone needs to debug the stuff as it
isn't all in
place yet (at least in other parts of the world :). Hence pretty
much
every client has some way of selecting the apex, and often the
DNS server
that it will query. Thus this argument is puff (and I suspect
that everyone
here knows it is :(
(ii) Every carrier (and maybe even end users if we don't get our act
together)
is going to have to select the servers they query and the net
address from
which they will accept a request and return data - true whether
its a split
or they just accept queries only from "anointed" network
addresses.
There *is* going to be carrier configuration of the servers *AND*
clients
in the same way that there is now (if only to set the resolver to
set/send
EDNS0 queries). Thus the idea that one size fits all is just not
going to
play with any Ops guys in any carrier (at least I hope not any
who provide
ME with service).
In short, a developer that doesn't allow change to the apex is even
less proficient
than I am at programming, and that's saying something. Similarly, each
carrier is
going to do configuration in any real situation; NGNs don't work out of
the box
[of course, this is not an official position of any vendor, but... ]
Richard has managed to confuse me over the term "non-terminal NAPTR".
(iii) This use of the term "non-terminal NAPTRs" is starting to grate.
I suspect
that the mail below doesn't talk about non-terminal NAPTRs
(according to RFC3403)
but instead implies a link to some kind of Service Resolution
Service is triggered,
or else I need the AA side of this explained in a lot more detail.
If this *is* the [names deleted to protect the alleged
perpetrators] idea of using
non-terminals at T1/T0 then I stand corrected, but I may well be
sick.
Please don't use the term Non-Terminal NAPTR (i.e. one with an
empty flags field)
if you don't mean such a construct. 'u' with E2U+sip or sip+E2U
is a kosher terminal
NAPTR. If the result of sending an INVITE to the server mentioned
in the URI isn't the
end of the story, that's a purely non-ENUM problem - blame the
cult, but not the ENUM
design - 340x and 3761 are at least crystal clear on this topic.
Forgive the rant, but I believe that there's nothing in the experiences
draft that won't be
applicable for *any* flavour of ENUM, and do not want to change it to
say that non-terminal
NAPTRs are nice friendly creatures that we should all grow to know and
love after all.
If you feel that this is necessary, I'll let you explain it in detail
(just give me due
warning so I can duck :)
all the best,
Lawrence
On 14 Dec 2004, at 21:59, Richard Shockey wrote:
At 03:48 PM 12/14/2004, Jim Reid wrote:
>>>>> "Richard" == Richard Shockey richard@localhost writes:
Richard> HUH are you kidding ... its is because of the basic and
Richard> orthogonal conflict between what carriers need and want
Richard> and what end users need and want.
I'm not convinced that really is (or will be) the case. Alice is an
end user with SIP applications that lookup E.164 numbers in public
e164.arpa tree to find SIP gateways. Fast-forward a few years. Bob's a
telco doing VoIP and SIP and using DNS lookups of E.164 numbers to
route calls in his net and to other operators. What's the difference?
a great deal .. network operators do not generally or historically
expose internal network architectures or border ingress elements into
something as public as the DNS.
the general requirement I have been constantly told is that the result
of the carrier TN2URI translation must not be publicly exposed or
amenable to MiM attack and is generally hidden behind some AA which
is why all the discussion on non terminal NAPTR records.
The applications are both using the DNS to figure out how to find the
right SIP server for some VoIP session (or whatever). Carol sells SIP
server and client software. Will she want to develop, sell and support
different versions of the same thing to Alice and Bob?
Of course not that is why the carrier record would be non terminal and
require out AA in fact most of the architectures I see nearly have
only 1 URI for the entire network. A huge wall of SBC's surrounding
the VoIP network.
Meantime, what
if Bob wants to dump calls from his network to Alice on Alice's
internet SIP server so that he doesn't have to pay termination charges
to Alice's telco?
Richard> Either bifurcate the tree at Tier one into two non
Richard> terminal NAPTR records (public & carrier)..which BTW will
Richard> break SIP applications since there is no standards any
Richard> where on how to deal with this.
Maybe there should be a standard on this? :-) Though the bifurcation
could also be realised with split DNS.
I do not agree on either point. SIP CUA's would all have to be
redesigned to accept the new DNS structure ..I dont think that is
acceptable.
Richard> Two merge T1 and T2 into the national registry which
Richard> makes the registry operator the central repository for
Richard> ALL SIP routing data for both the carriers and end
Richard> users...which at least preserves the existing model of
Richard> the DNS responds with an "answer" ..the carriers can
Richard> still use non terminal records but normal SIP CUA's would
Richard> simply ignore them.
This is too awful for words. I think there's general consensus that
end users should not see core telco routing data.
not if the URI is non terminal it only increases the requirements on
the registry. The Tier 1 Tier 2 constructs were artificial in the
first place to more balance the loads on the DNS and give end user
more flexible options on controlling their NAPTR records.
Richard> Three have two entirely separate trees ..e164.arpa for
Richard> number holders e164.int for carriers. The .int tree
Richard> could be designed to look into apra for answers it is not
Richard> authoritative for. Problem solved.
This gets very ugly very quickly IMO. Operationally such setups would
be very brittle and near-impossible to debug.
what are you talking about ..it would work perfectly well. End user
CUA's do not need to see carrier data so they would never look into
carrier.foo
but John is entirely right here the chances of carrier.foo getting off
the ground are problematic though .MOBI did get through ICANN for some
reason.
Richard> oh no we're not going down that rat hole of split DNS
It's no more of a rat hole than having yet another domain name with
funky forwarding/fallback on failure modes between the 2 (or more?)
domain names that you seem to favour. I suspect these could be much,
much worse to administer and operate than a split DNS solution. It
would be good to get hard data on the pros and cons of both
approaches. And any others for that matter. Even better would be to
get that data before a lasting decision is made. :-)
Richard> you forget the basic consumer or PBX edge ENUM resolver
Richard> has no need to see the carrier data.
I've not forgotten that at all. I think you have misunderstood
me. Well, I have an accent.... :-)
Suppose some company is writing ENUM-aware telephony software that
needs to figure out which SIP server to use when terminating a call
for some E.164 number. [Note the deliberate hand-waving about where
that software lives or which net the device is on.] How many DNS
lookups and domain names is it going to need to do that?
only one ..if the software is edge based in the case of IP-PBX's or
end user devices, two if the proxy is licensed carrier based ( aka
they issue phone numbers )
the definition of a carrier here is do you or do you not issue phone
numbers..if you do not you will not have access to the carrier data
and BTW that will not guarantee that the network provider will even
give you access to the network .. the two carriers will have presumed
to have a bi-lateral agreement in place covering inter network
transactions.
From a
developer's perspective, how will the software know which net it's in
so it knows which domain names to try (and in what order)?
>> A centralised database could well mean telcos expose their
>> customer and call routing data to each other. Which is unlikely
>> to get much acceptance.
Richard> Well then you have argued that LNP databases dont work
Richard> and I have it on good authority that they do :-)
You would say that, wouldn't you? :-)
Does a number portability database disclose to TelcoA how TelcoB
routes calls around its networK?
no only the destination endpoint or LRN in the case of the US and
Canada. The carrier TN2URI scheme would not expose internal network
archichecture either under the current designs I've seen ..only the
location of the network Session Border Element or Controller. The
terminating carrier network would still need to look up into its own
routing tables ..and this is where I see SIP redirect all over the
place..to find the actual end point routing data.
There is no doubt in my mind BTW that SIP redirect servers are being
used to replicate the functionality of Service Control Points (SCP's)
in the IN and that SIP is becoming the new NGN equivalent of TCAP.
But even exposing the LRN does permit the originating carrier to
deduce a great deal about the called party network provider...in the
first case you know the number has been ported and from the LRN tables
you can find out who that carrier is. In the US and Canada LIDB will
give you everything else you want to know about the customer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org sip:57141@localhost
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1
815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
|
|
|
|
