[ASTPPCOM-254] Feature Request : USA routing and billing Created: 01/Nov/17  Updated: 27/Oct/19

Status: To Do
Project: ASTPP Community
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature
Reporter: Samir Doshi Assignee: Samir Doshi
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As pointed out earlier, ASTPP does not support LRN (Location Routing Number) call routing and billing yet, which is necessary for routing traffic to the United States even if sending calls here from abroad because most carriers rate calls based on LRN and not DNIS anymore. Routing and rating calls based on the dialed number results in a loss of LCR functionality and can cause a great margin of error. Approximately 48% of numbers in the USA are ported either to a different local carrier or a different rate center Central Office (when a business or residence moves to a different part of town that is considered a ported number) which results in a higher or lower cost than the originally dialed number. Wireless networks are also using LRN to groom blocks of 10,000 phone numbers to various home location registers as they see fit instead of making switches perform this task. The most popular interface for retrieving this data from an LRN service provider is a SIP 302 redirect message. The 2nd most popular method would be ENUM via DNS and finally very few vendors have a so-called MySQL interface. The official source of the LRN database is Neustar (SIP-IX is their VoIP friendly access method) although many carriers go through a reseller to retrieve the data at a lower expense, either per query dip or a flat rate weekly charge.

Additionally, ASTPP does not even have interstate/intrastate/local/indeterminate call jurisdiction routing and billing yet which practically every other switch I have seen does support. This is done by using an NPANXX database such as Telcordia's LERG 6 and the appropriate rate tables to match the first 6 or 7 digits of the calling number and called number to see if the states or ratecenters are the same. A secondary source of this information would be API queries from Local Calling Guide but it should be stored locally in any case. Another reason this is important is that when selling retail minutes to an end user, international and interstate calls must be rated with two extra taxes and fees- the FUSF and FTRS, unless the customer is exempt with a FCC 499A (wholesale).

Hopefully at some point ASTPP can support these features as an awful lot of long distance traffic terminates to the United States domestically and international POI and this method of call routing and billing will not be changing for more than a decade from now due to tariffs put in place by the FCC and PUCs.

Thanks for your consideration for adding these features.

Created on behalf of Justin Hannah, Marc, Chandan Singh and Dusty Countryman.



 Comments   
Comment by countrdd [ 07/Jan/18 ]

I have been working on this...

Comment by chaudharyg [ 16/Jan/18 ]

There is one another issue while we using ASTPP for USA termination for CC traffic on the flat rate.

And the problem is if termination rate is high than origination rate then calls not connecting. is there any option to disable that from rate Group.

Because of this facing problem while selling USA termination on the flat rate.

Comment by legionnet [ 18/Mar/18 ]

In Russia MNP database is used, too.
Can you change "Code" in rates to support macros not only digits?

Comment by legionnet [ 19/Mar/18 ]

For example, I will plan to use the following identifiers:

  • DEF - all Russian mobile phones
  • MTS - operator MTS
  • MEGAFON - operator MEGAFON
    and etc.
    We can use astpp.custom.lua for external verification IDs
Comment by Samir Doshi [ 28/Mar/18 ]

[~legionnet]

Do you mean Code field should accept DEF, MTS keywords?

Comment by legionnet [ 28/Mar/18 ]

In Russia "DEF" abbreviation is mean all russian mobile phones. (DEF codes)
"ABC" is mean all russian fixed phones.
"MTS" is mobile operator name.
Maybe in other countries there are analogies.

I made such codes in DB instead '^79.*'. And made external checks for this codes.
"MTS" code is mean for me all native and transferred from other operators codes of MTS operator.

Comment by legionnet [ 28/Mar/18 ]

DEF codes has 6477 prefixes;
MTS codes has 919 native prefixes;
and so on.

Comment by legionnet [ 28/Mar/18 ]

I use for external checks number_loop() function now

Comment by Samir Doshi [ 04/Apr/18 ]

Alright, that can be handled using custom number replacement from code. Will check it out further with team about this feature request.

Generated at Sat Feb 10 07:15:31 CET 2024 using Jira 8.13.3#813003-sha1:22ebedbb75c99b147c66f14e031dd8a2d214753a.