Number Porting Possible?

Asterisk Asterisk Support
1

I want to know about routing numbers at the asterisk level where number ports are required. Routing would be implemented on the asterisk server to route any calls to the customer ported number to the network number. For an inbound call transparency would be required so the that CLI or the original caller is delivered to the customer extension rather than the routing digit. So from the example below, the caller would dial 01111 111111 and the call will be delivered to the customer extension showing a call from 01111 555555. Can someone confirm if this will be the expected outcome?

Inbound call route

Inbound Call (01111 555555) → Customer Ported Number (01111 111111) → Network Number (011111 999999) → Customer Extension

Similarly, on the outbound route customer will make a call from their extension which will have the applied number 01111 999999, will there be a reverse rule on Asterisk that swaps out the Network number to the ported number (number substitution) so that when the call is connected the outbound CLI will be the Customer Ported Number (01111 111111)? Customer will see a call from the customer number not the network number, Can someone confirm if this will be the expected behavior?

Outbound call route

Customer extension → Network Number (01111 999999) → Customer Ported Number (01111 111111) → Outbound call (01111 555555)

These are the expected outcomes, we need to make the network number transparent and in reality should be used for routing only.

Can someone guide me if this is possible on Asterisk level?

Any degree of help would be appreciated :slight_smile:

2

Asterisk has no knowledge of “number porting”. Calls are strictly routed according to however you write the logic to do so, and using the methods such as SIP you configure.

3

So, Asterisk would only be able to manipulate the caller ID on inbound and outbound calls, right? And is the number porting done at the carrier end, strictly?

4

I have not worked with how number portability works, so can’t comment on that.

5

I didn’t understand the original question, and I suspect the other responders were also not clear on what you are really asking. Number porting is not a term I’ve ever seen used on these forums.

You can do all sorts of number manipulations with Asterisk, although some of them may then be rejected by ITSPs.

6

My understanding of “number porting” is when one or more public telephone
numbers hosted by an ITSP and allocated to one of their customers get migrated
to a different service provider which the customer wants to use instead.

My approach to getting Asterisk to deal with this is simply to set up two
external connections from Asterisk to the two ITSPs, pointing to the same
context in Asterisk’s dialplan, so that Asterisk does not care which
connection calls come in on, and therefore the transition period is seamless
and transparent for the users on the Asterisk server.

For outbound calling, I set up one Dial() command to try one ITSP, and if the
call fails, a second Dial() command to immediately try to other one. Then,
provided the first-tried ITSP only allows outbound calling as long as it has
the number/s, the transition for outbound calling is also seamless and
transparent to the users.

Once the transition has completed, the connections to the original ITSP can be
deleted from Asterisk and everything returns to a simple configuration again.

Antony.

–
Don’t procrastinate - put it off until tomorrow.

7

My understanding of this is that it is something handled internally by the provider. They forward to the new provider, without involving the customer. Generally the whole point of legislation on this is to allow someone to choose a new provider without having to make their correspondents change anything.

If you are talking about a number assigned to the Asterisk user, that seems to represent a straightforward change in the endpoint used for calls intended to be treated as originated from that number.

8

can you explain how this will be handeled at Asteisk level? Like would I need to set caller-id in the dialplan for incoming calls? Or would I need to let the caller-id be set by the ITSP itself?

9

On Friday 07 February 2025 at 13:57:14, hishamjan via Asterisk Community
wrote:

can you explain how this will be handeled at Asteisk level? Like would I
need to set caller-id in the dialplan for incoming calls? Or would I need
to let the caller-id be set by the ITSP itself?

Unless the two ITSPs present Caller ID in different formats (in which case you
should simply be able to “normalise” it to your preferred format in your
dialplan anyway), then there should be no difference between person A dialling
in via ITSP 1 and the same caller dialling in via ITSP 2. It’s the same
caller in both cases, so the Caller ID should be the same.

I can’t imagine why any ITSP would change the actual number (other than format
variations such as E.164 with or without preceding plus sign) presented for an
incoming call.

