2017 year

I learned the ‘hard’ way that I’d better pay attention to messages returned in the PortaBilling web gui.

One evening I was to re-rate traffic for a customer who utilizes a product with 6 different tariffs. As I wanted to re-rate with the rates effective at the time of the call,

I had to schedule 6 re-rating task. So far, so good.When I had scheduled all the task nothing happened.

After approximately 30 minutes I got an e-mail stating that the first re-rating task had finished. Fine.

But when I looked at my e-mail the next morning, no other re-rating task had finished. Strange – so I created a case and added it to a ticket.

While doing so I realized what the issue was. While re-scheduling the re-rating task documenting the process,

I noticed that two of the messages returned by the web gui when a re-rating task is created are different!

Look at this:

Attached image 1

Attached image 2

Attached image 3

Attached image 4

When I waited a bit longer and let the first task finish, I could again schedule the last re-rating task:

Attached image 5

My wish for the “list” and further development is to make the two last messages shown above a little more distinct.

When one are in a hurry these two messages looks by the glimpse of an eye almost the same.

Could the error message/negative feedback e.g. be given a read background? A different button? This could save both user and support time.

> possibility of assigning IP to the end devices depending on a source radius IP

Are there any plans to implement this in future releases?

Also,

See image below.

Could a (seperate) POD server help with assigning IPs on DHCP?

So we can keep bandwidth accounting on our porta system, and do IP assignment on another?

Attached image

Wishing the following;

The Test Diaplan is great feature for ease of troubleshooting and comparing rates against customer and wholesale exchange tariffs.

A Test Diaplan feature for customers / resellers / account ID, might be useful for us administrators to troubleshoot tariff issues (even if locked to administrators only),

Specially where we set profit guarantee.

I need the following:

When a mobile handheld (GSM) registers, one of the following radius nodes of the mobile operator sends a radius request to one or our BE nodes:

PGW AH ADDRESS : 10.43.0.73/32

PGW RT ADDRESS : 10.44.0.73/32

PGW YP ADDRESS : 10.45.0.73/32

The above are their three radiuses.

When we get a request from AH, we need to assign an IP from the pool below:

PGW AH HANDSET POOL : 10.50.144.0/20

PGW RT HANDSET POOL : 10.60.144.0/20

PGW YP HANDSET POOL : 10.70.144.0/20

So, depending on where the radius request comes from, we need to assign IP from /20 A, B or C

Summary: we need to assign IPs based on where the radius request comes from

Grzegorz:

One of our customers would like this feature to be added to PortaBilling:

"The user will be using Internal numbers/extensions so won't be reachable

from external sources directly.

The user now has an PBX (Cisco, I believe) which gives them the option

to add a system as described.

The may have 100 numbers but there are about 250 people behind that

which Now they can all reach from outside by adding 1 extra digit to the

'external' number and the PBX accepts this, knows what to do and

'transfers' the call to the correct one of those 250 people.

Does this explain it well enough?

They have all business correspondence etc set up for this so making it

into a 2 step action has 2 main disadvantages for them and will possibly

prevent them from making the switch to us (or any Porta solution):

1) All printwork and communication (and prior knowledge) will have to be

deleted and renewed

