OpenSER Name Change

OpenSER has changed their name to Kamailio.

Name changes are tough. This name change is especially tough and dare I even say, personally frustrating.

Working with Star2Star is tough. We have a revolutionary architecture. We operate very differently from most other providers. Heck, we operate differently than most other companies! Don't get me wrong, this is one of the many things I like about us. That's why we're changing what people think about phone (communications) companies.

One of the main drawbacks of these differences (read: advantages) is working with legacy telco. Whether it's legacy telco people, equipment, process, or organization, I have had many, many frustrating clashes with telecom. Frustrations with technology excite me. Frustrations with people drive me crazy. People can't be fixed as easily.

This name change only exacerbates what I see as an already BIG problem. How am I going to talk to veteran telecom executives about a product who's name I can't even pronounce? Even if I do learn how to pronounce it I'll never get past it's awkwardness.

I am very proud of OpenSER. OpenSER has been crucial in making Star2Star what it is. OpenSER is amazing and I have the utmost respect for everyone involved with the project.

I am ashamed of Kamailio. Same project. Same people. Same awesome, quality software. It just doesn't feel the same. Unfortunately this is my emotional reaction to this name change. I can't help how I feel and I'm sure other people (like Alex) feel the same way.

OpenSER is a phenomenal piece of software that commands respect. It's name should too.

Maybe we'll start a new "support" mailing list. Not for people needing technical support for OpenSER/Kamailio, but support for those of us who have been personally affected by this name change.

Wow, now I'm just being dramatic!

IPv6

I've been playing with IPv6 a bit in the last couple of days and by playing I mean:

- Setup IPv6 tunnel with Hurricane Electric
- Configured Cisco 2811 for Iv6 tunnels (both ends)
- Subnetted (is that a word?) our /48 from HE
- Configured tunnels in Linux with iproute2
- Used radvd in Linux
- Setup AAAAs for services
- Added/enabled IPv6 in AstLinux
- Played with ip6tables
- Worked on my super-secret IPv6 project (more on that later)

Yep, it's been an IPv6 week. As of right now I've got a main IPv6 tunnel from HE (in Dallas) coming into my 2811 in Tampa. I have a /48 routing down that to other tunnels providing multiple /64s to several locations. I'm setup for providing more IPv6 tunnels and /64s in the future from my 2811 (with or without connectivity to the IPv6 net at large).

I've got IPv6 in the datacenter. I've got IPv6 in the office. I've got IPv6 at home. I've got IPv6 everywhere and a TON of IP addresses to boot. It's really pretty cool and other than my funky tunnel configuration (which I actually kind of like) it's pretty easy. Once I've setup the tunnels I just route the appropriate /64s down to each PtP address for each tunnel at each location. It's a bit of a hub and spoke configuration but it works very well so far. Of course it helps when your tunnel gateway (my 2811) has seven upstream IPv4 carriers.

I've also added IPv6 to AstLinux:

- Kernel (IPv6, mobile IPv6, "41" tunnels, netfilter, etc)
- C library (uClibc)
- Busybox (apps in general, ping6, etc)
- mini_httpd
- OpenSSH
- ntpd
- stunnel
- rsync
- php
- libpcap
- tcpdump
- dnsmasq (needs testing)
- nmap
- radvd
- and more

The IPv6 kernel module alias is disabled by default. Anyone that wants to use IPv6 in AstLinux will have to enable it via (you guessed it) rc.conf. It could use some more testing (hint, hint) but so far it looks pretty good.

There was one more thing I was going to talk about... Of yeah, my "super-secret IPv6 project"... I'll have another post for that soon...

One Week

One week - almost. That's how long it took me to realize that Maddox is right.

This time last week I was plotting how I could sneak into line to get one of those new iPhones. No it's not because I'm some Apply fanboy or some moron that can't do basic math (I'm not paying for the phone or the service). It's because my company is excited about what we might be able to do with the Apps store and the iPhone SDK. Trust me, it's really cool. That's all I can say right now.

I knew we needed at least a couple of these things (iPhones) and I didn't want to get stuck without them. The app we want to do is awesome and I wanted to get to work on it. That meant I was getting an iPhone. I had two choices:

