Thursday, 15 March 2012

Moving on - lets get SIP working...

Well, I have to put the ADR stuff behind me now - the main changes (apart from changing to the other ADR provider) are better record keeping so that any future case is a lot less work making a case file. We also need to have more paperwork and bureaucracy - whenever a customer says something such as suggesting they want to cease a line we will need to get a very clear statement from them one way or another so that some abritrator skimming the case file later does not miss facts!

But really, moving on, honest...

The SIP coding this week has really suffered. I am just in the process of making outbound registration requests. The protocol handling is slightly more work that the incoming registrations which just have to make responses. Outgoing requests need to have resolution of names, retries, and matching the responses that come in to the request. That means slightly more work on the protocol handling code to do that. I am reasonably confident I can get that working today.

This will mean we have the core SIP messaging (albeit only UDP at this stage) for both inbound and outbound message exchanges (transactions). It means moving to handle an INVITE to actually process a call will not be that hard from there! The biggest protocol element involved will be the SDP (message payload) and making the RTP actually pass the audio. To be honest, that is not as daunting as I expected.

Once we have that all working, we will find that we have missed obvious things, I am sure. We need to test actual scenarios, real phones, etc. I am sure we will need many tweaks and changes to the configuration structure as a result. I'll issue an alpha for customers to play with once we get there.

At this stage I am not sure if SIP will be in "fully loaded" bricks only, or a standard feature. It should avoid so many headaches with NAT and SIP that it may be a standard feature.

Once that is done, one of the really complicated issues we had with the previous SIP code I wrote was handling call transfers. I think it will be a tad easier with this code, but it is a complicated area with many different ways to transfer calls. That may not be something we get sorted this week! The main difference is that the previous (linux) call server was trying to act as a proxy. The FireBrick is a user agent and server providing back to back call handling. This avoids a hell of a lot of headaches, especially with things like call transfer.

Moving on from the simple SIP concentrator logic of the 2500 and 2700 needs quite a lot of work though. For a start we need RADIUS (or some other protocol) for authentication, call routing decisions, and especially call accounting. We will need call recording and various control systems tracking and re-routing live calls. But having got working protocol elements and RTP in the low level box, this should not be a massive job to move forward to make a big SIP router on the 6000 series. That may be some weeks later once the 2500/2700 code is matured and tested more. Maybe I'll even fit in OSPF work in the mean time :-)

So, my challenge for then end of the week is to (a) forget ADR (b) get to the stage of an actual call being made through an FB2700.

Not yet, but that is not out of the question in the long run. We plan to operate audio only on alaw 64K and only negotiate that. That way we can re-route the audio and call transfer and generate in-band tones easily.

It is specifically not an ALG - we have a policy of not adding any ALGs even though there is basic NAT and port/IP mapping. Adding ALGs is a big can of worms and never ending task.

What we are doing is making a back to back SIP endpoint which routes the calls. The routing logic on the 2500/2700 will be quite simple. It is designed to allow calls to/from a network based SIP carrier. I.e. the carrier does things like voicemail, and call logging, and so on, not the FireBrick.

The main reason for this is that it should avoid all of the usual NAT issues (with and without ALGs) as the Firebrick will use its real public external IP for communications to the carrier. It can use private IPs to communication with local SIP phones.

It is also not working as a SIP proxy, which avoids some of the issues with sdp negotiation and so on. It is a media gateway/relay as well.