Category Archives: Australian Telco

Under the Hood with NBN FTTC Hardware (DPUs)

09/11/2019Australian TelcoDPU, FTTC, NBN, NBNCoNick

NBNco’s FTTC technology is accounting for a larger and larger share of the access network mix as the rollout nears completion, but let’s take a look at the hardware doing the heavy lifting.

I won’t go into the fiber network build NBNco are using (Squids, etc) in this post, we’ll just focus on the DSLAM that lives in the pit outside your house, or in NBN parlance – DPU or Distribution Point Unit.

In short, this is a 4 port DSLAM, fed by a fiber service and reverse powered.

The unit itself is waterproof, allowing it to live in the pit outside a customer premises, for FTTC deployments it’s common for every second P3 pit to contain a DPU (each pit typically feeds two premises).

There’s 4 copper tails for connecting in each of the 4 copper pairs to feed 4 premises. The copper run is typically less than 100m and is pretty easy to work out – Pace the distance from your first telephone outlet (TO) to your nearest pit, and there’s a 50% chance that’s the length of your cable run. Because of the short run of cable it’s a lot less to go wrong in the CAN, the only joint on the pair being the one on the DPU itself and anything inside the demarcac.

The DPU is powered by the customer’s modem via a reverse power feed, this means NBNco don’t have to worry about powering the unit, something on FTTN cabinets has been a maintenance headache due to battery backup maintenance.

The lead in cable to the customer premises is joined to the DPU via a “Snot Box”.

Unfortunately due to the enclosures being water tight and sealed, they don’t have the best thermal management. It’s not uncommon for them to reach 50+ degrees C in the field, which leads to a high failure rate, especially during summer.

NetComm Wireless / Casa NDD-4100

In 2016 NetComm Wireless (Now owned by Casa Systems) signed an agreement with NBNco to provide Fiber to the Distribution Point (FTTdp) Distribution Point Unit (DPU) equipment to NBNco for the launch in 2018, using their NetComm NDD-4100 units.

The unit has 4 ports for customer connections over a VDSL G.9923 interface, with reverse power feed, meaning the unit is fed by the CPE.

For backhaul the unit has GPON G.984 interface.

The device may not be powered at all times so a management proxy caches commands that are fed to the system when it comes back online.

Promo video

Nokia lightspan sx-f

In June 2018 NBNco started trialing Nokia DPUs, and many later installations since then are using the Nokia DPU.

I’ve head a bunch of complains about the NetComm having issues and dying, and for a sealed unit there’s very little debugging that can be done to it.

In the Melbourne office of NBNco there’s a Nokia DPU that’s been running in a fish tank for a number of years.

Call routing in LNP

02/11/2019Australian TelcoACMA, LNP, Local Number Portability, Local Number PortingNick

Before we get started there’s a few key concepts we’ve got to be familiar with:

PLNR
Donor Carrier
Losing CSP
Gaining CSP
Donor Transit Routing
Third Party Ports

If you’re not familiar with some of these concepts go back to the LNP FAQ and Anatomy of Local Number Portability in Australia posts which explain them.

Before Porting

In the beginning ACA created the heavens and the earth? Wait, no, the Numbering Plan for Australia.

The numbering system lists all the phone numbers in Australia and the carrier they’re assigned to (Donor Carrier when ported).

This means each carrier downloads this data from what is now ACMA (but was at the time ACA) and for each outgoing call look the number up in that data set and route to the correct carrier.

This routing is used when a number has not been ported – The CSP it’s allocated to by ACMA is the CSP to route calls to.

During Porting – Donor & Losing CSP the Same

At the time the number is ported the Losing CSP provides Donor Transit Routing – In practice this is nothing more than a fancy redirection/ forward to the new carrier.

Once the port is completed (and the Emergency Porting Return period has expired) the Losing CSP (who in this case is also the donor CSP) updates their PLNR file, to include the number that’s just been ported out and the new carrier’s code.

During Porting – Donor & Losing CSP Different (3rd Party Porting)

At the time the number is ported the Losing CSP provides Donor Transit Routing – In practice this is nothing more than a fancy redirection/ forward to the new carrier.

Once the port is completed (and the Emergency Porting Return period has expired) the Donor CSP updates their PLNR file, to update the record for the ported number, which previously showed the code of the Losing CSP and now must show the new CSP code.

After Porting – PLNR Update

After the PLNR has been updated by the Donor CPSs, other CPS that participate in porting must update their routing records to ensure they route directly to the Gaining CSP and not to the Donor CSP and rely on Donor Routing.

Donor Routing is only required to be in place for a short time, meaning carriers that don’t update their routes will find the ported destination unreachable once donor transit routing has been stopped.

LNP / Porting FAQ

02/11/2019Australian Telco, RFCs & StandardsACMA, LNP, Local Number Portability, Local Number PortingNick

This is a follow up to my other post on LNP (Anatomy of Local Number Porting in Australia) with some of the frequently asked questions.

For more info on the routing I’ve also written about Call Routing in LNP.

I’ve cited the relevant section of the code below and you can find the code itself here – Communications Alliance – Local Number Portability.

