<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.<br>
The problem is caused when the 180 Ringing provisional response arrives after some seconds from the SIP caller.<br><br></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"><br>
</span><font><span style="font-family:arial,helvetica,sans-serif"><br><span style="font-family:courier new,monospace">UAC(caller) PROXY(opensips) UAS(callee)</span></span></font><br><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<br> </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><br><br><br>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"><br>
<br></span>UAC(caller) PROXY(opensips) UAS(callee)
INVITE ---------->
<---- 100 Giving a try
INVITE----------->
<---- 408 request timeout
ACK -------------><br></span></font></font></pre><pre><font><span style="font-family:courier new,monospace"> .... some secons ....<br></span></font></pre><pre><font><span style="font-family:courier new,monospace"> <--------- 180 Ringing
<------- 200 OK (invite)
<------- 200 OK (invite)
<------- 200 OK (invite)<br></span><span style="font-family:courier new,monospace"> <------- 200 OK (invite)</span><br></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 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 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 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 href="http://twitter.com/mparisdiaz" target="_blank">http://twitter.com/mparisdiaz</a><br></font>
</div></div></div></div></div>