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(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi, Thanks for answer my post, On Wed, 2006-11-29 at 17:27 -0500, T.R. Missner wrote: reInvite Do you have an idea of the overhead of dialog statefullness ? Would a DB storage of pending ACKs (mean 1 DB write per (re)INVITE callID+Cseq, 1 DB write (delete) per ACK, 1 DB read per reINVITE) have a big impact on performance ? Am I going to butcher my dear openser 1.1 by implementing this ?

Dropping the reInvite on the floor in the case of UDP transport certainly is Nice one. Do you have an idea of the average timeout waiting for an INVITE reply ? I mean before resending ? Because I makes no sense anyway to delay for more than this timeout instead of dropping the request ... but dropping requires DB overhead. But still, only delaying the reINVITE for a fixed amount of time indeed will generate escalating resends if delay is too big, and might no solve 100% of the issue (WILL not) if delay is too short (so to avoid resends). So in order to keep the UA from resending, one must carefully send provisionnal replies while delaying, which starts to get unpleasant to the eye (IMHO). Well it does :-) It made me think a bit more, I just didn't really worried about timeout and resends, but clearly one MUST take this into consideration, either by leveraging the mechanism to do part of the job or finding a workaround so it doesn't get into the way, depending on the approach. Cleary, if choosing to implement partial dialog statefullness for reINVITE handling, I'll stick to your suggestion, which is much more elegant than delay. Thanks again for your answer, Best Regards, Jerome Martin _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi Jerome, I this this is an interesting solution to the problem. 1) use the dialog module ; we can add a function to access the dialog state from the script.

2) when receiving a re-INVITE, if dialog state is NOT-ACKed, drop the request - the delay between re-INVITE and ACK should not be too long (as there were 2 requests going in the same direction, generated in reversed order), so 2, maximum 3 retransmission cycles should cover it up.

At least you can run some test to see what is the average delay between re-INVITE and ACK to get an idea what you should expect for.

You can also send a "pending" reply if you're already processing one INVITE and get another in the meantime.

On Thu, 2006-11-30 at 11:52 +0200, Bogdan-Andrei Iancu wrote: Yes, that's what I wanted to do, but I fear there could be a race condition for reading/setting the cookie between openser processes handling the ACK and the following reINVITE. What do you think ?

I wanted to add a "PendingACK" parameter to the dialog cookie upon successfull INVITE transaction, and check that parameter for every reINVITE received (and drop the reINVITE as suggested by T.R. Missner).

Agreed. Just for a test, by using a systematic (blindly) delay of 1 second when receiving a reINVITE, the probleme fully disapears in my tests.

yes please - open a feature request to have it in mind for the next release. Just to be sure - the enhancement I was referring at is not about adding additional information about the dialog state as RR param, but just a function to access the internal dialog state.

see above; the dialog module puts a dialog id in as RR param just for a fast dialog matching - the information about the dialog parameters, its state and so on are kept in memory by the dialog module.

Does it mean transaction information is kept in-memory as part of dialog state, and I could check if last ACK was processed ? I can't really see how this state information would be structured/what it contains.

Thanks, I misunderstood how it works. Now it makes sense :-) Do you plan to add an avp access to store/access arbitrary per-dialog information in-memory ? Like declaring avps to be dialog-specific as dialog module parameter, than just using avp the usual way ?

see in modules/dialog/dlg_hash.h the dlg_cell structure, state field. There is no state yet saying if ACK was received or not, but I guess can be added without problems

the dialog module will export a new PV containing the dialog state.

Jerome, please open a feature request on the tracker, otherwise I might forget about this :(. regards, bogdan Jerome Martin wrote: