But recently, these changes have been because I've been working on a very new and exciting project that has consumed almost all of my spare time, and will continue to do so for the forseeable future. I think it is time that I finally announced this new project.

The new project is called "Get A Life".

I guess I could write on for several pages about the terrible woes that have befallen me over the past few years (and I did start off doing exactly that), but the bottom line is that what has happened is nobody's business but mine, and there are lots of other people who are far worse off than me. So, I'll save the sob story and cut straight to the chase.

My experiences of the past year or so have had a profound effect on me. I'd like to think I am different person, but that's for other people to decide. Regardless, I'm working to redress nearly 20 years of being an asshole to my family.

I'm spending a lot more time with my wife and kids than I have in the past. If I had a brain, I would have done this a lot earlier but because I'm stupid I've let 20 years go by and damn near let my kids grow up and move out before it occurred to me to do anything about it. Hopefully it is not too late.

I'm also doing a lot of other stuff that is not sitting in front of a computer. For example, my eldest son and I have both become volunteer firefighters and now we are on call 24x7 to go and put out fires and attend car wrecks. I wish I'd done it years ago and I recommend it to anyone who wants to put something back into the community as well as meet new people and learn new skills.

As far as OpenH323 and OPAL is concerned, I will continue to work on both of these projects, both because I enjoy it and because that is how I intend to continue earning my living. But I don't intend to spend much of my discretionary time answering mailing list questions, unless I feel like it.

Anyway, just wanted to write something.

I feel better now :)

T.30 is transmitted over a switched circuit voice line by converting the bitstream into modulated tones. This is the familar warbling that you hear when you accidentally pick up on a fax call. But these tones are merely the modulation technique used to transmit the T.30 data over a fixed bandwith communications channel. The actual payload is the underlying T.30 fax commands transmitted at baud rates between 300 and 19200 baud - the tones themselves are not really important. In this regard, a fax machine is exactly the same as a data modem, except that T.30 defines the higher protocol layers rather than just providing a raw bit stream like a data modem.

T.30 tone modulation is designed to work over a circuit switched voice connection, which these days is usually a 64 kbps voice channel sampled 8000 times a second. This approximates the previous generation analogue phone technology that used a copper wire pair with an approximate bandwidth of 3100 hz. These circuit switched connections have low (and constant) latency, have no jitter, but may experience loss or dropouts. The T.30 modulation is designed for this environment - it exploits the full bandwidth of the circuit switched connection (well, as far as the modulation technology of the era allowed), and the T.30 protocol implements error detection, and error correction, to solve the drop-out and signal noise problems

Given all of this, it might seem that T.30 could be used over a G.711 VoIP connection, because these are intended to emulate ye olde analogue copper wire circuit connection just like a BRI. After all, fax is just audio tones and G.711 is (by definition) the same audio modulation used on PSTN for BRI or PRI lines. But as many people will tell you, fax over G.711 only works reliably over a LAN network, and becomes very unreliable if used over the public Internet.

So why is this?

Nobody uses G.711 for long haul VoIP because it is very susceptible to jitter due to the heavy load on the underlying network. Voice calls tend to break up unless every hop in the underlying network can easily handle the raw 64 kbps data rate, which is actually closer to 80 kbps if a frame size of 30 msec is used.

The circuit switched networks for which T.30 was designed don't have jitter, and the modulation techniques and protocols specified by T.30 contain no provision for dealing with it. Unsuprisingly then, T.30 simply can't deal with the variable jitter of a VoIP connection, although it tries (and fails) valiantly.

The problem is made worse if a codec other than G.711 is used, because most compressed codecs are based on a psycho-acoustical analysis of human speech and remove portions of the signal that, although not important to human voice communication, are vital for modulated data signals. This is the same reason why in-band DTMF tones don't work over compressed codecs, by the way.

The obvious solutions to this problem is to ensure the underlying network can support G.711 calls that are of sufficient quality to allow fax calls to work. Presumably this is what the Vonage network does, as they used to use G.711 (and may still) and they also advertised full fax functionality.

At this point, it's worth reviewing what happens when sending a fax over a VoIP connection using T.30 audio tone modulation.

The source image is converted into a stream of bits which is encoded into a stream of T.30 commands. This bit stream is then converted into an analog waveform that corresponds to an audio frequency tone with specific modulation characteristics. An approximation of this waveform is then created by sampling it 8000 times per second using a non-linear encoding (G.711), and the samples are grouped into 30ms chunks of audio data, and then transmitted over an IP network. The receiver re-assembles the received samples to recreate the analogue waveform and then demodulates it to retreive the original T.30 bit stream. The image data is then extracted from this bit stream.

