[Users] ACK and re-INVITE ordering

[Jerome Martin]

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