Trixbox 2.2.12 OR 2.4.X with Rhino RCB8Fxx Line not hanging Up

What version of firmware is on your card.

dmesg | grep rcbfx

Tested 2.4 Trixbox "minimal install" and Rhino RCB8 with 3 FXO modules have same trouble with pots disconnect when calling in from outside.

Amanda, James any ideas on this?

Tim

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

lancekoster,

I agree with you 100% but Rhino support insists this is a software issue. How do I prove them wrong!

Tim

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

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.

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 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

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.

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.

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....

What signaling were you using before you set loop start?

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.

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....

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,,,,

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,

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

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)

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

For my case, this new firmware has improved the situation. The hangup detection (or time-out or whatever) used to take almost 2 minutes and is now down to about 10 seconds.

so far 5 people have requested the update since it was posted all 5 have reported success

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

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/

YUM UPDATE wants to unstall this version Rhino-2.6.18-53.1.1.e15 Version 2.2.3-2 does this version have the Hang-up fix in it or any other enhancements

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

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

Firmware version 1.12 worked like a charm!

Way cool...

-=Mike=-

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 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.

Hey just want to say Great job to the Rhino Folks

hardware is a HP dc530 desktop with p4 2.6 ht disabled
1.5 gb ram
40 gig eied hd
rhino 4fxo ec (ROCKS)

i just did a upgrade/ fresh install from 2.2 to 2.6 and did the install of the updated Rhino "rhino-2.6.18-53.1.4.el5-1.4.9.1-2.2.5.4.rpm" and did the setup-pstn (dont think it did any thing) then did a cd /usr/sbin/ and then ran genzaptalconf and all 4 lines showed up on zapata_auto.conf!

Just wanted to pat you on the back for sticking out the 2.6 mess and getting some rockstar drivers!!

JOIN THE REVOLUTION!!
AMERICAN PRODUCTS MADE BY AMERICANS!

Hi i'm using tixbox with 3 fxo modules have the same busy tone problem
i am using the zapmicro card with 4 fxo modules. does this upgrade work for this card as well and if it does how do i go about installing it?

I had the same problem with Sangoma A200 and IVR.
When a caller select one of the option after IVR say his message the relative extension rings indefinitely until a user pick up the phone and even if the caller has hunged up.
To resolve the issue I've added to zapata.conf this lines:

busydectect=yes
answeronpolarityswitch=yes
hunguponpolarityswitch=yes

in this manner all works fine and when the caller hung up the extension stop to ring immmediately.
I hope my experience will be useful.

P.S. a suggestion to Kerry and his staff.
Trixbox Pro is too exapansive for small-medium offices (10-50 extensions) at list in Italy.
Trixbox CE is very good but and your support ad developement works is essential!
At this point, why you don't think to deploy a lite CE license (max 50 - 100 euro) for even server and only for the server with no limit on the number of extensions so that the license charge on our, small, installation will be lite and at the same time you can continue to offer to us your precious and wonderful work ?
This is a little idea.
What you think about?

Ing. Cosimo MERCURO
Mercuro for Business