SPA112 fails to dial out, but can receive incoming

[bvanbogart]

This started happening 3 days ago.  I have 2 lines associated with the SPA112, and first line 2 stopped being able to dial out.  When picking up the line, a dial tone is present but when you actually dial a number it sits there for a few seconds then gives what sounds like an error or busy signal but won't dial out.  Line 1 could still dial out, and both lines could receive incoming calls.

The service I'm using is Ring Central, with whom I spent a long time on the phone trying to troubleshoot it.  Eventually we hit upon the idea of switching which port was associated with each number.  This confirmed that the port on the SPA112 was the issue, not the number itself.  That was yesterday.

Now today, I have been dialing out on line 1 all day while waiting for my replacement SPA112 to arrive from Amazon and it's been working.  However at some point this afternoon it gave me the same weird tone and now neither line will dial out, though both still receive incoming calls.  This is extremely frustrating!

Now here's the interesting thing; I think this happened after trying to dial someone with a *67 prefix (to block the caller ID).  I sometimes do this when calling customers from line 2 to avoid them trying to call my number directly since if they do they'll get a fax machine answering.  Until 2 weeks ago I was using Vonage and had been for many years, and this works fine on that service.  I'm not sure I even tried using *67 on Ring Central and the SPA112 until this week, but I think that's what did it.  I think this because I dialed *67p<number> on line 1, forgetting it wasn't line 2, and that's when the tone started.  And thinking back I think I did the same thing right before the problem originally started on line 2 also.

So what gives?  Apparently I need to never EVER use this dialing code again!  Is there something this *67 does?  I can't find any mention of it in the manual or anywhere online, and dialing it again doesn't seem to change anything.  If this enables something, is there another code that disables it?  Any help here would be REALLY appreciated!

Thanks!

Brian Van Bogart

[JeffInAlberta · Accepted solution]

Hi Brian,

According to the SPA112 adminsitration guide, *67 will permanently set the line to block Caller-ID.

And, *68 will permanently remove the block on Caller-ID.

Perhaps try removing the block on the lines by using *68 and see how outbound dialing goes after that?

I,ve never used RingCentral myself, so I'm not really famaliar with their systems.  However, I did a little research on their web site and note that they seem to recommend that you use their "online administration" system to enable and disable Caller-ID blocking:

http://success.ringcentral.com/articles/RC_Knowledge_Article/Outgoing-Caller-ID-Block-5-10?priority=10&retURL=/apex/RCSupportPortalSearchNew&type=FAQ&id=kA280000000GrIQCA0&Title=Outgoing+Caller+ID+Block

And, they do go on to say that you can use *67 on a per-call basis for Caller-ID blocking, if you don't use their online administration settings.  This is making me wonder if there may be conflict between the SPA112 and RingCentral in the implementation of the DTMF star codes?

Regards,

Jeff - voipdiy.com

P.S.

I also note that the SPA112 admin guide says that *81 is used to block CID on the next outbound call on a per-call basis. (Use prior to each outbound call.)  Perhaps this is the code to use with the SPA112 and RingCentral if not using RingCentrals web-based administration call-blocking configuration settings? 

Message was edited by: Jeff B.

[bvanbogart]

Thanks Jeff,

I've since replaced and re-provisioned the box and it's working again.  I did notice some other weirdness when I got the new box and started to set it up though.

Initially when I got the new box, I saved the config from the old box then restored it to the new one (both had previously been updated to the latest firmware).  The same problem came with the restored configuration, which I found a bit surprising.  I ended up having to do a restore to defaults and re-provision both lines in order to get it working again, which I suppose I may have been able to do on the original box without needing a replacement.  With that in mind, I've made a "known good" config backup of the new box so that hopefully if I run across this problem or a similar one I can restore it and go back to a working state.

The information in your post is very helpful, thank you!  I'm a bit nervous to try any of this now that I'm back up and working though.  Even with the known good backup, I have no guarantee and really only a guess that a restore will fix it if this happens again and I can't just turn it back off.

I still don't really know what happened, but hopefully with a combination of keeping a good backup and having the * codes listed above I can avoid this issue totally stopping me again in the future.

Thanks again!

Brian Van Bogart