Why am I still billed after a number is ported out?

The Losing CSP does not need to take any action to disconnect Customer’s Telephone Number(s).
3.4.3

This means just porting out a number from a CSP doesn’t mean billing from the Loosing CSP will stop.

Continuing contractual agreements between the customer and Loosing CSP may still be in place and the customer is responsible for requesting the services be cancelled with the Loosing CSP.

Some CSPs work out that if you’re porting out a number you don’t want their services anymore, but they’re not obliged to and most will do what they can get away with.

What is a Bilateral Peering Agreement?

While a customer is legally entitled to move a number they have full control over (As outlined in Telecommunications Numbering Plan 2015), in practice phone numbers can only be moved from one carrier to another if both CSPs have a Bilateral Peering Agreement with each other.

These agreements primarily sort out the commercials of how much they’ll pay each other per port in / out.

It’s worth also noting that the Code only defines the minimum standard and process, two CSPs that have a bilateral peering agreement in place are able to process ports faster and more efficiently than the minimum standard outlined in the code.

Carriage Service Provider vs Carrier?

I’ve been sing the term Carriage Service Provider and Carrier interchangeably.

The difference as far as the code is concerned is one is who a customer pays for the service, while the other is the provider of the service. Generally it’s safe to assume that the CSP is also the Carrier and not a re-seller.

Donor Carriers

Under the Numbering Plan managed by ACMA numbers are allocated to certain CSPs.

These numbers can be ported to other CSPs (this is after all what LNP is all about) but after the number is routed to a different carrier the Donor Carrier remains the carrier listed in the Numbering Plan.

The Donor Carrier is responsible for Donor Transit Routing (A temporary redirect to numbers that have been ported away recently) for any numbers that have recently been ported out, and publishing the number and new carrier details for each number ported out in their PLNR file.

Donor Transit Routing

Under the Numbering Plan managed by ACMA numbers are allocated to certain CSPs.

In a scenario where a call needs to route to a destination where the current carrier for that destination is unknown, the call is routed to the Donor Carrier, as that’s who the number is originally allocated to by ACMA.

Upon reciept of a call by the donor carrier to a number that has been ported out, the donor’s switch finds the correct Access Service Deliver (ASD) and redirects the call to them.

This is a temporary service – CSPs are only obliged to do this for 5 days, after which it’s assumed the PLNR file of the donor will have been read by all the other CSPs and they’ll be routing the traffic to the correct CSP and not the Donor CSP.

Third Party Ports

Third Party Porting is where the Donor Carrier is neither the Losing Carrier or the Gaining Carrier. Third Party Porting requires bilateral agreements to be in place between each of the parties involved.

As we just covered ACMA allocates numbers to CSPs, when a number is ported to a different CSP the number is still allocated to the original CSP as far as ACMA and The Numbering System are concerned.

The CSP the number was originally allocated to is the Donor CSP – forever.

Let’s look at a two party port first:

A number is allocated by ACMA to CSP 1
The customer using that number decides to port the to CSP 2 using the standard LNP process
CSP 1 performs Donor Transit Routing for the required 5 days and updates it’s PLNR file to denote that the number has been ported to CSP 2

Now let’s consider a three party port, carrying on from the steps above.

The Customer decides they want to move from CSP 2 to another CSP – CSP 3
At the time of the port the donor CSP (CSP 1) must:
CSP 1 must update it’s PLNR records for this number to denote it’s no longer with CSP 2 but is now with CSP 3
CSP 1 must provide Donor Transit Routing for the required 5 business days – redirecting calls to CSP 3

So even though the number is moving from CSP 2 to CSP 3 as the number was originally allocated to CSP 1, it is, and will always be the Donor Carrier and as such has to provide Donor Transit Routing and update it’s PLNR each time the number is ported.

Port Reversal / Emergency Return

Ports have an emergency return window inside which the port can be reverted. For Cat C ports this invovles the project manager of one CSP contacting the project manager for the other CSP and requesting the return.

In the event the end customer has requested the Port Reversal / Emergency return they’re typically liable for a very hefty fee to do so.

Give Back & Quarantine of Numbers

After a number is no longer required, it’s given back to the donor carrier who places it in quarantine and typically does not reallocate the number for 6 months.

In some cases such as a wronly cancelled number the customer may be able to get a number that’s been cancelled back while it’s in it’s quarantine state, however this is not required and up to the donor carrier.

Including Customer Account Numbers when Porting

Prior to 2016, a customer moving from one CSP to another CSP were required to include their account number (“Service Account Number”) they had with the Loosing CSP to the Gaining CSP when submitting the Port which was verified against the Loosing Carrier’s records to ensure the correct Customer / Service combo.

This led to a lot of ports being rejected unnecessarily due to mismatched account numbers, as such the the requirement to include a valid matching account number with the loosing CSP has been removed.

Service Account is to remain as a mandatory field, and a standard validation but any mismatches are not to be rejected.

Where’s Cat B & Cat D?

Cat B Dropped in 2013 revision due to lack of use.

Cat D is almost the same as a Cat A port but allows services with an active ULL diversion to be ported. These are quite rare and a very specific use case.

