2015 year

Synety:

We have an internal UA that does "call control" functions. This provides us with things like click to call, transfers from software running on the user's computer, etc.

We have set up a call handing rule for this UA that allows it to authenticate by PAID. This means that it can bill calls that it creates to the correct customer's account, and also set the right CLI. The account number is sent in PAID and the CLI in From.

This is, however, bound by the account's CLI override rules. If the account is not allowed to override CLI, the internal UA cannot override CLI.

We would like to request a call handling rule, service policy, or similar that will allow certain UAs to override the CLI even when the account does not permit this.

Synety:

The PortaOne E-911 functionality sends addresses to Intrado, registered against the account's telephone number. When the 911 call is placed, Intrado looks up the address from the CLI and routes the call to the relevant location. If the address lookup fails, Intrado themselves handle the call and the supplier (us) are charged $75.

In a recent ticket, Andrey confirmed that "There is no specific CLI handling in case of using E911 functionality in our system yet".

This means that if an account has a CLI override, E-911 will not work. Most of our customers override CLI with a general company number, and as such cannot use E-911 functionality.

This is a concern in the event that someone makes a silent call to 911. In this instance, Intrado will call the supplier (us) to look up the address. This introduces a large delay in the dispatch of the emergency services and will be potentially life threatening.

In my eyes, the E-911 functionality in PortaOne is not fit for purpose as it is not compatible with a widely used feature. That said, I am requesting CLI override support be added to E-911 as a new feature.

I can see this being best implemented as a service policy option. The service policy could be as simple as a boolean flag that causes the CLI sent, for connections using that service policy, to always be the account number. Other suggestions welcome.

Synety:

We need to build an inbound tariff that is based on both CLI and CLD.

Example:

Receiving a call to a destination starts with ‘44800’ from a number starts with ‘4411’ will cost our customer .06 PPM.

Receiving a call to a destination starts with ‘44800’ from a number starts with ‘447’ will cost our customer .09 PPM.

Would such a feature be possible?

PortaONE:

I highly doubt a generic "rating based on all possible combinations of CLI / CLD" would be practical, since then the amount of possible rates grows exponentially with the increase of prefixes. E.g. even if you have only 20 domestic phone prefixes - you end up with 20 * 20 = 400 combinations to be filled in manually. For 100 domestic prefixes it would be 10,000!

Based on the example you provided - it seems that you need "rate calls to toll-free numbers based on CLI" - and this is of course supported. You need a "from vendor" connection(s) to identify toll-free calls and assign a separate rating code (e.g. "INCOMING-800") to those. Then in product configuration you would define that for INCOMING-800 code you rated based on CLI. So now instead of 400 rates you only need to define 40 (20 for regular incoming calls and 20 for toll-free).

Grzegorz K.:

One of our customers would like to have the following two features added to the Auto Attendant screen:

- an ability to adjust the timeout for user input (e.g. when selecting an option from the menu);

- an ability to play an audio file while waiting for user input (but after the announcement listing the available menu options has finished playing).

Can these features be added?

PortaONE:

Of course they can! Open an feature request - and they most likely will be added in the next available maintenance release in just 2-3 months.

Grzegorz K.::

At the moment, Call Screening allows you to choose a different answering mode depending on the CLI. But the forward destinations cannot be selected based on the CLI; you can only select whether to forward the call or not. Can such a functionality be added?
Mike H:

I like this, to be able to define the forward destinations for the call screened route independently from the accounts standard forwarding list would be a very powerful feature indeed!

Rob:

I'll second that. Would be a really useful feature to have.

Aleksei Shch.:

We had the task of separating the routes according to the source. The topology for the convenience of understanding: Vendors: FT, HK, NY. Proxy-servers in the same regions. It is necessary that if the call came from the proxy in HK, then send the call to the vendor's connection in HK. If the call came from the proxy server in NY, then send it to the vendor's connection in NY. And etc. All other calls by default sent to the FT.

Is this possible to achieve?

PortaONE:

Yes, routing considering POP is supported - the description should be included into the "Residential VoIP services" handbook with the next update.

Intercloud:

Roles: Involved parties, for example: Account Self-care user

Preconditions: Actions to be performed beforehand,

Consider following scenario:

Account 50019999 is configured at Portaone.

This account owner creates three (or more) conference Bridges using Account Self Care portal or Porta API.

Conference Bridges Name:

1. Red

2. Green

3. Blue

Now consider 01730330021 (Moderator), 01730330022, 01730330023 Joined at Conference Bridge “Red”

Our Requirements:

Following actions or events needs to be supported from PortaOne:

1. We need Account Self care portal / API Function to monitor who is currently participating at conference bridge “Red”

Sample Expected Monitoring Output:

