VOIP Errors

I am trying to test the VOIP portion of Ignition and I get some errors on the call manager. Is there something that I am missing? I have attached the log files.

We are using Skype and pretty sure that is set up properly. It says Registered with SIP Host.

Thanks,

Allen
logs.bin (1).gz (960 KB)

I think you upgraded the beta without installing the new versions of the phone & voice modules. We probably should have made it more clear that that was necessary. Try downloading them from this thread and see if that helps.

The module reloading on the voice doesn’t work very well right now, so the best way to update is simply stop the gateway, replace the modules under “{InstallDir}\user-lib\modules”, and start it up again.

Regards,

That is where I downloaded them from originally. I will replace it as you have instructed and report back.

Thanks

Alright - updated the modules, updated the beta and now I have the following issues as seen in the log files.
logs.bin (3).gz (975 KB)

Hi,

Response code “404” just means invalid phone number. We really need to make that better… but make sure that the phone number you’re calling starts with “1”, like “19165555555”.

The messages about “Some bound alarm properties failed to compile” aren’t really related, but mean that some bindings in your tags aren’t correct. You could get more information by turning “Alarm.Execution” to debug in Console>Levels, and then disabling & re-enabling the tags.

Regards,

Now I get a 403 - forbidden. Working down the line. As far as the other alarming issues see the other post. Not sure what happened there.

If you’re using skype, and it says “Registered”, your username/password are probably ok, so is it possible you don’t have any credit on the SkypeConnect channel?

Regards,

I found this skype connect guide which shows what the different responses could mean. Looks like this is, indeed, what you might get if you were out of credit.

Regards,

Sounds good - thanks Colby.

I did the update and tested making a call again and got this error: 4:56:31 PM CallManager Unexpected error in CallQueueTransfer. The thread will be restarted soon, but this error could indicate a serious condition affecting voice notification.

java.lang.NoSuchMethodError: com.inductiveautomation.ignition.gateway.expressions.AlarmEventCollectionExpressionParseContext.(Ljava/util/List;)V
at com.inductiveautomation.alarming.notification.sip.content.scripts.SettingsBasedScript.evaluate(SettingsBasedScript.java:180)
at com.inductiveautomation.alarming.notification.sip.content.scripts.SettingsBasedScript.buildAlarmPhraseGroup(SettingsBasedScript.java:165)
at com.inductiveautomation.alarming.notification.sip.content.scripts.SettingsBasedScript.(SettingsBasedScript.java:94)
at com.inductiveautomation.alarming.notification.sip.profile.SipNotificationProfile$TTSScriptFactory.buildScript(SipNotificationProfile.java:266)
at com.inductiveautomation.alarming.notification.sip.call.NotificationJob.run(NotificationJob.java:136)
at com.inductiveautomation.alarming.notification.sip.call.CallManager$CallQueueConsumer.run(CallManager.java:570)

Do I need to update the voice module again?

Yes, it looks like it. It would probably be best to wait until tomorrow, when all of the correct versions get put up on the website.

Regards,

Just updated and still get the same error. Doesn’t look like the version changed - was it supposed to in the official release?

Make sure you’re getting them directly from the download page. I just installed from scratch with all of the release modules, and didn’t have a problem.

Regards,

Figured it out. I downloaded the new version, but when I install it didn’t update the voice module. The names at some point had changed so once I downloaded the Phone Notification module and deleted the old one it worked fine.

Alright - so I had it working for a while this afternoon and I just got on to test after playing with the pipeline for a bit and got this:

8:31:25 PM PhoneCall Error executing call 'sBq69OT5-1367980255861@Thing1.mtregional.org

java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at com.inductiveautomation.alarming.notification.sip.call.CallManager$PhoneCall.run(CallManager.java:335)

Any ideas? Is this a Skype issue or internal?

Hi,

You should see something immediately before that in the logs along the lines of “Call has exceeded it’s permitted lifespan, cancelling.”. Each call has two potential timeouts: one that limits how long to wait for someone to answer, and one for how long the phone call can last overall (to limit the damage should the hangup fail to be detected. We haven’t seen this, but phone systems are weird). This type of error is bound to happen when either of them expires.

Ultimately the question is: was the timeout legitimate, or due to a problem? Have you tried to make a call again? Even something as simple as a wrong number could lead to this. As you test, perhaps keep a tab open on Status>Voice Alarming, with “live values” turned on, so that you can watch the call progress. See if it goes through the cycle of Ringing, Talking, etc.

Regards,

It looks like it never gets past the initializing phase of the phone call.

Thanks,

I see. So, it must stay at initializing for 30 seconds, and then get canceled. Could you look for the logger “Agent”, and turn it to debug, try to make a call, and then zip/attach wrapper.log? I can imagine it’s probably pretty simple: it’s trying to place a call, and isn’t getting the response back from skype, however, the log should help confirm this.

You said this worked and then stopped- Is there a chance something changed in the network or a firewall got turned on (windows update & restart?).

Regards,

See the attached log. Nothing changed network wise that I am aware of. I spoke with others as well and they don’t know of anything.
logs.bin (5).gz (970 KB)

Yes, as I expected, it repeatedly sends out call requests, but never gets anything back from skype.

Does this server possibly have two network interface cards? The log messages show the address used as 192.168… which I don’t think is going to work. If it was working before, either the machine was moved to be behind a router (which doesn’t support sip tunnelling), or (more likely), the auto detection of the bind interface started choosing the wrong one. If this seems possible, go to the settings for the voice profile, and under “advanced”, set the local and public bind addresses to the ip of the public interface.

Regards,