Bandwidth porting guideFollow
Note: This guide contains Bandwidth porting best practices and should not be used as a reference for company or industry policy.
Phone number porting, also known as LNP (Local Number Portability), is an important service offering at Bandwidth. Depending on the carrier, the porting process can be simple and easy, or lengthy and complex. Our mission is to provide the easiest and best porting experience, but it requires cooperation from all parties involved. Click here to learn more about how to port numbers to Bandwidth!
Understanding number porting
Number portability is required to be performed by local exchange carriers (LECs) and Interconnected VoIP providers in accordance with rules and procedures established by the Federal Communications Commission (FCC). However, within the structure of the FCC requirements, carriers may have individualized systems and processes for handling porting activity. Thus, while carriers’ LNP operations are largely similar and intended to accomplish the same end results, there are unique differences in processes and procedures from one to the next. Some of these unique differences are what can make or break an easy LNP process. At the outset, here are some basic rules of thumb to follow that work for the vast majority of all port requests:
Don't disconnect services with your current carrier
The authorized end user of a number should never disconnect services with their current carrier prior to submitting a port request. Disconnected or inactive numbers can't be ported. In fact, in order for porting to occur most smoothly, end users generally should not inform their current provider that they intend to transfer their service to a new carrier. The end user may, however, contact their carrier to attempt to obtain documentation of their account or the Customer Service Record (CSR), which is described more fully below. The end user will also want to make sure there are no freezes that would prevent porting activity on the current account, and be sure to have any applicable PINs, passwords, and account numbers ready for use when making a request to port numbers to a new carrier.
Provide accurate porting information
Address information for wireline and VoIP LNP requests (i.e. excluding toll-free and wireless porting) should be provided as the service address, not a billing address. Often the billing address isn't representative of where the number that is being ported is actually in service, and it's the service location that matters most for LNP processes. Additionally, the authorized end user should be sure that any and all additional information pertaining to their account (e.g. full port/partial port, passcodes, account numbers, etc.) is provided and is accurate.
Porting types and time frames
Bandwidth abides by applicable FCC standards, requirements and recommendations for number porting. Because the type of port request submitted can affect porting time frames - some of which are recommended and others required - this guide should provide a better idea of what to expect. Keep in mind however, industry standards and practices are subject to change. If an order is taking longer than indicated below, and has not received a rejection of any kind, please open a ticket with your Bandwidth Porting Team.
Note: All time intervals below are contingent upon the authorized end user’s information provided to Bandwidth being correct so that it matches the current/losing carrier’s applicable records. If the requisite information doesn't match, the time interval for porting will be longer. Please keep in mind that because Bandwidth can't predict any errors in processing, or the behaviors of other carriers, all quoted times below are Bandwidth’s goal to get the order completed, and can't be guaranteed for all cases.
|Port type||Estimated porting interval|
|Standard or off-net port||3-7 business days|
|Simple port||1-2 business days|
|Complex or non-simple port||3-4 weeks|
|Project port||3-4 weeks|
|Toll-free port||3-7 business days|
Bandwidth considers any single order to port 100 phone numbers or fewer that includes a single Billing Telephone Number (BTN), single address, single losing carrier and single rate center to be a standard port. All standard port requests must be entered into the Bandwidth portal, and most will begin processing immediately upon submission. A standard port request will typically be completed within 7 business days, if a first available date is requested, and if there are no rejections on the order.
Bandwidth utilizes an application programming interface (API) on the back-end of its portal that allows for quicker porting times and responses. Once a standard port request is submitted to the portal, and isn't considered off-net, the order automatically starts processing. Bandwidth has logic in its API that identifies other carriers that Bandwidth is bonded with and which identifies the earliest possible porting dates available with the losing carrier.
Example of a standard port: Bob of Bob’s Hardware is porting 5 phone numbers for his office to Bandwidth from his current carrier. All 5 numbers are located in the Phoenix, Arizona rate center, and share the same BTN, end user name and address. Also, all 5 numbers are currently serviced by the same LEC.
The FCC requires wireline, wireless and interconnected VoIP providers to complete “simple ports” within one business day, unless the requesting provider asks for more time. Contrary to the name, “simple porting” can actually be somewhat complicated to understand. A “simple port” actually depends very specifically on the criteria listed below. If the required criteria isn't met precisely, the order may be rejected by the current/losing carrier, which will cause the winning carrier to have to resubmit the port request with new requested porting dates thereby extending the time frame for successfully porting the number to Bandwidth. The criteria for simple porting are those ports for a single TN that exclude:
- Unbundled network elements
- Multiple lines
- Complex switch translations (e.g., Centrex, ISDN, AIN Services, Remote Call Forwarding (RCF), or multiple services on the loop)
A proper simple port must be submitted and received by the current/losing carrier by 1 p.m. local time (of the losing carrier) on a business day for it to be eligible for activation at midnight on the same day. Any simple port request received after 1 p.m. on a business day local time will be considered the next day’s business. All simple ports shall be entered into the portal just like a standard port request, but with a requested completion date within the aforementioned intervals.
Example of a simple port: Sara Jones is porting her basic residential phone number from her current carrier, to Bandwidth or a VoIP provider that Bandwidth supports. Her phone number doesn't have any extra features on it, like call forwarding, and isn't part of a bundled package.
Complex or non-simple porting
Single order port requests that include complex properties such as: multiple rate centers, multiple Billing Telephone Numbers (BTNs), and/or multiple addresses, to be “complex ports.” Complex porting may also involve the losing carrier’s identification of complex porting, due to legacy properties on the account that require special handling. Complex porting, like project porting, isn't subject to the same well-defined performance intervals that exist for “simple ports” under FCC rules and may be subject to negotiated arrangements between carriers.
The Bandwidth LNP Projects team aims to complete complex ports as quickly as possible but not longer than within 6 weeks. Complex ports are every similar to project ports but project ports typically include more TNs as part of the port request where a complex or non-simple port can include even a single TN if that TN has complex service properties associated with it.
Example of a complex port: Pottery King Retail stores are porting 10 of their phone numbers. The 10 numbers are located in the same state of Colorado but in 3 different rate centers (Denver, Grand Junction, and Colorado Springs). Three of the phone numbers currently belong to one LEC, while the remaining 7 belong to another LEC. Thus, the order has 2 different BTNs and 3 different addresses.
Bandwidth considers port requests presented as a single order, with 100 or more phone numbers, a single BTN, a single losing carrier and a single address to be “project ports.” Project porting requires manual handling, and generally can be completed within 3-4 weeks of submission. Please contact the project porting team for questions on project porting, including how to submit a project port, more specific timelines for completion, what is required to provide, etc.
Example of a project port: Dewitt’s Grocery Stores are porting all of their store numbers in a single rate center and state. The store has 35 locations in the same rate center, and there are 245 numbers that will be porting. The numbers are all with the same carrier but have multiple addresses and BTNs.
Toll-free porting is defined as the porting of any toll-free or “8YY” number (800, 844, 855, 866, 877 and 888 exchanges). It's a slightly different process throughout the industry, and isn't subject to the same mandates as LNP by the FCC. Toll-free ports are handled manually, but must be entered into the portal similar to a standard port request. Toll-free port requests should preferably be submitted within a week of when number activation is desired.
Toll-free numbers are at risk of being disconnected if not activated within 1-2 weeks after the provider that is designated to manage the toll-free number (also known as a RespOrg) has released it. In attempt to avoid accidental disconnects, Bandwidth won't submit a toll-free port request to the designated RespOrg until a week before the desired due date.
Toll-free port requests should be completed within 7 days, assuming there are no rejections on the order and a first available date is chosen. LOA submission for toll-free porting is different than standard number porting. Please see the LOA & documentation policy section for more information.
Occasionally Bandwidth provides services in rate centers that are not covered under its own interconnected CLEC footprint by partnering with other LECs. Such numbering arrangements are considered to be “off-net” because they are not supported under the Bandwidth CLEC, and identified as off-net ports (Tiers 1-5). For the most part, these flow through just like any other standard port request, however the control and administrative duties of porting are left up to Bandwidth’s partner.
LOA and documentation policy
There are specific instances when Bandwidth will require certain pieces of documentation, like Letter of Agency/Authorization (LOA) or Copy of Bill (COB), before initiating LNP orders. Follow these simple guidelines to make sure the proper documentation is submitted at the time of the order to prevent costly delays:
|Type of Port Request||Required||Conditional|
|Porting on-net to Bandwidth CLEC||X||X|
|Porting off-net to a Bandwidth vendor||X||X|
*A specific LOA format may be required for some carriers.
Conditional LOA policy
As a wholesale provider Bandwidth may not require its customer to produce the required LOA up front, however customers must be prepared to produce the LOA at any point during, before or after the porting process. An example of when Bandwidth may need the LOA is during an inadvertent porting situation (see below). In this case, the valid LOA should be provided to Bandwidth immediately upon request. If the LOA isn't provided immediately upon request, a number could be removed from the customer account and returned to the former carrier or customer.
Customer Service Record policy
A Customer Service Record (CSR) is often used by carriers to help determine that a port request is authorized. However, some carriers have policies that limit production of the CSR only to the end user of record, while other carriers will provide the CSR only to a winning carrier, and still others won't provide a CSR at all.
All reseller customers are responsible for advising their end users that accurate service address and end user information is required to port numbers, and then providing this information to Bandwidth with the port request. If a port request is rejected by the losing carrier for an information mismatch, Bandwidth will require the customer and/or the end user to obtain accurate and necessary information from the current carrier. If the customer and/or end user experience difficulties gathering necessary information, Bandwidth may be able to assist, including requesting the CSR from the current carrier.
It's not Bandwidth’s policy to request a CSR on every order, regardless of the status the order. A CSR will be provided at Bandwidth’s discretion only, and the cost to retrieve the CSR may be passed along to the customer.
The most common port rejections are those that indicate the information submitted doesn't match what the losing carrier has on file. Examples include things like: name mismatch, address mismatch, zip-code mismatch, and partial/full porting migration errors. It's the responsibility of each customer / end user to provide accurate information necessary to complete the port request through Bandwidth’s portal. By doing so, the potential for up-front rejections and delays in porting will be dramatically reduced. Please see the rejection table below for common rejections and resolutions:
Number Disconnected / Not Active
The TN or the account holding the TN is considered disconnected or inactive. All accounts and TNs must be active to port. End user will need to re-activate service with their provider to continue.
A pending order can be anything from another port request that has been submitted with this same number, a feature add or disconnect, address change, etc. The end user will need to contact the carrier to get the order close out or canceled in order to proceed.
BTN Mismatch / ATN Mismatch
The BTN provided on the order doesn't match the BTN on the carrier’s records (CSR). The end user will need to contact the carrier to obtain the correct BTN. Bandwidth doesn't have the ability to determine the ATN/BTN by pulling a CSR. This needs to come from the end user.
Partial Port / Migration Indicator
A partial port indicates the customer is porting away only some of the numbers they have with the current carrier. A partial port rejection can (generally) one of two things:
a) The order was submitted as a partial port, but it's not actually a partial port
b) The order was submitted as a full port, but it's actually a partial port.
Fixing this generally requires the customer / end user to review their inventory/services/CSR with the current carrier, then advising the LNP team how the customer wishes to proceed with the port. Sometimes this also comes through as a rejection for Migration Indicator, which is the toggle/button that is chosen when submitting the order to choose a partial or full port.
There are instances with this rejection, whereby the order would have to be cancelled and resubmitted. If the order is truly a partial port, a new BTN will need to be provided to the current carrier in order to keep remaining services intact. The new BTN must be a number that already exists on the same customer account with the current carrier.
Please contact the LNP team for assistance if needed.
Customer has requested a freeze to be placed on the account that prevents the numbers from being ported (a freeze prevents the change of carriers on an account). The end user will need to submit an order to the current carrier to remove the freeze. This process can take 1-3 weeks depending on the carrier. Once the freeze is removed, and the order to remove the freeze has closed out with the current carrier, the port may be restarted or resubmitted with Bandwidth.
DSL / Dryloop
DSL is an internet service. If DSL exists, unless the DSL provider allows Dryloop, an associated phone number is probably needed for that connection. Check with the DSL provider before attempting to port a DSL number. Generally, the end user will need to disconnect it prior to port, make new arrangements with the carrier for the DSL, or provide instruction to Bandwidth to disconnect the DSL in order to proceed. If a number is ported without the end user taking care of the DSL service, the DSL runs the risk of being completely disconnected.
Distinctive Ring or Other Feature
This is a feature most carriers won't port while active. The end user will need to disconnect it directly with the carrier.
The business or residential name on the order doesn't match that of the carrier’s records (CSR). The end user will need to contact their provider to pull the current name on the CSR.
Order activation (Day of FOC)
All non-project on-net porting requests are currently activated at 11:30 a.m. ET. Most off-net porting requests are also activated at this time, but please contact a member of the Bandwidth LNP team to confirm the time any specific order will be activated if this is a critical need. Because project ports are subject to non-standardized intervals, activation times will be scheduled according to customers’ requests according to the project porting schedule that is in place with the other carrier. Bandwidth doesn't currently support specific port time activations for any other type of port requests.
|Type of LNP Order||Set Activation Time||Other Activation Time|
|On-net/CLEC porting||11:30 am ET||Customer may select customer activation for times outside of that window|
|Domestic off-net porting||6 am - 10 pm ET||For more information, see how to manage U.S. off-net ports.|
|Non-domestic off-net porting||11:30 am ET|
|Toll-free porting||11:30 am ET|
|Project porting||Customer specific, unless noted by Project Manager|
|Complex porting||11:30 a.m. ET, unless noted by Project Manager|
SUPP is short for supplemental, which is an additional request that is sent on a LNP order, to the losing carrier, generally making a change to the order in some fashion. A SUPP can be anything from changing the due date (most common) to correcting something on the order due to a rejection.
Bandwidth allows up to three (3) SUPP requests on any order after FOC is received. Once FOC is received a SUPP request is only sent in an attempt to change the desired due date. SUPP requests can't be sent to the carrier with a new due date (whether it’s after FOC is received or before), for anything more than a 30-day interval from the current business date. Any SUPP request submitted less than 48 hours before FOC date, is considered best effort which means there is the possibility that the numbers may still port on their original FOC date. Additionally, the original FOC date may be lost and the order may need to be restarted once a SUPP is issued.
There may be costs associated with SUPP transactions. If Bandwidth incurs additional costs as a result of customer requested SUPPs, these costs will be passed along to the customer.
Order cancellation requests
A port request can be cancelled at any time up to 48 hours (2 business days) prior to the established FOC date on the port. However, cancellation request within this 48-hour window may trigger an expedited cancel charge. Further, a cancellation can't be guaranteed. Therefore, it's always best to find a way to accept a port request when it's within 48 hours of the FOC date to avoid an accidental outage on the phone number(s).
Short notice FOC
There are times that the current carrier doesn't provide a FOC date that matches what has been requested. Typically a FOC mismatch means the FOC date given is later than the requested date but there are times when the FOC date provided by the current carrier is within a very short window (e.g. 0-48 hours from the date/time submitted). Bandwidth will immediately notify its customers (via portal notification) of the shortened FOC window in an attempt to confirm the FOC can be accepted, or if a SUPP request needs to be sent to the carrier to change the date. A SUPP on a short notice FOC, which isn't a result of an expedite, is supported at no charge to the customer.
An expedite request is a customer-initiated request aimed to shorten the time frame of a specific LNP request, such as a FOC or a cancellation request. Any attempt to expedite a LNP request is considered best effort. Additionally, these types of requests require cooperation from the other carrier, some of whom may not readily support it. Please contact the Bandwidth LNP team for assistance for all expedite requests. Finally, any additional costs associated with expedite transactions will be passed along to the customer.
Porting away from Bandwidth
If a customer or end user wishes to port their number(s) away from Bandwidth, there's nothing that needs to be done from the end user perspective, other than providing the correct porting information to the new carrier, which can be found in the customer portal. Bandwidth doesn't utilize passwords, freezes, PINs or any other similar features at this time.
The responsibility of initiating the port request, and following the proper port-out procedure is on the new/winning carrier. However, Bandwidth understands that assistance may be needed in ensuring that the port-out occurs without incident. All winning carriers should be directed to Bandwidth’s business rules online at http://bandwidth.com/legal. If further assistance is needed, the carrier may contact the port-out team at 855-577-2929. Keep in mind, the Bandwidth port-out team works solely with other carriers (LECs), and not with end users directly.
Note: The numbers associated with disconnected services won't be eligible to port.
An unauthorized port is also known as a “slam". Slamming occurs when a number is ported out to a new carrier without proper authorization from the end user. FCC rules, guidelines, and policies establish that it's the new carrier’s responsibility to ensure that the port requests it submits are authorized. In order to encourage competition and freedom of choice by end users, applicable rules and procedures limit the ability of the old or “losing” carrier to verify that port out requests are properly authorized. Therefore, in order to support successful porting, Bandwidth requires its customers to obtain legally valid authorization from end users as part of each port request it makes. Legally valid authorization is captured through the execution of an LOA that contains at least the minimum required information according to the FCC’s rules and industry standards.
Bandwidth can provide port-out notifications so that customers are able review and validate phone numbers that have been ported out by end users. If a customer believes a number has ported without valid authorization, the Bandwidth LNP team will work hard with the other carrier to make a determination of the validity of the request and if the port was not authorized, return the number as quickly as possible. The following process is required in order for the LNP team to process a “snapback” of a number that has been ported without authorization.
Note: It's critical to report these types of incidents within 24 hours of the porting activity.
- Report the potential unauthorized port to the LNP team by opening a support ticket.
- An LOA signed by the end user of record identifying the end user’s choice of carrier may be required. If so, it should be attached to the ticket.
- Call the LNP team promptly at 855-VoIP-Pro to advise a number was potentially ported away without valid authorization, and a ticket has been opened.
The LNP team will immediately begin working with the other carrier in an attempt to return the number if the port wasn't properly requested. This may require further cooperation or input from the customer or end user. Things to keep in mind with unauthorized ports:
- Numbers are authorized based on the new or “winning” carrier’s criteria.
- An unpaid bill by an end user doesn't constitute an invalid port. In fact, the FCC has made clear that carriers can't delay or prevent porting due to a billing dispute or unpaid.
- Despite validation efforts taken by carriers, mistaken or unauthorized porting may still occur. If there's belief that a number was intentionally slammed, end users may report such claims directly to the FCC via this website.
Any unauthorized ports shall be reported to Bandwidth within 24 hours of the occurrence, but no more than 1 week after. Any unauthorized port request brought to Bandwidth’s attention more than a week after the day it ported away is considered a "winback", to which standard porting time frames and policies apply. An unauthorized port request that is older than week won't be worked as a "slam".
Please bear in mind that no provider (Bandwidth included) is immune from occasional inadvertent porting due to unintentional errors during the porting process. The most common errors occur when submitting the initial port request (e.g. a typo on the porting TN(s) itself). In these cases, the other carrier will contact Bandwidth and request the number to be released back to them and their customer or end user. Bandwidth has the following policy on reverse inadvertent porting (“snapback”):
- Bandwidth will review the request from the complaining carrier to determine the information used to port the number to Bandwidth, and the customer assigned to the number.
- Bandwidth will reach out to the customer of record indicating the number was reported as being inadvertently ported to Bandwidth.
- Bandwidth will require a valid LOA from the end user immediately (please see Bandwidth’s LOA policy). If the LOA isn't provided in a timely manner, and Bandwidth deems the port was made in error, the number will be released back to the complaining carrier immediately.
- Bandwidth will remove the number from provisioning in its portal, thus triggering a port-out notification, so that the customer may adjust their records accordingly.
Bandwidth service levels in the porting process
- Submit port request within 2 business days of receipt of end user.
- Provide an update on each order every 2 business days.
- Process the necessary supplemental and cancellation requests on orders within 1 business day.
Customer responsibilities in the porting process
- Provide correct porting information.
- Keep the end user letter of authorization (LOA) on file, and be able to present a copy immediately upon request.
- Provide toll-free LOAs upon port.
- Rectify the basis for an insufficient port request that results in a port request rejection within 10 business days.
- Provide a new LOA if the initial LOA and request become more than 30 days old during the course of porting.
When should I open a ticket?
If you don't receive assistance via the tools and resources available, or if there's an expedite request, an inadvertent porting incident, or any other reason where a ticket may be appropriate, please open one! The Bandwidth Porting Team works trouble tickets in the First In First Out (FIFO) order, but searches for tickets that have high priority first. Opening a ticket is the fastest way to get your questions answered.
Was this article helpful?
32 out of 45 found this helpful