Why is my Cat C Port taking so long?

You may find after submitting a port the date you’ve got back for porting is months away. The Loosing Carrier sets the porting date, and as they’re loosing the customer, they’re often not so keen to action the port quickly when they’re loosing the customer after all.

Lead Times are determined by the Losing Carrier. These may vary by product including variations due to the size of the product or the number of sites to which a particular service is offered.
3.5.10

Tidbit: One of Australia’s largest carriers has a 20,000 number per day limit on porting, meaning they’re only able to process up to 20,000 ports per day in or out. Once that limit is reached no more ports can be accepted for that day, so the ports are delayed until the next day, etc, etc, leading to considerable lead times.

The code requires CSPs to keep Service Metrics on porting time-frames, but there’s no penalty for being slow. (Section 3.6)

Third Party ports also take a lot longer due to the requirement to find a time window that suits all 3 carriers.

Can I arrange my numbers to be Ported after-hours?

CSPs are not required to port numbers outside of the “Standard Hours” defined in the code. (Section 3.8.1 )

However, most CSPs have included support for this inside their bilateral agreements with other carriers. This typically costs more for the customer, but also comes with the added risk of if the port fails there are fewer technical / engineering resources available at the Loosing and Gaining Carrier’s respective ends to sort it out if something goes wrong.

What’s a PNO?

Porting Notification Order – A message containing either a Simple Notification Advise (SNO) for Simple (Cat A) ports, or a Complex Notification Advise (CNA) for Complex (Cat C) ports.

Each PNO contains a unique sequential reference number to differentiate / associate the PNO with a particular porting request.

PLNR – Ported Local Number Registry

PLNR is nothing more than a giant text file, containing a list of numbers originally allocated to that CSP but that have been ported to another CSP, and with each number that’s been ported out the carrier code of the CSP it’s now with.

Information to facilitate Call Routing is provided by the Donor Carrier who is required to notify Carriers, via a Ported Local Number Register, that a Port is pending, completed or did not proceed. This relates to all Ports, including Third Party Ports. All participants must use the Ported Local Number Registers to determine the correct Call Routing.

Typically transferred via Web interface:

… a web site that contains a file with a list of Telephone Numbers that have been Ported away from the Donor, or have just returned.

PLNR data is encoded as a fixed-format text file.

What is Re-targeting?

Re-Targeting is a fancy term of changing the date & time.

It’s typically more efficient to re-target a port than withdraw it and resubmit it.

For only two re-targets are allowed for each unique SNA. (Section 4.2.9)

Anatomy of Local Number Portability in Australia

27/10/2019Australian Telco, RFCs & Standards, VoIPACIF C540, CNA, LNP, Local Number Portability, Local Number Porting, PLNR, PNV, Porting, SNANick

The Australian telecommunications industry was deregulated in 1997, meaning customers could have telecommunications services through a Carriage Service Provider (CSP) of their choice.

In order to increase competition and make it easier to move to a different CSP, the ACMA (Or as they were then the ACA) declared that Local Numbers (Geo numbers / land lines) were a “Portable Service”. This meant that if a customer didn’t like their current Carriage Service Provider (CSP) they could give them the flick (making them the Loosing Carrier), move to a new CSP (Gaining Carrier) but keep their existing phone numbers by moving them to the new carrier in a process known as Local Number Portability (LNP).

The Local Number Portability (LNP) standard was first defined by Comms Alliance in 1999 in ACIF C540 and defines the process of moving numbers between Carriage Service Providers (CSPs), however 22 years later the process can still be a baffling system for many customers, end users and carrier staff to navigate.

Acronyms galore exist and often the porting teams involved themselves aren’t 100% sure what goes on in the porting process.

In 1997 ISDN was first still an emerging technology and porting was typically a customer moving from one PSTN / POTS line provided by one CSP to another PSTN / POTS line provided by a different CSP – a simple port.

Two processes were defined, one for managing simple ports involving moving one simple number from one CSP to another CSP – Called Simple Porting or “Cat A” – which made up the majority of porting requests at the time, and another process for everything else managed by a project manager from the Loosing and Gaining CSP called Complex Porting or “Cat C“.

Since 1997, the advent of the NBN, VoIP, SIP and the announcement that one of Australia’s largest carriers is shutting down their ISDN network by 2020, means that today the majority of ports a business customer will face will be Cat C – Complex Ports.

LNP is an issue worldwide, and ENUM was released to try and make this a bit better, however it had one short trial in Australia a long time ago and hasn’t been looked at since.

Cat A / Simple Number Porting

Simple porting, classified as “Cat A” is used for porting single simple services (numbers).

The Cat A process can only be used for moving a “simple” standalone number – with no additional features – from one carrier to another.

The typical use case for Cat A port is moving a one copper PSTN / POTS line (Active line with no Fax Duet, Line Hunt, etc) from one carrier to another – as I said before, Cat A ports made up the majority of porting requests when the system was first introduced as the vast majority of services were copper POTS lines.

The process is automated at both ends, essentially the carriers send each other the numbers to be moved (more on that later) and their switches automatically process this and begin routing the number.

