Call Forwarding Options Issue - 24.01 Update 4

[Jason Cornell]

Good afternoon,

We updated to 24.01 Update 4 a couple of weeks ago and have been pleased with the results thus far. The one issue that we recently found has to do with Call Forwarding options in either the superadmin UI or an individual user/extension UI. When selecting the Call Forwarding tab/option to edit those settings, I am redirected to an Internal Error page which I have attached. Clicking on the link "Here" to continue redirects back to the login page to enter username and password.  Any insight into this will be greatly appreciated!

Thank you!

[OnRelay Support]

Hello,

Historically this can happen if the forwarding loop gets corrupted in PostgreSQL after an unsafe reboot or similar.  sipXconfig.log should give a clue why it exits. Please post any errors here and we will help check 

In any case also make sure you upgrade to update 5.

_______________________


OnRelay Support

US: +1 415 523 6400 

AU: +61 285 038 070 

UK: +44 208 629 1460 

NO: +47 21 93 72 27 


sup...@onrelay.net |www.onrelay.com

   

Waynesboro Area School District Mission Statement

EMPOWERING INDIVIDUALS FOR FUTURE OPPORTUNITIES - FIRST CHOICE

Pursuant to Waynesboro Area School District (WASD) policy and administrative procedures, this e-mail system is to be used for official WASD business only.  All users are cautioned that messages sent and received through this system are subject to the Freedom of Information Act, and Pennsylvania public disclosure laws, and may be reviewed at anytime by WASD.  There should be no expectation of privacy.

Please consider the cost and the environment before printing this email or any attachments.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/74d6e262-5b45-4af2-bbe3-1f0c67a6b4f4n%40googlegroups.com.

[Donovan Vincent]

Good Evening All,

I just wanted to bump this post as we are now experiencing the same issue.

I just updated my system to update 5 on Friday. I'll post logs momentarily.

Thanks,

--

Donovan Vincent
Director of Technology Services
Vincent Technology Services
717-219-7773 x1182
donovan...@vincent-tech.com

[OnRelay Support]

Hello,

As mentioned sipxconfig.log should give you a clue, and this error is likely due to a missing link in the forwarding ring due to an incomplete shutdown or similar corruption error.

To troubleshoot and recover, you can attempt this:

Open the psql prompt:

# psql -U postgres sipxconfig

Get the DB user ID of your problematic extension:

# select user_id from users where user_name='<user extension number>';

Check the forwarding ring for the user:

# select * from ring where user_id='<user ID returned above>';

If you find a missing index (0,1,2, etc) in the returned positions of the returned table, that is your culprit.

If there is a whole, e.g. one way to recover is to delete all forwardings for that particular extension (be careful!) as follows:
# delete from ring where user_id='<user ID returned above>';

[Donovan Vincent]

Good Evening,

Unfortunately that did not solve our problem. 

I will attach the sipxconfig logs to this email. 

Thanks for your help. 

[OnRelay Support]

Hello,

There are two errors kicked up there:

-- Looks like a bad URL has been configured for backup

-- On the call forwarding page it complains about an empty / null call forward timer.

These are not modules we have touched in 24.01.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/d1969be3-c2f1-4c3a-a113-2acd065afd60n%40googlegroups.com.

[Donovan Vincent]

Good Evening,

I'm aware of the first one. We're currently in the process of changing our backup strategy so sipx backups aren't working right now. My apologies for not mentioning that might show up. 

How would I go about changing the call forward timer value? 

Your help is very appreciated. 

[OnRelay Support]

Hello,

Beware they could potentially be related, e.g. a corrupt backup link may produce an incomplete backup or similar dependency.

Otherwise listing the ring table via psql (select * from ring;) should allow you to identify a row with a missing timer vakue.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/4b6446df-c49b-4b5e-823c-98c5c3710b48n%40googlegroups.com.

[Donovan Vincent]

Good Morning,

We were having this issue prior to changing our backup strategy but can try changing the settings back to how they were previously if we need to.

When executing the "select * from ring;" command there are no entries in the table. I get the same result when I target a specific user. I'm assuming this is the null value you were mentioning. 

Thanks,

---

From: OnRelay Support <sup...@onrelay.net>
Sent: Tuesday, September 17, 2024 3:16 AM
To: Donovan Vincent <donovan...@vincent-tech.com>
Cc: sipxcom-users <sipxco...@googlegroups.com>
Subject: Re: [sipxcom-users] Call Forwarding Options Issue - 24.01 Update 4

 