In other words, the analog image is converted into T.30 digital data which is converted into an analogue waveform, which is then digitised, sent as digital data over an IP network, converted *back* into an analogue wavform, converted yet back yet again into a T.30 digital bit stream to display an approximation of the original analog image. Analog to digital to analog to digital to analog to digital to analog again. How crazy is that? I think it is amazing that it works at all!!

Fortunately, other engineers have also looked at this Rube Goldberg chain of technology and quickly understood that there is an obvious solution. Given that the T.30 command stream is already digital data, it can be sent it over an IP network as is. No need to convert it into analogue tones - just send the raw T.30 data inside IP packets. The standard that defines how this is done is the well-known, but often misunderstood, ITU T.38 standard.

In one stroke, T.38 solves most of the problems with sending fax over an IP network. A T.38 fax call uses 20% of the bandwidth than the modulated audio approach because it is now a stream of bits at an average speed of 14400 bps rather than a stream of audio samples at 64000 bps.

Reliability is now greatly increased because the portion of the decode chain that was susceptible to jitter (the analogue demodulator) is no longer needed. To increase it even further, T.38 allows for the inclusion of redundant data to prevent errors caused by the occasional loss of packets when using a transport with non-guaranteed delivery, like UDP.

As far as implementation is concerned, T.38 does not require any analog modulation or demodulation, because it is only concerned with encapsulating and de-encapsulating a raw T.30 bit stream. As such, it requires much less CPU horsepower than the audio tone approach.

T.38 should not be confused with the similar-sounding T.37 which uses a totally different approach. Whereas T.38 is intended for realtime fax transmision using an encapsulated T.30 data stream, T.37 is intended for "store and forward" applications. It requires the fax data to be converted into TIFF format and then encoded using base64 into a text message and then transmitted using SMTP.

Hopefully this article has helped dispel some of the mystery surrounding fax over IP. Efficient fax transmission over an IP network is acheived by understanding that a fax call is not about sending and receiving modulated audio tones - these are simply the legacy of the old analog phone network and it far more efficient to simply deal with underlying bit stream and send that over the IP data network instead.

Three times in the past week I have been been faced with blatantly incorrect behaviour in someone else's code. Something really obvious, like a segmentation fault, or a return value set to something stupid, or a function that reports an incorrect input value when the the offending argument is obviously within the valid range.

In each of these cases I spent the time to isolate the problem and create a simple test program that demonstrated the failure condition.

In all three cases the author, when presented with this information, uttered those four hated words:

"It works for me"

If this happens again, I may just have to do serious damage to someone or something.

Let's just imagine you are a software author, and somebody has come to you with a problem that they think is in your code. And let's say that the user is not one of the clueless "why is my cursor stuck" kind - they are a fellow software developer who is highly motivated, who wants the software to work, and has done all of the kinds of things you would do if you were looking for this kind of problem. Things like isolating the bug to a specific set of failure modes, making sure it is reproducable, looking at alternate environments to see if that affects the failure mode - the usual stuff.

Given this information, you look at the report and think "Hey, that is impossible. There is no way the code can do that, and I should know because I wrote it". You might even try and reproduce the problem yourself and of course, it "works for you".

This means you have to make a choice on how to proceed. Do you:

a) Assume the person has got it wrong and there is no problem.

b) Assume that there is a problem but you can't see it for some reason.

Of these two choices, a) seems like most attractive because it is the one that involves the least work for you. But really, how realistic is this? For this to be the correct course of action, the poor sod reporting the bug would have to be so deluded that they have managed to concoct a whole story with no basis in reality simply for your benefit. Are you really so self-centred as to believe that people have nothing better to do than create works of fiction in order to bother you? Isn't there even the smallest chance that perhaps, just perhaps, there is a bug in your code that under some circumstances can exhibit the behaviour being seen? Or are you that perfect that this is simply not possible...

So really, the only sensible choice is b) - they actually have found a problem which for some reason does not occur on your system. So, you are to have to try and find it, or at least, provide them with some more information so they can try and isolate the problem further. Differential diagnosis can be very helpful in this kinds of situations.

The reverse often happens as well: you are using someone else's code and you can't even get it to work. Supposedly the code works, but damn it, you can't even get off first base. In this situation, you once again have two choices:

a) Decide that the code is fundamentally flawed if you can't get it to work, so it must be truly broken. Report this as a bug and do something else until it is fixed.

b) Realise that other people have used the code, and so you have failed to understand something that perhaps is not obvious.

You'd be suprised how many people chose a)...

