[OpenSIPS-Users] SIP caller is not notified when the INVITE has Request Timeout(408) from opensips

[Bogdan-Andrei Iancu]

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:note2 at hnj.kurento.com <mailto:sip%3Anote2 at hnj.kurento.com>}
> Jun  7 11:14:10 DBG:core:get_hdr_field: <To> [44];
> uri=[sip:note2 at hnj.kurento.com <mailto:sip%3Anote2 at hnj.kurento.com>]
> Jun  7 11:14:10 DBG:core:get_hdr_field: to body
> [<sip:note2 at hnj.kurento.com <mailto:sip%3Anote2 at hnj.kurento.com>>]
> 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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130612/0325ee0b/attachment.htm>