2016 year

Luca:

We have several customers with call center or Organization with offices and incoming calls to main number are transferred to Hunt Group and also call is sent to several phones/user.

When a user answer the call, all the other member of the HG receive on the phone alert of missed call.

As you can imagine, this is not a correct information, call was answered, all the other member, viewing a missed call, don't need to call back the number. Only direct call to the user have to be notified as missed calls, and only if any member of the HG don't answer the call is really missed and must be notified as missed

The calls to the hunt-group are organized in the following way now:

1) 'INVITE' messages are sent to all members of the HG

2) When one of members picks up the phone, all other call requests are cancelled by 'CANCEL' SIP messages

3) As soon as UAs receive CANCEL message, they show missed calls (because this particular UA didn't answer it).

In order to inform UA that the call was answered elsewhere PortaSwitch should send some additional headers (not mandatory in RFC) in the CANCEL request. So, that feature is rlevant for every UA model, which handles the incoming calls by pre-defined scheme of rules.

Currently PortaSwitch uses standard CANCEL method in accordance with RFC3261. However, requested functionality can be implemented via FR procedure (on the paid basis) or via wish list.

Smrita:

As an ISP, it is the core of the business to ensure you have a clear picture of the status of your customers that are expiring in x no. of days. Currently, we can only distinguish if a customer is active or inactive.
However a mechanism that will help us see the customers who are expiring will help us ensure we do all possible to make sure the customer stays with us while they're active rather than trying to convince them while they are and stay inactive.
For eg, If we are able to view customers that are
expiring in 7 days, 14 days 1 month
and
customers that have
expired in 7 days, 14 days, 1 month, 2 month, 3 month, 4 month, 6 month up till 12 months.
This will help us take different approaches to customers as per their grievances and decide on loyalty bonus. Similarly, it will also give us a chance of forecasting and managing customer relations to ensure they are frequenty questioned and asked about their service uptime while they are with us before they expire.
Bringing such features in the new releases will strengthen our commitment and use of portabilling for this platform.

Fritz:

Token based payment processing does not remove token on payment processor side when client want's his saved credit card data to be removed.

Current implementation by Portaone only removes the token-based record from the credit_cards table but does not initiate the removal of the saved token on payment processor side.

This is rather a lack of implementation of credit card removal (in terms of token based payments) than a feature request.

Also keep in mind that some payment processors charge by the amount of saved tokens (e.g. first 1000 tokens are free, then bundles of 500 get charged).

Thus its relevant that if the clients removes the saved credit card from porta-billing that the token removal also gets initiated on the payment processor side.

Otherwise the token keeps valid on payment processor side and sum up unnecessary (also it could lead to a security gap).

Further the customer assumes that when he removes his saved credit card its data will be fully removed and deleted (and not only its link).

BigRed:

We create products, and limit certain customer classes to have access to specific products only. We have some nasty custom code for it now.

The column porta is a patch so our employees only see this in porta-web, selfcare is for our custom selfcare.

However, this is not completely possible with Product Groups.

Reason: for example “ADSL”. It is possible Customer Class 1 uses ADSL, but also Class 2.

With a dropdown, it is limited to JUST ONE. So, if I assign it to Class 1, I can not assign the same product to ALSO another one.

> Correct. There is a predefined list of business models, which cannot

> be modified. The same is for account/ product roles.

Please consider making this more dynamic.

Because it is so limited now, it becomes useless rather quickly.

It would be nicer if, especially on the product level, it is more flexible.

And, not to use dropdowns (only 1 combination possible), but checkboxes.

Then, you can even link a product to multiple businesscases.

Please see my first email for more details.

Perhaps you can pass this on to your developers as a suggestion?

BigRed:

It would be nice to have a deactivation charge (static, not to be confused to CANCELLATION PENALTY) for when a subscription ends.

Example: we pay EUR25 when we cancel a DSL line. We charge the customer EUR25 also.

So, when the contract is for 1 year, and the customer cancels after 2 years, there is NO cancellation penalty.

But EITHER WAY, I still want to charge them EUR25. So, it is the exact oposite of an activation charge.

BigRed:

Since MR45, a lot of improvements have been made for DIDs.

I like that. However, charging and billing, some improvements were made, but there are still some limitations.

It would be nice to be able to easily manage DID charges per individual number.

Like we can with subscriptions of an account.

e.g. discount rate for that specific DID, start date (charging), finish date (charging), etc.

Also, for subscriptions, you can configure minimum contract duration. When the subscription is cancelled within that period, the user is charged the full amount.

DIDs do not offer this, which is a bummer.

in short: take a closer look to subscription charging. See what you can add to DID billing.

BigRed:

DID Groups, you can now not upload any data with a CSV.

This is possible with DIDs, and other stuff.

Please make it possible for DID Groups also, which will make it much easier to manage!

Dale:

We get a lot of requests from customer who want the ability for callers to to return to the operator if a call reaches the users mailbox. So the users records his/her personal greeting with the option to stay on the line to leave a message or to dial 0 to return to the operator.

It would be nice if the mailbox had a "break out setting" where you could select a digit that is dialed and a destination that the call is sent to.

We used to be able to achieve this by setting the mode of the mailbox to AA, but this changed when the AA changed in MR52 or somewhere around there.

Andre:

Current rerating done by Customer/Vendor/Reseller and by tariff. Can you please include a feature to select a specific destination(s) or for all destinations?

Business case:

A single rate on a tariff is incorrect. All other rates are fine. To rerate a big customer for this single incorrect tariff, all the calls will be rerated and not only for the incorrect destination. I am currently having to rerate about 5 destinations for a large customer and it runs for more than 24 hours.

Intercloud:

Currently we are using call handling for many accounts.It will be more easier if we applied call handing for 'Customer'.Suppose "ABC" is a corporate customer having 500 extensions.

All extensions are registered on portaone under NAT by same public IP.It is difficult to apply call handling for all extensions manually.For this situation it will be a best solution if call handling can be applied for customer.

PortaONE:

I assume you refer to "call barring", since call handling (using different auth methods such as IP authentication) does not really apply to extensions within IP Centrex.

Call barring configuration on the customer level (to be shared by multiple extensions) already has been implemented in MR56-57.

Aleksei Shch.:

If user has insufficient balance to make a call for direction, need to return 403 Insufficient Balance (or something else).

It's done for "max-in limit reached" already.

Intercloud:

We would like to have the auto-provision feature for the following IP phone sets :

1) Grand Stream GXP 1625