Here is a real-world example: I was asked recently to evaluate a video codec from a vendor who had created a highly optimised codec for a particular hardware platform. I wrote a benchmark program, and integrated the codec as per the documentation provided by the vendor. I could push frames into the encoder, which created a nice bitstream that was supposedly compliant with the codec specification. The bitstream had the right bitrate, but I could not decode the bitstream using a reference implementation of the same codec. However, the decoder from the same vendor recreated the source images just fine.

It was tempting to just decide that the code was just crap because, although it was self-consistent, it was demonstrably non-compliant to the specification. But I also knew that the vendor has delivered this code to other companies, and that it had been used before. So even though it was not compliant, it must be possible to make it work. I just had to find out how.

It took me two days, but I eventually discovered that if I reversed each byte in the bitstream end for end, and then reversed three bits in the first byte that specified the codec mode, then the bitstream magically became compliant and worked just fine. This was not documented anywhere, and the vendor was unable (or unwilling) to explain why this was needed. By assuming that the vendor did actually have somewhat of a clue, I was able to find a way to make it work. Of course it would have been nice if the code had done the right thing, or even if the documentation had been correct, but at least I did not embarrass myself by claiming the codec was garbage and then having the vendor prove me wrong.

So please, the next time a user report a bug that seems impossible, then remember what Sherlock Holmes said:

"How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?"

We have a shared media server with all of our music on it, which we seriously need because my kids have extremely eclectic tastes. As an example: I picked up a CD burnt by one of my kids a few weeks ago which contained tracks by Ramstein, some Bach, a few tracks from "The Secret Garden", and some songs by "Flander and Swan".

As far as TV is concerned, we don't have satellite or cable (I refuse to pay $80 per month for a stack of sports channels I will never use in order to get the few channels I do want). Our family policy is that nobody has TVs in their bedrooms (my wife and I included) and the one TV with an antenna is in the family room where anybody can use it. We watch the few free-to-air programs we like and then get what else we want via BitTorrent. Between us, we watch Stargate Atlantis, Stargate SG-1, Alias, the various elements of the CSI franchise, ER and The West Wing. We've also grabbed TV series that we all like that can't be had on free to air, such as "Scrapheap Challenge" (which we call "Skrothog" because that is the what it is called in Swedish and most of the BitTorrent files for Scrapheap Challenge have Swedish subtitles), Daria and Reboot.

It's very, very easy to get used to being surrounded by this warm glow of technology. So much so, that I was taken by suprise the other day when someone was astonished that I had already seen the latest episodes of just about anything worth watching on Australian free to air TV, even before the series had been advertised (let alone shown).

In that instant, I realised (again) that I am a member of a very small subset of the community that had access to this kind of technology. Most people think they have to wait two years for US TV shows to be shown in Australia. Most people still pay full-price for long distance and international phone calls. Lots of people have iPods, but very few of them realise that devices like this have been around since 1999. Most people see telephones and computers being completely different devices that don't really have anything to do with each other.

Some of you might remember a book from the 70's by Alvin Toffler called "Future Shock". The book title came from the name Toffler gave to the disorientiation felt by people who felt overwhelmed by the relentless arrival of new technologies that they did not understand.

I keep feeling the reverse of this (can we call it "history shock"?) when I hear someone complaining about how there is nothing on TV (why not use BitTorrent and get nearly anything you want?). I get it when someone complains about the cost of international phone calls (international phone calls are cheaper for me than long distance). I get it when someone says they can't find a phone number (why not use one of any number of Internet resources)

I'm not saying that "history shock" is a bad thing. Mostly, it is a reality check for the techno-geek that lets them know that they are living in a world that is detached from the "reality" that most people experience. This can be useful as a prompt to be more understanding of those who are not paid-up members of the digerati. It can also be a pointer to a possible opportunity to make money by converting a hard-to-understand technology into something everyone can use.

It's also good to remember that even uber-geeks can get so wrapped up in their toys that they miss good stuff going on elsewhere. History shock helps me know when to take time off. That, and my kids starting to roll their eyes :)

Time go and sleep.

First of all, I arrived on Tuesday evening at 5pm local Chicago time after 24 hours of continuous travel. I was dehydrated and jetlagged, so of course I went out with the other delegates and had a few drinks. I can remember until about 9:30pm, and then I woke up in my hotel room at 3:30am. Everyone says I had a great time, but damned if I can remember anything. I remember reading somewhere that everyone should give up drinking once they turn 40 - I think that time may have come.

Brian and Tony from AsterLink have done a fantastic job in looking after everyone and doing their best to keep everyone happy. I know I'll be doing my level best to come to the next ClueCon.

