Hello Miguel, 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).
If the transaction would still be in memory when the late 180 is received, the CANCEL will be fired (like in the working case). 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. 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 - http://www.opensips.org/html/docs/modules/1.9.x/tm.html#id250377) . Be careful as using higher values here may result in more sh mem used (as transaction will accumulate in memory). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 06/10/2013 05:20 PM, Miguel París Díaz wrote: > 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. > > If the Ringing arrives early we have a *successful case*: > > > UAC(caller) PROXY(opensips) UAS(callee) > INVITE ----------> > <---- 100 Giving a try > INVITE-----------> > <---- 408 request timeout > ACK -------------> > <--------- 180 Ringing > CANCEL ----------> > <--------- 200 OK (CANCEL) > <--------- 487 Request Terminated > > > But if the Ringing is late, we have a *error case*, and the SIP caller is not > notified, so it retry the 200 OK responses of the invite indefinitely. > > > UAC(caller) PROXY(opensips) UAS(callee) > INVITE ----------> > <---- 100 Giving a try > INVITE-----------> > <---- 408 request timeout > ACK -------------> > .... some secons .... > <--------- 180 Ringing > <------- 200 OK (invite) > <------- 200 OK (invite) > <------- 200 OK (invite) > <------- 200 OK (invite) > > The problem in this case is that cannot found a matching transaction, > as we can see in the next log: > > Jun 7 11:14:10 DBG:core:tcp_read_req: content-length= 0 > Jun 7 11:14:10 DBG:core:parse_msg: SIP Reply (status): > Jun 7 11:14:10 DBG:core:parse_msg: version: <SIP/2.0> > Jun 7 11:14:10 DBG:core:parse_msg: status: <180> > Jun 7 11:14:10 DBG:core:parse_msg: reason: <Ringing> > Jun 7 11:14:10 DBG:core:parse_headers: flags=2 > Jun 7 11:14:10 DBG:core:get_hdr_field: cseq <CSeq>: <2> <INVITE> > Jun 7 11:14:10 DBG:core:parse_to_param: tag=spekujkorj > Jun 7 11:14:10 DBG:core:parse_to: end of header reached, state=29 > Jun 7 11:14:10 DBG:core:parse_to: display={}, > ruri={sip:[email protected] <mailto:sip%[email protected]>} > Jun 7 11:14:10 DBG:core:get_hdr_field: <To> [44]; > uri=[sip:[email protected] <mailto:sip%[email protected]>] > Jun 7 11:14:10 DBG:core:get_hdr_field: to body > [<sip:[email protected] <mailto:sip%[email protected]>>] > Jun 7 11:14:10 DBG:core:parse_via_param: found param type 232, > <branch> = <z9hG4bK016c.417b8715.0>; state=6 > Jun 7 11:14:10 DBG:core:parse_via_param: found param type 236, <i> = > <03>; state=6 > Jun 7 11:14:10 DBG:core:parse_via_param: found param type 235, > <rport> = <5080>; state=9 > Jun 7 11:14:10 DBG:core:parse_via: next_via > Jun 7 11:14:10 DBG:core:parse_via_param: found param type 234, > <received> = <176.83.57.96>; state=6 > Jun 7 11:14:10 DBG:core:parse_via_param: found param type 232, > <branch> = <z9hG4bK_rfuwozfonk>; state=6 > Jun 7 11:14:10 DBG:core:parse_via_param: found param type 235, > <rport> = <30531>; state=16 > Jun 7 11:14:10 DBG:core:parse_via: end of header reached, state=5 > Jun 7 11:14:10 DBG:core:parse_headers: via found, flags=2 > Jun 7 11:14:10 DBG:core:parse_headers: this is the first via > Jun 7 11:14:10 DBG:core:receive_msg: After parse_msg... > Jun 7 11:14:10 DBG:core:forward_reply: found module tm, passing reply > to it > Jun 7 11:14:10 DBG:tm:t_check: start=0xffffffffffffffff > Jun 7 11:14:10 DBG:core:parse_headers: flags=22 > Jun 7 11:14:10 DBG:core:parse_headers: flags=8 > Jun 7 11:14:10 DBG:tm:t_reply_matching: hash 50704 label 1366865684 > branch 0 > Jun 7 11:14:10 DBG:tm:t_reply_matching: no matching transaction exists > Jun 7 11:14:10 DBG:tm:t_reply_matching: failure to match a transaction > Jun 7 11:14:10 DBG:tm:t_check: end=(nil) > Jun 7 11:14:10 DBG:core:destroy_avp_list: destroying list (nil) > Jun 7 11:14:10 DBG:core:receive_msg: cleaning up > > > To force this behavior I have set the next values in opensips.cfg > modparam("tm", "fr_timer", 2) # Timeout if a provisonal response for > INVITE does not arrive before 2 seconds > modparam("tm", "fr_inv_timer", 60) > > -- > http://twitter.com/mparisdiaz > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
