<anthm> filter add unique-id <uuid of a> <anthm> filter add unique-id <uuid of b>
Whee, (more) advanced event filters for mod_event_socket (not there yet)
(I hope he’s going to use apr_uuid_parse() and memcmp() for this, instead of strcmp()’ing the UUIDs.)
Found a possible solution to the SIP + RTP on the same interface issue with packet socket: Socket filters.
With the help of something like this:
{ 0x28, 0, 0, 0x0000000c },
{ 0x15, 0, 9, 0x00000800 },
{ 0x30, 0, 0, 0x00000017 },
{ 0x15, 0, 7, 0x00000011 },
{ 0x28, 0, 0, 0x00000014 },
{ 0x45, 5, 0, 0x00001fff },
{ 0xb1, 0, 0, 0x0000000e },
{ 0x48, 0, 0, 0x00000010 },
{ 0x35, 0, 2, start_port }, /* replaced: 0x00007fff */
{ 0x25, 1, 0, end_port }, /* replaced: 0x0000ffff */
{ 0x6, 0, 0, 0x00000044 },
{ 0x6, 0, 0, 0x00000000 },
only UDP packets on destination ports 32767 to 65535 will be delivered to the packet socket.
(The cryptic C code is the output of “tcpdump -dd udp dst portrange 32767-65535″)
There’s a possible problem with this solution though: no zero-copy support for socket filters on linux (still need to confirm that (FreeBSD has zero-copy bpf support in -current)).
BRI support in OpenZAP trunk currently “works” (the basic stuff, it’s far from complete) with “Bristuffed” Zaptel. The ISDN library needs a lot of attention atm and most of the work happens behind the scenes in the api branch of my personal OpenZAP git tree. It’s basically a complete overhaul of the Q.931 (Layer 3) ISDN code, lot’s of cleanups, a ton of message handling functions getting replaced by a couple of generic ones, stateful handling of calls, error handling, etc. Most of the changes are “under the hood”, meaning they don’t affect the application interface of the library, so we could merge the patch into trunk, after things stabilize a little and some missing features have been added back (e.g. all of the dialects, except the basic Q.931 one are broken atm).
One of the ultimate (long-term) goals however, is to get a new layer 4 API (the part that is used in ozmod_isdn.c), that gets rid of the message-centric way of handling calls. The new API will be call-centric (well, there will still be a way to send custom messages to the stack), since message mangling is the job of layer 3, not the upper layer’s. Changing this will help simplify and improve the code in ozmod_isdn.c, so it will be easier to add new features that are currently missing.
Short-term goals, that will be adressed in the near future (read: once i get my test setup back up and running): Further improving the reworked dialect handling, adding all the (now disabled / broken) dialects back (note to self: need to find victims to test ‘em), Q.931 timers (yah…), complete error handling and other random bits i forgot.
To be continued…
Another interesting idea:
Using PACKET_MMAP for transmission of packets. This one would need some kind of userland deadline I/O scheduler and a userspace network stack (same as netchannels).
There’s a major difference from netchannels though: Netchannels manages point-to-point connections, this approach just pipes all data from the associated interface to userspace (or vice-versa), so an actual implementation of this for RTP send/recv in FreeSWITCH would be limited to one or two threads (shared or one for each direction) per Ethernet interface.
The I/O schedulers job would be to collect and queue the RTP frames from the channel threads and send them to the kernel if a) the TX_RING buffer is full or b) the deadline has been reached.
(Signaling (SIP) and RTP on the same network interface (= the common case) could be a problem…)
Just another random item that was on my todo list for some time now.
LWN.net has a nice article about the concept: Van Jacobson’s network channels
The whole thing has been implemented by Evgeniy Polyakov.
(Direct links to his projects: Netchannels, Unetstack).
The code compiles (with a bunch of hacks) but needs more work (locks up during testing, after a couple hundred calls), and there are license issues too (unetstack is GPL)…