[Users] ACK and re-INVITE ordering

Hello everyone, I found many references in serdev, openser users, etc. MLs to the issue at hand, but only came up with diverging opinions and no solution whatsoever. The issue appears in case of a UA sending a re-INVITE inside of an established dialog. Depending on your configuration file, version, network conditions, there is NO guarantee that this re-INVITE will be sent to (I'm not even talking about reaching) the next hop (typically a PSTN gateway) AFTER the ACK to the first INVITE of the dialog. I perfectly understand why (openser being transaction and not dialog statefull being the only reason that really matters, given the fact that INVITE and ACK are separate transactions, often handled by separate openser processes) it is this way. However, it seems that several gateways are not handling this well at all, and just drop the transaction typically sending a "500 Server internal error". I've read reports about cisco AS5300, Asterisk, and I am myself experiencing this with an Andiocodes Mediant 2000 gateway. In my case, the issue is there 99% of the time. I know I could profile a bit my config file to ensure ACKs are processed faster than INVITEs (which propably is already the case), but this is hardly a workaround. I got tempted to even call an external "timer" via exec_msg when detecting a re-INVITE (if it is an INVITE, has a to_tag and is loose routed), but come on, I'm sure we can do better than this ! So no matter what the RFCs say or mean to say, no matter how long we argue about this, the facts are : - gateways often don't stand this ordering issue - many iPBXs are using reINVITEs for several call features - the only way to solve this is to be dialog statefull, at least for ACKs and INVITES So my conclusion is : I'm going to code an ugly little hack - using an external database and avpops - so that ACKs are logged per Cseq+callid, and when reinvites are detected, relay will be delayed until the last ACK is logged as sent. What do you think ? Is there a way to use the dialog module to optimize this (flagging the SIP headers themselves instead of an external DB) ? Best Regards, Jerome Martin