CELT support moving into Opal trunk
The last few issues with 32KHz mode and RTP timing have been resolved and the patches are being merged into Opal’s svn trunk.
Hi-def 48KHz VoIP with Ekiga
Took a little longer than planned, due to various little problems that added up, but here it is:
http://oss.axsentis.de/people/stkn/freeswitch/opal-3.4.2-32khz-48khz-celt-codec.patch
A patch that adds 32KHz, 48 KHz sample rate support and a CELT codec plugin to Opal, enabling Ekiga to use the new Ultra-Wideband ulta-low-delay codec developed by Jmspeex of xiph.org.
There are still some glitches in the output (not sure if it’s my code causing them or the codec itself, need to investigate further), but it still sounds totally awesome playing one of my favourite songs.
The patch is for the svn version of opal but can be applied to the latest release tarball too.Note: you have to autoreconf and reconfigure + rebuild after applying the patch to opal.
For those interested in the original annoucement that caused this work:
Another FreeSWITCH First: 48k VoIP
UPDATE: Changed patch URL, and here are a couple of other fixes for opal-3.4.2 and opal-3.5.1 you’ll find useful:
http://oss.axsentis.de/people/stkn/freeswitch/opal-3.4.2-ac_define-fixes.patch
http://oss.axsentis.de/people/stkn/freeswitch/opal-3.4.2-fix-h460-define.patch
http://oss.axsentis.de/people/stkn/freeswitch/opal-3.5.1-ac_define-fixes.patch
mod_ssh: yet another status update
test02 freeswitch-trunk # ssh -p2222 test@localhost test@localhost's password: Welcome to FreeSWITCH on test02 fs[1423]/test@test02#
That’s the new (not finished) terminal emulation, together with a customized (well, current ssh.conf.xml default) prompt.
mod_ssh status
Supported features:
- Useraccounts in ssh.conf.xml, passwords in cleartext, SHA1 or MD5 hashed
- Connection timeout, listen ip and port configuration via ssh.conf.xml (default: 127.0.0.1 port 2222)
- Password-based ssh authentication only, the server part of libssh doesn’t support public-key auth at the moment
- Connecting via ssh client and entering api commands works, the commands will be executed and the result sent to the client. Mod_ssh is still lacking a (simple) terminal emulator so line editing etc. won’t work.
- Logout via “…” or “logout” (use the “shutdown” api command to shut the switch down)
- “ssh” api commands to list/kick active sessions and list/lock/unlock accounts
Even more progress…
Output has been cleaned up:
freeswitch@test02> ssh account API CALL [ssh(account)] output: ===================== Accounts ===================== Username | Auth-types ---------------------------------------------------- foobar | password test | password =================================[ 2 account(s) ]== freeswitch@test02> ssh session API CALL [ssh(session)] output: ===================== Sessions ===================== Username | Online since | Misc. ---------------------------------------------------- - No active sessions - ==================================================== freeswitch@test02> 2008-11-28 17:43:49 [NOTICE] mod_ssh.c:512 ssh_handle_message() User "test" logged in 2008-11-28 17:43:49 [NOTICE] mod_ssh.c:583 ssh_handle_message() User "test" opened a shell session freeswitch@test02> ssh session API CALL [ssh(session)] output: ===================== Sessions ===================== Username | Online since | Misc. ---------------------------------------------------- test | 2008-11-28 17:43:49 | =================================[ 1 session(s) ]==
And another command works now:
freeswitch@test02> ssh session kick test API CALL [ssh(session kick test)] output: +OK: 1 session(s) kicked freeswitch@test02> ssh session API CALL [ssh(session)] output: ===================== Sessions ===================== Username | Online since | Misc. ---------------------------------------------------- - No active sessions - ==================================================== freeswitch@test02>
Some “minor” progress…
stkn@test02 ~ $ ssh -p2222 test@localhost
test@localhost’s password:
[15315] 2008-11-28 12:20:54 API CALL [version()] output:
FreeSwitch Version 1.0.trunk (10523M)
[15315] 2008-11-28 12:20:56 API CALL [status()] output:
Content-Type: text/html
UP 0 years, 0 days, 0 hours, 0 minutes, 57 seconds, 5 milliseconds, 204 microseconds
0 session(s) since startup
0 session(s) 0/30
logoutReceived disconnect from 127.0.0.1: 11: Bye Bye
stkn@test02 ~ $
Weird libssh deadlock / heap corruption 0 : 1 stkn
Long story short: both, apr and libssh have a function called “sha1_init” and of course, the runtime linker deceided to use the one contained in libfreeswitch.so instead of the (right) one from mod_ssh.so (libssh) resulting in a corrupted heap after calling it (even destroying some data used by the memory allocator in glibc, hence the deadlock in free).
Thing that saved the day: GCC Visibility support (hooray for marking all internal functions hidden)
And GDB command scripts are a wonderful thing (even if there are some bugs):
set pagination off
break buffer.c:buffer_free commands print *buffer continue end
With that obstacle out of the way it was fairly easy to get mod_ssh to do something a bit more useful…
The current code is in the git repository, it’s still not useable but moving in the right direction. The configure script works with GCC and SUN’s compiler, visibility support is a must though (>= GCC-4.0; SunStudio 12 / Express from July 2008 or newer).
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…
Hackathon day 2
No actual coding today, but i’ve put some other projects on our server (=> axsentis gitweb).
The (still non-working) project from yesterday is there too, if you’d like to take a look at the issue yourself:
git clone http://oss.axsentis.de/git/mod_ssh.git
Hackathon day 1
I chose to work on option number #2 (the new secret fs module), but haven’t gotten very far, due to some weird deadlock in free() / memory corruption problems in the library that i’m using for this.
The library ships with a couple of examples, those work perfectly fine, even adding some basic threading to one of the examples (and limiting the amount of stack space the thread can use) doesn’t make it fail, however, using the lib in a FS module makes it fail in interesting ways.
One interesting bit is, running FS in valgrind makes it work sometimes, so it’s definitely some sort of race-condition, which is funny, because i’m not using multiple threads to run that code as everything is running in the runtime thread of the FS module.
The bad thing is: i’m out of ideas on things to try and i lack experience in hunting down and fixing this type of bug.
All in all not a very productive (and satisfying) day in the coding department…