These ports are typically completed within a few days to a week and the customer gets a notification when the port is completed.

Cat C / Complex Number Porting

For all number porting that don’t meet the very specific requirements of Cat A aren’t met – and sometimes even if they are met, ports are processed as Cat C ports.

Cat C ports require a project manager at both the Gaining Carrier and the Loosing Carrier to agree on the details for the port and the move the numbers, each using their own internal process.

Lead times on Cat C ports are long – and getting longer, so from submitting a port to it’s completion can take 90+ days, and there is no confirmation required to the customer to let them know the services have been ported successfully.

Administrative Process of Ports (CatA & CatC)

Strap yourself in for a whirlwind of acronyms…

The Code does not constrain two or more individual industry participants agreeing to different arrangements
Section 1.3.6

Because of this it means this is the minimum standard, some CSPs have improved upon this between each other, however there’s a bit of a catch 22 in that CSPs have no incentive to make porting numbers out easier, as they’re typically loosing that customer, so the process is typically not improved upon in any meaningful way that makes the customer experience easier.

Without further ado, here’s what Cat A & Cat C ports look like under the hood…

Note: These all assume the Losing CSP is also the Donor CSP. More on that in the LNP FAQ and Call Routing posts.

Cat A – Simple Porting – Process

Summary

Cat A ports are automated – The process involves CSPs transferring formatted data between each other and the process that goes on for these ports.

The Loosing CSP must use the Cat A process if the service meets the requirements to be ported under a Cat A and the Gaining Carrier has submitted it as a Cat A port. This means a Cat A port can’t be rejected by the loosing carrier as not a valid Cat A port to be resubmitted as a Cat C port, if it does actually meet the requirements for Cat A porting. That said numbers that are valid in terms of Cat A can be submitted as a Cat C, this is often cheaper than submitting multiple Cat A porting requests when you have more than 5 or so services to be ported.

Here’s a brief summary of the process:

Customer requests port and details are validated
Simple Notification Advice (SNA) is sent to the Loosing CSP via a Porting Notification Order (PNO) – Essentially a form send to the loosing CSP of the intention to port the service
Loosing CSP sends back SNA Confirmation Advice to confirm the service can be ported
Electronic Cutover Advice (ECA) sent by gaining CSP to indicate gaining CSP wanting to initiate port
Loosing CSP provides Donor Routing by essentially redirecting calls to the Gaining CSP
ECA Confirmation Advice sent by loosing CSP to denote the service has been removed from the loosing CSP’s network & number is with gaining CSP as far as they are concerned
Losing CSP updates a big text file (PLNR) with a list of numbers allocated to it, to show the numbers have been ported to a different carrier and indicates which carrier

We’ll talk about the technical process of how the data is transferred, what PLNR is and how routing is managed, later on.

In depth process:

Step 1 – Customer Authority

The Gaining CSP must obtain Customer’s Authority (CA) to port number (Section 4.1.2) – Typically this takes the form of a number porting form filled in by the customer, containing a list of numbers to port, account numbers with loosing carrier and date.

If requested by the customer the Loosing CSP must explain any costs / termination payments / contractual obligations to the customer (Section 4.1.4), however the Loosing CSP cannot reject the port based upon an outstanding contract being in place.

Step 2 – Validation

Before anything technical happens, the Gaining CSP must validate the porting request is valid – this means verifying:

The requested numbers are able to be ported under the selected method (Cat A or Cat C)
Confirming the date of the Customer Authority is less than 90 days old
The requested numbers must be recorded

In practice these 3 steps are typically handled by a single form filled out by the customer in the first step. (Section 4.1.5)

If requested by the Loosing CSP this Customer Authority information has to be given to the Loosing CSP. This typically happens in cases of disputed ownership / management of a number.

Step 3 – The SNA PNO

Once the Gaining CSP is satisfied the port is valid, a Simple Notification Advice (SNA) is sent to the Loosing CSP via a Porting Notification Order (PNO) (Section 4.2.2).

The PNO is essentially a form that includes:

Area Code & Telephone Number of service to be ported
Service Account number with Loosing CSP
Porting Category set to Cat A
Date of Customer Authority

The Loosing CSP must then validate this info, by checking: (Section 4.2.4)

The requested number is a Simple service (Meets the requirements of Cat A)
Is with the Loosing CSP (Has not been ported to another carrier already)
Is not disconnected or pending disconnection at the time the SNA was submitted
The Customer Authority (CA) date is not more than 90 days old
Does not currently have a port request pending

After the Loosing CSP has gone through this they will send back a SNA Confirmation Advice if the port request (SNA PNO) is valid or a SNA Reject Advice along with the phone number and reason for rejection if the port request is deemed invalid.

The confirmation, if SNA Confirmation Advice is received, is deemed valid for 30 days, after which the process would have to start again and the SNA PNO would have to be regenerated.

Step 4 – Electronic Cutover Advice (ECA)

After the Loosing CSP sends back a SNA Confirmation Advice, the gaining carrier sends the Loosing Carrier an Electronic Cutover Advice (ECA) via the Final Cutover Notification Interface (Section 4.2.24 ).

When the Loosing CSP get the ECA it’s showtime. The Loosing CSP checks that there’s a valid SNA in place for the number to be ported and that it’s less than 2 days old (Section 4.2.27).

If the Loosing CSP is not satisfied they send back a ECA Reject Advice listing the reason for rejection within 15 minutes (Section 4.2.32).

If all looks good, the Loosing Carrier sends the Gaining CSP back a ECA Confirmation Advice within 15 minutes (Section 4.2.33).

Now is when the magic happens – the Loosing CSP “ports out” that number via their internal process, for this they provide temporary Donor Transit Routing – Essentially redirecting any calls that come into the ported number to the new carrier.

Finally the Loosing CSP sends a Electronic Completion Advice (ECA) to confirm they’ve processed the port out from their network (Section 4.2.34).

Within a day of the port completing, the Losing CSP updates the Ported Local Number Registry (PLNR) to show the service has been ported out and the identifier of the gaining carrier the number has been ported to. PLNR is nothing more than a giant text file containing a list of all the numbers originally allocated to the Loosing CSP and the carrier code they should now be routing to, this data is published so the other CSPs can read it.

Other CSPs read this PLNR data and update their routing tables, meaning the calls will route directly to the new Gaining CSP, and the Donor Routing can be removed on the Losing CSPs switch.

Cat C – Complex Porting – Process

Summary

Cat C ports are a manually project managed, and unlike Cat A are not automated.

This means that the Loosing and Gaining CSP must both allocate a “project manager”, the two to liaise with each other (typically via email) to confirm the numbers can be ported and then find a suitable time to port the numbers, finally at the agreed upon date & time each side kicks off their own process to move the numbers and confirm when it’s done.

Porting Number Validation – PNV

Before a Cat C port can be initiated the PNV process is typically called upon to validate the port won’t get rejected. This isn’t mandatory but is often used as PNV is processed relatively quickly which means any issues with the services can be worked out prior to submitting the port request.

The submitted PNV request is very similar to the actual Cat C porting request (CNA), containing the customer’s details and list of services to be ported.

The loosing CSP returns the list of numbers each with a response code denoting particulars of the service, and if rejected, a rejection code.

Response Codes:

Reason Code	Reason
P	Prime/Directory Service Number
A	Associated Service Numbers
S	Standalone Number
R	Reserved Number
D	Exchange based diversion
SS	Secondary Service linked to this Number (e.g. DSL)

Reject Codes:

Code	Reason
1	Invalid Customer Authorization date	Whole Request
2	Insufficient information supplied	Whole Request
3	Telephone Number appears to belong to a completely different end customer	Per Number
4	Telephone Numbers relate to cancelled services or services pending cancellation	Per Number
5	Missing / invalid PNV Sequence Number	Per Number
6	Telephone Numbers in the PNV request relate to services which are billed by a service provider other than the Losing Carrier.	Per Number
7	Telephone Numbers are not found / not present on Losing Carrier’s Network	Per Number

(Section 4.3.8)

It’s worth noting the main reason PNV is used so heavily in Cat C ports is if a batch of numbers / services are requested to be ported in a single Cat C porting request, if any one of those numbers gets rejected the whole port will need to be resubmitted, hence it being important that before submitting the numbers to be ported, the Gaining CSP verifies they can be ported via the PNV process.

The PNV does not guarantee a physical audit of the services, but rather an audit of available electronic data by the loosing CSP. It’s also only valid for the day of issue, so services can change between a PNV coming back clear and the port request being rejected.

99% of PNV requests should be processed within 5 business days. (Section 4.3.9)

Step 1 – Complex Notification Advice (CNA)

To initiate the port the gaining CSP submits a Complex Notification Advice (CNA) to the loosing CSP.

This contains all the data you’d expect, including customer’s details and the list of services/numbers to be ported, along with a batch number that’s unique to the Gaining CSP (Like a ticket / request number) and Gaining CSP’s Project Manager – The staff member as the Gaining CSP that will be responsible for the port.

Upon receipt, the Loosing CSP sends back a CNA Receipt Advice to confirm they’ve received and begins validating the CNA in a process very similar to the PNV process. (Section 4.4.1)

Step 2 – CNA Confirmation Advice

If verification fails and the CNA request is deemed not valid the CNA is rejected by the Loosing CSP, who sends back a CNA Reject Advice response. This response will contain a list of services and the reject code for each rejected service as per the PNV process.

If the CNA is deemed valid, the Loosing CSP responds with a CNA Confirmation Advice message, containing the Loosing CSP’s project manager for this port, along with the Gaining CSP’s batch number to the Gaining CSP.

This is sent in a batch file along with other CNA Confirmation Advice messages within 5 days. (Section 4.4.6)

Step 3 – Complex Cutover Advice (CCA)

Once the Gaining CSP has the CNA Confirmation Advice the project manager for the port at the Gaining CSP contacts the nominated project manager at the Loosing CSP and the two have to agree on a cutover date and time for the port. (Section 4.4.8)

The agreed date and time of the port is sent by the Gaining CSP to the Loosing CSP in the from of a Complex Cutover Advice (CCA) containing the Gaining CSP batch number and agreed date & time. (Section 4.4.27)

If the details of the CCA are valid from the Loosing CSP’s perspective, the Loosing CSP sends back CCA Confirmation Advice to confirm receipt.

Step 4 – The Porting

At the agreed upon date & time both CSPs are to execute the port from their organization’s perspective.

Typically the loosing CSP provides Donor Transit Routing forwarding / redirecting calls to the ported out number to the new CSP.

There is no completion advice and no verification the port has been completed successfully required by the code. (Section 4.4.48)

Within a day of the port completing, the Losing CSP updates the Ported Local Number Registry (PLNR).

Other CSPs read this PLNR data and update their routing tables, meaning the calls will route directly to the new Gaining CSP, and the Donor Routing can be removed on the Losing CSPs switch.

If you’ve made it this far I’m amazed. I’ve written two more posts on LNP that are relvant to this one, one with an FAQ on number porting, and another with info on how call routing in LNP works.

NBN FTTN Nodes in Disguise

19/10/2019Australian TelcoFTTN, NBN, NBNCo, NodeNick

I was walking through Woolwich the other day and noticed these NBN Fiber to the Node cabinets weren’t the usual green…

Turns out the local council are behind it, and NBNCo have a few other locations where nodes are being wrapped / decorated.

Traffic light controllers, also green boxes on streets, have long been painted / decorated.

End of ISDN in Australia

30/09/2019Australian TelcoISDN, SwitchoffNick

Starting from today, Australia’s largest carrier will begin disconnecting ISDN services, and all will be shut off entirely by 2022.

When I started working in the industry the question wasn’t how many SIP Channels you wanted, but rather PRI or BRI when it came to trunk lines.

We’d use ISDN dial up to remotely administer systems, and had a bulky ISDN PRI test set for testing lines and BERT.

ISDN Crossovers, QSIG, gateways, ISUP, Bit Error Rate Testing, loopbacks, clock slips, cause code 16, enblock dialing – all things I’m not likely to need to know anymore.

Since ISDN was first rolled out in Australia just over 3 decades ago, to it being switched off from today onward, ISDN has been crazily reliable, and as much as it pains me to admit it, it has availability stats any SIP provider would be envious of.

As the market evolved over the years the smaller telcos realized using ISDN-SIP gateways made by AudioCodes, Epigy, Sangoma & Quintum was a cheap way to provide a drop in replacement for those expensive Telstra/Optus ISDN services. This generally was a stop gap measure as companies then made the move to straight SIP and stopped paying for the gateway device each month.

And just like that, ISDN was no longer relevant.

So today SIP based VoIP is the clear standard, ISDN fades away, but strangely those POTS lines carry on. Sure they are just VoIP delivered over a carrier grade ATA, but that 48vDC loop of copper with AC ring current, standardized over 120 years ago somehow lives on…

Here’s an article from The Age dated 11 August 1989:

Number may be up for the Telephone

Alexander Graham Bell’s system of sending voices over wires with a varying electrical current started a revolution, then weathered it for 123 years.
In Australia, that unchallenged reign officially ended yesterday with the official beginning of another revolution called integrated services digital networking — ISDN. The telephone has married the computer and gone digital.
The revolution really began late last year when Telecom invited several big companies to try out the communications system that will soon extend its tendrils into our offices and eventually, our homes.
In Canberra’s new National Convention Centre yesterday, the Minister for Telecommunications and Aviation Support, Mrs Kelly, communicated simultaneously via voice, fax and photovideotex on a single telephone line with two senior officers of the Defence Department in an office on the other side of Canberra.
Mr Bell’s telephone could never do that — it does only one job at a time.
With ISDN, any device that speaks or responds to the simple on-off language of computer digital code, or anything that can be rendered in the same code, including the human voice, video images and computer images, can be sent simultaneously on a single ISDN connection.
Each type of information is coded and -addressed in such a way that, at the other end, fax messages go to faxes, voices come out of the telephone and computer images arrive onscreen or on a printer.
The system inaugurated by Mrs Kelly is called ISDN Macro-link. It allows large companies with high-volume communications needs to design their own communications networks by selecting from a range of services available through the network, and plugging in the devices they need to do their business.
Like Lego, ISDN can be configured in myriad ways. It permits permanent, high-volume links to be established between offices in widely separated locations so that big computers can talk to each other.
Charges for all ISDN use are based on the amount of information sent.
The blazingly fast G4 fax can transmit a full A4 page in a few seconds, and the image emerges perfect and with the tiniest detail still visible, as if fresh from a laser printer.
The same link allows an executive in Melbourne to call a colleague in Sydney as easily as dialing an extension in the same building.
One can sketch a diagram on his computer terminal, and it will appear at the other end as it is being drawn.
Photographs can be digitized on a scanner and sent to a computer or printer as they speak, and if they wish, the colleagues can even see each other’s faces on slow scan video.
ISDN’s availability will lead to a change in the design of items like telephones, personal computers, printers and faxes — already companies are making devices that integrate all four.
As Australian and overseas networks develop, and ISDN communication between continents increases, the global village will shrink even further.
Number may be up for the telephone – Grahame O’Neill, Science and Technology Reporter
‘The AGE’ Melbourne Australia – Friday 11 August 1989

Telecom Australia – ISDN Training Manual

The Sad story of ENUM in Australia

27/07/2019Australian Telco, RFCs & StandardsACMA, ENUMNick

ENUM was going to change telephone routing. No longer would you need to pay a carrier to take your calls across the PSTN, but rather through the use of DNS your handset would look up a destination and route in a peer to peer fashion.

Number porting would just be a matter of updating NAPTR records, almost all calls would be free as there’s no way/need to charge and media would flow directly from the calling party to the called party.

In 2005 ACMA became the Tier 1 provider from RIPE for the ENUM zone 4.6.e164.arpa

A trial was run and Tier 2 providers were sought to administer the system and to verify ownership of services before adding NAPTR records for individual services and referral records for ranges / delegation.

In 2007 the trial ended with only two CSPs having signed up and a half a dozen test calls made between them.

Now, over a decade later as we prepare for the ISDN switch off, NBN is almost finished rolling out, the Comms Alliance porting specs remain as rigid as ever, it might be time to look again at ENUM in Australia…

Kamailio Bytes – Routing to geo local RTPengine Instances with Kamailio

21/07/2019Australian Telco, Kamailio, RFCs & Standards, VoIPGeoIP, GeoIP2, Kamailio, Kamailio Bytes, RTP, RTP Proxy, RTPEngine, rtprelay, SIP, VoIPNick

I’m a big fan of RTPengine, and I’ve written a bit about it in the past.

Let’s say we’re building an Australia wide VoIP network. It’s a big country with a lot of nothing in the middle. We’ve got a POP in each of Australia’s capital cities, and two core softswitch clusters, one in Melbourne and one in Sydney.

These two cores will work fine, but a call from a customer in Perth, WA to another customer in Perth, WA would mean their RTP stream will need to go across your inter-caps to Sydney or Melbourne only to route back to Perth.

That’s 3,500Km each way, which is going to lead to higher latency, wasted bandwidth and decreased customer experience.

What if we could have an RTPengine instance in our Perth POP, handling RTP proxying for our Perth customers? Another in Brisbane, Canberra etc, all while keeping our complex expensive core signalling in just the two locations?

RTPengine to the rescue!

Preparing our RTPEngine Instances

In each of our POPs we’ll spin up a box with RTPengine,

We’d set it up in the way outlined in this post,

The only thing we’d do differently is set the listen-ng value to be 0.0.0.0:2223 and the interface to be the IP of the box.

By setting the listen-ng value to 0.0.0.0:2223 it’ll mean that RTPengine’s management port will be bound to any IP, so we can remotely manage it via it’s ng-control protocol, using the rtpengine Kamailio module.

Naturally you’d limit access to port 2223 only to allowed devices inside your network.

Adding Multiple RTP Engines to Kamailio Database

After adding database functionality to our Kamailio instance as we covered in this post, we’ll just need to add the follow lines to our config:

loadmodule "rtpengine.so"
modparam("rtpengine", "db_url", DBURL)
modparam("rtpengine", "table_name", "rtpengine")
modparam("rtpengine", "setid_avp", "$avp(setid)")

Next we’ll need to add the details of each of our RTP engine instances to MySQL, I’ve used a different setid for each of the RTPengines. I’ve chosen to use the first digit of the Zipcode for that state (WA’s Zipcodes / Postcodes are in the format 6xxx while NSW postcodes are look like 2xxx), we’ll use this later when we select which RTPengine instances to use.

I’ve also added localhost with setid of 0, we’ll use this as our fallback route if it’s not coming from Australia.

INSERT INTO `rtpengine` (`id`, `setid`, `url`, `weight`, `disabled`, `stamp`) VALUES (NULL, '6', 'udp:WA-POP.rtpengine.nickvsnetworking.com:2223', '1', '0', NOW());
INSERT INTO `rtpengine` (`id`, `setid`, `url`, `weight`, `disabled`, `stamp`) VALUES (NULL, '2', 'udp:NSW-POP.rtpengine.nickvsnetworking.com:2223', '1', '0', NOW());
INSERT INTO `rtpengine` (`id`, `setid`, `url`, `weight`, `disabled`, `stamp`) VALUES (NULL, '0', 'udp:localhost:2223', '1', '0', NOW());

We’ll restart Kamailio, and check the status of the RTPengines we added:

#> kamcmd rtpengine.show all
{
        url: udp:NSW-POP.rtpengine.nickvsnetworking.com:2223
        set: 2
        index: 1
        weight: 1
        disabled: 0
        recheck_ticks: 0
}
{
        url: udp:WA-POP.rtpengine.nickvsnetworking.com:2223
        set: 6
        index: 3
        weight: 1
        disabled: 0
        recheck_ticks: 0
}
{
        url: udp:localhost:2223
        set: 6
        index: 3
        weight: 1
        disabled: 0
        recheck_ticks: 0
}

Bingo, we’re connected to three RTPengine instances,

