The AstLinux team (of which I'm an occasional member) has released AstLinux 0.7. Darrick, Philip, Lonnie, and the rest of the community have done a great job getting this release out there. I couldn't be happier with how my little project has grown up!
In addition to getting this release out, they've also taken the time to focus on documentation and a new website.
Well done guys!
Wednesday, January 20, 2010
Testing with SIPP
A quick one, I promise...
I'd been having some issues testing Asterisk with sipp. It turns out there is a fairly well known issue with sipp when using five digit port numbers for RTP. A quick Google search found a solution pretty quickly.
Just in case that link ever goes dead, here's the diff:
diff -urb sipp.svn_orig/call.cpp sipp.svn_fixed/call.cpp
--- sipp.svn_orig/call.cpp 2008-12-19 13:14:51.000000000 +0300
+++ sipp.svn_fixed/call.cpp 2008-12-19 13:16:34.000000000 +0300
@@ -192,7 +192,7 @@
/* m=audio not found */
return 0;
}
- begin += strlen(pattern) - 1;
+ begin += strlen(pattern);
end = strstr(begin, "\r\n");
if (!end)
ERROR("get_remote_port_media: no CRLF found");
More on sipp later!
I'd been having some issues testing Asterisk with sipp. It turns out there is a fairly well known issue with sipp when using five digit port numbers for RTP. A quick Google search found a solution pretty quickly.
Just in case that link ever goes dead, here's the diff:
diff -urb sipp.svn_orig/call.cpp sipp.svn_fixed/call.cpp
--- sipp.svn_orig/call.cpp 2008-12-19 13:14:51.000000000 +0300
+++ sipp.svn_fixed/call.cpp 2008-12-19 13:16:34.000000000 +0300
@@ -192,7 +192,7 @@
/* m=audio not found */
return 0;
}
- begin += strlen(pattern) - 1;
+ begin += strlen(pattern);
end = strstr(begin, "\r\n");
if (!end)
ERROR("get_remote_port_media: no CRLF found");
More on sipp later!
Friday, October 9, 2009
I don't "do" testimonials
I was (admittedly) getting a little bored at the office today when I realized that one of my favorite activities to pass time is checking the recent changes page of the FreeSWITCH wiki. Think about that for a minute...
If that doesn't make me a FreeSWITCH fanboy, I don't know what does. I guess I just have to finally admit it:
I am a FreeSWITCH fanboy.
How I got here I'm not really quite sure. What I do know is that I despise fanboys of all sorts (in no particular order):
- Linux
- Apple
- Microsoft (how?)
- Asterisk
- FreeSWITCH (self-loathing and denial are very powerful forces)
I've been using FreeSWITCH for over a year and it's the closest thing to a whirlwind romance I've ever had (nerdom solidified, thank you). While I'm sure the honeymoon period will end eventually at the moment I'm still smitten. I sat down and started to write a testimonial on the FreeSWITCH wiki when I realized that this was the perfect opportunity to return to blogging. I'm back and I want to talk about FreeSWITCH. Here's what I have to say (complete with an obligatory car analogy):
Star2Star has over 12,000 (business) endpoints in the field and we currently use FreeSWITCH for:
- SBC (multiple applications - customer and provider facing)
- Conference services
We're very quickly moving to IVR and (ultimately) voicemail.
What is most impressive about FreeSWITCH are the small details that make working with it an absolute joy:
- Sofia profiles (multiple unique SIP identities Just. Like. That.)
- XML flexibility (static, custom module, mod_xml_curl)
- Dialplan (conditions, PCRE, etc)
- Channel variables (access to remote media IP address and anything else in a CHANNEL VARIABLE!)
- proxy_media
- bypass_media (beautiful, just beautiful)
- RICH SIP/RTP support (SIPS, TCP, UDP, SCTP, SRTP, PAI, RPID). Yeah, I can talk to anything any way I need to.)
- Codec support. Resampling. Repacketization. It's just getting ridiculous.
- Event socket. Inbound/outbound. Async. API commands. Events.
It is still *amazing* to me that I can make FreeSWITCH into the ultimate signaling-only SBC just by adding bypass_media=true or that I can send PAI to a destination with sip_cid_type=pid. Just about every component of FreeSWITCH I've come across is very well thought out, completely logical, and completely predictable. It's like driving a German car - if you take driving seriously everything just works and everything just works exactly as you expect it to.
It's as if Anthony, Brian, Michael, and everyone else on the FreeSWITCH team are constantly sitting around, agonizing every detail of this awesome piece of software just as Hanz, Fritz, and Karl are in Munich agonizing over every detail for the next BMW 7 Series. While there are several differences in this analogy perhaps the biggest difference is that it doesn't cost $100,000 for one of the most well engineered products I've ever come across (obviously I'm not talking about the BMW).
Did I mention that in addition to this rich feature support it actually scales? All the features in the world are completely useless to me in my environment unless they can scale. We've seen again and again - FreeSWITCH scales. With OpenSER/OpenSIPS at our core and FreeSWITCH serving various edge and endpoint roles I can't identify a single point where we couldn't (ultimately) scale to meet growth or demand.
Star2Star is very unique. We have a unique product, unique approach, and unique architecture. While the architecture has generally evolved and scaled over the years with the number of users, the introduction of FreeSWITCH in a given role has always been accompanied by an excitement for what we'll be able to do for our company and our customers with our new favorite piece of software. It's a very exciting time.
The future at Star2Star is powered by our (quickly) growing customer base, FreeSWITCH, and our efforts to relentlessly deploy it where we can.
If that doesn't make me a FreeSWITCH fanboy, I don't know what does. I guess I just have to finally admit it:
I am a FreeSWITCH fanboy.
How I got here I'm not really quite sure. What I do know is that I despise fanboys of all sorts (in no particular order):
- Linux
- Apple
- Microsoft (how?)
- Asterisk
- FreeSWITCH (self-loathing and denial are very powerful forces)
I've been using FreeSWITCH for over a year and it's the closest thing to a whirlwind romance I've ever had (nerdom solidified, thank you). While I'm sure the honeymoon period will end eventually at the moment I'm still smitten. I sat down and started to write a testimonial on the FreeSWITCH wiki when I realized that this was the perfect opportunity to return to blogging. I'm back and I want to talk about FreeSWITCH. Here's what I have to say (complete with an obligatory car analogy):
Star2Star has over 12,000 (business) endpoints in the field and we currently use FreeSWITCH for:
- SBC (multiple applications - customer and provider facing)
- Conference services
We're very quickly moving to IVR and (ultimately) voicemail.
What is most impressive about FreeSWITCH are the small details that make working with it an absolute joy:
- Sofia profiles (multiple unique SIP identities Just. Like. That.)
- XML flexibility (static, custom module, mod_xml_curl)
- Dialplan (conditions, PCRE, etc)
- Channel variables (access to remote media IP address and anything else in a CHANNEL VARIABLE!)
- proxy_media
- bypass_media (beautiful, just beautiful)
- RICH SIP/RTP support (SIPS, TCP, UDP, SCTP, SRTP, PAI, RPID). Yeah, I can talk to anything any way I need to.)
- Codec support. Resampling. Repacketization. It's just getting ridiculous.
- Event socket. Inbound/outbound. Async. API commands. Events.
It is still *amazing* to me that I can make FreeSWITCH into the ultimate signaling-only SBC just by adding bypass_media=true or that I can send PAI to a destination with sip_cid_type=pid. Just about every component of FreeSWITCH I've come across is very well thought out, completely logical, and completely predictable. It's like driving a German car - if you take driving seriously everything just works and everything just works exactly as you expect it to.
It's as if Anthony, Brian, Michael, and everyone else on the FreeSWITCH team are constantly sitting around, agonizing every detail of this awesome piece of software just as Hanz, Fritz, and Karl are in Munich agonizing over every detail for the next BMW 7 Series. While there are several differences in this analogy perhaps the biggest difference is that it doesn't cost $100,000 for one of the most well engineered products I've ever come across (obviously I'm not talking about the BMW).
Did I mention that in addition to this rich feature support it actually scales? All the features in the world are completely useless to me in my environment unless they can scale. We've seen again and again - FreeSWITCH scales. With OpenSER/OpenSIPS at our core and FreeSWITCH serving various edge and endpoint roles I can't identify a single point where we couldn't (ultimately) scale to meet growth or demand.
Star2Star is very unique. We have a unique product, unique approach, and unique architecture. While the architecture has generally evolved and scaled over the years with the number of users, the introduction of FreeSWITCH in a given role has always been accompanied by an excitement for what we'll be able to do for our company and our customers with our new favorite piece of software. It's a very exciting time.
The future at Star2Star is powered by our (quickly) growing customer base, FreeSWITCH, and our efforts to relentlessly deploy it where we can.
Wednesday, March 25, 2009
CANCEL
I don't have a tremendous amount of time so this is going to be a short one.
There is a CANCEL related bug in Asterisk 1.4.23 versions. To be honest I'm not sure when it was introduced but I know when it was fixed:
http://bugs.digium.com/view.php?id=14431
This caused trouble for me because I often use Asterisk in tandem with OpenSIPS and FreeSWITCH. Both platforms were unable to match the CANCEL sent by Asterisk to the original INVITE. As the bug note says, this is because the CANCEL sent by Asterisk had a different branch parameter than the original INVITE. OpenSER/OpenSIPS would fail when checking t_check_trans()as long as method==CANCEL.
FreeSWITCH was a *little* easier to diagnose because it would send a 481. I suppose I could have made (and should make) my OpenSIPS configurations do this when using t_check_trans for CANCEL:
if (is_method("CANCEL")) {
if (!t_check_trans()) {
# No matching transaction, error and exit
sl_send_reply("481","Call leg/transaction does not exist");
exit;
}
# Hand it to tm
t_relay();
exit;
Anyways this has certainly been fixed in Asterisk 1.4.24. I'm looking forward to not dealing with any of this for some time...
There is a CANCEL related bug in Asterisk 1.4.23 versions. To be honest I'm not sure when it was introduced but I know when it was fixed:
http://bugs.digium.com/view.php?id=14431
This caused trouble for me because I often use Asterisk in tandem with OpenSIPS and FreeSWITCH. Both platforms were unable to match the CANCEL sent by Asterisk to the original INVITE. As the bug note says, this is because the CANCEL sent by Asterisk had a different branch parameter than the original INVITE. OpenSER/OpenSIPS would fail when checking t_check_trans()as long as method==CANCEL.
FreeSWITCH was a *little* easier to diagnose because it would send a 481. I suppose I could have made (and should make) my OpenSIPS configurations do this when using t_check_trans for CANCEL:
if (is_method("CANCEL")) {
if (!t_check_trans()) {
# No matching transaction, error and exit
sl_send_reply("481","Call leg/transaction does not exist");
exit;
}
# Hand it to tm
t_relay();
exit;
Anyways this has certainly been fixed in Asterisk 1.4.24. I'm looking forward to not dealing with any of this for some time...
Tuesday, February 17, 2009
AstLinux-FreeSWITCH ISO available for testing!
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.
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.
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.
Subscribe to:
Posts (Atom)