just an update, i just made my first dahdi call using asterisk 1.8 on switchfin.
still rock solid

Hi Kelvin,

I have imported your Astfin credentials to Switchfin so you will be able to comit your patch directly in Switchfin.

In case you feel we better test Asterisk 1.8 at revision 500 please feel free to make a test branch.

For me it is OK to get the patch in the trunk in case Asterisk 1.8 is optional and 1.4 is the default telephony engine:)

Thank you!
Dimitar

I may briefly give it a try but the bad news is I've decided to give Yate a go instead as uClinux is an officially supported platform. The good news is I will add it as a package to Switchfin. Just waiting for funding at the moment but currently, things are looking very promising.

I haven't actually tried Yate yet but I've read about Asterisk's fundamental flaws, such as deadlocks. Deadlocks aren't a big issue for the small scale stuff that these boxes are likely to deal with but having worked with it for a few years, I know there are plenty of other oddities and inconsistencies that seem to stem from the fact that Asterisk had to grow very fast without the time for much refactoring or cleaning up. It has been improving but what it's needed more than anything is a rewrite and that's why FreeSWITCH, Yate, and others were created. This is a good read.

I had the pleasure of meeting Mark Spencer in 2005 (that's how I got into Asterisk) and actually got very drunk with him. He was a great guy and was passionate about what he was doing but I suspect the pressures of the business have meant that breaking Asterisk free of its legacy has simply not been a viable option. Real community projects are much more flexible in this regard.

I initially considered FreeSWITCH but it quickly became clear that this was never going to run under uClinux. It's just not been written with this in mind. Neither has Asterisk for that matter and I find the fact that fork() keeps reappearing in the code quite worrying. The manner in which these instances of fork() are then blindly replaced with vfork() is equally worrying. It seems unlikely that memory fragmentation has even been considered. Frankly, I'm surprised that it works at all and that isn't something you want to be saying when you need it to be rock solid.

More recently, I checked out the other options. Unfortunately, CallWeaver, a fork of Asterisk 1.2, didn't live for very long. That pretty much left Yate. I was about to say how great it is that it officially supports uClinux but having looked at their site again, I now realise I was wrong about this! What it actually says is...

It is embeddable - Yate perfoms just as well on ARM-based machines or uclibc-based Linux implementations.

I am currently more interested on stability/functionality rather than performance, still battling with these 2 issues, somebody out there might have a fix.
1.way back 2003 there was this discussion http://lists.digium.com/pipermail/aster … 08269.html
there has to be a way for an fxo to detect whether there is a line plugged into it, or if the line has dialtone or not. This is a very very old issue, and i am not aware of any way to do it, are there any?
2.http://forums.digium.com/viewtopic.php?t=73048
setting modems and fax rate are being ignored by res_fax / res_fax_spandsp. there is no way a blackfin can do 14400 with the current floating point implementation (i already checked with steve) so i am currently creating a patch which i am planning to submit to digium. https://issues.asterisk.org/jira/browse/ASTERISK-16409

Hi Guys,

Few telephony engines have been mentioned in this thread so I decided to clarify.

Yate is an PBX system similar to Asterisk and is probably good candidate to be put on IP0x, PR1, BR4 Appliance targets

OpenSER from the other hand is a SIP proxy server.
So it deals only with signaling no media ever cross the OpenSER server, so no codec transcoding , no protocol translations ,no IVR, Queuing, speech recognition, etc.
I don't see direct application of OpenSER on our hardware other then just utilizing its embedded CPU power.
Please correct me if I am wrong.

Best Regards
Dimitar

Hi Dimitar,

yes i agree, there is actually no advantage of using openser/kamailio on
blackfin (other than creating a supernode of clustered embedded opensers,
the idea which i was toying with years ago) what we need is an alternative
to asterisk, a PBX engine with all the bling-blings... like yate

admin wrote:

Hi Guys,

Few telephony engines have been mentioned in this thread so I decided to clarify.

Yate is an PBX system similar to Asterisk and is probably good candidate to be put on IP0x, PR1, BR4 Appliance targets

OpenSER from the other hand is a SIP proxy server.
So it deals only with signaling no media ever cross the OpenSER server, so no codec transcoding , no protocol translations ,no IVR, Queuing, speech recognition, etc.
I don't see direct application of OpenSER on our hardware other then just utilizing its embedded CPU power.
Please correct me if I am wrong.

Best Regards
Dimitar

Hi Kelvin,

Writing DSP code is a tedious task.
Writing fixed point DSP code is even more tricky -  issues like quantization noise , scaling, etc.

Now a days most of the open source code is targeting x86 (and similar) platforms with floating point support and people just use it for the DSP code as it is simpler. 

Please don't expect to find fixed point open source DSP code unless it is specially intended for the fixed point hardware.

I don't expect Yate to differ in this respect.
I just checked it quickly and for what I have checked
- It uses external libraries libgsm, libspeex (floating point)
- It uses matched filters for tone detection which uses double entities (floating point)
- The DTMF detection and generation is floating point too.

So I have not spend time to study in details but I would say (based on my quick 10 min research) that Asterisk is even a bit more friendly in this respect. Asterisk also uses some external libraries but it has its own gsm/lpc implementation.
For Blackfin we have fixed point tone detection in Asterisk and G729 (which probably we can reuse in Yate).

I would be interested in Yate if it appears to be more stable then Asterisk
and performs quicker (on a protocol level) which is important for the PR1 Appliance box.
(And all this apart of the DSP code)   

Best Regards
Dimitar

Hi James,

We currently use SpanDSP for two things:
- Caller ID detection
- faxing

The Caller ID detection involves FSK demodulation.
Caller ID in SpanDSP is fixed point.
Asterisk has its own floating point implementation which is supposed to be few times slower than the Span DSP one.
By default in the Switchfin building GUI we select SpanDSP based Caller ID

Fax modems in SpanDSP are floating point. You can hardly get one fax channel using 9600 fax speed on Blackfin.
Previous year I have spent some time on faxing. I realized that I can not afford that much time to rewrite the SpanDSP
fax modems in fixed point. At that time Zoiper opened their fax engine Attrafax which was simpler from algorithmic point
of view and the code was cleaner (Span DSP has more complex/advanced algos).
I have rewritten Attrafax in fixed point and now it is part of Switchfin.
It probably can achieve few channels on BF537 600 MHz. Still it may have some glitches however.

- DTMF uses Goertzel filters which we have in fixed point for Blackfin. This is included in our Asterisk patch.

- Astreisk has its own GSM and LPC10 codecs implemented in fixed point. That's why they run pretty fast on Blackfin.

- All the rest DSP either built in Asterisk or via  external libraries libspeex, iLBC, g729, etc is floating point and is slow.

Based on very quick browsing I have feelings that Yate will have slower DSP then Asterisk.

Best Regards
Dimitar

FYI, i made a patch to wcfxs.c to detect and flag fxo ports which does not have a pstn line plugged in.
How should i upload this to trunk? as a patch? or as a whole wcfxs.c? it just involves 2 additional lines.
I need you guys to test this also. i made some tests here on asterisk 1.8 and it works, outbound calls do not go to those ports which does not have a pstn line plugged in.
If a port is flagged and the pstn line is plugged back in, flag gets cleared.

committed revision 633

seem cleaner changing it directly

Hi James,

Oh good!
Keep up the good work

Best Regards
Dimitar Penev

Oh awesome work Kelchy

Hi,
I made some modifications to be able to compile asterisk 1.8.4 with Google Voice support. (Added Iksemel package)
I haven't tested it yet but I was able to compile and create an uImage.
Here you can find the modifications applied to revision 660:
http://dl.free.fr/nXphK3gMf
If someone want to try it.

BR,
Sam

Sure you can.
I don't have write access to the svn so I had to publish it this way.
I don't have my IP02 nearby so I can't test it but I will ASAP and get back to you.
Feel free to test and give me some feedbacks