The big highlight for me was spending time with the guys from Sangoma, especially Gideon and Nenand. I'd forgotten how much fun it is to work with smart, motivated people who love their work and really care about their products.

I announced the release of Derek's IAX2 code during my talk, and that got a round of applause. As it should - he has done some great work and I know that lots of people will be looking at that code very closely over the next weeks.

There is no way I will be able to remember everything that has happened so expect to keep hearing about various stuff over the next few weeks. I'll try and do some more posts as and when I remember stuff.

Oh byeah - Net connectivity is really good (most of the time) so I've been able to catch up on OpenH323 and OPAL patches. I'm going to try and get some coding done this weekend - or at least I'm going to try.

If you are looking for me, I'll be the one wearing the Open Source VoIP t-shirt :)

The fact that VoIP operates across standard networks makes it vulnerable to all manner of IP hacking - including man in the middle attacks,sniffing, session hijacking, etc.

This seems to be saying that VoIP is somehow less secure because it operates across networks that use standards. This is an interesting conclusion, because the implication is that this is somehow different from the situation with the existing telephone network that VoIP is replacing.

There are so many holes in this argument that it is hard to know where to start, but I'm going to try anyway.

Looking past this statement, the concern seems to be that VoIP networks are somehow more susceptible to interception or hacking than the technology it is replacing. Again, this argument does not hold water, because PSTN networks can be hacked in just as many ways as IP networks. As was pointed out by responders to the Slashdot article, any kid with a phone handset and a pair of alligator clips can clip onto a phone line and intercept calls, or make unlimited calls on someone else's account until they do something stupid and get caught.

So what's the problem?

As usual, I think it's all about perceptions. For some reason, VoIP networks are perceived as being less secure. And this is because the technology behind VoIP (i.e. the Internet) is understood to some extent by the the people making the claims. Those same people have little understanding of the PSTN network, because that has just become part of the invisible fabric of society. The reality is that both technologies currently have much the same problems and vulnerabilities. But there is on major difference - VoIP has much more room to actually address the issue of security.

The word "secure" tends to get used as a catch-all label for a grab bag of issues including call interception, phone fraud, and billing problems. As far as VoIP in concerned, the solution comes down to two issues: authentication, which means knowing that you are talking to the person you think you are talking to; and privacy, which relates to the ability to ensure that communication between two parties cannot be intercepted by an untrusted third party.

The two concepts of authentication and privacy are theoretically independent, but in practice there is little point in having privacy without authentication. This is because defeating a "man-in-the-middle" attack requires authentication, and there is little point in having private communications if it can be subverted by simply interposing a third party. So authentication is the first requirement, and then privacy will follow.

The PSTN network implements authentication by enforcing a relationship between a billing entity and a piece of wire or fibre. This works because the PSTN switches (which are under the control of servicde provider) are actually physical connected to a piece of network cable that goes to the customer. In the case of cell phones, authentication relies on a number embedded in the handset. Neither of these are particularly strong methods of authentication - cloning of cell phone handsets is rife and anybody who has seen a telephone technician attach a test handset to wire pairs in a street phone switch panel cannot possibly see this as being secure. Privacy is achieved by the same physical means, which in the end all comes down to security through obscurity, which we all know is a totally outmoded concept.

VoIP technology will change this. Not might change, but will change. I predict that the next few years will see cryptographically authenticated and encrypted VoIP networks become the standard. This technology will be based on exactly the same methods used by secure web sites, namely certificates and encryption. In fact, the standards already exist for authentication and privacy for both SIP and H.323 and the only reason they have not been widely implemented to date is just a matter of maturity (in the networks) and lack of demand (from consumers). That is already changing.

Apart from consumer demand, there are several factors driving the service providers towards fully authenticated and private VoIP communications. Emergency 911 support is one of them. There is also the desire to move to post-billing for VoIP which will require much more robust authentication than the simple account number and PIN that most vendors use currently.

A fully authenticated VoIP network requires an infrastructure to distribute issue, maintain and distribute certificates (or equivalent) to endpoints. I see this as being piggybacked onto some other authentication system, such as the keyring concept used by Phil Zimmerman's PGP network. It could also be done by the Passport system from Microsoft, or the similar offerings from any of the major portals such as Yahoo or AOL. Within a corporate environment, it could be done using smartcards or hardware built-in to the endpoint itself.

Regardless, there is no reason to believe that VoIP is any less secure than PSTN, and lots of reasons to see why it can be far more secure than PSTN could ever be. I'm looking forward to seeing it happen, and if possible, making it happen via OPAL :)

