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.
Subscribe to:
Post Comments (Atom)
Playing cards
One of the fun diversions I have had in my time was making playing cards. I did a whole chapter in my biography on this. My playing card des...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us...
-
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo...
-
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
More work from home, and have lots of data structures defined for the SDP/RTP and tone generation. All very convincing...
ReplyDeleteVery 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 :-)
ReplyDeleteThere'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.
ReplyDeleteI 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.
DeleteThe back to back user agent logic for small office use as a SIP concentrator should be pretty easy.