<div dir="ltr">Hi Remco,<div><br></div><div style>We´re actually doing it already, but we didn´t know how to avoid the duplicate 100-replies. Thanks for the hint!</div><div style><br></div><div style>Regards,</div><div style>

Mariana.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 6:19 PM, Remco . <span dir="ltr">&lt;<a href="mailto:remconl87@gmail.com" target="_blank">remconl87@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br><br>The same happens sometimes with INVITE requests, if it takes to long the UA might start retransmitting.<br>
I solve this by sending a provisional reply right upon receiving the request<br>
<br>if (is_method(&quot;INVITE&quot;))<br>
{<br>       sl_send_reply(&quot;100&quot;, &quot;Trying -- your call is important to us&quot;);<br>}<br><br>And then use t_relay(&quot;0x01&quot;) to avoid duplicate 100-replies. This avoids race-conditions, it might help in your case as well.<br>


<br>Regards,<br>Remco.<br><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Jan 8, 2013 at 9:49 PM, Mariana Arduini <span dir="ltr">&lt;<a href="mailto:marianarduini@gmail.com" target="_blank">marianarduini@gmail.com</a>&gt;</span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hello all,<div><br></div><div>I hope somebody can give me a kind hint on what to do here.<br>

<div><br></div>
<div>We have this piece of code for CANCEL handling:</div><div><br></div><div><div>

    # CANCEL processing</div><div>    if (is_method(&quot;CANCEL&quot;)) {</div><div>        if (t_check_trans()) {</div><div>            t_relay();</div><div>        }</div><div>        exit;</div><div>    }</div><div><br>




</div><div>What happens is sometimes we take too long to process the INVITE due to some DB issues, and the UAC sends us a CANCEL before we relay the INVITE. </div><div><br></div><div>We don´t use t_newtran() because of this big warning in docs saying that &quot;<span style="text-align:justify;font-size:12px;font-family:Helvetica,Arial">the changes on the request that are made after this function call will not be saved into transaction!!!</span>&quot;. We need to perform a lot of changes in the requests and I understand this wouldn´t be possible after calling t_newtran().</div>




<div><br></div><div>So our transaction is not created untill we relay the INVITE, which means that any CANCEL received before that will be dropped.</div><div><br></div><div>We also tried testing the CANCEL messages we´re receiving in these cases with has_totag() and loose_route(), but they won´t pass as well.</div>




<div><br></div><div>Is there any way to verify a CANCEL message in this scenario and relay it in case is belongs to a valid transaction?</div><div><br></div><div>Any help will be much appreciated.</div>

<div><br></div><div>Regards,</div><div>Mariana.</div></div></div></div>
<br></div></div><div class="im">_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></div></blockquote></div><br>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>