Lazyness…
I’ve been slacking a bit over the last week, working only on some smaller bits and pieces (e.g. the axdhcp2 lua backend).
My BRI test setup is finally back up (this time connected to the desktop box where i’m usually sitting at) and the last round of larger changes don’t seem to have caused a lot of problems.
So what’s next in OpenZAP land?:
There are some other fairly low-hanging fruit right now:
- Move unexpected (invalid) message handling from Q931Rx23() / Q931Rx43() into Q931ProcUnexpectedMessage(), so each dialect can have its own version (if it needs to)
- Change all Q931Proc* callbacks to work on call handles (getting rid of a CRV->call lookup in each callback, saving a few more lines of code and making message handling a little faster)
- Handle Q931L4HeaderSpace and Q931L2HeaderSpace in one place instead of each and every function that uses the message buffer(s) (and perhaps makes those two values per-trunk)
Timers… turns out to need a bit more work. The basic framework is there, message handling (resending, indications to upper layer / call control) is still missing though, so those callbacks don’t really do anything useful at the moment. I know a couple of people are waiting for this and i’ll probably try to get call tear-down working, as a short-term solution, to make sure calls are getting properly disconnected if something goes terribly wrong (which is still a major improvement, compared to the old code).
For the long-term solution there a couple of problems that need to be resolved.
Message resending needs some way to keep track of older messages, either by storing them in a per-call buffer, or storing the relevant IEs that are needed to regenerate the message from scratch.
Sending indications/events to upper layers is another problem (this includes events caused by timers, e.g. a call disconnect), the reason is fairly simple: code run in the event callback may change the state of the current call, which is bad if we change the state again after the callback returns, or try to do more work depending on the call’s state. The right solution (i hope) is probably to defer calling the event/indication callback till all the important work has been done, either before a response is being sent or after that (still not entirely sure on this).
Those two issues, together with the (inevitable) neccessary api changes for the new event callback system still need some experimentation to find a good solution (and will probably cause some breakage).
Let’s see what’s going to happen in the next few weeks…