SUMMER IS HERE!. I decided that i'm going to really make the most of this summer, rather than waste it in the office doing not very much with life (although the company would probably disagree :)).
Tommorow i'm back off down to Plymouth (i was there last weekend too seeing my great grandfather who had a stroke a few months ago), not only to see my great grandfather again, but also to take my International certificate of competence (actually, the RYA Powerboat Level 2) with Tim and Pookey. While the course is probably fairly basic, it means that not only is yacht insurance cheaper, but it is good for me to refresh the rules of the water: considering i've not been sailing since we took the boat to Greece 8 years ago!
We're also going to take the CEVNI exam for inland waterways so we can come back through the Canal du Midi rather than having to go around Gibraltar!
Then, on Sunday we're taking our VHF operator course and exam, so we are all authorized to sue the radio :)
I'm tempted to take a PADI open waters course when i get back from Greece. Having diving kit on the boat would be very useful at times ...
In other news is my driving test is now the 28th June in Banbury rather than 1st August thanks to my dsl.pl script which sent me an SMS to tell me a new slot became available :)
I also got a random call from my father today who was sitting in Molivos harbour with 2 friends from when i lived in Greece: Rebbecca and Justine. I've not seen them for about 7 years, and will hopefully meet up in London in July. We sailed over to Turkey together with my great grandfather back in '97 or '98!
So i'v been lazy and not updated fora long, long time. Probably because not much has changed :)
however, a few things have changed:
(Work In Progress)
I really do not approve of SIP parsers that cut corners when parsing SIP messages, and i'll tell you why. Note that this is not a true story ... yet, and the examples aren't the best in the world - if i have a few hours spare, i'll have a think about real issues that are common in a number of parsers/stacks i've seen.
Company Y wrote a SIP proxy that they rekoned was the fastest thing around; it claimed 80k/messages a second on a single thread of a xeon - not a bad number by any means.
While doing policy checking on the message, for speed reasons, it scanned a message for a "\r\nHeaderName[ \t:]", and parsed everyhting in until the next "\r\n[^ \t] ". Fast and effective. It then validated the content between those points to ensure it was valid for the identity provided, but provided relaxed parsing, allowing slightly dodgy contents if it knew how to handle it.
Problem is, that there might be another "\r\nHeaderName: xxx" futher down the message headers, that is totally valid. When the message is processed further downstream within the same trusted network, the second parser (which was a strict but silly parser) ignored the first header because it was broken, and jumped stright to the second, which was valid. It assumed that the upstream proxy had already validated the contents of the header in question, so just went ahead and used it. great. a security hole.
Another problem I have already seen is some really stupid parser (there are lots out there you know) doing what it really shouldn't with this:
INVITE sip:moo@cows.com SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:4567;branch=xxx X-Header1: sip:moo@cows.com;moo=" Some-Evil-Header: a proxy was supposed to remove X-Header2: "
There are lots of ways that someone can trick a parser unless every single last rule is followed from RFC3261 (minus a couple of ABNF bugs). If you ever write a SIP stack, make sure you do it right. Otherwise you risk introducing security risks for everyone - imagine if someone managed to find a way to get a proxy to ignore a Max-Forwards header it inserted itself because of clever SIP formatting bugs - especially if it goes via a forking proxy, sure - loop detection. Great - if the proxy does it!
People deploying networks might want to consider sticking to the same parser throught trusted elements for reasons outlined above, the security risks involved with having different parsers performing different things when a message header is not understood/invalid could be fairly dire. At the very least ensure your edge proxies forward strictly compliant messages, so the edge proxy is clear on what it is allowing through rather than just forwarding them.
SIP is a great protocol, but it's also a very dangerous protocol when used with some of the stacks currently out there. Combine that with every single stack out there supporting UDP, and you've got a rather serious DOS tool... especially with forking.
When we first found our Jordan was pregnant last year, we decided we needed to move to a larger house. After spending a while looking around, we came to the conlusion we were going to have to move out of Docklands if we wanted anything reasonably sized, as it seemed there was absolutly nothing larger than 3 bedrooms that were half decent.
Just as we'd found a lovely 5 bedroom house in Oxford, I received a phone call from a letting agent; "I've just had a 6 bedroom house come on the market 300 metres away from your current place, are you still looking?"
What the hell I thought, nothing to loose (other than the extortionate rental costs). So we plodded over and had a look.
The house was perfect for us; 4 storey, 6 bedrooms, recently rennovated, wooden floors nearly everwhere (great for messy kids!), and best of all for me, a massive room that made a perfect office, overlooking the Millenium Dome (now the O2 Dome) and the river. Couldn't ask for a better view, short of renting out the top floor of Canary Wharf! It even had a large balcony the size of the current flat, and a great big (for London) patio undeneath .. so some space for Demi to have a paddling pool! Being only a few hundred metres away from the old hosue it meant that Demi would not need to go to a different nursery, and I would not need to worry about having 50mbit/sec+ internet, as I still had line of sight to two of the UK's main datacentres.
Within a few minutes we agreed on a price and decided to take the place.
That was 7 months ago.
Sounds great, right?
Right.
However, One of it's major charecteristics is also one of it's major downsides: Being on the Thames.
Firstly, in the summer, on a very hot day, the smell can get pretty, well, strange ... a bit like yeast. It's not really a bad smell: i kind of like it. It reminds me of the French canals when I was very young. However, Jordan really doesn't seem to like it.
Secondly, and this one is a lot worse than the smell: THE BLOODY PARTY BOATS. Yes, you know - the booze cruises that take sober people on board, and go up and down the river playing really loud music, getting them completely wasted. I'm sure it's great fun for the people on the boats (i've done one once, and it was fun, yes). But we have a 1 month old and 3 year old trying to bloody sleep at midnight. Argh. Of course, we didn't know this before, as although we'd been living in the area for a long time, we'd been living on the Canary Wharf docks instead. Because the hosue is Grade II listed, there is no double glazing: so the neighbours have no problems, just us.
Now, if someone wanted to open a nightclub 50 metres away from someones house, it's highly unlikely they'd be given permission by the council... But, who gives the boats permission to park an (open topped) nightclub outside my house 15 or 20 times a night?
Moral of the story: Don't live on the riverside unless you have double glazing or like lots of noise in the summer.
Yet another asterisk bug.
This specific problem involves an INVITE forking at a proxy or UAC and rejoining at the asterisk box.
Under 8.2.2.2 (Merged Requests) of RFC 3261, there is the following text:
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
Asterisk fails to implement this - but that's not my problem.
The problem is, when the first branch gets a 200, the second branch is CANCELed - to which asterisk should respond with in the case here with a 200 OK with the same branch as the CANCEL request, and 487 the second branch.
However, asterisk does something more voodoo than that. Instead, it sends the 200 response to the CANCEL back on the 1st branch, and then sends a 487 on the same branch, dispite the fact we've already received a final (200 OK) response already.
The 2nd branch just lies around, and it appears there is no way of cancelling it.
If anyone feels like fixing it, please, re-write chan_sip from scratch. Don't even bother trying to fix it. I looked into doing it, and very quickly gave up after realising how badly it's (not) designed.
Someone asked me this evening why I have such a problem with people using asterisk for SIP. The answer is fairly simple:
It's SIP implementation is one of the worst i've seen. About as non-compliant to RFC 3261 (The SIP Specification) as they come.
Infact, it's probably as bad as some of the utter rubbish i've seen while evaluating no-name ATAs.
However, i'll obviously not just leave it at that, but instead update myself (and you) on asterisk's SIP progress. Although it's been a while since i used asterisk (I originally wrote chan_sccp and chan_bluetooth a few years back), i got so fed up with the shocking lack of skills the developers had back then, and how it made a 1st year uni project look impressive, i quickly gave up all hope on this project, and started wasting my time on other things.
Note: I'll leave things like the monstorous size of the single chan_sip.c file (13k lines), and other such developer evils out of this (including the complete lack of design), focusing instead on just pure RFC 3261 compliance.
By far the biggest gripe is the complete lack of anything resembeling a proper SIP parser. Infact, it's a joke. All over the place, we see code like this:
strcasecmp(content_type, "application/sdp")
or
strncasecmp(content_type, "multipart/mixed", 15)
or
strcasecmp(req->line[x + 1], "Content-Type: application/sdp")
... and that was in just one function! (check out find_sdp
For those that are wondering what the problem is here, RFC 3261, the document that specifies how the SIP protocol works, says:
7.3 Header Fields SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding. This specification conforms to RFC 2234 [10] and uses only explicit whitespace and folding as an integral part of the grammar.
Taking a quick look at the syntax allowed for the Content-Type header, I find:
LWS = [*WSP CRLF] 1*WSP ; linear whitespace SWS = [LWS] ; sep whitespace HCOLON = *( SP / HTAB ) ":" SWS Content-Type = ( "Content-Type" / "c" ) HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter)
What this is saying, is that all of the following examples are valid Content-Type headers:
[Content-Type: text / html ]
[Content-Type: text / html]
[Content-Type: text /html]
None of the above, would, of course, match, as Asterisk clearly does nothing to handle these edge cases (although i've seen a few implementations that suffer from trailing whitespace syndrome). Sure, the above examples may be convoluted, but when a specification clearly states that something is acceptable, implementations MUST adhere to them, otherwise we loose interoperability. Any programmers who are incapable of following fairly simple specifications, are in my opinion, idiots, and the reason we have interoperability problems in the first place.
This comment was interesting:
#define SIP_MAX_PACKET 4096 /*!< Also from RFC 3261 (2543), should sub headers tho */
SIP_MAX_PACKET is then used to define the size of the data structure for holding a SIP message in (see struct sip_request).
Curiously, i could not find a single mention of 4096 in RFC 3261:
$ grep -c 4096 rfc3261.txt 0
I did, however, find this:
However, implementations MUST be able to handle messages up to the maximum
datagram packet size. For UDP, this size is 65,535 bytes, including
IP and UDP headers.
The 200 byte "buffer" between the message size and the MTU
accommodates the fact that the response in SIP can be larger than
the request. This happens due to the addition of Record-Route
header field values to the responses to INVITE, for example. With
the extra buffer, the response can be about 170 bytes larger than
the request, and still not be fragmented on IPv4 (about 30 bytes
is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when
path MTU is not known, based on the assumption of a 1500 byte
Ethernet MTU.
hmm, odd?! Where exactly did this 4096 come from?
For those that want more, check out the same unreasonably defined limits on number of SIP headers allowed (SIP_MAX_HEADERS), number of lines in a message body (SIP_MAX_LINES), length of a contact (SIP_LEN_CONTACT), and numerous others ...
I'm sure any serious Asterisk SIP user will already know about this ... asterisk does not have TCP support. A rather major requirement considering it places artificial limits on sizes of SIP messages. Just to show you i've not made it up:
All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.
It's been a while since i last stopped working. Infact, exactly year, when i went to see my family in greece for a few days. Since then, i've worked every single day (yes, including christmas day and new year), so have decided i'm going to finally take a break.
It's not because I feel the urge to stop working, because i'm tired, or even because i can't concentrate on work. Infact, it's exactly the opposite. Over the last few months, i've been coming up with so many different ideas (both technical and business), that i'm trying to do far to many things at once, and my brain just won't stop.
So i've decided to take a few days out to do nothing but consider all these ideas, hopefully think of a few more, evaluate which are good ones, and which are stupid. Evaluate which ones I should work on to make money (i still need to do that), and which ones i should work on "for the good" (and maybe make a bit of money, too :-)).
And of course, spend some more time with my family.
I've also made a decision to "blog" more, so if you're lucky (or not for some people), you might notice an increase in rants.
Maybe. Just maybe.
On 22/07/06 at 19:37, Jordan gave birth to our second daughter, Solaris Marina Zourzouvilly.

Jordan had a few complications with the afterbirth not being delivered, so had to have a small operation, but is recovering quickly, and should hopefully be home tomorrow.
Thanks to everyone for your kind emails/calls/messages, we both really appreciate them.
There are a few photos here
For those than are wondering, no, Solaris is not named after Sun's operating system. It is latin, and means 'Of the Sun'.
Steve Kennedy seems to think that VoIP calls being free is a bad thing in the long term. From his post:
As everyone moves to zero or flat rate calls the telcos are going to struggle, they're used to billing minutes and have an industry out of it. They are going to suffer badly when their revenues decline. More consolidation, more firms going belly-up. That all sounds good initially, but then there's actually less competition and the market will end up with a few super Telco/ISPs.
It all comes down to Bell heads vs Net heads, and the Net heads are winning, though there's trouble in that area too as the US is fighting to make content providers pay more for people accessing their services, VoIP may fall into that category.
What's good for the consumer in the short run, may be disasterous for the industry and thus competition long term.
Disclaimer: This is my personal opinion and might not reflect the opinions of my employer or any other organisations i'm involved with.
Also, nothing contained herein discusses the realms of mobile (both MNO and satellite), which is sort of a totally different discussion due to cell/sat costs, etc
I'm afraid I couldn't disagree more Steve; it's going to be a good thing for both the consumer and the industry in the long run - although not the telecoms industry you are thinking of (which will be neigh on extinct in a few years). Thoughts like this, i believe, stem from the fact the telecoms world is so fixated around the price per minute model, as it's something they've been doing for far, far to long. Yet the 'new' telcoms world rolling out VoIP can no longer justify this - and if companies are not rolling out VoIP, (at least internally), they will be gone in a few years due to not being able to compete with their competitors.
First up, some background. Telecommunications no longer requires the massive infrastructure it did even 10 years ago, with networks merging voice and data onto the same IP network (i.e, the Internet).
While it may not seem paticuarly important that the two seperate networks are merging - it is. With the advent of some impressive compression technologies (MP-MLQ is almost reaching the magic MOS of 4.0) in under 10 kbps, the number of channels that can be transited over what is already a very cheap infrastructure compares to traditional TDM is phenomenal.
Combine that with the fact that interconnecting at IP is far cheaper than TDM (compare the cost of an E1 line card with the cost of a 10mbit line card! - and IP backhaul is also cheaper), that VoIP platforms are a fraction of the cost of identical TDM equipment with the same BHCA specs, and you quickly see that scalability, switching infrastructure, and redundancy is not where the cost of IP Voice networks are.
As costs have moved down to be more inline with IP network access, so can the charging models. I personally foresee pricing being moved towards a subscripton based model for capacity, not based upon usage, as usage cost is negligable - essentially the same as the IP world.
Saying that, the IP data world does not provide QOS in the way voice needs to, so obviously there is a slightly higher per byte charge that data, as real time media can not withstand congestion like other types of data can. But thats not to justisy per minute calls, with the charge depending upon the destination. After all, you (as an end user, i'm not talking about transit connecticity here) don't pay more to download From america than you do from the UK, right? What do you pay more for is: The quality of the connectivity (i.e, packet loss + latency), and in some cases how much you download.
And that is where VoIP will go. you'll pay based upon what you deem suitable quality. When i'm talking to Jordan (my wife), or any of my colleauges, i generally don't care if i'm talking with anything above an MOS of 3.5 or so. However, when talking to a client, or participating in a conference, i would get annoyed if the quality is bad. It's all about the bandwidth, baby.
and of course, what i really care about, is latency.
So now it looks like i'm arguing for per minute charges from your voice service provider - just in the form of different charges for different call quality? Wrong! Many people don't realise than SIP is short for Session Initiation Protocol. It's designed for setting up sessions. It actually has nothing to do with carrying the actual session data (i.e, the voice itself) from one phone to another - that's the job of RTP. RTP, in almost all cases does not need to go through a voice service providers network (unless of course, it's their network providing you with IP connectivity). So, your ISP will be the one that needs to implement these things, and bill you for them.
However! The way things currently are on the net, there is not any way for your phone to ask your ISP to reserve resources from your phone all the way through the networks to the person you are calling's phone - and that is a problem, as it means VSP's need to be providing the connectivity directly to the phones you are making a call from in order to garantee resources - something which i'm not a fan off. ISP's are good at providing IP, and VSP's are good at providing Voice services. Don't mix the two too much, or you end up with an Asda/WallMart of the internet world - Sure, they may make lots of money, but i much prefer my local bucher and fishmonger. (and besides, Asda and Wallmart mostly just sell other peoples products).
Of course, the 3GPP defines a model for building a network that provides signalling and media, but there is nothing within the specifications that say they need to be on the same networks, and that the media can't flow directly from one device to the other (other than of course, resource reservation).
So, i guess what i'm trying to say in a long winded way is: let's charge for bandwdith, not signalling. Voice providers should be charging for a signalling service (actually, an AOR/GRUU service i guess), and data providers charge for data usage. Sure, data providers will get more revenue, and voice providers will loose some - but the voice providers costs also goes down. If voice service providers are unhappy with this, then they should start developing intuative services, rather than ripping people off for providing the same stale services.
However, we (the Net heads :)) still have a few issues to overcome. Some that are currently really worrying me (note, these are all mostly SIP issues, the obvious winner of the VoIP protocol war) are:
Pookey recently blogged about the need for a decent mail client. I couldn't agree more. As with almost all software, operating systems, programming languages, and protocols - all mail clients suck.
Other things for consideration into a new mail client, along with his current list:
I got pissed off with WordPress, so i tried TextPattern. I got pissed off with that, so tried MovableType. None of them did what i wanted - a simple, plain text editor interface without any fancy javascript editors or such.
Mosly bizzarely, none of them appeared to output XHTML as the content within the RSS (although maybe they can, but I wasn't in the mood for hacking someone elses PHP, *shiver*), just encoded HTML - which feels just so wrong in 2006.
Note: Now i see what Pookey was ranting on about when whining about the problems with writting a real world RSS parser for Feed Banana. (Sorry i can't 'pingback/traceback/ifconfigback' you pookey - i've not worked it out yet)
So, 10 minutes later, an XSLT template addition to the current site, a few simple bash scripts, with moderate sprinklings of XMLStar, and i'm now running a fully web 0.1 compliant blogging "thing" (whatever the in name for them is these days, god knows - iBlogs maybe? :)).
Anyhow, all that is left to do by the looks of it is add traceback/pingback/whatever the hell it's called, and i'll be right up with the Web 0.2 guys. Ohh, and an RSS or Atom feed - once i work out the difference.
My how the web has changed in 3 years. I leave web stuff to go into programming real applications, and look how it all changes. I feel like an old man.
PS: Who's Scooble? :-P
Update: Upon further investigation of this whole RSS thing, i've discovered:
RSS is an XML-based format, which looks much like related formats such as HTML. Rather than including presentation information, though, the elements available in an RSS file are strictly limited to those required to define such things as a headline, a brief blurb, and a link to richer detail.
Well there, you really do learn something new every day (and i didn't mean the fact that RSS was XML, duh :)).
On the plus side, Atom looks like it's a far more well thought out for Syndication. I'm going to try and spend some time over the next few days reading up a lot more on it, and pondering what Atom could do with SIP. I'm sure there are some pretty funky applications out there (SUBSCRIBE to Atom feeds, and get NOTIFY'ed on changes anyone?)
As so many people are asking me, here's an update:
Jordan is being induced on Friday. We have 7:30am (!) appointment at the hospital. Hopefully things will be over fairly quickly (although it did take 3 attempts over 3 days with Demi), so we should have a Solaris Zourzouvilly sometime on Friday.
Jordan's pretty damned fat now (err, 'Large') and waddling around in the heat like a trooper, bless her. She's doing great; especially in a house with 4 flights of stairs!
Although i heard of it a while ago, i’ve just had a play with Windows PowerShell, previously known as Monad/MSH on XP, and I have to say – what an excellent concept. I’ve always been a big fan of .NET, and the thought of having the entire set of .NET libraries available to me at the shell is just – wow.
Take a peek at the PowerShell team’s blog for loads of examples of msh in action.
At this rate, i’m not going to have any excuses left for sticking to using a KDE desktop. With a decent shell finally on the horizon, it looks like the day i start using Windows on the desktop again may be closer than ever.
I noticed the following text on DCGLUG the other day:
DON’T BUY WINXP!!! Just cos its not supported doesn’t mean it’ll stop working!
I’d just make sure you back it up properly ( to your linux box) then re-install if it gets compromised
Now, this got my attention. Why on earth would someone give advice to continue using an operating system that is not supported. The security risks are insane. There are still millions (apparently, 78 million) of people using Windows 98 + ME – a ripe target for spammers, hackers, and organised internet crime groups who need zombie machines to perform their dispicable nufarious crimes. The advice, surely, should be to move away from Windows 98 and ME now that there are not supported as quickly as possible. My reply was as follows:
Sorry, but what amazingly bad advice.
Sure, you don’t have buy Windows XP, but that doesn’t mean you need to continue using a buggy, security hole ridden OS.
Using the age old car analogy: Would you advise someone to continue using a car without a seatbelt? assuming they were not a legal requirement, of course.
If you want to stick with using windows, then DO move to XP as soon as you can. Alternatively buy a mac, or move to linux. even if you move to win2k, fine. just whatever you move to:
-------> KEEP YOUR MACHINE UPDATED <-----
... and this is why you should no longer use 98 or ME. because there are no updates. People can now exploit it, safe in the knowledge MS will not release any more updates. Absolutely perfect for spammers, scammers, and hackers.
Even better for them, it doesn’t come with the “seatbelts” that 2k and XP now do.
If you do continue using win 98, then do not connect to the internet (for all of our sanity), or expect application upgrades to continue working for much longer. If you do continue using it, every time you get a piece of spam, then remember: people whole followed this advice are one of the reasons you are getting that piece of spam in the first place. If you suffer from credit/debit card fraud, then remember: the advice to continue using windows 98 was almost certainly the reason (or your lack of common sense).
Banks are 100% right to not support people running security risks to use their services – it encourages people to upgrade, something that is really badly needed.
However, it appears that some people will allow their hate for Microsoft get in the way of security, one reply looked like this:
No, no, no! Once again do not move to XP. If you have programs that need to be run on windows for whatever reason then you can run them reasonably safely off the net or behind a firewall.
If you are unfortunate to have to use IE for managing a bank account that you have no control over you have your old copy of 98 and configure your firewall to only allow that machine access to the sites/ports necessary to make the bank account work.
What you do not do is give large quantities of money to a company that makes the same mistakes over and over again – probably deliberately so mugs will upgrade.
Bizarre. This thread quickly turned into a handbag bashing argument between Linux Zealots and and me – and i’ll cover the points made in another post.
Someone with more sense pointed out that machines running 98 will probably not handle XP. A completly valid point – sort of.
However (and this is text adapted from this post i made), kettles, toasters, washing machines, microwaves, tumble drier, tumble driers, lawn mowers, and fridges to name but a few household appliances that all need replacing after some period of time/usage – generally, the price dictates the quality, and thus how long it’s usable life is.
While my grandparents had a washing machine that lasted 25 years, my mother gets through one every 2-3 years (5 kids!). I’ve only got through 2 kettles this year alone – but i blame the amount of coffee i drink. my mother has had just one kettle in 4 years… or at least one that looked the same last time i was there.
Explain why computers are any different? People seem to forget that windows 98 is now 8 years old, and ME is 7. A very long time in computer terms. 6 years before that we were lucky to have DOS, let alone windows.
i’d think you are a complete idiot for putting the public at risk if you were driving around a car lacking basic safety features. even more so if you were actually advising the use of dangerous cars. again, exactly the same thing with computers.
Cisco’s NAC stuff (incl 802.1x to an extent, too) does this already. It checks the software you’re running on your computer is up to a certian version (or patch level). If you’re running old software that is a known security risk, then your connectivity is either sevierly restricted (i.e, outbound HTTP only to allow upgrades), or not allowed at all. Obviously the not allowed at all thing is a bit silly in this case, as how are you supposed to upgrade :)
I’d personally like to see ISPs require something like this too. Why should Internet users who keep their machines up to date have to pay for the users who don’t?
Exploited machines sending out spam, acting as a DDoS drone, or trying to exploit other machines are using more and more bandwidth – which obviously pushes the costs up for the ISP, who in turn has to pass costs on to the user.
Not to mention that any decrease in exploited machines means decreases in spam.
Although it would obviously be possible to work around any sort of NAC that an ISP used, the idea would be that it’s the people who don’t know how to work around it that need this kind of access control in the first place. Generally, technical users are fairly good at keeping machines up to date.
I’m heavily up for computers requiring a certain “software safety standard” – for both the software and the user (the hardware already has in form of CE in Europe) before being allowed to connect to the internet. Hopefully a law will one day require this.
For gods sake, just make sure that any NAC methods implemented are open standards.
On a similar note, i’m becoming increasingly tempted to not allow users running known security risks such as Firefox pre 1.5.0.4, and unpatched IE versions to access our online services. The only thing i’ve not worked out yet is how i’d handle older browsers with backported patches as used in various linux distributions.
Argh! Jordan's now 4 days past her due date, and still no baby. She was 2 cm dialated on saturday, but not had a single contraction since. Rugh.
On a completley seperate note, i'm lookign for someone to take some load off my sholders due to my scarily hectic work + home life. Job spec here
Our SIP stack's dialog FSM needed an overhaul. It was time for proper PRACK support and do something about those really broken UA's with a totally messed up idea of what the SDP offer/answer model really is.
So i sat down and got through a lot of paper re-designing the INVITE FSM, and in doing so massivly tidied up the design of it.
Having a design both in my head and on paper, i started to proof of concept it.
Suddently things got even more difficult. A complicated FSM with sub states, events with different arguments, storage within for the states, and intra-state communication is damn difficult to implement in a non code-repetitive way (i.e, with a switch(x)/case) and clean implementation.
I spent a while looking at boost::statechart i had the basic functionallity. however … our SIP dialog library had gone up in size almost 400k!
Not only that, but the code was damn messy, and error prone with maintaning.
So i decided to try and solve the problem myself. And i think i have – at least for simple FSM’s
Here it is.
It’s only a first draft/proof of concept, but looks promising. Feel free to use/modify/criticise – let me know what you think.
It is not thread safe, it is not re-entrant, and will never be either of those things at least without wrapping within boost:threads or such.
However, it does not use a virtual method, so is impressivly fast. A random test of processing 1,000,000 events with 15 states jumping between each state took just over 100ms on a xeon 3.2ghz. Yum.
Todays rant is going to be about the ITU. A “standards” organisation that have been annoying me for far to long.
For the last year i’ve been working flat out on a fairly large C++ project based around SIP. One of the elements involved is a MEGACO/H.248.1 stack for use by our media gateway and controller.
The ITU published the protocol specification under a document named H.248.1, and the IETF has published it as RFC3525, naming the protocol MEGACO. The ITU provide a pretty PDF version, and the IETF produce a dull but error-free RFC for it based upon the H.248.1 document.
But that’s where the similarities end.
Because it’s mainly an ITU protocol, the ITU have developed specifications for additional “packages” that extend the protocol for features such as playing audio prompts into a context from a file located on a HTTP server, dynamic tone generation, and adaptive jitter buffers among other things. Without some of the additional packages defined in other h.248 series specifications, MEGACO is pretty useless.
Now on to what’s been annoying me.
From the ITU’s website: “ITU-T’s mission is to ensure an efficient and on-time production of high quality standards (Recommendations) covering all fields of telecommunications.”
Yet, to downlaod their apparent “standard” “specification”, i need to pay for it. about £1000 in total for the H.248 series documentation.
Maybe it’s just because i’m from the open source world, but it seems like absolute insanity that i need to pay around £1000 to be able to read a specification for what is supposed to be an industry “standard”.
Maybe it’s because i’m of the view “standards” should be available for all to read.
Either way, It makes me wonder what would happen if the IETF suddenly decided that all RFC’s are no longer freely available, and you need to pay 60 swiss francs each time you want to read one. Ohh, and lets charge to accessing drafts, too!
I’ve yet to find out what their excuse for charging for accessing standards documents is, and i’d love to hear anyone who knows why they think there is nothing wrong with what they are doing.
Ohh, and H.248.1 is a really badly written protocol specification, too.
And it’s a stupidly designed protocol.
And no one seems to have implemented it properly.
And the specification itself is buggy.
And there is only one reference stack around – written in erlang.
I hate MEGACO.
Well there we go - i've finally moved into the modern day and decided that as of today, i'm going to blog.
No idea what about yet, but i'll think of something.
Perhaps my daily rant about how great (or shit, depending on my mood) C++ is, or about how my house wobbles every time a car goes past the road at the front.
Or maybe about the water that is splashing from the thames into my garden.
Whatever it is, you can be assured it will be riveting stuff.
I can just see the smiles on your face already.
I have images of dave from Invasion in my mind when i think about blogging for some reason.