<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font size="+1">I concur on the ENUM solution being obsolete. Sure
it was better than TCAP, but not as flexible as a 302. Its appeal
originally was a centralized phone number ownership lookup but it
was never deployed that way; DNS is too slow at updating
information and too open to DDOS attacks.<br>
<br>
So without centralized and up to date information no one cares how
you route anymore. You're expected to do it yourself and they
don't (shouldn't) trust anything you pass them. A SIP trunk is all
you need and all of them are treated pretty much the
same(untrusted, measured, usage based on performance and cost).<br>
<br>
But if you want accurate billing/routing you need to check the LNP
yourself either via a nightly download from NPAC or as a SIP based
service from Neustar or others. The costs are not much for either
depending on your traffic volume and type.<br>
<br>
~Glen<br>
</font><br>
<div class="moz-cite-prefix">On 1/5/2021 9:17 AM, Alex Balashov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:22f6df7c-22d7-fb2c-e3f5-6bd6aee749f6@evaristesys.com">From
my perspective as an implementor down in the weeds, ENUM is just a
failure-prone moving part and a source of unnecessary complexity
at this point. DNS is not a particularly good transport vehicle
for data queries. As far as I can tell, the industry went in that
direction at the time it did because it was the more performant
option at the time, which is a commentary on the sad state of SIP
stacks early on.
<br>
<br>
Most folks realised a long time ago that SIP redirects are a lot
more flexible for data queries, and doesn't require a parallel
infrastructure of unrelated DNS componentry whose operational
support demands nonoverlapping technical competencies. ENUM as a
routing query mechanism has fallen into considerable neglect in
some of the major softswitch & SBC platforms, as far as I can
tell. I distinctly remember severe performance issues with ENUM a
few years ago on one of the most well-known SBC platforms (ahem);
when the vendor was contacted about it, the response was kind of,
"Why would someone still use that?"
<br>
<br>
But, of course, that doesn't mean the peering provider landscape
has caught up.
<br>
<br>
-- Alex
<br>
<br>
On 1/5/21 8:57 AM, Ross Tajvar wrote:
<br>
<br>
<blockquote type="cite">Based on this presentation [0] from
Comcast, they are interconnecting with their biggest voice peers
via SIP rather than SS7. They appear to use ENUM for route
selection. I'm sure others are doing this too, though I can't
find anything public.
<br>
<br>
I'm interested if anyone has more info on how this works. I'm
guessing participants maintain their own private ENUM servers
and just trust each other? As far as I know the only way to
validate number ownership is via an LNP dip, which would be
expensive to do for every call.
<br>
<br>
I would like to be able to consume a service like that, at least
in an outbound direction; as a small operator, I'm sure
convincing large carriers to trust my ENUM server would be very
difficult. But having a greater degree of interconnectedness
(and mostly importantly avoiding TDM) seems like a good thing.
<br>
<br>
Does anyone have experience with this sort of thing?
<br>
<br>
Thanks,
<br>
Ross
<br>
<br>
[0]
<a class="moz-txt-link-freetext" href="https://silo.tips/download/voice-peering-interworking-sip-and-bgp">https://silo.tips/download/voice-peering-interworking-sip-and-bgp</a>
<a class="moz-txt-link-rfc2396E" href="https://silo.tips/download/voice-peering-interworking-sip-and-bgp"><https://silo.tips/download/voice-peering-interworking-sip-and-bgp></a>
<br>
<br>
_______________________________________________
<br>
VoiceOps mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Glen Gerhard
<a class="moz-txt-link-abbreviated" href="mailto:glen@cognexus.net">glen@cognexus.net</a>
858.324.4536
Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037</pre>
</body>
</html>