The major issues we wanted to resolve were:

- We wanted to support a new protocol called SIP that everyone was talking about. It seemed obvious to us that as it was under the control of the IETF, it would only be a matter of time before it would be pushed as the successor to H.323 (which was administered by the ITU)

- In OpenH323, different types of connection were difficult to join together even though they had almost the same characteristics. For example, a H.323 connection, a sound card, and a PSTN termination device all have an audio channel, and some signalling controls, but look completely different to each other in terms of API. Wouldn't it make sense to have them all look the same (or at least, very similar) so that programs that handled one device type could handle them all?

- the directory structure of OpenH323 meant that filename collisions were possible. This was due to OpenH323 having a single layered include file hierarchy.

- OpenH323 did not provide abstract classes for concepts like "connection" and "endpoint", which meant that similar concepts in new protocols would not share any common ancestor with their H.323 equivalents.

- The implementation of shareable blocks of code such the RTP stack and codecs were not very well modularised.

- The video code in OpenH323 worked well, but did not seem to be a clean design. We felt it is needed to be streamlined and made easier to use.

Our plan was that Robert would start working on the reorganisation of OpenH323 to create OPAL, while I started on an implementation of SIP using PWLib and whatever parts of OpenH323 I could use. In the mean time, we would continue to support OpenH323 and backport changes to OPAL whenever needed.

We attacked the code with gusto, with Robert creating a new directory structure and implementing the idea of "streams" that we agreed would be the abstraction that normalised devices and protocols into interchangeable entities. Robert developed the idea of a "manager" that served to control the various protocol specific endpoints and provided the mechanism whereby an application could control various features from a single class instance regardless of the number of different protocols or devices that were being used. My SIP implementation was proceeding well, with simple calls working well and we were fixing SIP compatibility issues with equipment from various vendors. The single biggest missing feature at this stage was video, and that was next on Robert's hit list.

Then we decided to do the deal with Quicknet in early 2000, and OPAL effectively went into hibernation for four years. This was an immense source of frustration to Robert, as he had done the lion's share of the work on OPAL to date, but the simple fact was that neither of us were unable to spare time to work on OPAL when we needed to work on OpenH323 to earn money.

During this time, other people continued to work on OPAL but Robert and I did added almost no new code. Several times, Robert merged the OpenH323 source tree back to into OPAL, which helped to keep the code more or less at the same level as OpenH323. During this time, people like Damien Sandras (of GnomeMeeting fame) kept the flame alive by continuing to ask about the future of OPAL. But the reality was that OPAL was, if not dead, then certainly gravely ill.

Then, in mid 2003, we left Quicknet, and the picture changed again. Robert was able to find the time to do some work on OPAL, but he was now working somewhere else and was not working with either OpenH323 or OPAL at all in his professional life. I was working with OpenH323 at least some of the time, but there did not seem to be much interest in OPAL at all.

And then in the last 12 months, the picture has changed again. Thanks again to Damien Sandras, and other people like Ted Szoczei, interest in OPAL has resurfaced. Robert has also found the time to work on video again, and I have talked to many people who are interested in seeing OPAL become a fully working stack.

So that's how we got to where we are. OPAL is being actively developed and used by many different people and I expect that it will become the principal vehicle for many new VoIP projects in the near future. If you are interested in being part of that process, or have some ideas on how to help, then join the OpenH323 mailing list and let everyone know what you think. Or email me if you want to talk about it more in private - either way please speak up and make difference.

The Sydney Morning Herald is still my source of normal-world news. The daily Column-8 column provides a light-hearted way to start the day.

APOD is worth checking every couple of days, because a few times every week they slip in something new between the repeats. Same with IMDB and Dark Horizons - as a long time movie geek these help me stay up to date with the latest gossip. And I'm still reading Penny-Arcade every few days as well to keep up with the latest news in the gamer world. This helps me to stay in tune with my two sons who are both semi-serious gamers :)

James Randi's weekly commentaries provide me with dose of rationality in an increasingly irrational world. I've yet to find anything him say anything that I seriously disagree with. Which is very different from The Alpha Patriot with whom I can find sometimes find common ground, but who ocassionaly disappears into some alternate reality. Still, it provides a useful comparison to the usual bland fare offered by most new sites

After writing this, seems my tastes have not changed all that much over the past few years. Not sure if that is good or bad...

I know it has been a long time coming, but life kept getting in the way. But now that I have MovableType re-installed, I can get back to my semi-occasional discourses on a variety of topics.

A static version of my old blog will continue to be available until I can migrate entries I think are worth keeping.