Queuing calls

Well, today was a lot of tidying up small details - sorting some multi-homing issues where the FireBrick has more than one IP. E.g. if a phone registers with the FireBrick it has the odd idea that it wants calls from the same IP it spoke to, so it seems (well, SNOMs seem to). So we are now tracking IPs used for calls and registrations, and allowing outgoing registrations to pick the source IP, and so on. Seems to be working well.

It may not be a long way to NAT support (which I am not planning to finish/test just yet).

I have also done some tidying up on passing the "display-name" on internal calls, and so on, as well as passing call withheld status cleanly.

There are many more small details, but the next big challenge is call queuing. This all ties in with hunt groups, the order in which you ring phones, and how calls can queue for a group.

I'm going to sleep on it and come up with a design - one concern is making it scale as I would love this to be a feature in the big FB6000 based SIP switch - so needs to be efficient. Queuing is complicated as you have to handle things like starting to ring a phone after it hangs up if it is now the only phone in the set available, and wrap up times, and people on do not disturb or rejecting the call manually, and so on. You also want the caller not to have to be ringing forever as they will clear the call, so we need some answer and tones after a time. We almost certainly want "overflow" members of the group too - only rung if the call reaches a certain time.

It should be fun. Once we have call queuing we may be able to start using it in anger in the office for support calls. We have a few brave customers tinkering now as well...