Two posts in one day. Wow.
Just as the title says and previous posts have hinted, FreeSWITCH has been added to AstLinux. Please see the official announcement on the AstLinux homepage.
Tuesday, February 17, 2009
AstLinux Updates
Just a few quick AstLinux updates:
1) FreeSWITCH support is just about done and has been committed to trunk. Still needs some testing but things look very promising. The installed binaries are much smaller than I thought (~3MB or so stripped and linked against uClibc). This includes some cool stuff like mod_xml_curl, mod_lua, mod_vmd, mod_snom, and more. As Tony pointed out 1.2MB of that 3MB is mod_sofia! As frustrating as that is at least mod_sofia includes IPV6, UDP, TCP, TLS, session timers, and just about every other relevant SIP standard... ;)
Small note but worth mentioning - FreeSWITCH is the first package to be committed without support for a keydisk of any kind. You need to use unionfs with this one!
2) OpenSER support has been moved to OpenSIPS. I'm still not sure about this one... I've got an existing relationship with Bogdan and all of my projects have been moved to OpenSIPS (instead of Kamailio or SER). We'll see what the community wants on this one (if AstLinux users care about a high performance SIP proxy at all).
3) RTPProxy upddate to 1.1. I love this software.
That's it for now!
1) FreeSWITCH support is just about done and has been committed to trunk. Still needs some testing but things look very promising. The installed binaries are much smaller than I thought (~3MB or so stripped and linked against uClibc). This includes some cool stuff like mod_xml_curl, mod_lua, mod_vmd, mod_snom, and more. As Tony pointed out 1.2MB of that 3MB is mod_sofia! As frustrating as that is at least mod_sofia includes IPV6, UDP, TCP, TLS, session timers, and just about every other relevant SIP standard... ;)
Small note but worth mentioning - FreeSWITCH is the first package to be committed without support for a keydisk of any kind. You need to use unionfs with this one!
2) OpenSER support has been moved to OpenSIPS. I'm still not sure about this one... I've got an existing relationship with Bogdan and all of my projects have been moved to OpenSIPS (instead of Kamailio or SER). We'll see what the community wants on this one (if AstLinux users care about a high performance SIP proxy at all).
3) RTPProxy upddate to 1.1. I love this software.
That's it for now!
Friday, February 13, 2009
The Joys of the Internet
The members of the Yahoo! Financial forum are now referring to me as "little hitler" (it's because I have a German last name, how clever) and suggesting I be sued for libel... That would get interesting. Perhaps they have never heard of The Streisand Effect?
It is unfortunate that what should be a mature, productive discussion has come to this. What is it about the internet that brings out the worst in people?
Anyways, it is very clear this issue should have never left a technical forum. I don't give stock tips; they shouldn't argue RFCs.
It is unfortunate that what should be a mature, productive discussion has come to this. What is it about the internet that brings out the worst in people?
Anyways, it is very clear this issue should have never left a technical forum. I don't give stock tips; they shouldn't argue RFCs.
Yikes! (More on Sonus)
It seems that my Sonus rant has crossed over into some other arenas...
Yahoo! Financial Discussion
I've signed up for an account (kristian.kielhofner -at- yahoo.com) to participate in this thread. Should be interesting.
Yahoo! Financial Discussion
I've signed up for an account (kristian.kielhofner -at- yahoo.com) to participate in this thread. Should be interesting.
Monday, February 9, 2009
More on FreeSWITCH
I've hinted at it for some time:
I've been playing with FreeSWITCH.
Anyone who is reading this should already know what FreeSWITCH is and why someone (such as myself) would be so interested in it. I'm not going to go over all of that again; there are plenty of rave reviews all over the internet. I don't need to write another one (although I probably will some day).
Here's an update on what I've done so far:
1) FreeSWITCH support in AstLinux. Still coming along but much progress has already been made. It compiles cleanly (one more hack for sqlite) and appears to work. More testing soon but I was pleasantly surprised - the build system seems to be just as well designed as the rest of the project. They've done a great job!
2) I hate transcoding. Long, long ago I led an effort to re-record and convert all of the Asterisk prompts to various native file formats to avoid transcoding. More than two years later I'm doing it again for FreeSWITCH although this time I don't have to pay to re-record them all! Luckily they are made available in various sample rates already. I just had to update the script and do the converting. Big thanks to sox, Asterisk/res_convert and FreeSWITCH/Mod_native_file.
3) This one is barely worth mentioning but I've started (SVN branch, that's about it) working to re-implement recqual using FreeSWITCH to place calls. I've got some big plans for this. Let's see how much time I actually have to work on it. Don't expect much progress anytime soon.
4) Various production and consulting projects. Obviously.
As always, expect more to come!
I've been playing with FreeSWITCH.
Anyone who is reading this should already know what FreeSWITCH is and why someone (such as myself) would be so interested in it. I'm not going to go over all of that again; there are plenty of rave reviews all over the internet. I don't need to write another one (although I probably will some day).
Here's an update on what I've done so far:
1) FreeSWITCH support in AstLinux. Still coming along but much progress has already been made. It compiles cleanly (one more hack for sqlite) and appears to work. More testing soon but I was pleasantly surprised - the build system seems to be just as well designed as the rest of the project. They've done a great job!
2) I hate transcoding. Long, long ago I led an effort to re-record and convert all of the Asterisk prompts to various native file formats to avoid transcoding. More than two years later I'm doing it again for FreeSWITCH although this time I don't have to pay to re-record them all! Luckily they are made available in various sample rates already. I just had to update the script and do the converting. Big thanks to sox, Asterisk/res_convert and FreeSWITCH/Mod_native_file.
3) This one is barely worth mentioning but I've started (SVN branch, that's about it) working to re-implement recqual using FreeSWITCH to place calls. I've got some big plans for this. Let's see how much time I actually have to work on it. Don't expect much progress anytime soon.
4) Various production and consulting projects. Obviously.
As always, expect more to come!
Thursday, February 5, 2009
The update you've been waiting for...
UPDATE: Any updates for this and other SIP/RTP issues can be found here.
In my last post over one month ago, I ranted on and on (big surprise, right) about some issues with Sonus equipment we were experiencing. After learning more I should elaborate on "Sonus equipment".
Like many other manufacturers Sonus has multiple products. We'll be talking about their NBS SBC. Many providers use the NBS SBC in conjunction with GSX gateways and PSX route servers. I have no comments about GSX gateways or PSX route servers; this equipment is largely transparent to us "end users". My gripes are with the NBS SBC.
Providers that use Sonus NBS:
- Level(3) (w/ GSX)
- XO (w/ PSX & GSX)
- Global Crossing
- Broadvox
- Many others
If you are using these carriers for SIP services, be aware.
Last time I was talking about timestamps. This time it's far more insidious...
Apparently (as relayed to me from Level(3) engineers) Sonus has a DSP buffer limitation for RTP packet handling. If there is ever more than a 100ms (my experience has shown it to be much less) gap in RTP Sonus will in technical terms, "freak out".
We have now identified four RTP interop issues with Sonus equipment:
1) Sonus requires all RTP packets (events or voice) to have unique timestamps. The RFCs specifically state that not only is it valid to use the same timestamp for various RTP packets, it is ideal in some cases (like events, for example).
2) The RFC 2833 events generated by Sonus equipment are goofy, to put it lightly. The event duration increments do not match the packetization of the voice stream as stated in RFC 2833 and elaborated on in RFC 4733. Specifically, Sonus equipment increments RFC 2833 duration 80 samples
at a time as if the voice stream is 10ms (regardless of what it actually is). I don't know of any other implementations that do this. Even when the audio stream is *clearly* 20 ms (in the SDP, too) Sonus will continue to increment 80 samples at a time.
3) The most recent (and biggest problem) has been caused by the Sonus (seemingly arbitrary) requirement that there never be greater than 100ms gaps in RTP. This is inherently broken behavior for robustness in IP networks.
4) Sonus has yet another issue with RTP timing and sequencing... If a call is brought up with an endpoint that clocks it's own RTP stream (IVR server, for example) everything will be fine. Until the IVR server (or whatever) bridges that channel to another device that also clocks its own RTP. Sonus (probably related to #3 above) will lose sync and drop audio for up to several seconds while it catches up to the new RTP stream. This requires those of us that work with Sonus equipment to rewrite all timestamps and sequence numbers on our equipment; which has the adverse effect of less than optimal jitter buffering (which should ideally be done at each far endpoint).
Asterisk is largely ok with all of these issues, believe it or not. The one that still causes problems is #3. If you are using Asterisk and Sonus gateways, make DAMN SURE that you are using Packet2Packet bridging and that your devices (whatever they may be) implement RFC 2833 the Sonus way. If not...
NO DTMF FOR YOU!
If you are not using Packet2Packet bridging and your events need to traverse the Asterisk core (for features, fixup, or anything else) there will be a variable length RTP gap that often exceeds the Sonus DSP buffer requirement. With gaps in RTP...
NO DTMF FOR YOU!
FreeSWITCH is also ok as long as you avoid #4. FreeSWITCH provides the configuration option to rewrite timestamps and break jitter buffering. If you are using Sonus gateways you should enable it, otherwise...
NO DTMF FOR YOU!
All of this makes me wish I was around back in the old days when there was one telco and all DTMF was inband!
In my last post over one month ago, I ranted on and on (big surprise, right) about some issues with Sonus equipment we were experiencing. After learning more I should elaborate on "Sonus equipment".
Like many other manufacturers Sonus has multiple products. We'll be talking about their NBS SBC. Many providers use the NBS SBC in conjunction with GSX gateways and PSX route servers. I have no comments about GSX gateways or PSX route servers; this equipment is largely transparent to us "end users". My gripes are with the NBS SBC.
Providers that use Sonus NBS:
- Level(3) (w/ GSX)
- XO (w/ PSX & GSX)
- Global Crossing
- Broadvox
- Many others
If you are using these carriers for SIP services, be aware.
Last time I was talking about timestamps. This time it's far more insidious...
Apparently (as relayed to me from Level(3) engineers) Sonus has a DSP buffer limitation for RTP packet handling. If there is ever more than a 100ms (my experience has shown it to be much less) gap in RTP Sonus will in technical terms, "freak out".
We have now identified four RTP interop issues with Sonus equipment:
1) Sonus requires all RTP packets (events or voice) to have unique timestamps. The RFCs specifically state that not only is it valid to use the same timestamp for various RTP packets, it is ideal in some cases (like events, for example).
2) The RFC 2833 events generated by Sonus equipment are goofy, to put it lightly. The event duration increments do not match the packetization of the voice stream as stated in RFC 2833 and elaborated on in RFC 4733. Specifically, Sonus equipment increments RFC 2833 duration 80 samples
at a time as if the voice stream is 10ms (regardless of what it actually is). I don't know of any other implementations that do this. Even when the audio stream is *clearly* 20 ms (in the SDP, too) Sonus will continue to increment 80 samples at a time.
3) The most recent (and biggest problem) has been caused by the Sonus (seemingly arbitrary) requirement that there never be greater than 100ms gaps in RTP. This is inherently broken behavior for robustness in IP networks.
4) Sonus has yet another issue with RTP timing and sequencing... If a call is brought up with an endpoint that clocks it's own RTP stream (IVR server, for example) everything will be fine. Until the IVR server (or whatever) bridges that channel to another device that also clocks its own RTP. Sonus (probably related to #3 above) will lose sync and drop audio for up to several seconds while it catches up to the new RTP stream. This requires those of us that work with Sonus equipment to rewrite all timestamps and sequence numbers on our equipment; which has the adverse effect of less than optimal jitter buffering (which should ideally be done at each far endpoint).
Asterisk is largely ok with all of these issues, believe it or not. The one that still causes problems is #3. If you are using Asterisk and Sonus gateways, make DAMN SURE that you are using Packet2Packet bridging and that your devices (whatever they may be) implement RFC 2833 the Sonus way. If not...
NO DTMF FOR YOU!
If you are not using Packet2Packet bridging and your events need to traverse the Asterisk core (for features, fixup, or anything else) there will be a variable length RTP gap that often exceeds the Sonus DSP buffer requirement. With gaps in RTP...
NO DTMF FOR YOU!
FreeSWITCH is also ok as long as you avoid #4. FreeSWITCH provides the configuration option to rewrite timestamps and break jitter buffering. If you are using Sonus gateways you should enable it, otherwise...
NO DTMF FOR YOU!
All of this makes me wish I was around back in the old days when there was one telco and all DTMF was inband!
Subscribe to:
Posts (Atom)