<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Hi Mariana,<br>
<br>
no, you do not need to create the INVITE trasaction in advance -
do it as usually : at the end, on t_relay(). Because if the INVITE
transaction does not exist (not yet relayed), the t_check_trans()
for CANCEL will fail and CANCEL will be dropped (not relayed).
Only one of the following retransmissions on the CANCEL will get
relayed as soon as the INVITE transaction is created.<br>
<br>
Regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
<br>
On 01/09/2013 05:38 PM, Mariana Arduini wrote:
<blockquote
cite="mid:CABHUZgDS51ja3rjmHCQbskaH1Ux9hxPHou_t4Xh9coh+B1kZcw@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true" 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>
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 moz-do-not-send="true" 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
moz-do-not-send="true"
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 moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a moz-do-not-send="true" 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>
</blockquote>
</body>
</html>