2) ES 220 PN model

PortaONE:

Since there are many different vendors / models of IP phones - addition of new provisioning modules is typically handled via feature request (FR). Please open FR with your support team.

Worldcall: 

Our customer is interested in the implementation of the voicemail box on the customers' level - all customers accounts have the same mailbox accessible form the UA assigned to the account of this customer. Several accounts of the same customer - used the same mailbox.

francoism: 

Currently only 1 full username per Reseller is allowed

Resellers therefore cannot trace who within their company made configuration changes.

Would it be possible to create a "Full" access Callcentre user as the Reseller. (That has the same accessibility as the Main User of the Reseller)

Bravo: 

This feature allows account holder especially pre-paid customers to make Direct Calls to International destinations by dialing a local access number. This is a hybrid of the existing speed dial feature, just that this time the speed dial is at the access number level

Here is how it works:

1. The Admin or Customer Account reserve a set of local access numbers in its owner batch inventory, maybe between 6-10 access numbers

2. The Customer informs its pre-paid account holders of these special access numbers

3. When the account holder dials these access numbers for the 1st time, they will be prompted to dial the destination number they wish to assign to this local access number

4. The system will save and map the account holder callerID to the international number

5. The account holder will either get an sms message: "From now on just dial [XXX-XXX-XXXX] to connect to [011XXXXXXXXXX] immediately!" or get an automated message saying same message as confirmation that the mapping was sucessful

6. Going forward when ever the account dials the access number, it will automatically connect to the destination

7. Multiple accounts or callerID can use the same access number, but the destination numbers will vary

Andre J.:

We have tested your CDR import functionality in an effort to move Broadsoft CDR billing from MIND Billing to PortaBilling.

Due to the amount of usable fields in the Broadsoft CDR's, we would like to store some of these fields in the CDR tables. This would really be helpful if someone would like to store custom values in the CDR's.

Our requirement would be to store, as an example, a pin number and codec used when the Broadsoft CDR is imported.

The possibility of having 5 custom fields in the CDR's will be great.

PortaONE:

There is actually already an "auxiliary CDR info" table, which allows storing additional attributes. but at this moment this is a "static" list, extended by PortaOne.

I suggest to open a feature request to discuss whether it will be more efficient to add new attributes there (e.g. "codec" seem to be a good fit) or to allow dynamic definition of the attributes. Plus we need to extend CDR importer to pass the values to the rating engine.