I've been trying to help a friend get some Nortel i2004 phones working on RasPBX. We have set up unistim.conf, and set a custom extension with the appropriate dialstring.
Good news is that we we can make and receive calls, set up speed dial keys etc.
The catch is that the i2004 doesn't ring audibly, it just flashes the red light. I've also noticed that the call timer is listed as "duree" which appears to be a bug in the english language version of older versions of chan_unistim. We've tried messing with some of the options for ring volume etc in unistim.conf, but not much luck so far.
Google suggests others have had this on the Pi but have had it working on x86 builds. (I've tried an updated original build, and the newer beta build, but both respond with no audible ring.)
Is there a straightforward way to make sure we're on the latest chan_unistim driver?
Same here.. exact same issue. I've also started a bug report thread about how you will run out of ports eventually too, and asterisk will need to be restarted.
If you place a call to any voice function, then hang up, have a look at the udp ports on the pi; "netstat -l" -and you will probably also see your two rtp ports still there.. not closed down. Eventually you run out.
I'm hoping to get these issues raised too. The Nortel sets are such superb devices, it's a shame to leave this to rot.
I got around the ring problem by placing the distinct ring code at the end of anything which rings to a unistim extension like:
exten => 200,1,Dial(USTM/200@200/r00,10) -Where "/r00" is the ticket.
I have contacted the chap who took over the chan_unistim code in Russia, but he's not come back to me. I offered a donation, and to send another set even.
I wondered if there's something we need updated repository wise, or can compile ourselves etc to update, as the "duree" wrong-language bug for the call timer on chan_unistim phones appears to have been fixed some time ago, yet we still have it?
That's great, thanks for the distinct ring workaround, we can give that a try!
The udp ports not getting closed sounds like a problem though if the stack eventually runs out... Hope you get a response with your offers of help. Agree it'd be great to get the Nortels from almost working to working!
Chan_unistim is provided with the Asterisk sources and compiled freshly every time the Asterisk package is updated. Bugfixes will have to go the official way to be included in Digium's Asterisk source tarball. Therefore it might help to also file a bug ticket at asterisk.org.
Is this the bugfix you are referring to?
It has no target release versions assigned, maybe this is why it is not provided with the official sources.
Yes, thanks, that's the patch that I saw - sorry, not very familiar with how all the revisions and issues are tracked etc. I just assumed it was fixed and therefore now included in the updated builds...
...Jason, any luck with your reporting, not sure if you'd already seen the link posted above?
I never went through the asterisk channel as the raspberry pi isn't part of the official intended distribution I'd guess, being you can't install any digium boards onto one.. I just did an upgrade and the asterisk11 is now at 11.17.0 - I was at 11.15.0-1 when I initially reported this here, but I notice the UDP port issue still hanging around.. hmn. It also doesn't have the above fix, as I still get Duree on timer. ;(
Perhaps the above will make it into another iteration, but this port closure.. I'm guessing that if I run this on an intel machine, stock install, it won't be there. I.. am hesitant to believe Igor (maintainer) and others would have overlooked such a nasty bug. It must be a raspberry issue. (surely..) Though, you never know. Perhaps people only ever 'fiddle around' with a few Nortel sets then go back to crappy grandstream stuff and don't bother getting into it as FreePbx or other dumb-down front ends probably don't address advanced settings like that. (just endless loads of pointless features for the real world like localised weather novelties?)
I have a few Nortel BCM50's wrangled to use these sets so I kinda backed off for a bit. Wait and see? Igor never did get back to me. Seems new things are more fun etc. And I understand that. It's nice that folks do what they do, as I've not paid anyone. (I'd like to though!)
To all interested, some useful updates!
I've been building relatively small (88mb download img file?) asterisk builds for pi, orange-pi-one, banana-pi, and... a distro for the NanoPI-Neo for someone - works a treat in a commercial environment in the US, bridging two Nortel BCM systems with about 10 channel capability. (and sip and unistim sets too of course!)
I have sorted the ring issue with Igor (chan_unistim maintainer) this morning. He pointed out that the ARM environment 'char' values (in c) are unsigned. In x86 the default is signed. The original driver was written probably before there was any interest in asterisk on the pi, (ARM cpu family) so it was written with many 'char' assigns that produce wildly wrong numbers on ARM. (Because you can simply throw char around, and when you specifically need an unsigned char, you specify, relying on the default, so in ARM, it's the other way around.. everything is unsigned char, and so some of the explicit unsigned char definitions are moot.. funnily.) Without more boring explanation, I went through the chan_unistim code and made it x86/ARM friendly in ring functionality. Igor has the changes to push into his next update.
Another: I pushed the rtp port exhaustion issue on the asterisk official bug forum finally, and Igor created a patch that adds a couple of ast functions that close down rtp ports properly after a call is finished. So the unistim rtp "ports left open" bug I pointed out was acknowledged, and it went into the 14 strain..
But with that, sadly, there's no more updates for the 11' strain, and only bug fixes for the 13 strain. Problem: I extensively use the earlier NuFone Network's H323 channel driver, but the Asterisk team pointed out that "it's no longer supported" and they moved to the faulty ooh323 driver - which doesn't work with the Nortel business systems I am involved with. One way audio, farting about with "tunneled H245 messages" which then makes other systems break... sigh. I gave up. I don't need the features of the later builds in the smaller ARM environment.. it can't use the functionality anyhow..
I have stayed with the last 11.24.1. I've been working to bring the 11.24.1 chan_unistim up to date too, as it's not, and so far it's nearly complete. (working fine now, but pressing "hold" temporarily locks up the set until another call comes in and clears the situation.)
The two builds have no depends outside of libxml2, and really basic core system depends. I bundled the compiled libh323 and libpt needed for H323 as single files. The kits are a simple tar archive and contain no icing or scripts; simply the binaries, 4 libs, and the modules. I also re-compiled the 11-strain (fork) of chan_dongle for GSM dongles, for both arm varieties (pi - single core B, A20 dual-core Banana pi one, H3 quad-core Orange-pi One + Nano Pi Neo as above: There are two binary builds)
I am using it as an international link using IAX2, encrypted at AES128 (good enough), and then H323 to a Nortel phone system. There is also a Huwawei E160 dongle on one old PI model B (single core 700mhz, 512mb ram) set up as a GSM gateway to the internal phone network.
If anyone's interested, I will make a site here: http://srpl.com/astarm/ and provide links to where the binkits and full system builds are. The binary kits are about 5-11 megs.
Glad to have discovered the asterisk on pi site originally.
I am presuming these binaries can be laid into a system which uses one of the GUI's, but I don't use the GUI at all, and have no interest in their hugely expensive and inflexible dialplans. So please test first on a disposable build if you might do so. If you are like me, and build your dialplan and configs by hand with vi, these are the ticket.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.