Next up we’ll use the Geoip2 module to determine the source of the traffic and route to the correct, I’ve touched upon the Geoip2 module’s basic usage in the past, so if you’re not already familiar with it, read up on it’s usage and we’ll build upon that.

We’ll load GeoIP2 and run some checks in the initial request_route{} block to select the correct RTPengine instance:

        if(geoip2_match("$si", "src")){
                if($gip2(src=>cc)=="AU"){
                        $var(zip) =  $gip2(src=>zip);
                        $avp(setid) = $(var(zip){s.substr,0,1});
                        xlog("rtpengine setID is $avp(setid)");
                }else{
                        xlog("GeoIP not in Australia - Using default RTPengine instance");
                        set_rtpengine_set("0");
                }
        }else{
                xlog("No GeoIP Match - Using default RTPengine instance");
                set_rtpengine_set("0");
        }

In the above example if we have a match on source, and the Country code is Australia, the first digit of the ZIP / Postcode is extracted and assigned to the AVP “setid” so RTPengine knows which set ID to use.

In practice an INVITE from an IP in WA returns setID 6, and uses our RTPengine in WA, while one from NSW returns 2 and uses one in NSW. In production we’d need to setup rules for all the other states / territories, and generally have more than one RTPengine instance in each location (we can have multiple instances with the same setid).

Hopefully you’re starting to get an idea of the fun and relatively painless things you can achieve with RTPengine and Kamailio!

Numbering Systems in Australia: E.164 vs 0-NDC-SN

10/06/2019Australian Telco, RFCs & Standards, VoIP0NDCSN, 0NSN, CC-NCC-SN, E.164, NSN, Numbering Plans, Numbering SystemNick

You’ll often see numbers listed in different formats, which often leads to confusion.

Australian SIP networks may format numbers in either 0NDC-SN or E.164 format, leading some confusion. There’s no “correct” way, ACMA format in 0-NDC-SN, while most Australian tier 1 carriers store the records in E.164 format.

There’s no clear standard, so it’s always best to ask.

Let’s say my number is in Melbourne and is 9123 4567,

This could be expressed in Subscriber Number (SN) format:

9123 4567

The problem is a caller from Perth calling that number wouldn’t get through to me, there’s a good chance they’d get a totally unrelated business.

To stop this we can add the National Destination Code (NDC), for Victoria / Tasmania this is 3, however when dialling domestically a 0 is prefixed.

The leading 0 is a carry over from the days of step-by-step based switching, which had technical and physical design constraints that dictated the dialling plan we see today, which I’ll do a post about another day.

So to put it in 0-NDC-S format we’d list

03 9123 4567

But an international caller wouldn’t be able to reach this from their home country, they’d need to add the Country Code (CC) which for Australia is 61, so they’d dial the CC-NDC-SN

So they’d dial 61 3 9123 4567

This formatting is called E.164, defined by the ITU in The international public telecommunication numbering plan,

Sometimes this is listed with the plus symbol in front of it, like

+61 3 9123 4567

Each country has it’s own international dialling prefix, and the plus symbol is to be replaced by the international dialling prefix used in the calling country. In Australia, we replace the + with 0011, but it’s different from country to country.

SMS Security – Banks

20/05/2019Australian Telco, SecuritySecurity, SMSNick

The other day I got an SMS from my bank, one of the big 4 Australian Banks.

BANKNAME Alert: Block placed on card ending in XXXX, for suspicious transaction at ‘THING NICK PURCHASED ONLINE’ for $29.00 at 13:56. If genuine, reply ‘Yes’. If Fraud, reply ‘No’.
SMS from bank

They’d detected possible fraud on my card, and were asking me to confirm if it was me or not by texting back.

That is my correct card number, and as it happens I had made an online purchase that was what it was querying.

I was already at my computer, so out of curiosity, opened the SMS Gateway I use, and set the caller ID to be my mobile number (Because spoofing Caller ID is trivial) and replied to the number the bank sent me the SMS from.

My phone beeped again:

Thank you for confirming this transaction is genuine. The block will be removed from your card within the next 20 minutes. No further action is required.
SMS from Bank

So what’s the issue here?

The issue is if someone were to steal your card details, and know your mobile number, they could just keep texting the bank’s verification line the word “yes” from an SMS gateway spoofing your Caller ID, the bank won’t block it.

No system is foolproof, but it seems a bit short sighted by this bank.

Texting back a code would be a better solution, because it would allow you to verify the person texting received the original SMS, or cycling the caller IDs from a big pool would decrease the likelihood of this working

PMG / Erricson 3 line 8 ext PMBX

12/02/2019Australian TelcoAntiques, PMBX, SwitchboardNick

It’s no great secret I collect old phone stuff, I got this Melbourne made PMBX (Private Manual Branch Exchange) a while back, and I finally got around to doing something with it.

I’ve cleaned all the relays, got all the electronics happy (still need to replace the ring generator), taken everything out, sanded it, varnished it, 3D printed replacement knobs, cleaned the glass and got it looking all schmick.

Before

During

After

Glass replaced, contacts cleaned, wooden case taken apart, treated for boras, sanded and stained.

Next up fit all the 3D printed knobs, and repaint all the switch assemblies