1) Carry two phones
2) Port my number to our AT&T corporate plan and cancel T-Mobile

I wasn't going to carry two phones. A guy I work with carries at least two and it seems like a hassle. I HATE hassle. So it looks like I was going to port my number to AT&T and leave T-Mobile.

I'll skip the next part. We all know what happened here. Quick summary:

- In line at 7:45am
- Out of store by 10:30am (16GB white)
- Phone activated by 3:30pm

Let's just say I couldn't believe the activation problems. I guess Apple and AT&T were too busy marketing the hell out of this thing to remember to buy more servers or upgrade their network. Unbelievable.

Now that I've had the iPhone 3G for almost a week, here's what I've learned. Looking around the web, everyone already knows this:

- The camera sucks. Stills are grainy and often blurry. It can't do video at all. The Motorola RAZR could do video - five years ago. Today any free phone with a service plan can do video.

- Battery life sucks. For the first time in years, I actually worry about my cell phone battery.

- I don't care what anyone says, the keyboard sucks. It does ok considering there are no buttons but Apple needs to learn when they're wrong. They were wrong with the first gen, and they still are. It is not usable for any real work. I almost got to the point where I started sending incomprehensible teenage TXT: "OMG! WHR R U? LOL!".

Obvious so far. Here's where people might start to disagree with me...

What really surprises me about the iPhone is how little Apple got right. The following things also suck:

- The phone. There is a delay when picking up a new call and audio quality still sucks, regardless of method - ear buds, bluetooth, ear piece.

- No MMS for txt. Plain text SMS like it's 1999.

- Bluetooth. It's borderline useless. No profiles other than headset and A2DP (so I hear). Wow, I'm so glad my company paid so much for such a crippled device.

- The iPod. I don't HOW they screwed this one up... With just under 1,000 songs, the iPod software freezes the entire phone for a few seconds upon startup. Navigating around the various functions shows more of the same behavior - random freezes. The audio quality is horrible. HORRIBLE. Regardless of EQ settings or type of music, audio sounds weak and distorted. Don't ask me how that's possible at the same time, it just is. Any application of volume shows clipping and distortion, regardless of source material. The rotate function will drive you crazy. Listen to a song. Toss the iPhone in your pocket at any angle. When you pull it out the screen will be rotated horizontally in some kind of artist/album/song selection menu that scrolls around. Yes, it's very pretty but functionally, it's crap. Just like the rest of this device. God forbid you need to get out of this travesty and back to the somewhat functional vertically oriented interface. Good luck.

- Just like the iPod app, Contacts takes at least 3-5 seconds to start - EVERY TIME. I don't have that many contacts - just under 300 (297). I can't wait for a few seconds every time I need to interact with that database. I just can't.

- The calendar. This thing might work for you if all you have to do is set a reminder for the slumber party at your BFFs house this weekend. After all, you're a 13 old girl and that's all you have to worry about. That's obviously Apple's target market, and they NAILED it. Let's see - scroll wheels for setting dates and times are superfluous eye candy (more of the same from Apple). The alarm for events is useless. First of all, because it isn't persistent. It doesn't require you to acknowledge anything and rarely repeats. Secondly, it provides fixed options for notification before an event. I know I live 22 minutes away from a meeting. I want to set an alarm for 22 minutes. Too bad. I have an iPhone. Apple knows 13 year old girls don't need that and probably couldn't figure that interface out anyway. Setting schedules for recurring events - daily, weekly, etc. What if I want an event M-F, and another event M, W, F. How about another Saturday and Sunday. These recurring events are not supported. I have to create a new event for each day. Absolute crap. If I depended on this to make it to meetings and conference calls I'd be out of a job soon.

- The interface. I know I'm not the average user. I work (and play) in a command line environment all day and have for years. That means I'm used to having somewhat of an intimate connection with my devices. I type commands, hit enter, and it does what it is told. The man-machine communication is there. It's like driving a BMW. You really almost do feel one with the machine. I don't think I've ever felt so disconnected from a machine like I do with the iPhone. I never got the sense that I was really controlling this thing. From the keyboard to the excessive scrolling, rotating, blinking and other useless eye candy, to the lack of configurable options in everything I've come to the conclusion that I can't interface with this thing.

