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.
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
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...
And to get more sleep!
ReplyDeleteAre you planning to handle video?
ReplyDeleteLots of the top end sip phones now have video capabilities.
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.
DeleteIs your goal to make the FB devices completely "SIP aware" and translate packets according to logic you will be programming into them?
ReplyDeleteI just fear you will fall into the same trap as everyone else and end up with a SIP ALG that actually breaks what it was intended to fix!
But then, I forget, A&A are an ITSP too, so you must already have some experience of these woes.
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.
DeleteWhat 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.
Well, outgoing SIP registrations against AASIP are working!
ReplyDeleteMy plan is to have a call via the brick by the end of the week - but getting bogged down with other real work (no, not ADR), so I may have to stretch the "end of the week" to Sunday night...
ReplyDeleteAnyway, once I have a call routing by some means, I'll release an alpha for customers to try.
Does this mean that you can have a non ipv6 compliant phone and make calls over IPV6 to compliant providers?
ReplyDelete(phone>---(internet IPV4 and 6)-<ipv6 sip provider)
Yes, that is one of the key reasons for doing this the way we are!
Delete