All Circuits Are Busy Now..... but they're not
Submitted by robricc on Sun, 02/10/2008 - 5:04pm.
I have been having considerable difficulty getting any version of Trixbox to play nicely with our Rhino R8FXX-EC and Verizon POTS lines. For a very long time, disconnect supervision was not working. After emailing Rhino back and fourth for a while, they determined that it must be an issue with Verizon. After a couple months of getting nowhere with Verizon, Rhino released the latest firmware for the analog cards which took care of the disconnect problem. However, it introduced another, even more annoying problem. Even with all channels completely inactive, we are getting "All Circuits Are Busy Now" 80% of the time.
If my outbound route only includes trunk ZAP/g0, only the first channel is tried before getting the "All Circuits are Busy" recording. Even if that channel was busy, shouldn't asterisk try other channels in that group? This is what the CLI looks like:
-- Executing [MY PHONE NUMBER@from-internal:1] Set("SIP/27-09476208", "EMERGENCYROUTE=YES") in new stack
-- Executing [MY PHONE NUMBER@from-internal:2] Macro("SIP/27-09476208", "dialout-trunk|1|MY PHONE NUMBER||") in new stack
-- Executing [s@macro-dialout-trunk:1] Set("SIP/27-09476208", "DIAL_TRUNK=1") in new stack
-- Executing [s@macro-dialout-trunk:2] Set("SIP/27-09476208", "DIAL_NUMBER=MY PHONE NUMBER") in new stack
-- Executing [s@macro-dialout-trunk:3] Set("SIP/27-09476208", "ROUTE_PASSWD=") in new stack
-- Executing [s@macro-dialout-trunk:4] GotoIf("SIP/27-09476208", "1?noauth") in new stack
-- Goto (macro-dialout-trunk,s,6)
-- Executing [s@macro-dialout-trunk:6] GotoIf("SIP/27-09476208", "0?disabletrunk|1") in new stack
-- Executing [s@macro-dialout-trunk:7] Set("SIP/27-09476208", "_NODEST=") in new stack
-- Executing [s@macro-dialout-trunk:8] Set("SIP/27-09476208", "DIAL_TRUNK_OPTIONS=tr") in new stack
-- Executing [s@macro-dialout-trunk:9] Set("SIP/27-09476208", "GROUP()=OUT_1") in new stack
-- Executing [s@macro-dialout-trunk:10] Macro("SIP/27-09476208", "user-callerid|SKIPTTL") in new stack
-- Executing [s@macro-user-callerid:1] NoOp("SIP/27-09476208", "user-callerid: device 27") in new stack
-- Executing [s@macro-user-callerid:2] Set("SIP/27-09476208", "AMPUSER=27") in new stack
-- Executing [s@macro-user-callerid:3] GotoIf("SIP/27-09476208", "0?report") in new stack
-- Executing [s@macro-user-callerid:4] GotoIf("SIP/27-09476208", "0?start") in new stack
-- Executing [s@macro-user-callerid:5] Set("SIP/27-09476208", "REALCALLERIDNUM=27") in new stack
-- Executing [s@macro-user-callerid:6] NoOp("SIP/27-09476208", "REALCALLERIDNUM is 27") in new stack
-- Executing [s@macro-user-callerid:7] Set("SIP/27-09476208", "AMPUSER=27") in new stack
-- Executing [s@macro-user-callerid:8] Set("SIP/27-09476208", "AMPUSERCIDNAME=Rob Riccardelli-JR") in new stack
-- Executing [s@macro-user-callerid:9] GotoIf("SIP/27-09476208", "0?report") in new stack
-- Executing [s@macro-user-callerid:10] Set("SIP/27-09476208", "AMPUSERCID=27") in new stack
-- Executing [s@macro-user-callerid:11] Set("SIP/27-09476208", "CALLERID(all)="Rob Riccardelli-JR" <27>") in new stack
-- Executing [s@macro-user-callerid:12] Set("SIP/27-09476208", "REALCALLERIDNUM=27") in new stack
-- Executing [s@macro-user-callerid:13] NoOp("SIP/27-09476208", "TTL: ARG1: SKIPTTL") in new stack
-- Executing [s@macro-user-callerid:14] GotoIf("SIP/27-09476208", "1?continue") in new stack
-- Goto (macro-user-callerid,s,23)
-- Executing [s@macro-user-callerid:23] NoOp("SIP/27-09476208", "Using CallerID "Rob Riccardelli-JR" <27>") in new stack
-- Executing [s@macro-dialout-trunk:11] Macro("SIP/27-09476208", "record-enable|27|OUT") in new stack
-- Executing [s@macro-record-enable:1] GotoIf("SIP/27-09476208", "0?2:4") in new stack
-- Goto (macro-record-enable,s,4)
-- Executing [s@macro-record-enable:4] AGI("SIP/27-09476208", "recordingcheck|20080210-172357|1202682237.52") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/recordingcheck
recordingcheck|20080210-172357|1202682237.52: Outbound recording not enabled
-- AGI Script recordingcheck completed, returning 0
-- Executing [s@macro-record-enable:5] NoOp("SIP/27-09476208", "No recording needed") in new stack
-- Executing [s@macro-dialout-trunk:12] GotoIf("SIP/27-09476208", "0?skipoutcid") in new stack
-- Executing [s@macro-dialout-trunk:13] Set("SIP/27-09476208", "DIAL_TRUNK_OPTIONS=") in new stack
-- Executing [s@macro-dialout-trunk:14] Macro("SIP/27-09476208", "outbound-callerid|1") in new stack
-- Executing [s@macro-outbound-callerid:1] GotoIf("SIP/27-09476208", "1?start") in new stack
-- Goto (macro-outbound-callerid,s,3)
-- Executing [s@macro-outbound-callerid:3] NoOp("SIP/27-09476208", "REALCALLERIDNUM is 27") in new stack
-- Executing [s@macro-outbound-callerid:4] GotoIf("SIP/27-09476208", "1?normcid") in new stack
-- Goto (macro-outbound-callerid,s,9)
-- Executing [s@macro-outbound-callerid:9] Set("SIP/27-09476208", "USEROUTCID=") in new stack
-- Executing [s@macro-outbound-callerid:10] Set("SIP/27-09476208", "EMERGENCYCID=") in new stack
-- Executing [s@macro-outbound-callerid:11] Set("SIP/27-09476208", "TRUNKOUTCID="Times Square Lighting" <8459473034>") in new stack
-- Executing [s@macro-outbound-callerid:12] GotoIf("SIP/27-09476208", "0?trunkcid") in new stack
-- Executing [s@macro-outbound-callerid:13] GotoIf("SIP/27-09476208", "1?trunkcid") in new stack
-- Goto (macro-outbound-callerid,s,16)
-- Executing [s@macro-outbound-callerid:16] GotoIf("SIP/27-09476208", "0?usercid") in new stack
-- Executing [s@macro-outbound-callerid:17] Set("SIP/27-09476208", "CALLERID(all)=Times Square Lighting <8459473034>") in new stack
-- Executing [s@macro-outbound-callerid:18] GotoIf("SIP/27-09476208", "1?report") in new stack
-- Goto (macro-outbound-callerid,s,22)
-- Executing [s@macro-outbound-callerid:22] NoOp("SIP/27-09476208", "CallerID set to "Times Square Lighting" <8459473034>") in new stack
-- Executing [s@macro-dialout-trunk:15] GotoIf("SIP/27-09476208", "0?nomax") in new stack
-- Executing [s@macro-dialout-trunk:16] GotoIf("SIP/27-09476208", "0?chanfull") in new stack
-- Executing [s@macro-dialout-trunk:17] AGI("SIP/27-09476208", "fixlocalprefix") in new stack
-- Launched AGI Script /var/lib/asterisk/agi-bin/fixlocalprefix
> fixlocalprefix: Using pattern 1845|NXXXXXX
-- AGI Script fixlocalprefix completed, returning 0
-- Executing [s@macro-dialout-trunk:18] Set("SIP/27-09476208", "OUTNUM=wMY PHONE NUMBER") in new stack
-- Executing [s@macro-dialout-trunk:19] Set("SIP/27-09476208", "custom=ZAP/g0") in new stack
-- Executing [s@macro-dialout-trunk:20] GotoIf("SIP/27-09476208", "1?gocall") in new stack
-- Goto (macro-dialout-trunk,s,22)
-- Executing [s@macro-dialout-trunk:22] Macro("SIP/27-09476208", "dialout-trunk-predial-hook") in new stack
-- Executing [s@macro-dialout-trunk:23] GotoIf("SIP/27-09476208", "0?bypass|1") in new stack
-- Executing [s@macro-dialout-trunk:24] GotoIf("SIP/27-09476208", "0?customtrunk") in new stack
-- Executing [s@macro-dialout-trunk:25] Dial("SIP/27-09476208", "ZAP/g0/wMY PHONE NUMBER|300|") in new stack
-- Called g0/wMY PHONE NUMBER
-- Hungup 'Zap/1-1'
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [s@macro-dialout-trunk:26] Goto("SIP/27-09476208", "s-CHANUNAVAIL|1") in new stack
-- Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)
-- Executing [s-CHANUNAVAIL@macro-dialout-trunk:1] GotoIf("SIP/27-09476208", "1?noreport") in new stack
-- Goto (macro-dialout-trunk,s-CHANUNAVAIL,3)
-- Executing [s-CHANUNAVAIL@macro-dialout-trunk:3] NoOp("SIP/27-09476208", "TRUNK Dial failed due to CHANUNAVAIL - failing through to other trunks") in new stack
-- Executing [MY PHONE NUMBER@from-internal:3] Macro("SIP/27-09476208", "outisbusy|") in new stack
-- Executing [s@macro-outisbusy:1] Playback("SIP/27-09476208", "all-circuits-busy-now|noanswer") in new stack
-- <SIP/27-09476208> Playing 'all-circuits-busy-now' (language 'en')
== Spawn extension (macro-outisbusy, s, 1) exited non-zero on 'SIP/27-09476208' in macro 'outisbusy'
== Spawn extension (macro-outisbusy, s, 1) exited non-zero on 'SIP/27-09476208'Keep in mind that all channels are completely inactive. It's sunday and I'm the only one at work and nobody is calling in.
The only way I can kind-of make this more bearable for the employees is to set the outbound trunk sequence to:
ZAP/6
ZAP/5
ZAP/4
ZAP/3
ZAP/2
ZAP/1
ZAP/g0
If I do this, the card will be forced to try each channel and then g0 again. Most of the time, this routine will find a channel that responds properly to allow an outbound call. Sometime is doesn't. I would guess about 20% of the time, the number must be redialed.
Like I said, this problem just cropped up after the new firmware was applied to fix the disconnect supervision issue. We were using 2.4.0 until today when I installed 2.4.2 fresh in an attempt to start from a clean slate. Still have this problem.
At this point, I'm quite embarrassed because there is nothing but a stream of problems with the Trixbox install that I'm responsible for. Many of them were not related to Rhino, but I just can't seem to catch a break. One day, I would just like to be able to enjoy worry-free phones.
I have contacted Rhino via email again, but I would like to get this solved as soon as possible. Please help!
Experiencing the same exact issue
Thu, 02/14/2008 - 2:20pm
Experiencing the same exact issue with a Trixbox 2.2.12 installation utilizing a Rhino R8FXX-EC card with 6 FXO channels configured with the new firmware that provides the call disconnect fix.
It is also a very inconsistent issue that I see on my client's server. I've triple verified the status of the PSTN lines and each time all of them are idle. I can usually only make 1 call at a time, sometimes I can make a couple calls....But, it's very much a luck thing.
Rhino representatives, is this a common issue that has now surfaced after the firmware upgrade? Any assistance would be greatly appreciated.
Best regards
Surprised and disappointed that Rhino Support Hasn't Responded
Fri, 02/15/2008 - 12:07pm
I'm very suprised and disappointed that Rhino Support hasn't responded to this issue. This isn't really like them to not be responsive to a critical issue such as this. I hope and pray that Rhino Support replies to this issue today or tomorrow. Even if it's to say that they are looking into it or some comparable response.
Best regards
Mark,
Thanks for the fast
Fri, 02/15/2008 - 3:28pm
Mark,
Thanks for the fast response, I actually already commented that line out. It was in another thread I read eariler. I still have the same problem. I have no doubt this is a rhino issue, my digium card works fine and my log looks exactly like the one above. it ends with CHANUNAVAIL - failing through to other trunks") in new stack. Just like that one
Any Resolution or Response from Rhino - anyone?
Fri, 02/22/2008 - 6:45am
Has anyone found a resolution to this issue? Or, has anyone received a response/reply from Rhino? It seems that this issue has gone on for quite some time with no response from the vendor that is supposed to be moderating this forum.
I would personally expect at least we're working on it or it isn't our issue and why......
Rhino, Please assist us with this super pain in the neck issue. Thank you!
Still waiting for a reply/response from Rhino
Mon, 02/25/2008 - 10:01am
We are experiencing the same
Mon, 02/25/2008 - 4:40pm
We are experiencing the same problem also. Actually I'm having several different issues.
1. random ring backs- no response from message board and very little when I emailed rhino support, asking asterisk log records, that I email and have not received anything back, still waiting.
2. now all "circuits busy", we just discover today preparing for a install for tomorrow and customer called me this evening telling me about "all circuits busy", we just install last week
I might have to really reconsider rhino cards now, I have 6 more installs and having nothing but problems lately started with disconnect issues, ring backs, now all circuit busy.
I really need solutions
I once recall I was playing
Wed, 02/27/2008 - 1:21pm
I once recall I was playing with rx/tx levels (working on echo at the time) and caused a digium card to no longer see that the line was available. I would get the all circiuts are busy now error were in fact they were not in use. Once I put the rx/tx levels back It would see the lines.
I may be taking a stab in the wrong direction but it seems that if the disconnect fix in the latest firmware is now causing these new issues on certain POTS lines and it may be due to the fact the the card is too sensitive (or not sensitive enougf) to see the line properly.
I also recall a post by bubbapcguy to check how hot the POTS lines are when it came to fxo line issues. Perhaps you guys that are experiencing the hangup issues and now all circuits are busy may have somthing in common with how hot your POTS are. I am not sure what the line specs should be for asterisk but maybee this has somthing to do with the problem too? Come to think of it any time that asterisk or vendors update code and firmware it seems to change how senstive the hardware sees the lines. In result its not uncommon to read on the board that these changes also cause new problems with echo, and line problems (disconect supervision for instance)
has anyone ran "zap show channel 1" (1 being the channel or port on the card) or zttool too see what asterisk is claiming the card is seing?
Just some ideas with my two cents, not sure if it will help
crees
Test the POTS
Wed, 02/27/2008 - 10:44pm
Now just to clarify I am not sayting this is the Phone companies problem, But I feel that depending on what kind connection your getting with your POTS (line voltages etc) may be contributing to the problem. If this is the case, then finding out what line quality people get may help determin what settings/code/firmware is needed to deal with the line properly.
When I get a second tonight I will fire up my rhino test box and see what results I get (disconnect supervission and circuit status) and I will also see if I can measure the POTS voltage (IMPORTANT - this will be done carefully and will not be measured off the card but instead will be mesured at the jack). I will report my findings and see if this info is of any use or if its relative to the problem.
Ok I researched more info on POTS lines and standards and also CPC (Calling Party Control) Some really good info here that may/maynot be relative to the problems
http://www.sandman.com/cpcbull.html
crees
Calls are going to blank for few Seconds
Thu, 02/28/2008 - 7:54am
Your post doesn't really go with the flow of this issue
Thu, 02/28/2008 - 11:58am
jayakandan,
F.Y.I....The issue you're experiencing isn't really a part of this issue. You seem to be having something happening at the Network Interface/OS level and not a Rhino Equipment issue.
I would first ensure that you have a solid network that isn't having any issues....Verify NIC interface, cables, switch, etc.....Or, it could be the hardware that you're running Trixbox on....You could also try firing up another PC with Trixbox and see if you still have the same issues on the same network.....Just a few Ideas....I know it's frustrating when we install, configure all of the hardware and it doesn't work......I wish you luck toward a rapid resolution of your issues.
Best regards,
Luis
Successful day with Sangoma
Thu, 02/28/2008 - 3:19pm
Whats the odd for me
Thu, 02/28/2008 - 5:57pm
Whats the odd for me returning 5 rhino cards ?
I've been in contact with rhino just thru email since friday last week. still no solution, just asking me, do I have call waiting on, voicemail on, what type of hardware these cards are installed in, what version firmware, drivers. Thank god 4 of 5 of my customers been patient, just 1 complainting everyday, and I do not blame him, he has a business and relies on his phones to work. The Rhino is just not working out. I even had the phone company out to test the lines, they could not find any problems. So at this time, things are not looking good for me.
Do I go back to ver 1b on the firmware and deal with the disconnect issues or stay on ver 1c and deal with phantom ring back and all circuit busy.
Sorry I 'm just venting here, its been a tough week.
Mike
This is not. I will repeat
Tue, 03/04/2008 - 4:29pm
This is not. I will repeat this is not an issue with Rhino cards. Please not that the recent releases of Asterisk have broken allot of things. It may be of use to start monitoring the Digium bugs. We are of course looking into finding a way to remedy what exactly needs to be done. I am sorry if anyone is having difficulties with out support, with this said I would like to state that we are trying our utmost to fix issues that do not originate with us. We found a solution when the asterisk revisions were not disconnecting properly so we altered our code and we will continue to try and evolve with every new asterisk ans zaptel revision as timely as possible. Please have a bit of patience we are working on these issues very diligently.
I will confirm that rhino
Tue, 03/04/2008 - 5:12pm
I will confirm that rhino has been working with my issues, "ring backs" and "all circuit busy". after upgrading the new beta firmware, we were almost able to duplicate the "ring backs" everytime. We have a extra line at the office that doesn't have caller id, we use that line to call in, the phones display "unknown caller" we answer,say something, then hang up, the caller hangs up. 10 to 20 seconds later phones ring again shows "unknown caller" we answer again, nobody there, we hang up. I have a feeling this could be related to CALLER ID. I'm going back to firmware 1c to see if we can duplicate the issue tommrow.
The two things I have notice when we had the tdm400 card in, it picks up caller id everytime when I call in with my cell phone. When I have the rhino card in, caller id is not picked up everytime. Why was this overlooked ? We had privacy manager turned on. turned off now.
All circuits busy, we key in the numbers to dial out phone system announces "all circuit busy" we hang up, repeat, you might get lucky and able to dial out on the next try. Of course this does not happen every time.
Not a Rhino problem?
Wed, 03/05/2008 - 7:58am
ahonea wrote:
This is not. I will repeat this is not an issue with Rhino cards.
Well, it's certainly an issue with the Rhino card I had to remove from our phone system.
ahonea wrote:
I am sorry if anyone is having difficulties with out support, with this said I would like to state that we are trying our utmost to fix issues that do not originate with us.
I wouldn't classify ignoring emails and this thread for 3 weeks "trying our utmost." I had to spend $800 on a competitive solution to solve my problem after your finger-pointing and lack of response.
ahonea wrote:
Please have a bit of patience we are working on these issues very diligently.
I've experienced your past two show-stopping bugs seemingly earlier than most people. When I had the disconnect issue back in mid December, you SSH'd into my system twice and even did a hardware swap. I appreciate the quick service there, but the best you could come up with was that Verizon was doing something wrong. Of course, we know now that this was not the case. We had screwed-up phones for two months or so before a miraculous firmware patch was issued suddenly for the disconnect issue.
The same day I applied the beta firmware for the disconnect issue, I emailed and told you that we now have this "all circuits are busy" problem. You stated that you hadn't heard this issue yet and asked for me to follow up on my findings. I went as far as to blow away our trixbox 2.2 setup and install 2.4 from a clean slate. The issue was still present, and I emailed explaining this on February 10th. To this date, there has been no direct response and, until your post in this thread, no acknowledgment that anything was being done.
ahonea wrote:
Please have a bit of patience we are working on these issues very diligently.
3 months is enough patience, I think. On top of that, these issues are still not fixed. The more time that went by without our phones working properly, the more I look like an ass. When I have no answers to give on the status of getting them to work, I look like I'm slacking on something as important and basic as the office telephones. Personally, I don't think I could ever look at a Rhino product seriously ever again.
-Rob Riccardelli
PS- Anyone interested in buying an R8FXX-EC populated with 4 FXO modules? According to Rhino, it works perfectly. Just don't attempt to run it with Asterisk.
We are very sorry your
Wed, 03/05/2008 - 9:56am
We are very sorry your having difficulty, your issue is an exception
not the rule. We test all of our cards in real world and extreme
environments. Unfortunately with the state of infrastructure and the
number of phone companies making up their own rules on standards we
can not necessarily account for all instances. We do our best to find
out what is going on and even if its outside our purview we do are
best to correct it. Unfortunately not all issues can be solved
straight away. We are working on this issue and others but are
unfortunately limited. We cant fix everything but we try and sometimes
we lose. I can say allot of companies throw up the "not my problem
card" which may be acceptable, however I think our flaw is we take
ownership of others issues so we sometimes fails would not have even
tried. We offer a money back guarantee of 30 Days on our products but
in your case I think I can help. I really do apologize Rhino didn't
work in your case and I will issue an RMA for refund if you contact me.
Regards.
I hear what you're saying
Wed, 03/05/2008 - 3:00pm
Rhino Team,
Being an individual that works in technology, I clearly understand that sometimes bugs/issues happen. It's unrealistic to believe that everything one deploys is going to always work 100% the first time around. No one or nothing is perfect.
My greatest issue really has to do with the points listed below. I know this doesn't get us closer to a solution, but I really didn't like the previous responses provided.
1. This topic has been floating for many weeks with no response from Rhino. I even private messaged James myself and got no response.
2. Many individuals are experiencing the very same issue and have tried clean installs with no difference.
3. Servers with Digium and Sangoma cards aren't having this issue.
4. Servers that had Rhino and now have Sangoma cards have resolved their issues.
In this particular case, these cards aren't "Free". We pay and we pay pretty good money for your cards. My expectation would be to get responses and solutions to issues that we experience with your products. Nothing more and nothing less.
I look forward to a solution to this issue in a timely manner.
I do want to end with the fact that I have seen Rhino responsive in the past - but not on this occassion.....
Thank you in advance for your assistance and patience with those of us that have been living with this issue and having to face our clients day-in-day-out.
Best regards
I personally try to make it
Thu, 03/06/2008 - 6:58am
I personally try to make it a point to be as available as possible. I do my best to float between 4 forums, 2 mailing lists and still get other things accomplished. I will admit the last 2 months has been crazy working on special projects. I do filter through hundreds of messages a day and honestly I missed this one. As of 9pm last night there were emails floating around our engineering team about this issue and our programmer is combing the code. I am dedicating today to this issue. Please note even though we "moderate" these forums it is not an efficient support channel for certain things. If you are having hardware difficulty and are not finding an answer here from either a Rhino employee or community member PLEASE use an official support channel.
By Email support@rhinoequipment.com
By Phone 1-877-RHINO-T1 Option 2
By Web https://support.rhinoequipment.com
From my understanding there are less than a hand-full of people with this issue. If you are one of them and would like to help with testing any solution we devise please email our support team. (Mike we have your info)
Thanks
Keep you updated
I've been
Sat, 03/08/2008 - 5:15am
Keep you updated
I've been working with rhino the past few days. The new firmware looks very promising. We've been just focusing on "all circuit busy" right now. Last night I upgraded. Setup remote extension from my house to the office made numerous calls out, did not get any "all circuit busy". Unfortunately I cannot get to the office today, Cincinnati is being hit by a major snow storm. I'll keep testing remotely from my house and keep you posted.
Once again thanks amanda, jim , and james for all your help on this issue.
We are doins a
Wed, 03/12/2008 - 6:54am
We are doing a semi-controlled beta right now If you are having these issues and would like to try the new firmware please contact support@rhinoequipment.com
Thanks....
All Circuits Busy
Thu, 03/13/2008 - 10:43pm
Hi James:
If you remember me, I was having the disconnect issue with Bell Canada. But luckily enough, the client have Allstream and they are providing disconnect signal right away. So the 12 second delay issue is not there anymore and Rhino card with the solution for disconnect issue has been working really great.
After my client went live in Feb 22, I heard a few complaints about all circuit busy. I told them maybe because they are using up all 4 of their ZAP lines and I configured a VOIP line to use if ZAP is not available. Since then I have not heard any complain but now after reading this forum I am beginning to think that maybe they are still having this issue and adding a VOIP trunk in the sequence is just bypassing the issue.
I also heard complains about DTMF not always working perfectly. Do you suggest I upgrade their firmware as well?
Thanks,
Kim
MiamiMan,
All testing is
Mon, 03/17/2008 - 8:00am
MiamiMan,
All testing is looking good, If you are having the problems listed here feel free to email support @ rhinoequipment.com and request upgrade instructions and the latest firmware file. I think sometime this week if all goes well we will push it out of beta. From what we have seen and with the help of some great customers this looks solid.
Everybody
I've been working
Mon, 03/17/2008 - 12:17pm
Please note that the latest
Mon, 03/24/2008 - 8:46am
Please note that the latest update we have is revision 1.14beta4
ftp://ftp.rhinoequipment.com/Drivers/Beta/rcbfx_114beta4.fw
The instructions are
Mon, 03/24/2008 - 7:05pm
The instructions are below... You can see these and much more on our new support portal
https://support.rhinoequipment.com
1) Download the latest firmware onto your server
wget ftp://ftp.rhinoequipment.com/Drivers/Beta/rcbfx_114beta4.fw
2) Rename the downloaded file to rcbfx.fw
mv rcbfx_114beta4.fw rcbfx.fw
3) Install the firmware
Install -m 644 rcbfx.fw /lib/firmware/
4) Stop Asterisk
killall -9 safe_asterisk (for FreePBX users)
killall -9 asterisk (all)
5) Remove the module from memory
rmmod rcbfx
6) Load the module into memory
modprobe rcbfx
7) Load the channels back in to zaptel
ztcfg -vvv
8) Restart Asterisk
asterisk
amportal start (FreePBX users)
DTMF Problem with Rhino Card?
Tue, 03/25/2008 - 9:53am
Anybody having DTMF issue connecting to a remote/external IVR with Rhino FXO cards? I have a client with Rhino 8FXX-EC card having problem.
On a test system, I did an exact configuration as my client's but I did it with a Digium X100P clone since I do not have a spare Rhino card to test with and I do not have any problem punching in numbers on a remote IVR.
Can someone please verify if they can call a credit card or a company they know have IVR and test it. I am using Trixbox 2.4.2.0
Thanks,
Kim
Firmware update
Tue, 04/01/2008 - 2:04am
I followed the directions for firmware update above and am posting the results of 'dmesg | grep rcbfx'. Not sure if this output is normal. I did a test call into the system and the IVR answered as normal, but the volume was very quiet. I changed the gain in zapata.conf the 8.0 rx and tx. I'm try to solve a dropped call issue on a 2.4.2 Trixbox system. Here is the output:
[trixbox1.localdomain ~]# dmesg | grep rcbfx
rcbfx 1: Rhino PCI BAR0 ff8fe000 IOMem mapped at ef924000
rcbfx 1: Waiting for response from card .........
rcbfx 1: Firmware Version 1.b
rcbfx 1: Firmware File Version is 1.b
rcbfx 1: Hardware version 10
rcbfx 1: G168 DSP App file size = 50928 c6f0
rcbfx 1: G168 DSP Ping DSP Version 106
rcbfx 1: G168 DSP Active and Servicing 4 Channels - f
rcbfx 1: Starting DMA
rcbfx 1: Spotted a Rhino: Rhino RCB24FXX (2 modules)
rcbfx 1: Use Count 3
rcbfx 1: Use Count 2
rcbfx 1: Use Count 1
rcbfx 1: Use Count 0
rcbfx 1: Released a Rhino
rcbfx 1: Rhino PCI BAR0 ff8fe000 IOMem mapped at efb36000
rcbfx 1: Waiting for response from card .........
rcbfx 1: Firmware Version 1.b
rcbfx 1: Firmware File Version is 1.e
rcbfx 1: Firmware Uprgrade In Progress -- Do Not Interrupt!!
rcbfx 1: New Firmware is 75ceh bytes - loading into 800h to 7dceh
rcbfx 1: Starting to send firmware
rcbfx 1: Acked block 1 of 75 rcbfx 1: Acked block 2 of 75 rcbfx 1: Acked block 3 of 75 rcbfx 1: Acked block 4 of 75 rcbfx 1: Acked block 5 of 75 rcbfx 1: Acked block 6 of 75 rcbfx 1: Acked block 7 of 75 rcbfx 1: Acked block 8 of 75 rcbfx 1: Acked block 9 of 75 rcbfx 1: Acked block a of 75 rcbfx 1: Acked block b of 75 rcbfx 1: Acked block c of 75 rcbfx 1: Acked block d of 75 rcbfx 1: Acked block e of 75 rcbfx 1: Acked block f of 75 rcbfx 1: Acked block 10 of 75 rcbfx 1: Acked block 11 of 75 rcbfx 1: Acked block 12 of 75 rcbfx 1: Acked block 13 of 75 rcbfx 1: Acked block 14 of 75 rcbfx 1: Acked block 15 of 75 rcbfx 1: Acked block 16 of 75 rcbfx 1: Acked block 17 of 75 rcbfx 1: Acked block 18 of 75 rcbfx 1: Acked block 19 of 75 rcbfx 1: Acked block 1a of 75 rcbfx 1: Acked block 1b of 75 rcbfx 1: Acked block 1c of 75 rcbfx 1: Acked block 1d of 75 rcbfx 1: Acked block 1e of 75 rcbfx 1: Acked block 1f of 75 rcbfx 1: Acked block 20 of 75 rcbfx 1: Acked block 21 of 75 rcbfx 1: Acked block 22 of 75 rcbfx 1: Acked block 23 of 75 rcbfx 1: Acked block 24 of 75 rcbfx 1: Acked block 25 of 75 rcbfx 1: Acked block 26 of 75 rcbfx 1: Acked block 27 of 75 rcbfx 1: Acked block 28 of 75 rcbfx 1: Acked block 29 of 75 rcbfx 1: Acked block 2a of 75 rcbfx 1: Acked block 2b of 75 rcbfx 1: Acked block 2c of 75 rcbfx 1: Acked block 2d of 75 rcbfx 1: Acked block 2e of 75 rcbfx 1: Acked block 2f of 75 rcbfx 1: Acked block 30 of 75 rcbfx 1: Acked block 31 of 75 rcbfx 1: Acked block 32 of 75 rcbfx 1: Acked block 33 of 75 rcbfx 1: Acked block 34 of 75 rcbfx 1: Acked block 35 of 75 rcbfx 1: Acked block 36 of 75 rcbfx 1: Acked block 37 of 75 rcbfx 1: Acked block 38 of 75 rcbfx 1: Acked block 39 of 75 rcbfx 1: Acked block 3a of 75 rcbfx 1: Acked block 3b of 75 rcbfx 1: Acked block 3c of 75 rcbfx 1: Acked block 3d of 75 rcbfx 1: Acked block 3e of 75 rcbfx 1: Acked block 3f of 75 rcbfx 1: Acked block 40 of 75 rcbfx 1: Acked block 41 of 75 rcbfx 1: Acked block 42 of 75 rcbfx 1: Acked block 43 of 75 rcbfx 1: Acked block 44 of 75 rcbfx 1: Acked block 45 of 75 rcbfx 1: Acked block 46 of 75 rcbfx 1: Acked block 47 of 75 rcbfx 1: Acked block 48 of 75 rcbfx 1: Acked block 49 of 75 rcbfx 1: Acked block 4a of 75 rcbfx 1: Acked block 4b of 75 rcbfx 1: Acked block 4c of 75 rcbfx 1: Acked block 4d of 75 rcbfx 1: Acked block 4e of 75 rcbfx 1: Acked block 4f of 75 rcbfx 1: Acked block 50 of 75 rcbfx 1: Acked block 51 of 75 rcbfx 1: Acked block 52 of 75 rcbfx 1: Acked block 53 of 75 rcbfx 1: Acked block 54 of 75 rcbfx 1: Acked block 55 of 75 rcbfx 1: Acked block 56 of 75 rcbfx 1: Acked block 57 of 75 rcbfx 1: Acked block 58 of 75 rcbfx 1: Acked block 59 of 75 rcbfx 1: Acked block 5a of 75 rcbfx 1: Acked block 5b of 75 rcbfx 1: Acked block 5c of 75 rcbfx 1: Acked block 5d of 75 rcbfx 1: Acked block 5e of 75 rcbfx 1: Acked block 5f of 75 rcbfx 1: Acked block 60 of 75 rcbfx 1: Acked block 61 of 75 rcbfx 1: Acked block 62 of 75 rcbfx 1: Acked block 63 of 75 rcbfx 1: Acked block 64 of 75 rcbfx 1: Acked block 65 of 75 rcbfx 1: Acked block 66 of 75 rcbfx 1: Acked block 67 of 75 rcbfx 1: Acked block 68 of 75 rcbfx 1: Acked block 69 of 75 rcbfx 1: Acked block 6a of 75 rcbfx 1: Acked block 6b of 75 rcbfx 1: Acked block 6c of 75 rcbfx 1: Acked block 6d of 75 rcbfx 1: Acked block 6e of 75 rcbfx 1: Acked block 6f of 75 rcbfx 1: Acked block 70 of 75 rcbfx 1: Acked block 71 of 75 rcbfx 1: Acked block 72 of 75 rcbfx 1: Acked block 73 of 75 rcbfx 1: Acked block 74 of 75 rcbfx 1: Acked block 75 of 75 rcbfx 1: Sent partial block 76
rcbfx 1: Acked partial block 76
rcbfx 1: All blocks transfered and acked
rcbfx 1: Hardware version 10
rcbfx 1: G168 DSP App file size = 50928 c6f0
rcbfx 1: G168 DSP Ping DSP Version 106
rcbfx 1: G168 DSP Active and Servicing 4 Channels - f
rcbfx 1: Starting DMA
rcbfx 1: Spotted a Rhino: Rhino RCB24FXX (2 modules)
rcbfx 1: Use Count 3
rcbfx 1: Use Count 2
rcbfx 1: Use Count 1
rcbfx 1: Use Count 0
Disregard last post
Tue, 04/01/2008 - 3:05am
Disregard last post. I rebooted system and now dmesg appears normal.
[trixbox1.localdomain ~]# dmesg | grep rcbfx
rcbfx 1: Rhino PCI BAR0 ff8fe000 IOMem mapped at ef852000
rcbfx 1: Waiting for response from card .........
rcbfx 1: Firmware Version 1.e
rcbfx 1: Firmware File Version is 1.e
rcbfx 1: Hardware version 10
rcbfx 1: G168 DSP App file size = 50928 c6f0
rcbfx 1: G168 DSP Ping DSP Version 106
rcbfx 1: G168 DSP Active and Servicing 4 Channels - f
rcbfx 1: Starting DMA
rcbfx 1: Spotted a Rhino: Rhino RCB24FXX (2 modules)
We have had good success so
Wed, 04/02/2008 - 2:56pm
We have had good success so far, Our programmer has been working with a customer who has the perfect "no ones lines could be this wacky" lines and so we have been using him to tweak and fine tune the firmware to a state where we feel like if it will work here it will work anywhere.
Latest Beta is at " ftp://ftp.rhinoequipment.com/Drivers/Beta/rcbfx_114beta5.fw "
Feel free to load it up we have had good luck with it and worst case you just roll it back....
Well the target date was
Thu, 04/03/2008 - 8:49am
Well the target date was last Monday but our engineer is a bit of a perfectionist so it was delayed. We are having an engineering meeting this morning, we may be able to release it today or they may wish to let the beta status ride the weekend. I will update this when I hear something.
Hi,
I've installed all the
Wed, 04/09/2008 - 4:28pm
Hi,
I've installed all the latest firmware and drivers for my RXX 8FXO card, on Trixbox 2.6. After an initial install, setting up a single Extension, and not modifying any of the conf files, I can't get the card to answer incoming calls any earlier than about 3 rings. Is there something obvious in the zaptel conf for this unit that I can change to have it detect incoming calls earlier?
I've been the test subject,
Thu, 04/10/2008 - 7:02am
I've been the test subject, and working with Rhino. I must say, the guys at Rhino are working very hard. I never work with a vendor who has put so much effort in resolving a issue. If and when we resolve the CID and fully test the firmware, Rhino has my business. This said, I think we are very close in finishing up.
Hopefully we are wrapping up
Thu, 04/17/2008 - 5:55pm
Hopefully we are wrapping up here. I've been the test subject working closely with the firmware engineer the past several weeks. This last beta firmware I'm using today, CID is working. I've been testing at work and my house. I like to test more, "ring backs" , "all circuit busy" and "CID" before we release. This said, I personally can not say when it will be released, unless I find something, but my guess sometime next week. I can not make that call.
Once again I cannot stress enough how rhino support work on these issues. These guy's are very professional, I thought many times on giving up on them, but they made it work !
They have my business.
Sorry been a while since I
Fri, 05/02/2008 - 6:35am
Sorry been a while since I touched this thread,
Mike has provided an insane test bed and from our experience if it works for him it will work anywhere. His lines are amazingly awful which has allowed us to debug in ways we have been unable to in the past. We are 100% confident that our beta is good and I know you have heard this before but we are slating a release Monday or Tuesday and it should coincide with our 2.2.6 driver release. The code is cleaned up and ready. This firmware has been optimised and cleaned up so it now runs 8 times faster. The last stage before we release is an engineer is flying out to mikes location to collect data and do the final testing. Somehow at our location we got the worlds perfect Qwest lines, almost as if they knew we would look. The work mike has done has raised the quality and confidence tremendously. I have to say this is what community is about.
Thanks to everyone.....
Everybody
I honestly believe
Mon, 05/05/2008 - 4:11pm
Everybody
I honestly believe the firmware is ready, I tried like hell to break it. "ring back", "all circuit busy, and CID, the issues has been resolved finally. I must have the worst lines in the country.
Tested all day in the office over 100 calls, no problems. Rhino support created a new script to make installing the cards very easy. Download from the package manager. This will only setup the card and install the new drivers, firmware still need to be install manually.
Once again I cannot say how much rhino support team worked on these issues, especially the firmware engineer. We must have tested over 50 different firmware. We resolve the issue Saturday evening, if we were unable to resolve, the engineer was flying out.
I called and gave him the news this evening after testing the firmware/drivers in a live environment today. So look for the firmware soon.
Thanks again Rhino
Mike
Thanks for the update, Mike
Thu, 05/08/2008 - 5:17am
Mike, Appreciate the update and very encourging words on the firmware. Thanks for all of the updates and status that you've provided.
Rhino Support, Any further status on when this final firmware will be released? I know that James stated maybe this past Monday or Tuesday, that the new final firmware would be released. Can you provide another expected release date? Thanks!
Best regards,
Luis
Rhino Support - Status Please
Mon, 05/12/2008 - 11:51am
Hello Rhino Support,
Any word on the final release of the firmware that you've been working with Mike on? I know you stated that last Monday or Tuesday. But, I haven't seen any word from Rhino, so I was curious to know where it stands.
Thanks and best regards,
Luis
Member Since:
2007-03-05