03-16-2020 07:13 PM
I am trying to troubleshoot problems with SPA112's and am seeing the following sequence in Syslog:
uchDisconnectEpFromNode(), invalid node ID: -1
Already has a RTP channel.
uchConnectEpToNode(): Error Connecting EP VoIP 0 to Node 0. -93.
Can anybody enlighten me as to what is happening here?
03-17-2020 10:05 AM
Just single line with no context ? No information who's calling whom (if we are speaking about a call at all, no firmware version mentioned ...
Sorry, no enlightenment. I'm no prophet.
Provide complete syslog&debug of voice application related to the particular call, capture network activity (SIP, RTP and possible related ICMP as well). Don't forget to disclose the task (what you are doing).
OK. Do you wish for just blind shot ? RTP packet sent by SPA112 has been refused by a firewall (a error ICMP as been received SPA112). Just guessing ...
03-17-2020 06:28 PM
My question doesn't relate to a specific call so that's why there is no context. Actually, there are 3 lines in the body of my question (only 1 in the title).
I manage thousands of SPA112's and see the 3 lines in Syslog quite a lot. To my knowledge, there is no document from Cisco that gives any meaning to Syslog messages and so we are left with guesswork. Thank you for your guess - I suspected firewall issues too, but I was hoping someone in the community may know for sure what any of the 3 lines mean.
I will now go and find a specific device, do a SIP trace along with Syslog/Debug and try to provide a context....
03-17-2020 07:14 PM
My question doesn't relate to a specific call so that's why there is no context.
Despite of it, it's hard to analyze it with no context.
Important note - the messages are from SPA112 kernel log. Such log have little or no relationship to voice operations of the device. You need to capture syslog&debug messages of voice application running on SPA112.
Debug and syslog Messages from SPA1x2 and SPA232D ATA
I will now go and find a specific device, do a SIP trace along with Syslog/Debug and try to provide a context....
We will not guess the meaning of the messages unless you are facing an issue.
03-17-2020 09:11 PM
@Dan Lukes wrote:We will not guess the meaning of the messages unless you are facing an issue.
I have been facing a serious issue for months now where hundreds of devices have 'gone to sleep'. Try as I may by sending NOTIFY with Reboot_Now four times a day to each device, they continue to lock up - regardless of which firmware version they are running.
So, anyone please feel free to guess if uchConnectEpToNode(): Error Connecting EP VoIP 0 to Node 0. -93 could be a clue to my issue.
03-18-2020 02:57 AM - edited 03-18-2020 03:02 AM
It's why I'm calling for other logs - this message may not be primary reason, but just generic consequence of an (not know yet) .primary cause.
Wishing for blind shots ? OK. End Point VoIP 0 is an structure describing RTP of the call while Node 0 is either structure describing the control part of call (e.g. SIP session) or the analog line 1 itself.
Possible reason for failure may include (but are not limited to):
Remember - it's blind shot based on final message describing the result but not the causes.
You should know the SPA112 is not ready to be exposed in unfriendly network environment. It have no countermeasures against various kind of remote attack. I recommend to everyone not to expose SPA112 to public Internet or to LAN with public access (open WiFi or so). Even in closed local network, make sure there's no infected computer doing something nasty. SPA112 is somewhat volatile - even intensive broadcast traffic can harm.
Best solution - VoIP devices should be connected to dedicated (V)LAN not used for casual computers whenever possible.
03-18-2020 07:43 PM
@Dan Lukes wrote:You should know the SPA112 is not ready to be exposed in unfriendly network environment. It have no countermeasures against various kind of remote attack. I recommend to everyone not to expose SPA112 to public Internet or to LAN with public access (open WiFi or so). Even in closed local network, make sure there's no infected computer doing something nasty. SPA112 is somewhat volatile - even intensive broadcast traffic can harm.
Best solution - VoIP devices should be connected to dedicated (V)LAN not used for casual computers whenever possible.
Thank you so much. I may never find the meaning of those Syslog messages, but it doesn't matter. What you have done is make me realize that I have been approaching the 'going to sleep' issue in the wrong way. I have made dozens of changes to settings within the Cisco devices over several months and nothing has been able to prevent devices locking up.
I now need to focus more on what could be happening within the corporate network where the devices are located (across 1500+ stores). It's highly unlikely there will be any infected computers but they are currently in a DMZ, so who knows what other traffic they may be exposed to.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide