<!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 text="#000000" bgcolor="#ffffff">
<tt>Hello Miguel,<br>
<br>
In the bogus case, the problem is that the replies are received
long after the transaction was deleted by opensips (as it was
completed via the local timeout).<br>
<br>
If the transaction would still be in memory when the late 180 is
received, the CANCEL will be fired (like in the working case).<br>
<br>
As configured right now, the UAS, as not receiving an ACK for the
200 OK , must drop the call - this is what the RFC3261 says.<br>
<br>
Another option for you would be to prelong how long OpenSIPS keeps
transactions in mem after completion (see wait timer - wt_timer in
TM module -
<a class="moz-txt-link-freetext" href="http://www.opensips.org/html/docs/modules/1.9.x/tm.html#id250377">http://www.opensips.org/html/docs/modules/1.9.x/tm.html#id250377</a>)
. Be careful as using higher values here may result in more sh mem
used (as transaction will accumulate in memory).<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 06/10/2013 05:20 PM, Miguel París Díaz wrote:
<blockquote
cite="mid:CAEn+E3huUUqgEM+aFWX3-D2pRgw-43dh_aXo0MjRc8RfRHyhcw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<pre><font><span style="font-family: arial,helvetica,sans-serif;">Hi, I am using opensips-1.9.1-tls and some times I have a problem when there is a Request Timeout (408) for the INVITE request in the proxy side.
The problem is caused when the 180 Ringing provisional response arrives after some seconds from the SIP caller.
</span></font></pre>
<pre><font><span style="font-family: arial,helvetica,sans-serif;">If the Ringing arrives early we have a <b>successful case</b>:</span><span style="font-family: arial,helvetica,sans-serif;">
</span><font><span style="font-family: arial,helvetica,sans-serif;">
<span style="font-family: courier new,monospace;">UAC(caller) PROXY(opensips) UAS(callee)</span></span></font>
<font><span style="font-family: arial,helvetica,sans-serif;"><span style="font-family: courier new,monospace;"><font><span style="font-family: courier new,monospace;">INVITE ---------->
<---- 100 Giving a try
INVITE----------->
<---- 408 request timeout
ACK ------------->
<--------- 180 Ringing
</span></font></span></span></font><font><span style="font-family: arial,helvetica,sans-serif;"><span style="font-family: courier new,monospace;"><font><span style="font-family: courier new,monospace;"><font><span style="font-family: arial,helvetica,sans-serif;"><span style="font-family: courier new,monospace;">CANCEL ---------->
<--------- 200 OK (CANCEL)
<--------- 487 Request Terminated</span></span></font></span></font></span>
But if the Ringing is late, we have a <b>error case</b>, and the SIP caller is not notified, so it retry the 200 OK responses of the invite indefinitely.</span><span style="font-family: courier new,monospace;"><span style="font-family: arial,helvetica,sans-serif;">
</span>UAC(caller) PROXY(opensips) UAS(callee)
INVITE ---------->
<---- 100 Giving a try
INVITE----------->
<---- 408 request timeout
ACK ------------->
</span></font></font></pre>
<pre><font><span style="font-family: courier new,monospace;"> .... some secons ....
</span></font></pre>
<pre><font><span style="font-family: courier new,monospace;"> <--------- 180 Ringing
<------- 200 OK (invite)
<------- 200 OK (invite)
<------- 200 OK (invite)
</span><span style="font-family: courier new,monospace;"> <------- 200 OK (invite)</span>
</font></pre>
<font><br>
The problem in this case is that cannot found a matching
transaction, as we can see in the next log:<br>
</font></div>
<div>
<div>
<div>
<div><font><br>
<span style="font-family: courier new,monospace;">Jun
7 11:14:10 DBG:core:tcp_read_req: content-length= 0<br>
Jun 7 11:14:10 DBG:core:parse_msg: SIP Reply
(status):<br>
Jun 7 11:14:10 DBG:core:parse_msg: version:
<SIP/2.0><br>
Jun 7 11:14:10 DBG:core:parse_msg: status:
<180><br>
Jun 7 11:14:10 DBG:core:parse_msg: reason:
<Ringing><br>
Jun 7 11:14:10 DBG:core:parse_headers: flags=2<br>
Jun 7 11:14:10 DBG:core:get_hdr_field: cseq
<CSeq>: <2> <INVITE><br>
Jun 7 11:14:10 DBG:core:parse_to_param:
tag=spekujkorj<br>
Jun 7 11:14:10 DBG:core:parse_to: end of header
reached, state=29<br>
Jun 7 11:14:10 DBG:core:parse_to: display={},
ruri={<a moz-do-not-send="true"
href="mailto:sip%3Anote2@hnj.kurento.com">sip:note2@hnj.kurento.com</a>}<br>
Jun 7 11:14:10 DBG:core:get_hdr_field: <To>
[44]; uri=[<a moz-do-not-send="true"
href="mailto:sip%3Anote2@hnj.kurento.com">sip:note2@hnj.kurento.com</a>]
<br>
Jun 7 11:14:10 DBG:core:get_hdr_field: to body
[<<a moz-do-not-send="true"
href="mailto:sip%3Anote2@hnj.kurento.com">sip:note2@hnj.kurento.com</a>>]<br>
Jun 7 11:14:10 DBG:core:parse_via_param: found
param type 232, <branch> =
<z9hG4bK016c.417b8715.0>; state=6<br>
Jun 7 11:14:10 DBG:core:parse_via_param: found
param type 236, <i> = <03>; state=6<br>
Jun 7 11:14:10 DBG:core:parse_via_param: found
param type 235, <rport> = <5080>;
state=9<br>
Jun 7 11:14:10 DBG:core:parse_via: next_via<br>
Jun 7 11:14:10 DBG:core:parse_via_param: found
param type 234, <received> =
<176.83.57.96>; state=6<br>
Jun 7 11:14:10 DBG:core:parse_via_param: found
param type 232, <branch> =
<z9hG4bK_rfuwozfonk>; state=6<br>
Jun 7 11:14:10 DBG:core:parse_via_param: found
param type 235, <rport> = <30531>;
state=16<br>
Jun 7 11:14:10 DBG:core:parse_via: end of header
reached, state=5<br>
Jun 7 11:14:10 DBG:core:parse_headers: via found,
flags=2<br>
Jun 7 11:14:10 DBG:core:parse_headers: this is the
first via<br>
Jun 7 11:14:10 DBG:core:receive_msg: After
parse_msg...<br>
Jun 7 11:14:10 DBG:core:forward_reply: found module
tm, passing reply to it<br>
Jun 7 11:14:10 DBG:tm:t_check:
start=0xffffffffffffffff<br>
Jun 7 11:14:10 DBG:core:parse_headers: flags=22<br>
Jun 7 11:14:10 DBG:core:parse_headers: flags=8<br>
Jun 7 11:14:10 DBG:tm:t_reply_matching: hash 50704
label 1366865684 branch 0<br>
Jun 7 11:14:10 DBG:tm:t_reply_matching: no matching
transaction exists<br>
Jun 7 11:14:10 DBG:tm:t_reply_matching: failure to
match a transaction<br>
Jun 7 11:14:10 DBG:tm:t_check: end=(nil)<br>
Jun 7 11:14:10 DBG:core:destroy_avp_list:
destroying list (nil)<br>
Jun 7 11:14:10 DBG:core:receive_msg: cleaning up</span><br>
<br>
<br>
</font></div>
<div><font>To force this behavior I have set the next
values in opensips.cfg<br>
<span style="font-family: courier new,monospace;">modparam("tm",
"fr_timer", 2) # Timeout if a provisonal response
for INVITE does not arrive before 2 seconds<br>
modparam("tm", "fr_inv_timer", 60)</span><br
clear="all">
</font></div>
<div><font><br>
-- <br>
<a moz-do-not-send="true"
href="http://twitter.com/mparisdiaz" target="_blank">http://twitter.com/mparisdiaz</a><br>
</font>
</div>
</div>
</div>
</div>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</body>
</html>