<div dir="ltr">Hi Bogdan,<div><br></div><div style>So I understand that the only way to recognize the transaction of a CANCEL message received before relaying the INVITE is to create the transaction using t_newtran() just after receiving the INVITE, but this would affect some of our features.</div>
<div style><br></div><div style>In this case, weŽll have to work on the time our server is taking to process the INVITE and make sure it wonŽt be stuck for too long waiting for a DB query or something.</div><div style><br>
</div><div style>Thanks again for the kind help!</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 11:29 AM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div bgcolor="#ffffff" text="#000000">
<tt>Hi Mariana,<br>
<br>
According to RFC3261, the CANCEL processing (as cancelling the
call) is not up to a proxy, but up to the end devices. So a proxy
has to simply relay all received info (INVITE and CANCEL) - it
cannot terminate the call by itself.<br>
<br>
So you have to relay both INVITE and CANCEL and let the end device
to reject the call.<br>
<br>
Regarding Flavio's suggestion - that function (as name says)
solves the problem only for the flags, but not for changes as
headers or SDP, AVPS, etc.<br>
<br>
Regards,<br>
</tt><div class="im">
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
<br></div><div><div class="h5">
On 01/09/2013 02:31 PM, Mariana Arduini wrote:
<blockquote type="cite">
<div dir="ltr">Hi All!
<div><br>
</div>
<div>Thank you both for the hints and explanation.</div>
<div><br>
</div>
<div>The retransmission of CANCEL messages would for
sure be really helpful, but weŽd like to be able to handle
cases where processing the INVITE takes too long. If
introducing some huge delays in INVITE processing, OpenSIPS
will relay it when the processing finally ends, but UAC had
already canceled it, so UAS picks a dead call up.</div>
<div><br>
</div>
<div>FlavioŽs suggestion looks interesting. IŽm just
wondering if t_flush_flags() would update all kind of changes
in the SIP message. We perform lots of translations in headers
and SDP and not applying any of them would totally mess
everything up. Any idea of limitations?</div>
<div><br>
</div>
<div>I begin to think that including timeouts during
INVITE processing with smaller values than the previous hop
fr_inv would be less risky. IŽd like to hear your oppinions.</div>
<div><br>
</div>
<div>Thanks again for the help!</div>
<div><br>
</div>
<div>Regards,</div>
<div>Mariana.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jan 9, 2013 at 9:54 AM,
Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#ffffff" text="#000000"> <tt>Hi Mariana,<br>
<br>
If CANCEL hits opensips while the the INVITE is still
under processing (in a different process), the INVITE
transaction will not exist yet (it is created by
t_relay), so the t_check_trans() will return false ->
script will exit without doing anything for the CANCEL -
more or less the CANCEL will be dropped without being
replied or fwded. This will force retransmission of
Cancel -> buying more time to finish the processing
of the INVITE.<br>
<br>
Hope this helped.<br>
<br>
Regards,<br>
</tt>
<pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre>
<div>
<div> <br>
On 01/08/2013 10:49 PM, Mariana Arduini wrote: </div>
</div>
<blockquote type="cite">
<div>
<div>
<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("CANCEL")) {</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 "<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>". 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>
</div>
</div>
<pre><fieldset></fieldset>
_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div></div></div>
</blockquote></div><br></div>