I am about to make some email to fax gateway --- some python program will make Asterisk call files and put them into some queue (files or db based).

Then another program should take "call tasks" from queue and "feed" them to asterisk (honoring some configured limit, because of res_fax_digium will drop over-limited tasks).

Next, let's suppose, everything is great and asterisk successfully sent some fax document. What could be a way to get the status of this operation?

If logfiles parsing is the best, I would, probably, assign some special accountcode (I can play with this field, probably) to drop CDRs into separate files, too.

Please, which other ways I should evaluate?

Let's say I have an Asterisk system with a bunch of connections: there are phones (who register itself with *) and providers (who wish to establish SIP trunks to put a lot of calls over, with different Caller IDs).

Here is my vision about how calls should be placed over an authenticated SIP trunk: remote end of SIP trunk should send INVITE's with From field set to it's identity (username for authentication) and Contact field set to what should be Caller ID for this call.

Is that true?

Why I believe this should be true: now, I can not specify username/secret and host=<IP> -- for remote end to register I need to say host=dynamic. So, I can setup "pseudo-trunk" as a bunch of extensions, or I need to setup trunk with host and no authentication. No authentication is bad.

So, is the above true? And will asterisk match peers by looking at From field and use Caller ID from Contact field?

If that is not true --- how an authenticated SIP trunk should work?

Thanks!

I have a nice shaper, with hashed filtering, built at a linux bridge. In short, br0 connects external and internal physical interfaces, VLAN tagged packets are bridged "transparently" (I mean, no VLAN interfaces are there).

Now, different kernels do it differently. I can be wrong with exact kernel verions ranges, please forgive me. Thanks.

2.6.26

So, in debian, 2.6.26 and up (up to 2.6.32, I believe) --- this works:

tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \
    u32 ht 1:64 match ip dst 192.168.1.100 flowid 1:200

Here, "kernel" matches two bytes in "protocol" field with 0x8100, but counts the beginning of ip packet as a "zero position" (sorry for my English, if I'm a bit unclear).

2.6.32

Again, in debian (I've not built vanilla kernel), 2.6.32-5 --- this works:

tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \
    u32 ht 1:64 match ip dst 192.168.1.100 at 20 flowid 1:200

Here, "kernel" matches the same for protocol, but counts offset from the beginning of this protocol's header --- I have to add 4 bytes to offset (20, not 16 for dst address). It's ok, seems more logical, as for me.

3.2.11, the latest stable now

This works --- as if there is no 802.1q tag at all:

tc filter add dev internal protocol ip parent 1:0 prio 100 \
    u32 ht 1:64 match ip dst 192.168.1.100 flowid 1:200

The problem is that I couldn't find a way to match 802.1q tag so far.

Matching 802.1q tag at past

I could do this before as follows:

tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \
    u32 match u16 0x0ed8 0x0fff at -4 flowid 1:300

Now I'm unable to match 802.1q tag with at 0, at -2, at -4, at -6 or like that. The main issue that I have zero hits count --- this filter is not being checked at all, "wrong protocol", in other words.

Please, anyone, help me :-)

Thanks!

I've been using debian with 2.6.26 kernel; now I've started to test 2.6.32 for my needs. And I've noticed that u32 filter behaves differently for, namely, "protocol 802.1q".

To discover the tendency, I've run my tests on ubuntu server with 3.0.0-12 kernel. And I've found that I can not match packets by VLAN id at all:

# this worked in 2.6.26:
/sbin/tc filter add dev world0 parent 1:0 prio 100 protocol 802.1q \
        u32 match u16 0x0ed8 0x0fff at -4 \
        flowid 1:fe51

So, that's the preface.

I would like to ask where is the best place to discuss these questions? -- it seems that LARTC list is rather inactive. I am not a programmer, so I hardly believe that I should dive into LKML...

Thank you!

UPDATE

I've built 3.2.11 (latest stable) and in all my tests it appeared impossible to catch any protocol but ip (or all, which seems to be quite the same as ip now). But when catching ip or any it appeared impossible to match vlan tag or the like, with negative at value, too.