Children of the init

Don't feed the geek!
  • Home
  • Imprint / Impressum

Lazyness…

Published by stkn on November 18, 2008 12:58 am under OpenZAP

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…

No Comment

Comments are closed.

Posting your comment.

  • Categories

    • Development (39)
      • FreeSWITCH (23)
      • FreeTDM (2)
      • OpenZAP (9)
    • Hardware (1)
    • Misc (2)
  • Pages

    • About
    • Imprint / Impressum
  • Archives

    • January 2011
    • November 2010
    • June 2010
    • February 2010
    • January 2010
    • December 2009
    • October 2009
    • August 2009
    • July 2009
    • June 2009
    • April 2009
    • February 2009
    • January 2009
    • December 2008
    • November 2008
    • October 2008
    • March 2008
    • January 2008
    • November 2007
  • Meta

    • Log in
    • Entries feed
    • Comments feed
    • WordPress.org

Copyright © 2021 Children of the init
WordPress Theme based on Light Theme