Trixbox 2.2.12 OR 2.4.X with Rhino RCB8Fxx Line not hanging Up
Submitted by thenning on Wed, 01/02/2008 - 4:07pm.
I have trixbox 2.2.04 with a Rhino RCB8Fxx with 3 FXO modules for 6 outgoing lines.
After doing a yum update the POTS lines do not disconnect when the external user hangs-up. If they hang-up in a voicemail message it can result in a rather long message with the annoying disconnect tone. Some messages are over 2 minutes long.
So after trying to modify zapata and zaptel with no success I did a Clean Installed with 2.2.12 in hopes that the symptoms would correct themselves but have had no success.
Here are some particulars:
I reside in the US Minnesota to be specific. My POTS carrier is Qwest.
Zapata.conf
;
; Zapata telephony interface
;
; Configuration file
[trunkgroups]
[channels]
language=en
context=from-zaptel
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
;
; Whether or not to do distinctive ring detection on FXO lines
;
;usedistinctiveringdetection=yes
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=7.0
txgain=2.0
group=0
callgroup=1
pickupgroup=1
immediate=no
;faxdetect=both
faxdetect=incoming
;faxdetect=outgoing
;faxdetect=no
;Include genzaptelconf configs
#include zapata-auto.conf
group=1
;Include AMP configs
#include zapata_additional.conf
*******************************************************************
zapata-auto.conf
; Autogenerated by /usr/sbin/genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;
; Span 1: ZTDUMMY/1 "ZTDUMMY/1 (source: Linux26) 1"
; Span 2: Rhino RCB8FXX/1 "Rhino RCB8FXX/1"
;;; line="1 FXO/1/0"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-zaptel
channel => 1
context=default
;;; line="2 FXO/1/1"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-zaptel
channel => 2
context=default
;;; line="3 FXO/1/2"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-zaptel
channel => 3
context=default
;;; line="4 FXO/1/3"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-zaptel
channel => 4
context=default
;;; line="5 FXO/1/4"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-zaptel
channel => 5
context=default
;;; line="6 FXO/1/5"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-zaptel
channel => 6
context=default
***********************************************************************
zaptel.conf
# Autogenerated by /usr/sbin/genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#
# It must be in the module loading order
# Span 1: ZTDUMMY/1 "ZTDUMMY/1 (source: Linux26) 1"
# Span 2: Rhino RCB8FXX/1 "Rhino RCB8FXX/1"
fxsks=1
fxsks=2
fxsks=3
fxsks=4
fxsks=5
fxsks=6
# Global data
loadzone = us
defaultzone = us
Any ideas or suggestions would be appreciated.
Tim
Firmware version
Tue, 01/08/2008 - 4:34pm
Firmware version is 1.b.
I have been talking on the telephone with both you and James on this.
Tried the busydetect and callprogress options.
You remoted in and checked out my config files.
I did a fresh install of 2.2.12 and did a minimal config and had the same results with the delayed hangup of the POTS line and long busy signal in the voicemail messages.
I'm going to try a minimal install of 2.4 when I get some time to bring the system down.
If that does not work I'll try going back to 2.2.4 which is what I used on the original install that did work correctly!
If none of this works I'll have to suspect hardware or something that Qwest has done to their lines that prevents them from disconnecting.
Thanks
Tim
Rhino Diconnect
Mon, 01/21/2008 - 7:44am
Have you contacted Rhino support? Please Do so, So this issue gets accelerated.
They claim this is a Asterisk / Zaptel problem!
As I stated above I built this system with Trixbox 2.2.4 and did not have this issue. As I Upgraded the problem started.
It appears that the latest 2.2 and 2.4 Trixbox have the issue with Rhino Analog.
Tim
Voice Mail press #
Mon, 01/21/2008 - 8:08am
On a inbound call if it goes to VM and the caller hangs up the line never disconnects if the caller terminates the call pressing the # key as instructed by VM instructions the call hangs up the way it should. Since the call can be hung up properly I wouldnt think this is a hardware issue.
THENNING
Mon, 01/21/2008 - 9:32am
Sorry if I Confused you I DO NOT think this is a hardware issue. If it were, Pressing # when terminating a voicemail would not disconnect the call . Im also getting a dial tone as a VM message which I think would mean it hung up but the zap channel stayed open, in any case I'm going to try and figure out what update caused this problem to surface.
LANCEKOSTER
Mon, 01/21/2008 - 10:42am
My missread as well!
I personally have not been able to bring my system down and reload with 2.2.4 which seemed to work correctly. If I can get a weekend I will also try to go back to determine the start of the problem. I know going to 2.4.X does not solve the issue. And a clean install of 2.2.12 does not solve it either.
If you come up with anything I will try to confirm your findings and will also pass mine along as well
Tim
This worked
Mon, 01/21/2008 - 1:08pm
TRY THIS
Insert this in your zapata.conf file
busydetect=yes
busycount=4
This causes the channel to hangup after the busy tones from your provider are heard.
It takes around 10 sec. But at least it hangs up, if your listening to a voice mail your hear the busy tones and thats the end of the message.
PS I had to reboot to get the setting to work
FYI
Mon, 01/21/2008 - 1:37pm
We believe this to be a bug in asterisk. We have done our best to reproduce the issue so we can work towards a solution but as of yet we can't replicate the issue. We have seen reports of this same thing happening on digium and sangoma cards thats why we point to software. As soon as we replicate it we will report back weather in the form of a fix or with a bug report to asterisk. As stated above you can use callprogress and busydetect to create fake supervision which isn't the most efficient method but it does work.
I'm having this issue as
Mon, 01/21/2008 - 2:01pm
I'm having this issue as well. On 2 brand new Ceros machines with RCB24FXX cards in them. I'd really like to know what's going on here as well.
Here is the link to what I'm experiencing:
http://www.trixbox.org/forums/trixbox-forums/trunks/issues-trixbo...
James - you and I spoke about this last week as well.
This DID NOT work
Mon, 01/21/2008 - 3:59pm
lancekoster,
TRY THIS
Insert this in your zapata.conf file
busydetect=yes
busycount=4
This causes the channel to hangup after the busy tones from your provider are heard.
It takes around 10 sec. But at least it hangs up, if your listening to a voice mail your hear the busy tones and thats the end of the message.
PS I had to reboot to get the setting to work
This Did not work for me. I've tried this b4 with many variations but no luck.
I see the Rhino reps have finally responded. Thank you!
sorry to hear your not able to duplicate the problem. It appears more and more people are seeing it.
Hopefully someone will find a solution as to why this is happening.
I will continue to try things Time and equipment availability permitting.
Tim
This is looking like a bug
Tue, 01/22/2008 - 11:45am
This is looking like a bug in native bridging within asterisk based on reports of the issue with all hardware vendors here and within other forums and mailing lists. We are still not able to reproduce the issue but are dedicated to finding a solution for the community and not just a bandaid fix. Anyone having this issue weather it is with our cards, a digium card, a sangoma card or some 3rd world knock off please email me (jfinstrom (at) rhinoequipment.com) the following. Your hardware ( cards and sip phone) manufacturer and model. Your phone service provider. and the steps you take to reproduce the issue and the exact symptoms.
With this data we should be able to get an answer to the issue and hopefully a patch to whichever project is dropping the ball.
NOTE: any testers out there who have both a lab and real world connections that can reproduce this issue, please also contribute any findings thanks
only rhino cards
Wed, 01/23/2008 - 7:29am
re:
Thu, 01/24/2008 - 7:28am
Right, once change to digium card the ghost calls or dropped calls were history.
One other thing. I installed the Rhino card into the other system where the Digium card was removed from and now that system has the ghost calls and dropped calls problem.
I tried posting on Rhino's forum but in order to do so one has to get registed and the site kept rejecting my email addresses and days later the registration form page was broken .. I just gave up on it.
You see I can afford loosing $400 to correct a problem but I cannot afford $350 to get a replacement card that's gonna give me the same problem and risk loosing a client. Voice is still more important than email. You can come up with some tech BS for email issues and everything is forgiven. With voice a dropped call pisses off everyone.
~Bela.
You will notice the top post
Thu, 01/24/2008 - 8:50am
You will notice the top post in our forums says they exist for archival purposes.
I think the Digium card thing was more luck than anything as I have been seeing post regarding these issues on other manufacturers.
The issue we have is we can not reproduce it
edit: We have attempted calls via qwest pstn lines in fact all pots lines in our office terminate qwest.
we have thousands of cards in the field and 2 direct reports to us. This isn't a wide spread issue but seems to be an issue that occurs with the right recipe of card, phone company and asterisk versions.
As you can see from my previous post we do not discount your issue, infact we have been trying to replicate it. My post above asking for information from users having this issue had invoked only the second report, with yours being the first.
Again if we cant reproduce an issue we can't debug it. It seems that requests for information has fallen on deaf ears but we are still requesting. We can only be as timely with results as users are with data for troubleshooting.
Rhino support can always be contacted via https://support.rhinoequipment.com or by phone at 1-877-RHINO-T1.
You may have written Rhino off but we haven't written you or your issue off. Please provide the requested info above and we will still work to replicate and debug the issue.
re:
Thu, 01/24/2008 - 1:41pm
i'm writing off Rhino at all. You're products are feature rich otherwise i would have not gotten it the first place.
All the boxes i set up use verizon and prior to post on the forum i had them come out many times to look for ground, burst etc issues on each line where rhino cards were installed. i'm positive you're backing up every customer you have with great support.
~Bela.
This is a problem with Sangoma on TB2.4 as well
Fri, 01/25/2008 - 6:35pm
I have been able to replicate this with TB 2.4 using a Sangoma A200 card.
For my own experience I think it is strange since this only happens on my 3rd channel, and then only if the third channel is dialed from the outside, and not if I use the third channel to dial out.
I'm currently working with my vendor on this, but I will try all of the above as well.
As a "quick fix" I set the maxmessage length in my Voicemail system to 120 secords. This at least allows my Voicemail system to hang up.
If any Fonality people want to take a look at any logs, please let me know.
-Steve
Here is what I have done so
Fri, 01/25/2008 - 9:43pm
Here is what I have done so far still no luck making it fail.
Sketch box ->fxo->zaptel->asterisk->zaptel->fxo->Qwest POTS ->AT&T wireless... OK
Channelbank with 1s batt pull ->fxo->zaptel->asterisk->zaptel->fxo->Qwest POTS ->AT&T wireless... OK
Qwest POTS ->fxo->zaptel->asterisk->zaptel->fxo->Qwest POTS ->AT&T wireless... OK
All scenarios have been run with the following.
1. custom bare answer and dial dialplan
2. custom bare answer record and dial dialplan
3. FreePBX Followme Dialplan
We have also tested FreePBX from-pstn and from-zaptel with standard inbound routes.
We will continue to work on this....
I had this same issue with
Fri, 01/25/2008 - 10:34pm
I had this same issue with the cheap x100p card. After updating to trixbox 2.4, I noticed incoming calls to voicemail would hang and not disconnect. Adding busydetect=yes in zapata.conf did not help. The issue was resolved by changing the signaling to loop start along with busydetect=yes. Most FXO lines in the U.S. are loop start.
Not sure it will help with the name brand cards.
kewl start
Mon, 01/28/2008 - 8:14pm
I was using kewl start which is also identified in this original post. I changed the signalling in /etc/zaptel.conf to fxsls=1 and set signalling=fxs_ls in zapata.conf. I am connected to POTS service from my local telephone company. POTS use line side terminations which have loop signaling.
I also have same issue with Sangoma A200
Tue, 01/29/2008 - 11:34pm
Hi,
I have the same issue with Sangoma A200 (8FXO Ports). I also have another system with a clone X100P with same problem - Here is my info:
System 1: Dell Poweredge 840
Sangoma A200 Remora
Trixbox 2.4.02 with Asterisk 1.4 CentOS 5.1
System 2: Compaq Deskpro P3 900Mhz
X100P Clone
Trixbox 2.4.0 Asterisk 1.4 CentOS 5
TELCO: Bell Canada in Toronto
I have two other systems that I will test out soon.
My Problem:
I am calling from a differetn line (Cell, VOIP) to my POTS/PSTN line from Bell Canada that is hooked up to the X100P or Port 1 of the Sangoma Card.
In both cases, when I hang up from my other line, I continue to see the FXO ZAP ringing for 1 or two times then the line is held on. In parallel, I hooked up an analog phone. The analog phone stops ringing instantly. I also am able to hear a click when I hang up my other line. That made me believe that I have disconnect supervision. The click is almost instantly and it sounds like a relay disconnecting and connecting back. So I think I definitely have disconnect supervision.
I then added the following line in zapata.conf
hanguponpolarityswitch
With the above line, I am able to partially solve the problem. Now the incoming calls on my Sangoma Port(s) hangup after about 1.5 rings. But when I remove the line from the Sangoma (or X100P) port and plug it into the analog phone and hangup my other line I can hear the disconnect click on the Bell Analog line immediately.
This makes me believe that the combination of Asterisk and Analog cards are adding some delay (1-2 ring delay) before acting on the disconnect. It could very well be that the recent asterisk-trixbox flavor made the hardware drivers incompatible somehow. I think, the hardware folks can come up with a driver to fix it.
I am still pulling my hair, so hope the above information will help all the hardware guys to come up with a solution.
Thanks,
Kim
Addition: Just tried the X100P clone on Trixbox 2.2.9 which has Asterisk 1.4 and CentOS 4.5.
Results: The line was hanging up after 1.5-2 ring delays even without the hanguponpolarityswitch and adding this line in the zapata.conf did not make any difference. I am using Kwel-Start signalling - Earlier tried calling Bell Canada and after hours of transferring between different tech support I finally ended up to a person in billing - so go figure if I am going to find out anything about it so I assumed that in Toronto Bell probably used Kewl-start.
I will next try an Elastix and AsteriskNow6 beta just to eliminate software related issue. I am trying these with X100P clone hoping that if the clone hangs up properly and instantly then the more powerful sangoma should work.
I have a new piece of
Wed, 01/30/2008 - 2:47pm
I have a new piece of firmware for the RCBFX. In this piece of code we are trying to force asterisk to hangup with extended options. So if anyone would like to be a beta tester of this and allow us to monitor the progress with you this will be a big help for everyone!
If you are interested please send me a private message.
A thought from across the
Wed, 01/30/2008 - 6:34pm
A thought from across the pond
I'm assuming here everyone is using kewlstart and their PSTN lines are providing some sort of valid disconnect supervision (CPC/Disconnect Clear signal).
Another site mentions that some Qwest customers had to have this signal actually enabled (it appears to be switched on by default here in England, at least for business lines..)
http://www.voip-info.org/wiki/index.php?page=Asterisk+Disconnect+...
(as mentioned in the above site, a quick way to check this is to get a phone with an LED illuminated keypad, dial the line from your mobile phone and then hang up, you should see the keypad blink as the battery is removed from the line for the duration of the CPC)
For those who do actually have the signal, could the problems be more to do with the duration of this signal? It appears to vary wildly in duration between telcos and even between the same lines on different exchanges!
I started off with Linksys SPA3102 FXO ports, and at the moment am using the Atcom (digium clone) style cards.
Although I am not using Trixbox these days I started off evaluating the system with the Atcom FXO cards on Trixbox, to get them to recognise disconnect clear signal reliably I had to request that British Telecom increased the Disconnect Clear signalling time from 100ms to 800ms. (In fact 200ms worked with the linksys kit but not with the Atcom/Digium type cards)
I thought I'd seen in the source code somewhere what the normal timing was that Asterisk expects for this signal, but unfortunately I can't recall in which file this was...
IMO it would be worth being able to adjust this as some telcos (such as BT!) provide signals as short as 90ms, particularly on "residential" lines, in a similar way to how Linksys provides this functionality....
Bell Canada does not disconnect for up to 10 seconds
Thu, 01/31/2008 - 12:43am
Actually I've found out that Bell Canada in a situation where the caller hangs up before it is answered, Bell Canada just removes the ring signal but still keeps a hold on to the line for about 10 seconds. They disconnect apprx. 10 seconds later.
So Disconnect Supervision wont work as well as busy detect as I see the phone light blinks after about 10 seconds followed by busy tones.
In this situation can there be anything done to disconnect earlier? I hear a silence between this 10 seconds, can callprogress = yes help?
call progress could help. if
Thu, 01/31/2008 - 6:27am
call progress could help. if BC is not sending the signal there is no way for the card to signal zaptel and in turn signal asterisk. Maybe your best bet is to call BC and say DUDE FIX IT. of course BC is probably like all the other baby bells in the US and will say its not their problem so tuff noogies,,,,
New firmware testing
Thu, 01/31/2008 - 9:52am
Amanda-
I've got the new firmware deployed on both a Trixbox 2.2 and 2.4 system. Seems to be working so far.
This fixed the issue of having 2 zap trunks to the PSTN bridged together if someone forwarded a call off net (or did a conference call). I'm going to monitor it over the next 24-48 hours, but so far it looks good.
Thanks,
If there is no way then why answering machines dont behave this
Thu, 01/31/2008 - 10:49am
Hi James:
Also, I have answering machine hooked up to the line now and I don't get the dialtone recorded. How come the answering machine can handle it and the zap cards+asterisk cannont?
For test, I do see the line stays busy for about 4 seconds though. what I did was, I called the line and when the answering machine answers I hangup and then I call again rightaway and I get busy tones.
The reason for this is I think that the answering machine monitors the ring tone.
and THe zap cards do not monitor the ring tone, so when the ring tone is removed from the line, the ZAP cards continue to ring ending up in a voice mailbox.
Is there a way to monitor to see if the ring tone is removed or not? Your hardware should be able to monitor the voltage on the Ring and Tip and should be able to detect if a ring voltage is there or not - could not you?
Thanks,
Kim
A few things. We have yet to
Thu, 01/31/2008 - 11:21am
A few things. We have yet to be able to reproduce this in our Lab. We have seen this across the manufacturer board. I have reports of issues with Our cards 3 Sangoma 3 digium 1 and clones 1. We are 99% positive the issue lives as a bug in asterisk or zaptel. This is not a blocker as it only happens in certain circumstances. As you can see 7 reports in what amounts to thousands of cards in the field from all OEM's and a clone company. Since we can not replicate the bug we in an attempt to be pro-active took a stab at rewriting our firmware to be more aggressive when talking to zaptel. Basically we turned our request in to a demand with threat of bodily harm :) . Zaptel now seems to understand the gravity of the situation and allows the disconnect. Our success resides with our customers in the field as we again tested with the few people we know about who can consistently replicate this. I would not hold my breath for other manufacturers to follow our lead and rewrite their firmware for a very small minority who are having an issue with a third party product, however if you are using our cards and having issues with the above stated please email support@rhinoequipment.com and we will send instructions. Once the success base gets a little wider we will release the firmware and instructions to the wild (hopefully tomorrow sometime)
I would agree with what
Thu, 01/31/2008 - 12:24pm
I would agree with what James says that the issue lies more within Zaptel, and TBH I think a lot of it is to do with the wildly varying durations of CPC/Disconnect signals - across the world they can be anything from 90ms to an entire second!
Although a lot of newer consumer equipment is made to recognise these signals it has long been the case that either PBX's (including old style ones) had to be programmed to accept the normal CPC duration, or Telecom had to change the signal duration at the exchange
Here's a useful article about the variations and the headaches they have caused to phone system installers for many years (long before VOIP) and (particularly for US people) potential workarounds...
http://www.sandman.com/cpcbull.html
Incidentally for those brave enough to delve into the realms of recompiling Zaptel I found this in the source code (this is what I was referring to yesterday)
Quote:
#define ZT_KEWLTIME 500 /* 500ms for kewl pulse */
#define ZT_AFTERKEWLTIME 300 /* 300ms after kewl pulse */
http://svn.digium.com/view/zaptel/trunk/zaptel.h?revision=3304&vi...
if these constants are what zaptel is expecting to see as a CPC pulse (a 500ms drop and battery returning for 300ms after) if your telco is sending a CPC < 500ms (or none at all!) then I would expect zaptel is never going to correctly recognise the signal on a kewlstart trunk unless its recompiled with a different value in these constants... (NB: i haven't tried this though so can't vouch for certain if this will solve the problem).
Updated Rhino Firmware
Thu, 01/31/2008 - 4:54pm
Preliminary testing shows that the hang-up problems are resolved with this patch. As soon as a caller hangs-up "after leaving a voicemail message" the call is also hung-up on this end in about 1 second.
I'll leave the system in this state with no further updates and provide feedback as to other problems or benefits that may arise.
Thank You - Rhino Team
Tim Henning
Rhino Support Rocks...
About the CPC Singal & Zaptel
Thu, 01/31/2008 - 11:10pm
Actually to be honest, I have a Sangoma Card and a digium clone and I was told by a Sangoma Tech that they cant' do anything and they have the same issue with their own Bell Lines and they learned that Bell sends the CPC or Disconnect singal after about 10 seconds. But when I tested my Bell line, I hear a very short blip (50-70ms) almost instantly when I hang up the other end followed by a 10 sec. silence and then I hear another blip which is a little longer (close to 500ms) and then I hear busy tones. I have hooked up a Voltmeter and during and after I picked up the analog phone it dips to 6.6V from 51V and stays at 6.6 all the time except at the 2nd blip it seems to go to 0V. Again, this is just a cheap vmeter and probably could not see the 1st blip at all. So I am guessing I may have a CPC instantly but it is too short for zaptel. I will borrow a scope and use trigger to capture this blip and then I will know for sure whats happening. In the meantime would you provide me a guide on how to compile the zaptel file?
And to JAMES: I am very happy to see your initiative in trying to resolve these issues. If you can give me some assurance that your firmware may solve this. I will return my Sangoma tomorrow and buy yours. I have another project coming up where I will need a 14 port FXO and I am already decided to go with yours. But for the existing Sangoma one I would like to see some indication that you will support/ give assurance before returning.
Thanks,
Kim
Kim
Fri, 02/01/2008 - 8:18am
Just a follow up I forwarded your situation to my programmer and he guarantees it will work. And if there is another hick-up We will make it work. We stand behind our stuff 100% down to rewriting code as needed. Our cards have an on-board micro-controller which we can make respond to any line situation and we are geeky so we take issues personally and don't give up if we can potentially fix it.
I like Rhino's Attitude
Fri, 02/01/2008 - 11:42am
Hi James:
I really appreciate your attitude. That's how a company should be - not giving up on problems. It's sad to see that other manufacturer in their own turf with the same telco have seen this 10 sec delay long time ago and have reproduced this problem in their own lab but did not take any measures to come up with a solution. They keep shrugging it off to Asterisk and how Asterisk handles incoming calls and rings.
When I asked for an RMA they replied with that this not a problem with their cards rather it is a zaptel + Telco issue and would not issue an RMA. Also, they insisted that I make sure it is a Rhino Solution on Rhino's firmware rather then a update on Zaptel.
My thought is whether it is a zaptel update or a firmware update from Rhino, I don't care - only thing that matters to me is to make it work and however it is done is irrelevant to me. If someone from a Manufacturer takes the initiative like Rhino to do whatever it takes to make it work whether providing me a update on Zaptel or their own firmware, is what all that matters.
So, I will get in touch with my reseller to see if my card can be returned in exchange for a Rhino 8port fxo card.
Thanks,
Kim
Reproduce in your Lab
Fri, 02/01/2008 - 12:25pm
Hi James:
In the meantime, would you be able to reproduce this issue by simulating this in your lab. All you would have to do is stop sending the ring and after stopping the ring, wait about 10 seconds before doing a disconnect. That is how Bell Canada analog lines act. It's sad that having Bell Lines in Sangoma's own office and them having the same problem for a long time, I am resorting to asking you to simulate this.
Thanks,
Kim
Please see the following
Fri, 02/01/2008 - 4:04pm
Please see the following link in Rhino Equipment's KB to install the new firmware that our engineers have written specifically for this disconnect issue. Even though this issues is not a hardware defect Rhino takes great pride in the quality of our products and customer satisfaction, with this said we have released this as a fix for all analog Rhino cards. Please if you have any issues with this firmware let us know immediately.
https://support.rhinoequipment.com/kb/entry/49/
It does but it has a Bug so
Wed, 02/06/2008 - 9:23am
I'm getting a R8FXX-EC tomorrow
Thu, 02/07/2008 - 9:59pm
Hi James:
I am returning my Sangoma A200 and will be picking up a R8FXX-EC tomorrow from my distributor. Would you be able to guide me on how to remove the Sangoma Drivers and Install Rhino? I guess I need to remove sangoma's wanpipe and related stuff from it?
Please note that this is due to the Hangup Issue. About the post you have just made above about a bug does it affect the R8FXX?
Thanks,
Kim
Install is pretty simple you
Fri, 02/08/2008 - 6:25am
Install is pretty simple you can remove the sangoma stuff and add the rhino stuff through the package manager. Then in s shell tyoe modprobe rcbfx and run setup-pstn. Should get you going. If you run to any snags we have free hrdware upport 1-877-Rhino-T1 at the IVR press 2
Package Manager does not show Sangoma
Fri, 02/08/2008 - 10:08pm
Hi James:
Sangoma was installed as an RPM install see this link on the installation method:
http://wiki.sangoma.com/wanpipe-asterisk-trixbox-rpms
So it does not show up in the package manager.
Now, I have removed the Sangoma and Installed the Rhino on a different PCI
But during bootup it showed a lot of zaptel and wanpipe failures. I guess, I need to manually remove atleast the wanpipe drivers and utilities. As Zaptel modules are configured for Sangoma's Wanpipe. Any idea on how manually I can remove/uninstall Sangoma?
For Rhino Installation the package manager shows this:
rhino-2.6.18-53.1.4.el5 Rhino Telephony interface support 2.2.2-1
And the firmware version in the couple of posts before 1.12 is what I want to install for the Disconnect issue.
What should I do? What should be the step by step process?
Let me know if the following process is correct:
1. Remove the board
2. Manually remove Sangoma Drivers
This is how I removed:
#>rpm -e wanpipe-modules-2.6.18XXXXXXXX
#>rpm -e wanpipe-util-3.2.1-0
3. Reboot
4. Install Rhino Dirvers from the package manager
5. setup-pstn
6. Verify Freepbx for ZAP lines
7. Update Rhino Firmware
Reboot
Please provide me a step by step instruction.
Please email me at kimnkhan at gmail dot com
for 2.4 I recomend using
Wed, 03/12/2008 - 6:48pm
for 2.4 I recomend using ftp://ftp.rhinoequipment.com/Drivers/RPMS/trixbox/CE/2.4/rhino-2....
THIS WILL NOT WORK ON 2.6
I am having the exact same
Sat, 04/12/2008 - 12:01am
I am having the exact same problems mentioned in this thread but with an a200 card. My problem exists on both sides though. If I hangup on the trixbox side or the PSTN side first the line stays open for an extended period. I have tried 100s of different configuration settings in zapatel.conf. I am running 2.4.2.
If I call my cell from the trixbox side and hangup on the trixbox side the connection to my cell stays open. I can then make another call out of the trixbox and it will pick up that same line and start dialing, even though there is no dial tone. I can hear the DTMF tones going out on my cell.
Netvision,
Unfortunately it
Mon, 04/14/2008 - 7:42pm
Netvision,
Unfortunately it was impractical to maintain our presence in the trixbox repository and remain stable. With the rapid changes in the repo and recent zaptel variations one yum update could bork your whole box. The kernel modules are very touchy switching out a module here or there ad not all modules will cause instability, panics, and crashes. Pulling out of the repo allows us to support a wider range of users. We are fine tuning an install-rhino script that will detect your environment and install the appropriate packages automatically. The script is almost done we are just getting the infrastructure in place.
Hi James,
That type of
Mon, 04/28/2008 - 12:52am
Member Since:
2007-01-10