- Rotate. Make rotate system wide or don't support it at all. Very few apps actually support rotate. Again, I don't know what Apple was thinking here.

I've got plenty more but I'm done complaining for now. I came from a Nokia E-70. Let me tell you why this phone is awesome:

- Real keyboard. I can smoke ANYONE typing on this thing. Seriously, try me. Did I mention it also has a full phone keypad?

- Full bluetooth. Transfer files, push contacts, tether to your laptop. ANYTHING you want. It's even the little things... For instance - Symbian supports "profiles". Profiles allow you to configure just about any alert or setting on the device. You store them in profiles and can change carious settings with a single button. Think of memory seats in your car. It's basically that for phone settings. Anyway, Symbian supports automatically changing the profile based on which bluetooth device it's connected with. Basically, I used this to change the settings on my phone once it was connected to my car. I can never feel vibrate in my car for some reason. I can hear the tones I've assigned to this profile. I don't need to think about it. Get in the car, settings change on the phone. Get out, and they revert back to what they were before. Brilliant.

- PIM functions (Contacts, Calendar) have never done me wrong in over a year of ownership.

- MMS. Good MMS too.

- Awesome camera. 2MP, complete with night mode and video.

- 3G, 802.11g wifi, SIP.

- Real battery. Expandable storage.

Did I mention this phone is over two years old?

I'm serious about the iPhone being a play toy for teenagers. Why do you think it comes with Youtube? Once you're done playing Light Saber get a real phone - Blackberry or something running Symbian. That's it and that's why my iPhone SIM is in my E-70 and my iPhone is sitting on the table where I dump all of my junk mail when I walk in the door.

Seriously, if I didn't need this for my project I'd prop it up somewhere and unload some buckshot on it. Or maybe I'd give it to my friend Jason. He teaches middle school after all. Maybe he can sell it to one of his students and get this thing where it belongs.

This is the ONLY time you will find any profanity on this blog. Get an iPhone, and you'll see how justified it is:

The iPhone is a piece of shit, and so is your face.

Maddox, you are the man!

Asterisk Cookbook

We've been trying to get the Asterisk Cookbook going. It's the same format as other O'Reilly cookbooks - practical instructions for specific problems posted as recipes, just like a cookbook you'd use in the kitchen (at least that's what people usually do with them).

I haven't contributed much but I have an excuse - I don't really work with Asterisk that much anymore. So, a couple of days ago I asked the other authors and editors if we could widen the scope of the book to include some of my favorite technologies. Anyone that reads this blog knows what that means - Cisco, OpenSER, etc. I plan on writing quite a bit about OpenSER. As I said in my OpenSER book review, OpenSER needs more press and documentation. Let's work on that!

I've now contributed three recipes! My SIP DoS/DDoS mitigation script and a couple OpenSER scripts. Some of the OpenSER stuff is a little obscure and probably won't make it to the final book. I'll be adding more OpenSER, Cisco, and SIPp stuff over the next days/weeks/months. Keep checking here and there for updates.

Oh, and if you feel like you have something to add, get a hold of one of the authors (myself, Jim, Leif, Matt, Jared, etc) and we can figure out how to get you an account on the wiki.

Book Review: Building Telephony Systems with OpenSER

I've been looking for and wondering about an OpenSER book for quite some time...

Everyone knows Asterisk is king when it comes to anything open source VoIP or telephony. OpenSER rocks but it just seems so, well, hardcore.

I can't imagine anyone walking into a Borders or Barnes and Noble, grabbing a book about OpenSER and cuddling up in one of those comfy, over-stuffed chairs on a rainy afternoon for some reading. Ok, I don't know anyone that does that anyway, and certainly not anyone with a book about OpenSER. I don't know about you but my tech books always end up getting rammed into my carry on for reading during "electronics prohibited" periods of air travel. That's all the time I care to dedicate to dead tree reads. But hey, it beats SkyMall (Jim Gaffigan: "Hey buddy, I work for SkyMall and I don't appreciate you jabbing us").

Bringing this back into focus (and on topic), is there a market for an OpenSER book? I've worked with two publishing companies in the past doing various amounts of writing and technical reviewing. Mostly O'Reilly but lately another company: Packt Publishing. Well, Packt decided there was a market for an OpenSER book and they decided to publish one. It's called Building Telephony Systems with OpenSER.

I found out about this book and knew I had to read it. What would an OpenSER book look like? What OpenSER features would be explored? What would it cost? What would it smell like? Ok, I'm just kidding about that last one but I was very interested.

I happened to be working on a couple of Packt Publishing projects at the time. I thought I'd contact one of my editors to see if they could hook me up. Turns out the book had already gone to press but they were willing to send me one. Cool!

Before I go any further I need to tell you: I won't be bought and I'm not easily influenced. Just because I've worked with Packt in the past doesn't mean I'm going to spare them any criticism or cut them any slack. If anything I'll go a little harder on them because they usually know how to get good authors and reviewers (me). ;) (Kidding, of course).

