2018 year

Please implement a possibility of modifying CLi based on dialed pattern.
For example, if customer is making call to US then it will go US number and if customer makes UK call 
then CLI should go as UK number.

Whenever create a new customer account or existing account, block are unblock we should receive notification 
or alerts from admin email .

I'd like the option to be able to clone Routing Plans.

Currently when we need to add a custom Routing Plan for a customer we have to copy all the existing route overrides we have for the default plan by hand. This takes a long time.

The GDRP is to protect customer data.

Any holder of information, must report data leaks to the government.

Fines are HUGE.

Customers are always worried that their data is leaked. Even if it is just a company name and an email address, a leak is a leak.

It is considered a very serious thing here.

We currently use the SIP PASSWORD salting.

So, h323_password = abc123 becomes h323_password = HGT$%Y%$^

Totally useless to hackers.

It would be nice to do this for porta-billing.Customers (etc) as well.

So in case there IS a leak, the data gathered is useless to hackers.

Is it also possible to encrypt customer info, such as address info (baddr, etc)?

Currently, the dial directory requires you to upload a separate recording for the name of the extension, I propose the two following feature additions:
1. If one exists, take the “Recorded Name” recording from the accounts UM box and associate it with the extension assign to that accounts UM box dial directory recording
2. Text to speech - if option 1 has not been complete, use Asterisks (or Amazon Polly / Google TTS) to have Porta say the name of the extension
3. Existing functionality - keep the existing functionality in case it is needed

I’m writing to you cause we are facing an issue with our Voice Call vendors . Their device (Huawei MGCF) does not support (DTMF RFC-2833). 

So my suggestion is  PortaOne System should has DTMF types conversion that enables us to convert between DTMF types (Like RFC-2833 to Inband or vice versa)

in your Future versions of the system.

“Without using an IVR, the Client needs to have a message played to the caller before connection.

For example, the caller calls, the phone rings, the phone gets answered  with ' Hello and welcome'

and than the phone on the client side actually connects and rings.

It is a static message.”

This message could then be used as a greeting to the caller.

When making a manual credit, it is not possible to choose the "subscriptions" service.
When we want to manually credit a subscription, it would be beneficial if the credit CDR used the same service as the charge. This ability would make a lot of reports

(internal and to government)more accurate. When PortaBilling itself credits prepaid subscriptions that are terminated, it uses the subscription service.

We are looking to have NMS for our system mainly to monitor the below parameter,

1. Active Call
2. ASR and ACD
3. Top Destination
4. Top accounts utilization
5. Alerting for the above

I've created a ticket about a feature I wish to have it in the new versions of PortaOne System. So please see my conversation with your support team in the ticket

([PortaOne #631112] Send IM using APIs) to know all about the feature I want.

In addition: please consider following examples:
Example 1:
-------------
1- Our Operations Center agents are creating tickets (Example: Agent#1 will create ticket#234. Summary of ticket#234 is: "LTE MME#5 is Down").
2- Agent#1 will assign ticket#234 to "LTE network - MME Administrators" (Let us say: Admin#6, Admin#7, and Admin#8).
3- Our ticketing system can request API methods. So the ticketing system will request some API methods to our PortaOne system to send the summery

of ticket#234 to Admin#6, Admin#7, and Admin#8 numbers through IM.

4- Admins will receive IMs and will quickly work on the damaged network device.

Example 2:
-------------
1- One of the local supermarkets makes a discount on some of the goods they have. They will send us the advertisements.
2- We will send the advertisements about the discounts through IM to all of our end-users through API.

Scenario:

On reception we have 2 phones, for example ext, 21 and 22. All calls from PSTN should dial to queue Reception where ext. 21 and 22 are agents.

All is easy, but in situation when one from agents is busy (during call), all calls to queue in that time should get busy signal and disconnected.

Scenario:

A (potential)  client calls and the person answering the phone hears a short message before the connection is completed.

This is used for marketing efforts and will play the uploaded mp3, for example, a message like 'the caller is coming from Google'.

the scenario would be as follows:

1) The number was connected to an ad, campaign or the likes and would be specific for that campaign at that time.

2) The caller dials the number and the number forwards to another number from within Porta.

3) The 2nd number answers and hears the message played before the connection/call is actually transferred.

Does that all make sense?

And I think this would be the easiest, clearest and least intrusive way to get this implemented.

As alternative, I guess it could also be that the calling number would be recognized by the Call Screening option and therefore plays the message

before the connection is made but I think that would be more difficult to manage and  much less clear.

The Gigaset N510 Pro is the professional version of the C610.

The C610 provisioning actually works for N510, so there is not a lot to do.

However, we request:

-          Advanced network settings

o   VLAN settings

o   DHCP or static IP config

-          SIP transport UDP/TCP

-          Language settings

-          LDAP settings

-          Admin password

Details can be found here:

https://teamwork.gigaset.com/gigawiki/display/GPPPO/N510+XML+provisioning+parameters

The C610 CPE profile currently does not support entries for these.

While, they CAN be configured as you can see.

I see that other phones, such as Grandstream CPE provisioning, DO support values like this.

When you get a voicemail, it is possible to receive EMAIL *NOTIFICATION* about this.

