<div dir="ltr">Hi Mariana, <div><br></div><div>There is the t_flush_flags to push changes in the flags after t_newtran(). </div><div><br></div><div>For CANCEL, if you call t_check_trans, you can relay the CANCEL automagically based on the transaction. It is like a shortcut. It is in the default script. </div>
<div><br></div><div>if (is_method(&quot;CANCEL&quot;))  {</div><div>        if (t_check_trans()){</div><div>            t_relay();</div><div>            exit;</div><div>        }</div><div>    } </div><div class="gmail_extra">
<br clear="all"><div><div>Flavio E. Goncalves</div></div><div><a href="http://www.sippulse.com">www.sippulse.com</a></div>
<br><br><div class="gmail_quote">2013/1/8 Mariana Arduini <span dir="ltr">&lt;<a href="mailto:marianarduini@gmail.com" target="_blank">marianarduini@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>_______________________________________________<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></div>