Antony.

–
There’s a good theatrical performance about puns on in the West End. It’s a
play on words.

10

If you’re adding a number, you will need to add the new number as an extension in your dialplan so the PBX knows what to do with it.

[voipms-inbound]
exten = 5555551212,n,Goto(inbound-ivr,s,1)
exten = 5555551213,n,Goto(inbound-ivr,s,1)

You’ll also have to add some dial-out rules to send this number as your caller ID depending on your provider and configuration.

Everything else involving porting happens at the carrier level beyond your control or knowledge. Asterisk will literally just see a call to your PBX to an extension that matches the DID. That’s it.

11

@dewdude
so if i want a case where when a person A dials 1234, the call should be delivered to person B but the CLI would rather show a call coming from 5678 instead, is this possible at asterisk side or will this porting take place at the carrier level?

12

I’m slightly confused.

If the customer has a ported number, why do they have this second network number? Is this somehow doing multiple call forwarding rather than actually porting a number into a trunk? Is this network number not an existing routable number…ie…is it basically an internal extension?

13

So basically, we have an internal portal where we have purchased a pool of DIDs from the local ITSP. When a new customer onboards with us, a random DID (out of the pre-purchased pool) is assigned to it. This is something that happens randomly and we have no control over it. Now, keeping this in mind, I would want the porting to take place at Asterisk level which would land on the customer number via the purchased DID internally whenver somene dilas the customer number from their end…

I hope this clarifies the point

14

On Saturday 08 February 2025 at 11:53:21, hishamjan via Asterisk Community
wrote:

So basically, we have an internal portal where we have purchased a pool of
DIDs from the local ITSP. When a new customer onboards with us, a random
DID (out of the pre-purchased pool) is assigned to it.

What is supposed to happen to calls which then come in to the DID? How do
calls actually get to “the customer”?

I can’t help feeling that the phrase “number porting” has been something of a
red herring in this discussion.

Antony.

–
The best time to plant a tree is 20 years ago.
The second best time is now.

15

Hi @Pooh ,

I actually had to dig deep down and have come up with the entire process for you, p.s. it’s a long read…

So the customer is with supplier A and would like to move to us (supplier B) and bring their existing number:

  • Customer places an order with us and says they want to port an existing number (porting is subject to number porting agreement being in place between our provider and the customer’s existing provider).
  • We place an order for Broadband and/or extension(s).
  • on our portal, a user account is created and is allocated a new number is assigned to the customer account.
  • Broadband and phone can be installed at this point however service will have new number configured (not the ported number)
  • We supply customer with a letter of authority (LOA) template that they fill in outlining their existing supplier, address and number or numbers that need to port. This letter gives us the authority to port the number.
  • We then place a number port order with our provider
  • We then supply the LOA to our provider, who then validate the data on the request
  • If the data on the LOA is validated, then the order is placed, and the port request will be sent to the losing number supplier.
  • The losing supplier will either accept or reject the number port request (rejection can be down to incorrect data being included on the porting form). If the port is accepted, they will issue a schedule porting date generally 5-7 working days for a single number or 20-30 working days for a number range.
  • In the run up to the port configuration changes will be made at the national routing table level, the number will still reside with the originating number provider however a routing configuration will be implemented saying that this number now resides on our network. Our network SBC’s will be configured to route the number.
  • On the scheduled day of porting the number routing change will be implemented, this will then see the ported number being routed to our network and onto the internal SIP trunk.
  • Number will then be routed down our trunk and configuration will need to be implemented to get this to the required extension (this configuration should ideally be completed prior to the port so that on the day of port the number just starts routing into our network and routes to the correct extension).

We would need the number substitution to happen so that the inbound and outbound CLI is correct, this is assuming that the number issued to customer in step 3 is retained and we don’t go back in and reconfigure the extension and apply the ported number directly to the customer account (my worry here would be a break in service once the port happened).

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.