So they sent me a book. It's 295 pages and written by Flavio E. Goncalves. Flavio is a Brazilian that runs VoIP training in Brazil. Florianopolis, to be exact. Florianopolis is gorgeous. If you ever go to Brazil check it out. Hey, while you're there take an OpenSER training class from Flavio and get your company to pay for the whole thing!

Anyways, this is where my criticism starts to come in... I'm not one of these American English Nazis (does that make any sense?) that stands in line at the grocery store and freaks out when someone speaks Spanish or any other foreign language. However, I do believe that language exists as a mechanism to effectively communicate between people and sometimes that can be a little tricky even between two speakers of the same language. How many misunderstandings have you had with your friends, relatives, strangers etc while speaking the same language?

Brazilians speak Portuguese and I love it. It's one of the best sounding languages around. Being Brazilian, Flavio's first language is of course, Portuguese. It's also the language this book (Building Telephony Systems with OpenSER) was originally written in. My understanding from reading the book is that the book was developed out of Flavio's original (Portuguese) training course work and later translated to English. This makes for some very interesting and (sometimes) difficult to understand English language usage. There are several instances in the book that are difficult to follow because the language is, well, awkward. It looks like there was a proofreader... Maybe his style is different from mine but I'm pretty sure most people agree with me.

Part of me feels like this criticism is unfair and I wrestled with even mentioning it. Here's my chance to elaborate on this and explain myself.

Neither the author, editor, nor reviewers are native English language speakers yet this is what the book was written in. That's amazing to me. These people, in addition to being remarkably talented in their respective fields (publishing, technology) can all speak multiple languages and work on a team, around the world (India, Romania, Brazil) in a second language. The world is flat, my friend.

I feel like I can barely work and speak English half the time. Most Americans are the same way. We're all lazy, fat, SUV driving slobs that grunt back and forth in something that resembles English (which is already pretty "ugly"). Ok it's not that bad but that's what it's often made out to be... Anyone ever seen Idiocracy?

So for a technical book, my main criticism is English language usage and that's not even that bad. So far they're doing pretty well! On to the technical stuff...

I thought the book did a great job explaining the use of various OpenSER modules and OpenSER scripting in general. I also like how Flavio introduced readers to the various (relevant) SIP RFCs along the way. In working with OpenSER and SIP in general I can't stress how important this is. Many SIP platforms isolate you from the RFCs as much as possible. Everything is taken care of and it magically works (even with Asterisk when compared to OpenSER). With OpenSER this is not the case. You better know your RFCs. You better know the difference between components in a SIP network (Proxy, UAC, UAS, B2BUA, etc). You better know some core aspects of RFC3261 (stateful vs. stateless, strict routing, loose routing, methods, dialogs, domains, etc). Flavio isn't afraid to present this to the reader and he does it in a way that doesn't come across as snobby. Depending on the situation I've been known to quote RFCs and sections before. I probably (almost always) end up looking like a jerk but sometimes, hey, it needs to be done!