CAUTION: This message was sent from outside of Vincent Technology Services. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe.

Vincent Technology Services

MORE THAN JUST THE IT GUY

 

Pursuant to the Vincent Technology Services policy and administrative procedures, this email system is to be used for official Vincent Technology Services business only. All users are cautioned that messages sent through this system may be reviewed at any time by Vincent Technology Services. There should be no expectation of privacy. Although the company has taken reasonable precautions to ensure no viruses are present in this email, Vincent Technology Services cannot accept responsibility for any loss or damage arising from the use of this email or attachments.

[Support]

Hello,

It is always good practice to resolve the first error that appears in a java log. Depending on implementation, java exceptions as seen being caused by your invalid backup URL, may break the normal execution flow of your configuration service if not caught. So this means such an exception can cause the loading of your configuration to exit, break or stop/

Anyhow, looking more closely at your last log error, it is the callfwd/timer setting on your user itself that is empty / invalid / corrupt / null (see screenshot below), and not a setting on one of the forwarding rings.

So you should be able to locate the corrupt row with the missing callfwd/timer by selecting on the user table and / or the the user’s settings table instead of the ring table.

PS. A quick check of the code that is causing sipXconfig to crash in this case indicated a missing null pointer check when reading the empty callFwdTimer, so we quickly added that check, which will be included in a next release / update to prevent the crash and allow you to fix from web config. But this doesn’t explain why the timer setting got corrupted in the first place.

_______________________

 

OnRelay Support

US: +1 415 523 6400 

AU: +61 285 038 070 

UK: +44 208 629 1460 

NO: +47 21 93 72 27 

sup...@onrelay.net | www.onrelay.com

On Sep 17, 2024, at 3:32 PM, Donovan Vincent <donovan...@vincent-tech.com> wrote:

Good Morning,

We were having this issue prior to changing our backup strategy but can try changing the settings back to how they were previously if we need to.

When executing the "select * from ring;" command there are no entries in the table. I get the same result when I target a specific user. I'm assuming this is the null value you were mentioning. 

Thanks,

<Outlook-d2js2lt3.png>

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/PH7P220MB189368B4C4E39DD9C6C8CB0EAE612%40PH7P220MB1893.NAMP220.PROD.OUTLOOK.COM.

[Beto Garcia]

What do we need to do to implement this patch? What file is this in?

Thanks!

[Beto Garcia]

We are experiencing this and it would be good to know either where/how to apply this patch or when the next update will come out.

Thanks!

Bet Garcia

On Tuesday, September 17, 2024 at 9:09:06 AM UTC-5 Support wrote:

[OnRelay Support]

Hello Beto,

We know sipXconfig hangs due to a user's callFwdTimer setting being null / empty, but we don't know what is causing this corruption error as we are unable to reproduce it on any of our test or production instances here. We suspect it may be a result of a server reboot in the middle of a DB operation or similar.

As of now, if you are not familiar with or comfortable accessing the DB directly via psql to update this value, you can try to update a different setting on the user and save it, alternatively try to rebuild the problematic user.

If someone can post a consistent way of reproducing the problem here, we will be quick to resolve and patch it. Otherwise we will try to code review it in legacy code to prevent in the next update, with release TBD as we are not aware of any other open issues.

[Beto Garcia]

Interesting, when I run "TABLE ring;" it shows the following

sipxconfig=# TABLE ring;
 ring_id | number | position | expiration | ring_type | user_id | enabled | schedule_id
---------+--------+----------+------------+-----------+---------+---------+-------------
(0 rows)

I have about 8 lines that I added.

[OnRelay Support]

Yes, that could indicate some DB replication errors.

In any case, the null value in question that sipXconfig complains about appears from the logs we have seen to be a missing callfwd/timer entry in the setting_value table where the correct value_storage_id is found in the user table.

[Beto Garcia]

FYI, I just created this VM instance using the last CentOs 7 iso, and following the directions exactly for installing sipxecs at https://onrelay.github.io/sipxecs/installing.html

[OnRelay Support]

Hello,

We don't doubt you see the error, however we have done the same 100s of times (for every test build) without this error showing up.

It could seem the missing callFwd timer setting prevents subsequent ring updates.

Does the error clear if you regenerate server profiles, replicate DB and / or reboot your instance?

Are you able to reproduce consistently? If so can you provide your exact steps to do so, and also let us know on what hardware / cloud image etc?

[Beto Garcia]

Thanks!

It reproduces for all users consistently, including superadmin. Go to user click on Call Forwarding, and get the error above and log output as described above. In Devices/Line, if we chose Advanced there is a call forwarding default time set at 20 seconds. 

We have tried rebooting and that has no effect, we have reverted to the very earliest snapshot before we had users installed and then added a test user and had the same issue. We are using Proxmox on a separate dedicated Ceph. The VM is setup using the recommended CPU, memory, and drive space.

 

uname -a output:

Linux sipx1.ourcompany.com 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

The sipx version is 24.01 from 7/19/2024

[OnRelay Support]

Good, if it reproduces that consistently maybe with your help we can bottom this out.

Where exactly in the admin interface are you referring to by Devices / Line - Advanced?

Note the default forward expiration time setting is under System - Services - SIP Proxy - Default Serial Fork Expiration

[Beto Garcia]

Devices - Phones - Click on a Line link and it will bring that line/user up, then on the left is a menu and it has an option - Advanced with a dialog box "Delayed Call Forward Wait Time" which is filled in with the default option 20.

The default forward expiration time setting under System - Services - SIP Proxy - Default Serial Fork Expiration is also 20.

[OnRelay Support]

Please be 100% precise so we don't have to guess what you are doing and send unnecessary messages figuring what settings you refer to.

When you click on Devices - Phones - (a line) there is no Advanced menu on the left there, whether you click the Line or the Phone options.

Where exactly is the Delayed Call Forward Wait Time you are referring to and with what exact click sequence do you get to it from the Home page?

[OnRelay Support]

You may use a different phone type than us (Polycom VVX), which could explain why we are not seeing the setting.

Since you can reproduce this on the superadmin user as well, it is likely not phone related.

It is definitely worth a try to update the Default Serial Fork Expiration under System - Services - SIP Proxy.

We modify it from default here, which could explain why we are not seeing the error if the culprit is how the default value is replicated.

[Beto Garcia]

Logged in as superadmin, under Devices - Phones, you see a list of phones and their associated lines, correct? Click on one of those lines in the Lines column and on the left there is a menu with the following options Line, Registration, Network, User Options, Advanced, Security Settings. If you select Advanced, you will need to scroll down through a dozen options before you see "Delayed Call Forward Wait Time".

[Beto Garcia]

We are provisioning Grandstream 2135 phones. We could go back to our earliest snapshot before any phone was provisioned, or create yet another VM and test if the phone provisioning created this issue, but it won't happen this evening and I can't imagine that is actually the issue.

[OnRelay Support]

OK, thanks, yes, all those settings are not there for Polycoms, hence our confusion (see below).

Yes, if you can reproduce this issue on the superadmin user before adding any other users or phones it should be very straightforward for us to resolve.

Please also check whether changing the SIP Proxy Default Serial Fork Expiration away from default changes anything.

[Todd Hodgen]

I don’t think Grandstream has been very well supported.  And I would guess that is where your issue is.   Build a fictitious Polycom Phone with a made up Serial number and try it – I’m betting you will have difference results.   The Grandsteam profiles were a donation from an end user if my memory serves me right.   I never had good luck provisioning GrandStream, even the old ones – and replaced them all with Polycom phones – which have always had excellent support from the developers of the main system.

 

From: sipxco...@googlegroups.com <sipxco...@googlegroups.com> On Behalf Of OnRelay Support
Sent: Tuesday, October 1, 2024 4:28 PM
To: sipxcom-users <sipxco...@googlegroups.com>
Subject: Re: [sipxcom-users] Call Forwarding Options Issue - 24.01 Update 4

 

OK, thanks, yes, all those settings are not there for Polycoms, hence our confusion (see below).

Yes, if you can reproduce this issue on the superadmin user before adding any other users or phones it should be very straightforward for us to resolve.

Please also check whether changing the SIP Proxy Default Serial Fork Expiration away from default changes anything.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/be6c1599-cb72-4eed-b57e-6e47700dda6fn%40googlegroups.com.

[OnRelay Support]

Todd, you are right, Polycoms is most definitely the safe option.

