[Serusers] Local ACKs for SER-SEMS

[Greger V. Teigre]

>> I've tried to find some meaning in what you sent, but I don't really know
>> the details of the ACK hack (pun not intended) Jan mentioned. To me it 
>> looks
>> like the ACK is absorbed correctly.
>
> In the logs provided, the acks are not absorbed at all (well, yes, due
> to a hack in my config file ... but otherwise not).

? Hm, I saw some debug lines on ACK absorbed...?!

>>However, the REGISTER messages confuses
>> me a bit. Also, you don't record_route CANCELs and ACKs, why?
>
> I don't know :) So far it worked fine. Do you think that
> record-routing the ACKs may solve this problem? ( See the following
> paragraph for a strange development )
>
> Also, we checked yesterday and ... surprise! :)
> We discovered this "feature" after upgrading from ser_0.9.0 to
> ser_0.9.4 ... we still have some pcs with ser_0.9.0 (ser.cfg and sems
> are the same overall), and they don't show this behavior (OK/ACK being
> resent for a while). This only happens in the newer setups with
> ser_0.9.4

Hm. Strange. I'm not enough on-top-of diffs from 0.9.0 to say anything smart 
about that :-)
You had some strange messages in there about message with multicast address 
looped back.
You alsoe have this:
Warning: sl_send_reply: I won't send a reply for ACK!!
Which normally means that an ACK hits an sl_send_reply() somewhere in your 
script.
And now that I had another look at your config, I see that you loose_route 
to ROUTE_RELAY, but then you do lookup before t_relay(). Loose routing is 
NOT looking up and ACKs with Route should not be looked up, but just 
t_relayed. That may introduce some problems.
I would guess that the Warning for ACK above is due to this:
if( ! lookup("location") ) {
sl_send_reply("404", "Not Found");
break;
}
in your ROUTE_RELAY.
g-)