[VoiceOps] More Question about routing

Wed Sep 9 12:19:00 EDT 2020

Brett at the STI-GA told me the same thing. To get your Federal or State 
Permission you either have to apply to the FCC to get your IPES 
Numbering Authorization or you have to apply to each state to be 
certified as a CLEC. I don't know why they had to muddy the waters by 
stating you needed authority to get numbering resources from the pooling 
administration when the requirement was really to have an FCC 
authorization or State Certification. As with most things in Telecom, 
certain players in the industry go to great lengths to make even the 
simplest tasks seem difficult just so new companies will be discouraged 
from entering the market. Those players will go unnamed, but it's not 
the iconectiv people!

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-1111

On 2020-09-09 10:50 AM, Dave Frigen wrote:
> OK, hot off the press from ATIS, the U.S. SHAKEN General Authority….
> 
> Nothing has changed in the STIR/SHAKEN application process. Each
> service provider (SP) will need to apply through the PA to be able to
> participate in the SHAKEN ecosystem. The FCC is recently concerned
> because several providers using wholesale number pools to operate
> today are now applying for numbers out of the national pool.
> 
> Actually acquiring numbers out of the national pool is not necessary.
> The only current numbering pool requirement is that you are a national
> or state registered SP that HAS ACCESS TO NATIONAL NUMBER POOLS (you
> don’t actually need to possess any of your own numbers…..continue
> to use wholesale resources to operate).
> 
> So in closing, you do not need your own phone numbers to operate. You
> just need federal or state permission to access the national number
> pool as one of the credentials and qualifiers to become a registered
> SP with the PA.
> 
> Dave
> 
> From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Zilk,
> David
> Sent: Tuesday, September 8, 2020 4:20 PM
> To: voiceops at voiceops.org
> Subject: [VoiceOps] More Question about routing
> 
> Having come into telephony from the data networking end, rather than
> from a PSTN telephony background, where would one find a good  basic
> to detailed tutorial of how routing of VoIP calls into the PSTN and
> vice versa works?
> 
> I have so far only been involved with routing from our SIP platform to
> and from wholesale service providers, and have not yet had to manage
> our own numbers and peering. With STIR/SHAKEN we may need to get into
> that, and I need to get up to speed.
> 
> Thanks,
> 
> David
> 
> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of
> Richard Jobson
> Sent: Tuesday, September 8, 2020 12:44 PM
> To: Glen Gerhard <glen at cognexus.net>; voiceops at voiceops.org
> Subject: Re: [VoiceOps] Question about SS7 routing
> 
> Hi Ross
> 
> So in your original email you were wondering about the role of MTP,
> the layer 3 protocol. This keeps tabs on the point codes. If you are
> troubleshooting down to the SS7 messages (MSU’s), SLTM’s &
> SLTA’s tell you what point codes those links are reaching.
> 
> The Global Title Translation uses the SCCP/SS7 protocol when
> connecting to IXC.
> 
> Local Number Portability uses AIN/TCAP to dip the database to
> determine the LRN. But many SS7 operations just troubleshoot this by
> looking at the ISUP protocol where the original calling Party number
> (CGN) appears in the Generic Address Part GAP and the LRN in the
> called party number (CDN) field.
> 
> Cheers
> 
> Richard
> 
> From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Glen
> Gerhard <glen at cognexus.net>
> Date: Tuesday, September 8, 2020 at 11:47 AM
> To: <voiceops at voiceops.org>
> Subject: Re: [VoiceOps] Question about SS7 routing
> 
> Hi Ross,
> 
> 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.
> 
> 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.
> 
> ========
> 
> ANSI Point Codes
> 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:
> 
> NI – 001-255
> NC – 001-255 (if ni = 001-005) or 000-255, * (if ni = 006-255)
> NCM – 000-255, *
> 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:
> 
> NI – 000-255
> NC – 000-255, *
> NCM – 000-255, *
> 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.
> 
> 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.
> 
> 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.
> =======
> 
> ~Glen
> 
> On 9/3/2020 10:55 AM, Mary Lou Carey wrote:
> 
>> 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).
>> 
>> 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.
>> 
>> 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.
>> 
>> MARY LOU CAREY
>> BackUP Telecom Consulting
>> Office: 615-791-9969
>> Cell: 615-796-1111
>> 
>> On 2020-09-02 04:46 PM, Ross Tajvar wrote:
>> 
>>> Hi all,
>>> 
>>> I'm trying to understand how routing works in SS7-land. I am
>>> familiar
>>> with portability, and I know (at least in the US) the first step
>>> in
>>> routing a call is doing an LNP dip to get the LRN.
>>> 
>>> However, it looks like addresses in MTP3 are "point codes" (PCs)
>>> which
>>> are assigned to switches. Calls are set up with ISDN-UP, which is
>>> transported via MTP3. So in order for a call to be set up, the
>>> destination switch's PC must be known. How is the destination PC
>>> determined from the destination LRN?
>>> 
>>> Thanks,
>>> Ross
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops [1]
>> 
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops [1]
> 
> --
> 
> Glen Gerhard
> 
> glen at cognexus.net
> 
> 858.324.4536
> 
> Cognexus, LLC
> 
> 7891 Avenida Kirjah
> 
> San Diego, CA 92037
> 
> _______________________________________________ VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> 
> -------------------------
> 
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and
> confidential. If the reader of the message is not the intended
> recipient or an authorized representative of the intended recipient,
> you are hereby notified that any dissemination of this communication
> is strictly prohibited. If you have received this communication in
> error, notify the sender immediately by return email and delete the
> message and any attachments from your system.
> 
> Links:
> ------
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_voiceops&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=lSYJuWWkYAlbnO78O2t9H5EFCSIB6SJj1gm-aOb9Fdo&s=3SjT12Q2cxk_W6Sobks1FC_1xSqAsJ07kA4ehuB4fRY&e=
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops