[Users] ACK and re-INVITE ordering

[T.R. Missner]

We solved this problem in a SBC I used to work on by dropping the reInvite
if the ACK was still pending.  This works in UDP since the reInvite then
would be resent. Of course the SBC was dialog stateful.

Dropping the reInvite on the floor in the case of UDP transport certainly is
easier than delay/resending

Hope this helps

T.R.


On 11/29/06 3:09 PM, "Jerome Martin" <jmartin at longphone.fr> wrote:

> 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
>  
> 
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users