Saturday, 17 March 2012

One SIP at a time

Well, slow progress. I am trying to get as much of the actual RFC as practical done "properly", and that is slow going. However, we are getting there. We have the message retransmissions and, handling ICMP errors, and DNS lookups, and all that now.

I now have it identifying INVITEs, and at least saying "100 Trying" when they are valid. It is a nightmare, as you have to work out if it is a new INVITE, or a resend of a previous one, or a re-INVITE in an established call. If a new INVITE you have to work out if one from an outbound registered carrier, and so not challenged, or if from a user, so challenged for credentials. This is all before I have the concept of third party authentication via some means like RADIUS which will add to the fun a lot!

Anyway, I am at the stage of creating "call leg" records, so that I can handle the whole process of the invites and call establishment. I suspect I need to do the media relaying before I can go any further as (understandably) the phones I have will not progress a call if there is no media negotiated :-)

So that is next step really. I may try and make a call complete in to the brick hitting a simple internal tone generator. Then I can look at doing the same with an outgoing call. These should nicely allow CANCEL and BYE processing to be completed. I am planning to include simple tone generation code, so ring tones, etc, all work sensible.

Then finally gluing calls together - that will be fun.

I plan to allow simply hunt group logic as well even in the 2500/2700.

I am just not confident I'll get it done my tomorrow night now. So maybe it will drag on to next week. Shame, but I won't say what slowed me down so much this week as I promised to drop it :-)

BTW, we are also trying to sort out a simple mailman type mailing list for firebrick and A&A testers. Watch this space.


  1. More work from home, and have lots of data structures defined for the SDP/RTP and tone generation. All very convincing...

  2. Very exciting. Glad to hear you are adding more functionality to the 2500/2700. Would be great to be able to use one of these as a mini ITSP server :-)

  3. There's a reason that SIP stacks are licensed by even large companies. There are so many interop issues that it takes a mature SIP stack to bring something to market commercially that doesn't have a slew of support issues.

    1. I am pretty confident we can handle any support issues and have the code mature quite quickly though. This code is much better, standards wise, that the linux code we are using commercially now and that had relatively few interop issues (apart from where NAT is involved). I am hopeful we can make this better able to cope with NAT but that will be a challenge to face later when doing the 6000 based SIP switch.

      The back to back user agent logic for small office use as a SIP concentrator should be pretty easy.