Having said that, this error has popped up in a few different deployments now, and seems like one of those landmine bugs that should be cleared sooner rather than later.

So now that we have a case where it is readily reproducible let's try to bottom it out.

[Beto Garcia]

Hi folks!

I'm building a brand new virtual machine. We did try changing that default SIP Proxy setting with no luck. We have an old Polycom Sound Station IP 7000.

[Ivar Plahte]

Hello,

Note you don't need to add any phones to create users and set their forwarding rules.

So are you able to reproduce this issue before adding any phones on a fresh install? 

E.g. you mentioned you can reproduce this issue on the superadmin user?

[Beto Garcia]

I just created a brand new, brand new instance, no users, no phones. I go to superadmin, scroll down to call forwarding and the same issue. An internal error has occurred.

So to replicate, create a new Centos 7 virtual machine and here is my command history.

2  yum install nano
    3  ping google.com
    4  yum update
    5  sed -i 's|mirror.centos.org|vault.centos.org|g' /etc/yum.repos.d/CentOS-*
    6  yum update
    7  sed -i 's|mirrorlist|#mirrorlist|g' /etc/yum.repos.d/CentOS-*
    8  sed -i 's|#baseurl|baseurl|g' /etc/yum.repos.d/CentOS-*
    9  yum update
   10  yum remove -y epel-release
   11  yum update -y
   12  shutdown now
   13  nano /etc/sudoers
   14  yum install nano
   15  nano /etc/sudoers
   16  wget -O /etc/yum.repos.d/artifact-registry-plugin.repo   https://storage.googleapis.com/sipxecs/artifact-registry/artifact-registry-plugin.repo
   17  yum install wget
   18  wget -O /etc/yum.repos.d/artifact-registry-plugin.repo   https://storage.googleapis.com/sipxecs/artifact-registry/artifact-registry-plugin.repo
   19  yum install -y yum-plugin-artifact-registry
   20  wget -O /etc/yum.repos.d/sipxcom.repo   https://storage.googleapis.com/sipxecs/sipxcom/24.01/centos-7-x86_64/sipxcom.repo
   21  yum install elasticsearch
   22  systemctl enable elasticsearch
   23  service elasticsearch start
   24  nano /etc/security/limits.conf
   25  reboot
   26  yum install -y sipxcom
   27  sipxecs-setup
   28  yum update -y
   29  sipxecs-setup
   30  nano /etc/hosts
   31  systemctl status sipx*
   32  tail -f /var/log/sipxpbx/*.log
   33  reboot

[OnRelay Support]

Thanks! Could you please zip up and attach all logs found under /var/log/sipxpbx?

If anything sensitive there you may just email them to sup...@onrelay.net as well.

[OnRelay Support]

Thank you, could you please also share with us the exact steps you do in the admin portal before you open the superadmin panel to reproduce the error?

Have you e.g. started the phone services under System - Services - Telephony Services? If so, which ones?

[Beto Garcia]

Want to say I am very impressed by the timely and substantial response by OnRelay Support. We are testing out multiple phone systems and this is a very positive experience that will certainly influence our decision.

[OnRelay Support]

Thank you!

As per the logs you shared, the below entries in sipxconfig.log don't look right and don't match ours.

sipxconfig.log will normally kick up some SSL errors before the server has been initialized, but we haven't seen these.

In particular, it looks like 'select 1 from feature_local where feature_id = ?' fails, and blocks subsequent DB operations.

We are investigating.

"2024-10-02T16:25:09.483000Z":17:JAVA:WARNING:sipx2.asgc.com:pool-11-thread-1:00000000:JDBCExceptionReporter:"SQL Error: 0, SQLState: 57P01"
"2024-10-02T16:25:09.483000Z":18:JAVA:ERR:sipx2.asgc.com:pool-11-thread-1:00000000:JDBCExceptionReporter:"FATAL: terminating connection due to administrator command"
"2024-10-02T16:25:09.483000Z":19:JAVA:WARNING:sipx2.asgc.com:pool-11-thread-1:00000000:JDBCExceptionReporter:"SQL Error: 0, SQLState: 08006"
"2024-10-02T16:25:09.484000Z":20:JAVA:ERR:sipx2.asgc.com:pool-11-thread-1:00000000:JDBCExceptionReporter:"An I/O error occured while sending to the backend."
"2024-10-02T16:25:09.594000Z":21:JAVA:ERR:sipx2.asgc.com:pool-9-thread-1:00000000:TaskUtils$LoggingErrorHandler:"Unexpected error occurred in scheduled task."
org.springframework.dao.DataAccessResourceFailureException: PreparedStatementCallback; SQL [select 1 from feature_local where feature_id = ?]; FATAL: terminating connection due to administrator command; nested exception is org.postgresql.util.PSQLException: FATAL: terminating connection due to administrator command
at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.doTranslate(SQLStateSQLExceptionTranslator.java:104)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:603)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:674)
at org.springframework.jdbc.core.JdbcTemplate.queryForRowSet(JdbcTemplate.java:805)
at org.sipfoundry.sipxconfig.feature.FeatureManagerImpl.isFeatureEnabled(FeatureManagerImpl.java:135)
at sun.reflect.GeneratedMethodAccessor116.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at org.springframework.orm.hibernate3.HibernateInterceptor.invoke(HibernateInterceptor.java:111)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
at com.sun.proxy.$Proxy41.isFeatureEnabled(Unknown Source)
at org.sipfoundry.sipxconfig.systemaudit.ConfigChangeLoader.run(ConfigChangeLoader.java:35)
at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:65)
at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
Caused by: org.postgresql.util.PSQLException: FATAL: terminating connection due to administrator command
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:351)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:255)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76)
at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:644)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587)
... 28 more

[OnRelay Support]

Would you mind turning on DEBUG level logging for sipXconfig, reboot, and post or send the sipXconfig logs again?

The log level is set under System - Settings - Admin.

Thank you.

[Beto Garcia]

Will do

You received this message because you are subscribed to a topic in the Google Groups "sipxcom-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sipxcom-users/xKDiiFs9mKU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sipxcom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/844a6e74-b713-435d-9af0-80f509569139n%40googlegroups.com.

[Beto Garcia]

I changed logging to debug and rebooted.

[OnRelay Support]

Thank you for all the info. We have what we need and should be able to issue a fix in update 6 within the next few days. 

We are busy with a cell carrier launch with our friends at Cisco, but It is an ugly error so we will give it some priority.

Thanks again.

[Beto Garcia]

Excellent! Thanks!

[Beto Garcia]

The new fix allows me to access the call forwarding page, but now when I try to add a call forward and apply it, it gives me the internal error page.

[OnRelay Support]

Looks like you just beat us to it while we were updating repositories, if you do another fresh install from the live repos it should work now.

The culprit was a not previously discovered difference in dependencies or similar inconsistency between our docker builds and our cloud image builds.  This caused a database initialization corruption error running the sipxecs-setup script using the docker built live repos.

We have now built the live repositories from a cloud image instead (as per the Building instructions), and the problem went away.

As we do not expect to do a lot more work on CentOS 7 we will not spend endless hours analyzing what went wrong with the Docker builds, but rather continue to release any CentOS7 updates from our cloud image builds moving forward.

We also do most of our testing on these cloud image builds, which is why this problem both confused and escaped us.

We appreciate your help in finding a resolution, and would be great if you could confirm all OK now.

When you do, we will stamp and tag update 6 in GitHub.

On Tuesday, October 8, 2024 at 10:56:02 AM UTC-7 Ivar Plahte wrote:

Hello Beto,

We are still working on this issue, we attempted an update to just prevent the null pointer, but it has not resolved the problem.

We will post here when issue is resolved.

[Beto Garcia]

Thanks! So I reinstall completely?

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/0246e0a2-664f-4403-a313-435225d0f427n%40googlegroups.com.

[OnRelay Support]

Yes, if you just update over your previous install the DB setup error may not clear, since the DB remains initialized then. 

An uninstall / reinstall should clear it as well, albeit we haven't checked.

[Donovan Vincent]

Good Evening All,

I was reading back through this thread as we are still facing this issue.

Would there be a way to restore the database issues without data loss or starting anew?

Thanks,

Donovan

[OnRelay Support]

Hello Donovan,

We heard directly from Beto his issue was resolved with the latest update 6, but yes, he may indeed have started from a fresh install.

Did you try to upgrade to update 6 on top of your existing DB?

If that didn't fix it there is a good chance doing a fresh install of update 6 and subsequently restoring your DB from backup will work, but we haven't checked it.