<br><br><div><span class="gmail_quote">On 11/30/06, <b class="gmail_sendername">Jerome Martin</b> <<a href="mailto:jmartin@longphone.fr">jmartin@longphone.fr</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>Thanks for answer my post,<br><br>On Wed, 2006-11-29 at 17:27 -0500, T.R. Missner wrote:<br>> We solved this problem in a SBC I used to work on by dropping the reInvite<br>> if the ACK was still pending. This works in UDP since the reInvite then
<br>> would be resent. Of course the SBC was dialog stateful.<br><br>Do you have an idea of the overhead of dialog statefullness ? Would a DB<br>storage of pending ACKs (mean 1 DB write per (re)INVITE callID+Cseq, 1<br>
DB write (delete) per ACK, 1 DB read per reINVITE) have a big impact on<br>performance ? Am I going to butcher my dear openser 1.1 by implementing<br>this ?</blockquote><div><br>You might get away cheaper with a little TM modification and using TCP with the gateway:
<br>- you have to enhance TM to allow you to see if a transaction belonging to same dialog is still pending; if it is, either drop the second transaction (as already suggested) or reply with something like 480 or 491 (none of them best suited for the job, but might work);
<br>- by using one TCP connection you minimize the chance of packet reordering.<br><br>Delaying is not really possible without blocking the process doing it: you could end up with a blocked server.<br><br>Hth, WL.<br></div>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Dropping the reInvite on the floor in the case of UDP transport certainly is<br>> easier than delay/resending
<br><br>Nice one.<br>Do you have an idea of the average timeout waiting for an INVITE reply ?<br>I mean before resending ? Because I makes no sense anyway to delay for<br>more than this timeout instead of dropping the request ... but dropping
<br>requires DB overhead.<br><br>But still, only delaying the reINVITE for a fixed amount of time indeed<br>will generate escalating resends if delay is too big, and might no solve<br>100% of the issue (WILL not) if delay is too short (so to avoid
<br>resends). So in order to keep the UA from resending, one must carefully<br>send provisionnal replies while delaying, which starts to get unpleasant<br>to the eye (IMHO).<br><br>><br>> Hope this helps<br>> T.R
.<br><br>Well it does :-)<br>It made me think a bit more, I just didn't really worried about timeout<br>and resends, but clearly one MUST take this into consideration, either<br>by leveraging the mechanism to do part of the job or finding a
<br>workaround so it doesn't get into the way, depending on the approach.<br>Cleary, if choosing to implement partial dialog statefullness for<br>reINVITE handling, I'll stick to your suggestion, which is much more<br>elegant than delay.
<br><br>Thanks again for your answer,<br>Best Regards,<br>Jerome Martin<br><br><br>_______________________________________________<br>Users mailing list<br><a href="mailto:Users@openser.org">Users@openser.org</a><br><a href="http://openser.org/cgi-bin/mailman/listinfo/users">
http://openser.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></div><br>