Participant Role Joining Time Quit Time

01730330021 Moderator 10:00 continue

01730330022 User 10:05 continue

01730330023 user 10:06 10:08

1. Call Details Report/ CDR of Conference Bridge call needs to visible from Account self-care portal / similar result from API Functions.

2. Conference Moderator can able to kick off any Participant from conference using Account Self Care Portal or through relevant API.

3. Conference Moderator can able to mute any Participant from conference using Account Self Care Portal or through relevant API.

Stefano C.:

to better comply with the Italian privacy laws regarding data retention of telephone CDRs we need that Porta-Billing is more adherent to the keep_month and keep_month_failed variables set via Porta-Config regarding the current delay of archiving.
While discussing with Porta-One support regarding this issue, we understood the logic behind the data retention process, quicky described here:
Every CDR (failed or normal) is kept online (CDR tables) until is moved to CSV files.



Even if this seems good and reasonable, it is not for the Italian privacy law. In fact the law imposes a maximum of 6 months of retention for regular calls and a maximum of 1 month of retention for unsuccessful calls; for the sake of accuracy the italian text of the law exactly states "unaswered calls" that in the dialect of Porta-Billing we can translate with "failed calls" that means the CDR_Failed* tables data and the process that moves that data to the CSV files.
Now, independently from the interpretation of the law, it seems that the legislator can admit an unspecified amount of "technical time" that is tolerated for removal.
Conversely the law states that you have a timeframe of 30 days to document the removal of CDRs from the system.
This is the specific webpage of the legislator regarding the privacy law.
http://www.garanteprivacy.it/web/guest/hom.../docweb/1502599
Today we are not aware of how much "technical time" is tolerated.
This is the excerpt from the aformentioned law:

That said, the feature we would like to see in new versions of Porta-Billing is a mechanism that guarantees the non-existence of CDRs after the]keep_mont] periods...
or at least, at the cost of performance degradation, a config switch to choose the data partition groping in days instead of weeks. This way the delay would be at maximum 2 days, that is much less than 14 days when discussing with legal authorities).

PortaONE:

Since this is a case, specific to your local environment - I believe it is better to open a feature request.

Stefano C.:

We asked clarifications to the legislator and we are waiting for an official reply.

In the meantime my company has currently decided to open a feature wishlist request because we know that we are not alone in Italy using Porta-Billing and because other Countries may pose such limitations, thus, having a more flexible Porta-Billing retention mechanism would be potentially good not only for our environment.

Brian:

It seems reasonable that the CDR retention feature be more customizable to fit all local laws and preferences.

Is_support:

Currently LNP can be either enabled or disabled globally. Such configuration is pretty useless in real business because some vendors bill by LNP numbers and other vendors do not use LNP and bill by actually called CLD. Therefore it causes billing discrepancy with either the first or second group of vendors (in addition to incorrect LCR). Ideally, the solution would be:

- check LNP

- if the number is not ported, change nothing in the current algorithm and skip further steps

- find all routes to the LNP destination from vendors which support LNP

- find all routes to the CLD destination from vendors which do NOT support LNP

- combine results

- apply standard routing algorithms (preferences, costs, etc.)

- on the billing stage (stop accounting) the system should figure out which route was used and bill the vendor and the customer according to either LNP or CLD number.

You can refer to the ticket #446816.

Brian:

Looks interesting. I don't know if I agree with the exact flow, but I agree that the LRN functionality should be looked at for effectiveness.

Brian:

For statistical purposes, we use the subscriber_ip field in porta-billing.CDR_Accoutns table. It seems reasonable that you could add the Client's User Agent. That way we can see the effectiveness and/or problems associated to a particular UAC. PortaSIP already has this information, and registrations actually have the temporal information stored in the porta-sip.locations table. We believe that other customers of PortaSwitch would find it useful as well.

Jouk:

We would like to send a text message when receiving a voice mail. We also have (GSM)mobile devices as SIP accounts on our platform.

It is common that you can set to receive a voice mail and then send a text message

PortaONE:

Now that we have PortaSIP of capable of interfacing with virtually any SMS aggregator or mobile operator via SMPP it is very easy. If you open a feature request it can be implemented in one of the upcoming releases within a few months.

Rob:

Could I request the support for recall of transferred calls.

Currently if a user performs a blind transfer to an unavailable destination (for instance a busy destination which is set to ring only and call waiting disabled) the call is dropped.

This has always been a basic feature in the PBX environment and it is reasonable to expect it to be supported in Porta Switch.

Grzegorz K.:

One of our custoemrs would like to use one time passwords as a means of added security for accessing the Admin web interface. Their vision is that a user receives a one time password in a text message or an email message, and then has to enter both his web interface password and the one time password in order to be able to log in.

Is this possible to achieve?

Mike H.:

We have had a number of resellers enquiring about the possibility of Hot Desking which might be of interest to the development team to consider.

The general idea is to have a simple feature code whereby a user could dial a "log on" code along with an AccountID and pin code which effectively sets up the account of the hot desk phone they are dialling from, with the incoming and outgoing service features, DDI alias (or forward their original accounts alias to the hotdesk phone) and call barring levels of their own account. When finished they dial a simple log off code which removes the settings and leaves the hot desk phone in a state where it has no ability to be used other than to log on with another account?
It might mean that a pre-requisite of a hot desk user would be that they have to have a virtual account for every user in order to hold their details and be able to pull over to the physical hotdesk phone when logged in.
It may also require some mechanism to allow the hotdesk phone to automatically reset after a certain time (configurable idle time?)
Something to think about?

Mike H.:

I have been talking to a few suppliers looking to develop solutions which require live data and call control functionality. The requirements below seem to be the most common. It would be useful to know if P1 are considering such enhancments to the API to cover call control and live monitoring as it would be extremely useful?
Call monitoring – to see the details of live calls as they happen, with CLI, DDI, Call Id (for controlling), Extension, etc.
Call Control: Answer, Hangup, MakeCall, Hold, Transfer, Pick up, Deflect. We need events so know state of the a call and actions so we can control the state (or actions of the handset]

Mike H.:

Can Portaone consider adding support for "302 Moved Temporary" with Call Forking enabled.

This would allow call forwarding, setup on an endpoint device, as long as endpoint redirection is enabled on their account.

PortaONE:

The simult. registrations (forking) is suppored in the new PortaSIP cluster and 302 redirect has been supported for a long time; so these two should work together - please contact support for assistance if something is off..

The "old" forking (within a single PortaSIP server) is deprecated anyway

Mike H.:

I originally opened a ticket on this one and was advised to put in an FR or open as a wishlist request. But they didn't mention it was because we don't have the cluster solution. For ref the ticket was #442789.

"The "old" forking (within a single PortaSIP server) is deprecated anyway"

So does this mean the feature will be withdrawn on a single sip server at some time in the future?

Is_support:

Please consider such a possibility.
One instance is already not sufficient for our customers.

PortaONE:

I suggest to open a feature request and discuss your specific requirements: e.g. do you need more total conversion performance, or this is because of some regulations in case of different countries, etc.

Is_support:

Please check the ticket #425021. Do we need anything else? Should we discuss it there or here?

Rob:

There is a problem with the PortaSwitch implementation of huntgroup ringing which is causing our resellers a big headache.
At the moment, a huntgroup call uses the accounts’ ringing timer as part of the call processing.
Whichever is the shortest, the accounts ringing timer or the huntgroup ringing timer, will be the timer which affects ringing of the extension in the hunt group.
If the huntstop flag is checked the call will not forward but, in the case of a “Simultaneous Hunt Sequence”, will stop ringing when the shortest timer is reached. You could set the ringing time of an extension to be 60 seconds, but the phone could stop ringing after 10 seconds.
With an “Order Hunt Sequence” the call is progressed to the next member in the list if the accounts ringing timer is shorter than the extension ringing time.
This does not seem logical.
I propose huntgroup ringing should not use the accounts ringing timer at all, but use the hunt group ringing time only.
Therefore with the huntstop flag set a huntgroup call would ring the extension as defined by the hunt group ringing time.
With the huntstop flag not set the huntgroup call would use the huntgroup ringing timer to progress the call to the accounts forward/voicemail destination as determined by the account set up.
Internal/DDI calls can then set to forward independently depending on the users wishes.
Does any one else agree?

Mike H.:

Seconded
Calls delivered to Huntgroups should only use the ring stop timers set against the members in the group.

Dale:
Try setting “Routing.LimitForwardExpiry” to “yes” on Porta Configurator

Rob:

We have tried this, but this breaks the delayed ringing timer in the hunt group.
In this case when a hunt group extension has a ringing time set for a time less than the accounts ringing time, the account will continue past the hunt group ringing time until the account ring timeout expires.
Another reason to revisit the timeout implementation, I think.

Pavel B.:

Current Porta GUI is very limited in functionality and the new interface design, which we can find in Products now is not improving things much.
These GUI features are standard for modern interfaces, especially for those systems, which have such rich set of functionalities like Porta. Also, note that we are aware of all features Porta GUI currently provides, like Import/Export for tariffs, Import for DIDs, Account Generation, etc. But all these features are either very limited in their functionality or simply don’t exist on most of the GUI pages:

1) The GUI needs to have an ability to apply various filtering criteria (equal, not equal, like, not like, more, less, RegExp) by every data field in each table.
There is very basic filter/search functionality currently exists in the GUI, but its just too simple and in many cases it does not provide the required filtering power.
This feature should be available on all pages as default GUI feature. For instance, searching connections by specific RTP Proxy Type is impossible.
Searching XDRs is only possible by Date/Time. What about searching by Country, Destination, Disconnect Code, Dialed number, Duration, etc? If I wanted to search XDRs for a specific Customer/Account with filter by Duration AND/OR Country, AND/OR charged amount or whatever, I can not do this. I have to manually search dozens of pages to find the records or use third party tools like Excel.
If I wanted to search Tariffs by route category, for example, it is impossible as it doesn't have advanced search.

2) Sorting by each data field is necessary as well. Sorting data on GUI page is as important as proper filtering. Only few GUI pages currently provide sorting. Plus, if there are more than 1 page of data, sorting must work for the entire data set, not just for the records displayed on the current page.

3) GUI exporting feature is important (ability to export filtered/unfiltered data from any table). Pretty often it is need to export various data currently displayed on the page for further processing. This can be Accounts, DIDs, Connections, etc.

4) GUI Import. Pages should have ability to import data (Accounts, Connections, Customers, Route Categories, etc.). Sometimes we experience situations where we had to manually create a lot of records of the same type due to lack of this feature.

5) It is also very helpful to have an ability to bulk modify of GUI records (for instance, Accounts, Customers, Connections, etc). This means that when I have 5 Accounts displayed on the page and I need to change (or delete all of them at once) just one common option for all of them, I shouldn’t click on each account separately, I simply should be able to select all required accounts and change the same parameter for all of them at once.

6) Data cloning feature is very limited and exists only on a couple of pages. Data cloning is important on almost every page (Accounts, Connections, Tariffs, Route Categories, Routing Plans, anywhere…). The good cloning feature must allow a user to edit any field on the newly cloned record before it is saved.

Todd D.:

It’s quite common for customers to turn their equipment off, or for firewalls to block SIP registrations, or for various other reasons to cause incoming calls to fail to be connected to customers’ equipment.
We would like either we or our customer (ideally both) to be able to be notified when something like this occurs. This could also be extended to notify the customer they have hit the maximum concurrent usage on their SIP trunk.

BigRed:

I would like to know the recommended settings for routing criteria in case of false ringing.
Some vendors "cheat". Instead of 180 ringing, they immediately answer the call and play an audio that plays beep beep (180 ringing simulation). Problem is that, because the call is ANSWERED (and some audio playing) we (and our customer) get charges.
Is there a way to say thay there needs to be at least an X-amount of ms of true 180 or 183 ringing before answer (200 ok), or else block route?

PortaONE:

Penalization of vendors cheating with "false ringing" is already supported - see the "Routing Criteria", "Too short PDD" section

BigRed:

We would like to offer call recording as an additional service, so, sell per minute or per MB base.
So, when a call is recorded (on demand or auto record), it must not only create a normal call record, but also an additional record for the call recording.
This way, we can charge the customer based on usage.
Please make it work together with volume discount plans, etc.

PortaONE:

If you have a specific business case - it makes sense to work on this as a feature request to ensure it works exactly as you require.

Mike H.:

Call Barring Classes are currently setup globally in the Dial Plan menu. I find this is OK for generic barring of destinations globally on the platform e.g. International, National & Local or bar all calls except internal calls etc but quite often customers are asking if it's possible to allow specific destinations only for some of their users.
It would therefore be worthwhile looking to add a per customer implementation so that customers can have their own barring/exceptions on top of the global options.
Additionally some method where call barring settings can be applied to selected multiple accounts instead of having to go into each individual account to select from the options previously defined in the call barring settings.

Mike H.:

For future consideration for addition to the batch account update screen in the admin portal, could we have the account default answer mode and ring timer?

Dale:

Would it not be possible to use the recorded name from the users voicemail for the Dial by Name feature, then each user could simply record their own names via the "One's Own Voice Mailbox Access" feature code, rather than the administrator having to save wav files for each user then import them via the new SC interface?

Mike H.:

I'd agree with this.

BigRed:

We would like the tariff importer to support XLSx, instead of just XLS.

BigRed:

Porta now supports customer/vendor offset.
So, you can offset balances with eachother.

However, now, it works for ALL of time.

So, if I have:
* vendor-A, and I BUY from them since 2012,
* and in 2015 vendor-A also becomes my customer,
* Since 2012, I have spent over $100,000 with Vendor-A
* I set Customer-A (which is equal to Vendor-A) credit limit to $5,000
* Customer-A has a limit of $105,000

It does not take into account the billing period, e.g. weekly, monthly, etc.
Would be nice if this could be taken into account.