SIP progress

Well, I am finally coding again, and have been bogged down with BACS stuff and HMRC stuff, and even some FireBrick stuff, and I really have to make some progress on the FireBrick SIP code now.

We have been using in the office since last year some time, and it works really well. The features so far make up a good, scalable, PABX system. We can expand on those features over time, but we already have hunt groups and time profiles and fallback groups and busy lamp fields and call steal and transfer and so on. A good set of PABX features.

One small point has been integration testing, and I am pleased to say that it is going well. We have customers starting to use the FireBrick as a PABX now, and getting useful feedback. Even the entry level FB2500 has the PABX features.

We know it works well with a range of handsets including Snom (on which busy lamp field works too), grandstream, gigaset, and I think a few others. Obviously if anyone has anything they can test, let us know. We have tested on a few IPv6 handsets now too and that works well and maps the media to/from IPv4 as needed.

The server side has not had a lot of testing until now as people have been using with A&A VoIP, and we know that works. Turns out we were missing some of the Record-Route logic for use with proxies. I was hoping to avoid a lot of that by being an endpoint only and not a proxy. We had included the main areas of this but not all. One of SIPs most annoying features is the route set logic which has to be stored on the dialogue. Well, we have added that now, with some careful reading of the RFC and testing.

The result is we have it working with sipgate and gradwell nicely. What is fun is that we even have it working on BT with credentials that normally go on a home hub. Sadly this is a slightly bodged config with a faked DNS reply added as BT talk to a proxy but use a different hostname in the actual messages, one that has no A or SRV records. They could have done this right so simply, and just need a DNS entry. I may try and make the FireBrick config cater for this though, as it seems that some other devices will do the same (talk to named proxy but use different name within the payload). I am sure we can do the same if that is what devices usually do.

The plan is to test more handsets and SIP services - apply any fixes if needed - and write up configuration examples on the web site. We'll also look at any changes to make things more intuitive in the config (always a challenge for SIP).

I then need to work on the second phase of development, starting with a re-write of the RADIUS client code so that it can be used for SIP as well as L2TP, then doing RADIUS based user registration and call routing and CDRs... We then have various fun features, like call recording, voicemail, and so on, to bolt on. Maybe even conferencing if I feel adventurous.

Watch this space, as they say.