Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

SPA112 Locking up Every Day

My SPA112 has decided it wants to stop providing dial tone and locks up on average of once per day.

When it allows me to browse the Voice section on the web interface it simply says "Voice module not ready.". 

When I try to reboot it from the web interface it says "Changes cannot be applied while calls are in progress. Please try again when phones are idle.", although there are NO calls in progress.

It has locked up several times this week, currently it's not responding to the web interface either. 

The end of the debug log shows:

Jan  3 13:37:14 spa112.local SPA112 syslog-ng[123]: STATS: dropped 0

Jan  3 13:47:14 spa112.local SPA112 syslog-ng[123]: STATS: dropped 0

Jan  3 13:50:49 spa112.local SPA112 [17179593.084000]  In cordless Driver Codec 0 and str PCMU/8000  chan 0 

Jan  3 13:50:49 spa112.local SPA112 [17179593.084000]  In cordless Driver Codec 8 and str PCMA/8000  chan 0 

Jan  3 13:50:49 spa112.local SPA112 [17179593.084000]  In cordless Driver Codec 100 and str NSE/8000  chan 0 

Jan  3 13:50:49 spa112.local SPA112 [17179593.084000]  In cordless Driver Codec 112 and str encaprtp/8000  chan 0 

Jan  3 13:50:49 spa112.local SPA112 [17179593.084000]  In cordless Driver Codec 255 and str   chan 0 

Jan  3 13:50:49 spa112.local SPA112 [17179593.084000]  In cordless Driver Codec 255 and str   chan 0 

Any ideas on why this is suddenly constantly locking up?

  • ATAs Gateways and Accessories
Everyone's tags (5)
1 REPLY
New Member

SPA112 Locking up Every Day

I looked through my asterisk logs at the same time frame and saw that there was an error with a callerID module that I was using.  Esentially the caller ID name was being passed as "

Again, this was a problem that I have fixed with the modules so the caller id (if it ever gets fixed on the SPA112) is passed it won't pass this HTML header anymore. 

However, it SHOULD NOT LOCK UP the SPA112 when getting erroneous callerid info.  As you can see at the end of the log, both connected extensions/peers get disconnected because the SPA112 freezes up.

[Jan  3 13:51:36] VERBOSE[6699] pbx.c:     -- Executing [s@macro-user-callerid:20] Set("SIP/FutureNine-00000013", "CALLERID(name)=

[Jan  3 13:51:36] VERBOSE[6699] pbx.c:     -- Executing [s@macro-user-callerid:21] NoOp("SIP/FutureNine-00000013", "Using CallerID "<

!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML" <4083858913>") in new stack

....Skipping lots of non-useful info....

[Jan  3 13:51:36] VERBOSE[6699] netsock2.c:   == Using SIP RTP TOS bits 184

[Jan  3 13:51:36] VERBOSE[6699] netsock2.c:   == Using SIP RTP CoS mark 5

[Jan  3 13:51:36] VERBOSE[6699] app_dial.c:     -- Called SIP/100

[Jan  3 13:51:36] VERBOSE[6699] netsock2.c:   == Using SIP RTP TOS bits 184

[Jan  3 13:51:36] VERBOSE[6699] netsock2.c:   == Using SIP RTP CoS mark 5

[Jan  3 13:51:36] VERBOSE[6699] app_dial.c:     -- Called SIP/300

[Jan  3 13:51:36] VERBOSE[6699] app_dial.c:     -- SIP/100-00000014 connected line has changed. Saving it until answer for SIP/Future

Nine-00000013

[Jan  3 13:51:36] VERBOSE[6699] app_dial.c:     -- SIP/300-00000015 connected line has changed. Saving it until answer for SIP/Future

Nine-00000013

[Jan  3 13:51:36] VERBOSE[6699] app_dial.c:     -- SIP/100-00000014 is ringing

[Jan  3 13:51:36] VERBOSE[6699] app_dial.c:     -- SIP/300-00000015 is ringing

[Jan  3 13:51:43] NOTICE[3077] chan_sip.c: Peer '100' is now UNREACHABLE!  Last qualify: 47

[Jan  3 13:51:43] NOTICE[3077] chan_sip.c: Peer '101' is now UNREACHABLE!  Last qualify: 47

3257
Views
0
Helpful
1
Replies