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

Miguel París Díaz mparisdiaz at gmail.com
Mon Jun 10 16:20:19 CEST 2013


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}
Jun  7 11:14:10 DBG:core:get_hdr_field: <To> [44]; uri=[
sip:note2 at hnj.kurento.com]
Jun  7 11:14:10 DBG:core:get_hdr_field: to body [<sip:note2 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130610/bb1ab7e2/attachment-0001.htm>


More information about the Users mailing list