2) A 2-step process is much less desirable for them (as I'm sure you'll

understand, it's more involved and error prone)"

"Сlient has decided against us/a Porta solution, mainly because of lack in expected/desired functionality. Their main reason as explained by the client:Companies that have a strong German base can readily handle the direct dialing of an extension (bypassing the main number/IVR entirely). Wasn't "critical", but it is a really nice feature, especially since business cards are circulating, and that's what our users currently expect, and it's apparently standard in Germany. So switching would be very notable shift."

Leslie:
Implement possibility of charging calls according to CLI in case of hidden calling number.

Imagine I have a tariff with the following destinations:

31

32

49

43

|

That means, when +380 calls, its matched as pipe.

When anonymous calls, its matched as pipe.

So unless I put ALL codes in there, anonymous is not matchable.

Only to "pipe", i.e. ALL OTHERS.

Which in the above also include 380.

Nick:

We would love it if there was an option to lower the credit limit, or block access to Fraud Traffic profiled destinations, if a Fraud Traffic Profile alert is tripped.

So if a customer's PBX has been compromised and starts making a lot of calls to a destination, Fraud Traffic Profiles catches it (as it already does),

but as well as sending an email, also either lowers the credit limit, or prohibits access to destinations in that Fraud Traffic Profile.

This would mean no manual intervention is needed to stop the toll fraud.

Leslie:

Make feature to assign SIM to customer, without having accounts.

Like with DIDs.

You can assign DID to customer, but not create account yet.

With SIM cards, you can't.

Would be nice to have.

Send customer SIM cards, he can use them later.

Leslie:

SIM Card Inventory

Add a STATUS = RESERVED

Leslie:

Is it possible to optimize processing of send_notification task to include superusers in addition to users that are currently in the env?

In our case there were notifications about quarantining account which means fraud activity and such notifications are quite critical for customers (and limitation is not obvious for them).

Leslie:

Add possibility of CALL FROM VENDOR > AA > QUEUE > HG > EXT > FORWARDED TO VOICEMAIL or AA

Our customers are true end users. Turning on the light switch is challenging for them, let alone configuring an AA.

Remember the answering machines with a tape, from the 80s? You can turn it on and off, whenever you want. Customers want THIS.

Leslie:

Possibility of receiving SMS and converting them into email, like fax-to-email.

Leslie:

Include in future releases a new version (1.0.5.29) of the firmware for Grandstream GXP2140,

where there is added option "Disable Active MPK Page" in CPE Profiles.

Dale:

Please could you consider adding the ability to assign DID numbers to resellers from the main DID Inventory page, so that blocks of numbers can

be made available for selected Resellers without other Resellers being able to view or access them.

Leslie:

Should do the same as CUSTOMER>WEB SELFCARE>LOGIN BUTTON

By default, this goes to  https://porta.rgtn.com:8444/

We have our own self-care.

Would be nice if configurator has a definable URL, so an admin can define a link to a custom login, like we have.

Go to our portaweb, customers overview page.

See the red button? Click it.

See screenshot Add “SELFCARE”

Mukit:

We would like to have a search option to find calls to/from a certain number on the customer self-care dashboard.

This will enable the customer to find the CDR of the specific number more easily.

Leslie:

I would like to create destinations when using email tariff import.

Leslie:

We now have our own LDAP server for a “phonebook” service.

So, the LDAP stores info for the user, with all his contacts.

Then, all his phones, have the same (synced) phonebook.

Does porta also offer this service, natively?

Leslie:
Is it possible to have the email tariff importer, import ONLY the rates I want?

So, I can setup a unique key for email import, based on filename?

Will that work?

Leslie:
Please consider expanding this feature by:
Generating NORMAL invoices, with NORMAL amount.
Not ZERO amount.
But, hide XDRs from customer.
This way, billing COLLECTION can be done externally, but INVOICING can be
done on the porta side.

Leslie:
> "^NULL" is a special internal account that is used for the notifications. Its usage
  is hard-coded and can't be changed in the configuration.

So much better if this would be a proper "from" (configurable in configurator?)

Oleg:

User Story: Sometimes it becomes important to apply translation rules on the account level to CLI only,

without changing CLD, or apply different translation rules for CLI and for CLD.
The reason for this is that CLI arrives from customers (represented by accounts whose ID = IP address of the softswitch) in the wrong format and needs to be translated. This will allow to transfer CLI in proper format in outgoing calls.
Since this is a customer-specific requirement, usage of CLI translation rule on connections is not a suitable solution.
Currently translation rules which are done on the account level (using Dialing Rules Wizard) for CLI translation,

applied to CLD as well, but it should apply for CLI only.

Use case: Converting CLI on the account level

Roles: Admin

Preconditions: There is account with ID 192.50.226.15. The CLI translation is enabled for it on the account level.

Scenario:
1. Admin opens settings of account 192.50.226.15 and sets the outgoing translation rule for CLI

 which would append a leading '1' to the caller number.
2. When an authorized call comes from 192.50.226.15 (CLI:6465919971, CLD:3225884287),

the outgoing translation rule is applied to the CLI and '6465919971' is translated to '16465919971'.
3. The original CLD 3225884287 should remains the same.

Leslie:

The following scenario:

There 135 emergency services area’s in the country.

So for every state/province there is one or more.

Each emergency call center, covers a specific geographic area.

It is useless to make a call to a 911-center in the west of the country,

While customer is in the east side of the country.

Before ambulance is there, the guy is already dead...

This is why there are area’s.

So, we have configured it like this:

+--------+---------+---------------+------------------+------+

| i_unit | name    | i_parent_unit | emergency_number | path |

+--------+---------+---------------+------------------+------+

|      1 | 01      |          NULL | 31141201112      | /    |

|      2 | 02      |          NULL | 31141202112      | /    |

[etc...]

HOWEVER, it is possible, there is no specific geographic area.

Think of NON GEOGRAPHIC (voip) numbers, or MOBILE numbers.

What happens in that case, is that it goes to a CENTRAL call center, which first asks you for your city.

They then manually transfer you.

Now, the desired feature:

When you enable E911 on an account, but DO NOT specify zip, state, baddr1, or whatever, it will tell you:

“no valid address provided, E911 disabled”.

This is not desired.

Why? Cause, it WOULD make sense (see above reason) to route calls to E911-zone (zip/baddr1/etc)

to a specific  number.

So, I created this SQL record:

|     27 |         |          NULL | 3170222000       | /    |

So, a NULL value, will route to 3170222000.

We tested this, by resetting SUBSCRIBER value to NULL manually in SQL.

When I then make a call, it matches NULL, finds #27, calls 3170222000

However, portaweb prevents me to save NULL values.

It is requested that you make a configurator value, that allows E911 enabling WITHOUT

address verification, so NULL-routing becomes possible.

Attached is a log

Leslie:

Please make portaweb support uploading of XLSx tariff files. Porta web and email import.

Fritz:

Is there anything in your pipeline regarding two-factor authentication for
the admin interface, config interface and/or ssh user?
Google Authenticator seems to be quite easy and suitable to use,
implementation also should not be a too big deal.

https://en.wikipedia.org/wiki/Google_Authenticator
https://www.linux.com/blog/securing-ssh-two-factor-authentication-using-google-authenticator
Do you have any plans to integrate and support this in the next future?

Francois:

A customer requires a possibility of showing extension number when the call is sent back to the transferor,

so that the transferor knows not only an initial caller's number but an extension to which the call was transferred as well.

Currently only an initial caller's number is displayed in this case.

Leslie:

It would make sense to have a DECLINE feature under INVOICES UNDER REVIEW, if you also have an ACCEPT feature.

Leslie:

It would be nice if we can ALSO storage compressed logs, when they are deleted from Elastics.
e.g.: store in DB for 7 days, but keep compressed (for legal reasons) for 60 days thereafter.

Leslie:

What if we want to use this customer class for all customers, but we want to allow 21 days payment term just  for ONE customer?

Can we override this value, under customer?

See Attachment_2

Alexey:

Is  it possible to change "403 max-in limit reached" to "486 Busy here" in
the code? Logically it will be more correctly, IMHO.

Leslie:

You have made a “protection” against deleting Tariffs (and vendors was never possible).

This is not desired. It creates a mess in the system.

Please reconsider your logic.

The protection is to prevent issues on XDR rerating. When tariff (or vendor, or destination, see ticket) not there, it will createreratingissues.

Proposalis that, when tariff deleted, XDRreratingshould SKIP the CDR in question. This information should be included in the report, sent by email.

With this logic, we can also dodeleteof vendor, sosystemcan be clean and not polluted.

Francois:

I would like the following method to be added to the API get_ua_profile_list which should return a list of UA profiles (including the i_ua_type & ua_profile_id)

The reason for this is currently to use the add_ua method these 2id’sare required.

CurrentlyI have to get the values from the database. I am using this to bulk add IP Devices.