Yesterday I was ranting about my frustrations with modern technology. Today I'll be making some apologies.
I wrote my post yesterday after struggling with a Snom 360 for a couple of hours. I came at it today, fresh from my five hours of sleep last night and got it working in 10 minutes. A long time ago while working my first real job at Wisconsin Vision Associates, my co-worker taught me the benefits of a "fresh pair of eyes". I had a tendency to obsessively attack a problem until I solved it. This had been an issue of mine for quite some time. I rarely made it to my first class during high school because I would often stay up until 6am working on some computer problem I was facing. Dave used to remind me to stop and try again later with a fresh pair of eyes.
Looks like that's all I needed. I came in today, tried upgrading the firmware (using the bootloader interrupt method) and the Snom 360 came to life. I had a couple of reasons for testing the Snom 360. First, I need to configure them for Star2Star. Secondly, I wanted to test the Asterisk sip-tlstcp branch. Why TCP for SIP? Why TLS? Why bother?
First of all, SIP is pretty insecure. It's 2007. Everything, everywhere should be encrypted. There's just no excuse for it anymore. People transport some pretty valuable data over the telephone. Their credit card numbers, their banking/identity/medical details, their deepest, most private thoughts. Not the kind of stuff you want just anyone to get their hands on.
If you are using standard VoIP, it's probably SIP. SIP is a signalling protocol, it handles session initiation (hey - Session Initiation Protocol) for media sessions that (typically, but don't have to) use RTP (Realtime Transport Protocol). In a typical call scenario, the source and destination phone numbers, caller name, etc would be transported by SIP. While this data isn't terribly important, it could be valuable to an attacker. Most of the good stuff, however, is transported using RTP. This includes DTMF digits (if using inband or RFC2833 signaling) and audio (your voice, music on hold, heavy breathing, whatever). It's more important to secure RTP. The best standard for this is currently SRTP (Secure RTP). The problem is, like all crypto, there has to be an exchange of keys. How do we do this? Easy - SIP. But what if the SIP channel isn't secure? Ah ha. It needs to be. That's where SIP TLS comes in.
Fine, I'll implement SIP TLS then. Well, in Asterisk you have another problem. TLS (usually) requires TCP. The SIP channel driver in Asterisk doesn't support TCP. Why use TCP for SIP? Isn't that bad, doesn't that mean my voice packets will be delayed/blow up/melt my router? Shame on you! You haven't been paying attention. Your voice uses RTP and even with SIP TCP/TLS that's still UDP (even with SRTP). Don't worry about that. Only the session-type stuff (SIP) will use TCP. Why bother with TCP? Well, first of all, it's cool. Secondly, we get to use TLS. Third, TCP allows for packet fragmentation and (ultimately) will allow for more cool stuff to happen. For instance, if you've got some crazy videophone that supports a million types of sessions, codecs, etc your SIP+SDP infoz could possibly exceed the MTU size of your connection. Bad things will happen.
With this branch of Asterisk, we get all of that cool stuff above with the exception of the actual SRTP implementation. Don't get so greedy! I'm sure it's coming. This is open source, after all. If you don't like it you can ask for your money back and deal with some other vendors.
Anyways, back to the original point. I wanted to test this branch and it had already been tested with all of the other equipment Star2Star uses - Cisco gateways, Polycom phones, other Asterisk systems, etc. I wondered if I could get these Snom phones to work with it. But first I had to get them working with Asterisk and standard SIP/UDP. I did, and a little while later, I got it the Snom to use TCP/TLS. From a message I posted to Asterisk-dev:
*CLI> core show version
Asterisk SVN-group-sip-tcptls-r92242-
a i686 running Linux on 2007-12-10 19:29:26 UTC
*CLI> sip show peer snom
* Name : snom
Secret :
MD5Secret :
Context : default
Subscr.Cont. :
Language :
AMA flags : Unknown
Transfer mode: open
CallingPres : Presentation Allowed, Not Screened
Callgroup :
Pickupgroup :
Mailbox :
VM Extension : asterisk
LastMsgsSent : 32767/65535
Call limit : 0
Dynamic : Yes
Callerid : "" <>
MaxCallBR : 384 kbps
Expire : 3028
Insecure : no
Nat : RFC3581
ACL : No
T38 pt UDPTL : No
CanReinvite : Yes
PromiscRedir : No
User=Phone : No
Video Support: Yes
Text Support : No
Trust RPID : Yes
Send RPID : Yes
Subscriptions: Yes
Overlap dial : No
DTMFmode : rfc2833
ToHost :
Addr->IP : 10.16.5.237 Port 2060
Defaddr->IP : 0.0.0.0 Port 5060
Transport : TLS
Def. Username: snom
SIP Options : (none)
Codecs : 0x4 (ulaw)
Codec Order : (ulaw:20)
Auto-Framing: No
100 on REG : No
Status : OK (25 ms)
Useragent : snom360/7.1.30
Reg. Contact : sip:snom@10.16.5.237:2060;transport=tls;line
*CLI> sip show tcp
Host Port Transport Type
10.16.5.237 2077 TLS Server
Not only did I get this phone to work, I got it to work with some super-cool bleeding version of Asterisk. Heck yeah. Plus, it turns out I really like Snom phones. Maybe even more than Polycom!
I'd like to clear the air about something else too... I was really angry at BMW yesterday. So angry that I made an appointment to test drive a potential new car - a Maserati Quattroporte. It's an Italian thoroughbred. With a Ferrari engine, Pininfarina styling, and a legendary name to boot. A few miles down the road, I realized BMW was the car for me. Don't get me wrong, the Maserati is a really nice car but it has some serious shortcomings. The GPS system looks like 8-bit Nintendo. The DuoSelect transmission revs WAY to high and is too clunky. Two serious problems.
In summary, I have some apologies to make - to Snom, to BMW, and to an entire country - Germany. Over-engineered or not, you're still the best at it.
Hey! I enjoyed reading your post. Well, not only because I'm from Germany :-P Interesting stuff you're writing about and I like your writing style. Cheers!
ReplyDelete