<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font size="+1">Hi Ross,<br>
<br>
Unless you have an SS7 trunk to an ILEC you don't need to worry
much about the Point Code. For SIP traffic you just dip the call
and route on the LRN.<br>
<br>
The Point Code itself is a special format that is assigned to you
when you set up your SS7 capable switch. Unless you have one of
them you never need to worry about it.<br>
<br>
========<br>
<br>
ANSI Point Codes<br>
ANSI point codes are made up of three groups of digits called the
network indicator (NI), network cluster (NC), and network cluster
member (NCM). The values for ANSI point codes depends on the value
of the pctype parameter of the chg-sid command, either ansi or
other. If the pctype parameter is set to ansi, the ANSI rules for
the ANSI point code are used to define the point code. The range
of values for an ANSI point code with the pctype=ansi parameter
are:<br>
<br>
NI – 001-255<br>
NC – 001-255 (if ni = 001-005) or 000-255, * (if ni = 006-255)<br>
NCM – 000-255, *<br>
The pctype=other parameter specifies that the ANSI point codes do
not meet ANSI standards. The range of values for ANSI point codes
with the pctype=other parameter are:<br>
<br>
NI – 000-255<br>
NC – 000-255, *<br>
NCM – 000-255, *<br>
The asterisk (*) point code value indicates a single cluster
address for a cluster point code (for example, 20-2-*) or a
network routing destination (21-*-*). for more information on
cluster point codes, see the Cluster Routing and Management
Diversity (CRMD) section. For more information on network routing
point codes, see the Network Routing section.<br>
<br>
A double asterisk (**) and triple asterisk (***) can also be used
for the NC and NCM fields of the ANSI point code, but for only the
rtrv-dstn, rept-stat-dstn, rtrv-rte, and rept-stat-rte commands.<br>
<br>
A double asterisk in the NCM field of a point code (for example,
20-2-**) produces a summary report that shows all point code
destinations or routes residing in the given cluster (20-2). This
does not include the cluster point code, if the cluster point code
(for example, 20-2-*) is provisioned. The following examples
(rtrv-dstn and rtrv-rte) are reports generated using two asterisks
in the NCM field of a point code.<br>
=======<br>
<br>
~Glen<br>
</font><br>
<div class="moz-cite-prefix">On 9/3/2020 10:55 AM, Mary Lou Carey
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1f1c314fdd5908d3f446bcee26c5208d@backuptelecom.com">I'll
try to make this as short and sweet as possible even though it's
pretty complicated. Point Codes are the 10 digit addresses for a
particular switch and LRNs are the 10 digit addresses for a
particular connection point that switch is associated with. In the
PSTN world, all connections are dedicated and implemented by LATA
/ Tandem area for Local / IntraLATA traffic. When you get your
first NPA-NXX for a LATA / tandem area, you enter it in the LERG
(National Routing Database) and populate the tandems (Local,
IntraLATA and FGD) that you are connecting to. Then you assign a
10 digit phone number from your NXX block to be your LRN. You add
that to both the LERG and NPAC (National Porting Database).
<br>
<br>
Once you've published all your switch information in the LERG and
NPAC, then you establish your ISUP trunks with each ILEC you're
interconnecting with. You can set up additional trunks with other
carriers if you want a cheaper option for routing traffic, but the
minimum required is the ILEC. Each carrier's switch will have a
distinct point code associated with it so you'll order ISUP trunks
to each switch (point code route) you need to be connected to.
You'll also associate the distinct LRN for that LATA / carrier
tandem area with that trunk group. Usually there's multiple trunk
groups per LATA / tandem area so you'll program your routing
tables with the NPA-NXXs each trunk group serves. That way when a
customer originates a call, your switch can do the LNP dip to find
the LRN and send it over the route that the NPA-NXX of the LRN is
associated with. Routing tables can get complicated depending on
how many carriers you're connected to. Companies that operate in
more than one ILEC area or LATA usually purchase Least Cost
Routing software so they can send their originating traffic out
over the cheapest route.
<br>
<br>
IXC traffic is routed a little differently because it is routed by
CIC (4 digit code that identifies the IXC) rather than by NPA-NXX.
They connect to all the ILEC carriers just like the CLECs do, but
they populate their routing information in the SMS database
instead of the NPAC database. Once the call is dipped, the traffic
is delivered in pretty much the same way.....by dedicated trunk
group / tandem area.
<br>
<br>
<br>
<br>
MARY LOU CAREY
<br>
BackUP Telecom Consulting
<br>
Office: 615-791-9969
<br>
Cell: 615-796-1111
<br>
<br>
On 2020-09-02 04:46 PM, Ross Tajvar wrote:
<br>
<blockquote type="cite">Hi all,
<br>
<br>
I'm trying to understand how routing works in SS7-land. I am
familiar
<br>
with portability, and I know (at least in the US) the first step
in
<br>
routing a call is doing an LNP dip to get the LRN.
<br>
<br>
However, it looks like addresses in MTP3 are "point codes" (PCs)
which
<br>
are assigned to switches. Calls are set up with ISDN-UP, which
is
<br>
transported via MTP3. So in order for a call to be set up, the
<br>
destination switch's PC must be known. How is the destination PC
<br>
determined from the destination LRN?
<br>
<br>
Thanks,
<br>
Ross
<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>
</blockquote>
_______________________________________________
<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>
</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>