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 best porting experience, but it requires cooperation from all parties involved. To learn more about some of the most common porting questions, check out this quick guide.
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 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, that 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.
|Estimated porting interval
|Standard or off-net port
|3-7 business days
|1-2 business days
|Complex or non-simple port
|3-7 business days
Bandwidth considers any port request presented as a single order containing 99 or fewer numbers, a single Billing Telephone Number (BTN), a single address, a single losing carrier, and a 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
Bandwidth considers any port request containing complex properties such as multiple rate centers, multiple BTNs, and/or multiple addresses to be a “complex port". 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 no longer than 6 weeks. Complex ports are very similar to project ports but project ports typically include more TNs as part of the port request, whereas 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 containing 100 or more 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 2 weeks 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 an attempt to avoid accidental disconnects, we advise our customers to not submit the port request until they are within that 2-week timeframe to overcome any potential rejections while also ensuring that we get FOC in time to meet the desired activation 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 are 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 a 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
|Porting on-net to Bandwidth CLEC
|Porting off-net to a Bandwidth vendor
*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 before, during, 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 the production of the CSR only to the end user of record, while others will provide the CSR only to a winning carrier. There are also carriers that 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 of 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 the 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. Most often, Bandwidth doesn't have the ability to determine the ATN/BTN by pulling a CSR.
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 and then advise the LNP team on 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 canceled 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 the remaining services intact. The new BTN must be a number that already exists on the same customer account as the current carrier. If this has already been provided, please contact the LNP team as the current carrier may require explicit handling instructions to be provided for the remaining TNs.
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. As a best practice, it is encouraged for the end user to obtain a confirmation number for the freeze's removal.
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 by default. 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
|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
|11:30 am ET
|Customer-specific, unless noted by the Project Manager
|11:30 am ET
|Customer may select customer activation for times outside of that window
SUPP (short for supplemental) is an additional request sent on an LNP order to the losing carrier, that generally makes 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 the FOC date is considered "best effort", meaning 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 canceled at any time up to 48 hours (2 business days) prior to the established FOC date on the port. However, cancellation requests within this 48-hour window may trigger an expedited cancel charge. Further, cancellation can't be guaranteed, so 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 an 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 with all expedite requests. Finally, any additional costs associated with the 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 919-937-2024. Keep in mind that 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 a legally valid authorization from end users as part of each port request it makes. A 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 to review and validate phone numbers that have been ported out by end users. If a customer believes a number has been 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 the carrier may be required. If so, it should be attached to the ticket.
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 any 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 older than a 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 the end user information.
- Provide an update on each order as it progresses.
- 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 processes tickets in the First In First Out (FIFO) order but prioritizes tickets that have high priority. Opening a ticket is the fastest way to get your questions answered.
When will my ticket be resolved?
We make every effort to address concerns as quickly as possible once brought to our attention, and aim to have service-impacting issues resolved within the same business day and all other requests resolved within 48 hours. Please note if our team has to escalate to the losing carrier (such as to confirm latent translations have been removed or to request an update on an order once SLA has been exceeded), the losing carriers' turnaround times may extend this timeline, but we will provide regular updates on the ticket until resolution.