Is it also possible to get an SMS?

I’d like the option to be able to log in to different environments using SOAP.

Currently when you perform a SOAP login, the environment that will be used for all the subsequent SOAP requests is the same one the user last logged in as.

I’d like an extra parameter to be added to the login request which specifies which Environment subsequent SOAP requests should use.

This is required because have some very complex scripts to provision and modify accounts, and too many errors are being made because users are previously logged into the wrong environment.

With many environments on different Porta installations it isn't practical to have a separate login for each one.

The termination partner has informed about a new charging model due to changed market conditions. Thus a provider will apply a higher termination rate based on a caller number (EEA or non-EEA)

for calls terminated to certain countries and mobile phones.

That's why a support for charging based on CLI and CLD is required, which will ensure correct billing for calls.

Use cases are in the attachment: PortaOne_EEA.docx

Spending plan usage is not checked during a call, so it’s very easy to exceed using multiple calls.

It also can’t be influenced by overdraft protection.

Is it possible to STACK VDPs?

So, I have customer A who orders a product and wants 100 free minutes

And I have customer B who orders the same product, but pays for 200 free minutes.

I don't want tons of different products and different VDPs.

Instead, I want one product, and apply multiple VDPs.

So, I create a package 100 free minutes.

For customer A, I apply it once.

For customer B, I apply it twice,

We have some custom modules.

These modules are applications, such as: 12331 and 12330 (turn voicemail on/off), etc.

We now have to patch the original porta file:

ivr_manager/UmConf.py

we need to do this, in order to load our modules.

It would be much nicer if you make this more dynamic in future releases.

This offers us the possibility to create extra modules, but not touch original porta code.

Before, we had lots of custom code. We abandoned this all. However, these modules we can not abandon.

If you can include this “include” fix, we do not have to modify original porta files. We can just simply ADD new files on our own...

I'd like to add a feature request - Daily Spending Plans to work the same way as Credit Limits. Specifically adding Dynamic Re-Authorisation of calls / Fund locking to Daily Spending Plans

like in Credit Limits to ensure a Daily Spending Plan cannot be exceeded.

At the moment we use Dynamic Re-Authorisation to ensure customers never exceeded their Credit Limits in the event of toll fraud scenarios.
We also use Daily Spending Plans to act as a daily Credit Limit. However, in its current configuration, the Daily Spending Plans do not dynamically authorise the calls, so it's only

charged / deducted when the call is hung up. 

In a toll-fraud scenario this leads to an expectation that the Daily Spend cannot be exceeded when it very easily can and in our experience has been by hundreds of dollars.

During authorisation on Call handling, Is it possible to check diversion header in spite of CLI if a diversion header exitsin Invite message?

Porta is able to check only CLI with related IP address and accepts account without registration if a call handling rule exists.

However sometimes customer sends forwarded calls with associated account, that is presented in diversion header.

So it becomes necessary to check diversion header in spite of CLI in UR for such calls.  

That should be good to authorise the call in respect to CLI in diversion header if diversion header exists.

Example:

I have account 999000123 on the platform.

Account 123000999, on the same env, calls 999000123. This is an onnet call.

However, number 999000123 is not ported yet.

Thus, in this case, it would loop internally, connecting nowhere (UA not connected yet).

In order to prevent that, I want a fair over overflow to a PSTN vendor.

In respect to customer demantionson display screen on IP phones, It should be good to use extension id and extension name for auto provision profiles. Most of the customers are asking

for displaying extension information on the phones in spite of subscriber information. Thanks to Portaone customers are able to manage their cloud PBX functionality via web page.

They are able to change extension definitions very quick when an employee changes his/her department or new employee starts in the company. However, customers are asking

if the display options are also able to be changed when the customer edits the extension information via portaone.

This is why we are wondering if it is possible to add such a feature that  provides operator to create a profile that can use extension id and extension name , so the customers  ip

phones are able to be changed in respect to extensions information change.

Use case: Two-Dimension Tariffs

Roles: Administrator

User Story: We require billing on CLI and CLD numbers. Calls originating from international CLI need to billed differently to Calls Originated Locally.

Preconditions: Calls routing to Vendors Setup

Scenario:

Sequence of actions or events, for instance:

• So, if a call to 44555777999 originates from 27555444000, the customer will be charged according to rate 27 + the 44 = ZAR X/min as it is originating from 27 the rate will be R0.00

• If a call to 44555777999 originates from 7888000333, the customer will be charged according to rate 788 + 44 = ZAR Y/min. here the originating rate is R3.00

• This will need to be applied to all our vendors as they have all enabled this requirement.

• The Vendor price will depend on both the CLI and the CLD

• The customer will need to be charged for the CLI and CLD charge.

• Customers already doing this need their rates re-calculated to reflect the CLI charge as well as the CLD charge.

Check-list:

• Our Vendors have notified us that they will be routing all calls originating International CLU to be routed via their International Routers and charged accordingly.

• The end user is not getting billed for using the International CLI so we need to pass this cost on the customer

• All Calls with a CLInota South African number will have this applied to and charged as International Originating

• Calls made with an International CLI will be charged with the CLI and CLD price added and charged to the customers account.