While reading I was disappointed to see so much focus on MediaProxy. I don't like MediaProxy. It's written in Python. Yuck. Enough said. I kept reading and by the end of the book Flavio admitted the mistake of more or less ignoring RTPProxy and agreed it was mostly superior. Bravo! No one knows everything, not even the guys that write the books. It was refreshing to see this in print. Once again, well done.

A couple of specific (nit picky) problems... The Asterisk config for a PSTN gateway on pg. 147 is suspect. The type doesn't make it clear which file you are working in and I doubt anyone would really use that SIP configuration in production. There's also no Zaptel config. I know this isn't an Asterisk book (there are plenty of those, the best one is free) but there should at least be a pointer to an online resource for Asterisk/Zaptel configuration or something.

The same thing goes for the Cisco config. If you look closely you'll see the dial-peer uses sip-notify for dtmf-relay. No one uses this and we certainly haven't configured OpenSER for it. Again, it's nit picky but some user could end up pulling all of his hair out trying to get this to work.

I didn't go over the OpenSER script bracket by bracket but it looked pretty good. That's even tougher to comment on because it's practically a programming language and no programmer ever completely loves the way someone else wrote something. That's just how it goes.

Overall, this is a very good book and it deserves to do well, for Flavio, everyone at Packt, OpenSER and the community in general. People who should be running OpenSER aren't. Hopefully this book can help change that!

Thank you to Flavio, the OpenSER team, and everyone at Packt Publishing!

An update on SIP DoS mitigation

After spending a couple of hours on the VoIP User's Conference last week I thought I'd keep working on my SIP DoS/DDoS script a bit and get it to the point where I'd like to run it on some of my systems (if only to collect statistics).

The new version includes several new features, the most exciting (and certainly controversial) are changes to the string pattern matching for SIP requests. I now block ALL tel: URIs by default. I don't like tel: URIs. I think they're anti-SIP and you shouldn't use them. Now my script won't let you (unless you disable it, of course).

Anyways, I had to do this because (as I've already mentioned), I changed the way pattern matching runs on SIP requests. Two big changes:

1) Support a (configurable) offset for searches into the packet.
2) Update the SIP method matches to match "$METHOD sip:"

First of all, we now (by default) only search the first 65 bytes of the packet. That should be more than enough to search the first line for the SIP method and URI. Speaking of URI, I now match the URI along with the method to prevent false matches. Before we were only matching on the method and it was causing some false positives because of things like the Allow: header (where all of the supported methods are listed).

We'll see how this goes.

One thing I wanted to bring up in the VoIP User's call last week but failed to do so is the possible use of OpenSER to protect Asterisk (and other systems) from attack. In addition to supporting cool things like SIP message length filtering (msg:len) you can also use the pike module for some basic (but slightly more intelligent) SIP rate limiting. Of course then you need to support an OpenSER config, which a lot of people don't want to do...

What else is new in the script? Basic support for udp and/or tcp, configurable bursting, fixes to the FORWARD support and more. Check it out, it's free!

SIP DoS/DDoS Mitigation

An interesting thread came up on Asterisk-Users the other day...

Someone had problems with some miscreant attempting (and apparently succeeding) to bruteforce a SIP account on his Asterisk system.

That's a problem. Asterisk currently has no means to protect against any type of SIP flooding/bruteforce/DoS (other than running out of resources/crashing). That's ok because some people (like myself) would argue that these types of attacks are best handled via other means...

Like the kernel, or preferably the kernel of a completely seperate box.

It got me to thinking - maybe I could whip up a script using some of the cool stuff in iptables/netfilter to mitigate these SIP DoS attacks in the kernel. I don't have a ton of time to elaborate on the script but for now here it is:

http://admin.star2star.com/sipdos

It's not great. It's not very SIP-specific. Who knows how accurate/effective/resource intensive it is. It hasn't been tested (much). For all I know, it will just make things worse. However, I think it is a step in the right direction and hopefully one of many tools that can be used to protect Asterisk and other SIP/VoIP systems.

By the way, I call it "SIP DoS Mitigation" because with any large enough DDoS attack, you are toast. ..

Speaking of other tools... We're all going to celebrate America's birthday this Friday by getting together on a conference call/IRC to talk over some of these issues with the VoIP User's Conference. Hear you there?