[SR-Users] ACC issue on 4.0 trunk when doing serial fork

Daniel-Constantin Mierla miconda at gmail.com
Fri Dec 20 10:25:24 CET 2013


Hello,

in failure route is given the SIP message as it was at the moment of 
transaction (e.g., the headers added/removed in request_route will be 
still kept there, but not those added in branch_route or other 
failure_route blocks).

It would be good to get access to the attributes of the branch that was 
the winner in a parallel forking or the last of serial forking, but this 
is a new feature. Perhaps a class of PVs will do it. You can open a new 
item in tracker for feature request, so we don't forget about it.

For now, you can keep store values in avp/xavp as you need to retrieve 
in failure route.

Cheers,
Daniel

On 19/12/13 10:42, Kelvin Chua wrote:
> modparam("tm", "failure_reply_mode", 3)
> modparam("tm", "contacts_avp", "tm_contacts");
> modparam("tm", "contact_flows_avp", "tm_contact_flows");
> modparam("tm", "failure_reply_mode", 3)
> modparam("tm", "restart_fr_on_each_reply", 0)
>
>
> Kelvin Chua
>
>
> On Thu, Dec 19, 2013 at 3:57 PM, Daniel-Constantin Mierla 
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Can you share here the parameters you set for tm module?
>
>     Daniel
>
>
>     On 19/12/13 01:55, Kelvin Chua wrote:
>>
>>     Also noticed $ru pegged at the first branch's ruri upon entering
>>     failure_route for succeeding branches. Is this also an expected
>>     behaviour? Should it not contain the ruri of the previous failed
>>     branch?
>>
>>     On Dec 18, 2013 4:19 PM, "Daniel-Constantin Mierla"
>>     <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>>         Hello,
>>
>>         I will look over it -- I wanted to know exactly the situation.
>>
>>         Cheers,
>>         Daniel
>>
>>         On 17/12/13 15:54, Kelvin Chua wrote:
>>>
>>>         Yes, a local timeout. The call was sent to a bogus IP. i
>>>         still feel this behaviour is wrong. $rd in acc should
>>>         contain the failed gateway's ip and not the previous one.
>>>
>>>         On Dec 17, 2013 4:43 PM, "Daniel-Constantin Mierla"
>>>         <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>>
>>>             It is a local timeout, not a 408 received from callee,
>>>             right?
>>>
>>>             Daniel
>>>
>>>             On 17/12/13 05:16, Kelvin Chua wrote:
>>>>             it's for a 408 timeout logged into missed_calls
>>>>
>>>>             Kelvin Chua
>>>>
>>>>
>>>>             On Mon, Dec 16, 2013 at 8:52 PM, Daniel-Constantin
>>>>             Mierla <miconda at gmail.com <mailto:miconda at gmail.com>>
>>>>             wrote:
>>>>
>>>>                 Hello,
>>>>
>>>>                 is it for a 200ok reply or >=300?
>>>>
>>>>                 In the code, the r-uri from the branch that is used
>>>>                 for relaying the reply should be used.
>>>>
>>>>                 Cheers,
>>>>                 Daniel
>>>>
>>>>
>>>>                 On 14/12/13 12:15, Kelvin Chua wrote:
>>>>>                 this is the 2nd branch, the first branch is sent
>>>>>                 to 100.200.30.40
>>>>>                 $rd is set properly according to xlog
>>>>>                 (10.20.30.40). tcpdump proves packets are sent to
>>>>>                 10.20.30.40
>>>>>                 however, after failing, ACC logs dst_domain as the
>>>>>                 previous branch's $rd (100.200.30.40), not the
>>>>>                 current one.
>>>>>                 is this the expected behavior? seems incorrect.
>>>>>
>>>>>                 modparam("acc",
>>>>>                 "db_extra","src_user=$fU;src_domain=$fd;src_ip=$si;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;callrate=$avp(callrate)")
>>>>>
>>>>>                 failure_route[SERIAL] {
>>>>>                         if (is_method("INVITE|SUBSCRIBE")) {
>>>>>                 t_on_branch("MANAGE_BRANCH");
>>>>>                 t_on_reply("MANAGE_REPLY");
>>>>>                         }
>>>>>                         if ( isbflagset(FLB_CANCEL) ) {
>>>>>                 xlog("cancel bflag set!\n");
>>>>>                     exit;
>>>>>                         } else if ( !t_next_contacts() ) {
>>>>>                 xlog("serial fork done!\n");
>>>>>                 t_reply("404", "Not here or busy");
>>>>>                     exit;
>>>>>                         } else {
>>>>>                 setflag(FLT_ACC);
>>>>>                 setflag(FLT_ACCMISSED);
>>>>>                 xlog("failure_route new branch - $ru\n");
>>>>>                 t_on_failure("SERIAL");
>>>>>                 $avp(callrate) = "";
>>>>>                     if ( $sel(ruri.params["rtmr"]) != $null ) {
>>>>>                 t_set_fr($sel(ruri.params["rtmr"])*1000,$sel(ruri.params["dtmr"])*1000);
>>>>>                 $avp(ABSOLUTE) = $sel(ruri.params["tmr"]);
>>>>>                     }
>>>>>                     if ( $sel(ruri.params["callrate"]) != $null )
>>>>>                 $avp(callrate) = $sel(ruri.params["callrate"]);
>>>>>                 xlog("failure_route sending INVITE to $rd\n");
>>>>>                     t_relay();
>>>>>                         }
>>>>>                 }
>>>>>
>>>>>                 ERROR: <script>: failure_route sending INVITE to
>>>>>                 10.20.30.40
>>>>>                 DEBUG: <script>: new branch [1] to
>>>>>                 sip:14X88X72X2X at 10.20.30.40:5060;dtmr=1;rtmr=20;tmr=60;callrate=0.007600000000
>>>>>                 DEBUG: siputils [checks.c:103]: has_totag(): no totag
>>>>>                 DEBUG: rtpproxy [rtpproxy_funcs.c:148]:
>>>>>                 check_content_type(): type <application/sdp> found
>>>>>                 valid
>>>>>                 DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
>>>>>                 extract_mediaip(): located IP address
>>>>>                 [192.168.5.191] in `o=' field
>>>>>                 DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
>>>>>                 extract_mediaip(): located IP address
>>>>>                 [192.168.5.191] in `c=' field
>>>>>                 DEBUG: rtpproxy [rtpproxy.c:2630]:
>>>>>                 force_rtp_proxy(): proxy reply: 10370
>>>>>                 2X8.1X1.3X.2X#012
>>>>>                 DEBUG: siputils [checks.c:103]: has_totag(): no totag
>>>>>                 DEBUG: <core> [msg_translator.c:461]:
>>>>>                 clen_builder(): clen_builder: content-length: 172
>>>>>                 (172)
>>>>>                 DEBUG: <core> [msg_translator.c:206]:
>>>>>                 check_via_address():
>>>>>                 check_via_address(1X5.2X2.1X7.1X0, 192.168.5.191, 0)
>>>>>                 DEBUG: <core> [parser/sdp/sdp.c:793]: free_sdp():
>>>>>                 _sdp = 0x7f53c9a5e580
>>>>>                 DEBUG: <core> [parser/sdp/sdp.c:795]: free_sdp():
>>>>>                 sdp = 0x7f53cb87d3e0
>>>>>                 DEBUG: <core> [parser/sdp/sdp.c:797]: free_sdp():
>>>>>                 session = 0x7f53cb87d480
>>>>>                 DEBUG: tm [t_reply.c:1710]: relay_reply(): DEBUG:
>>>>>                 relay_reply: branch=0, save=0, relay=-1
>>>>>                 DEBUG: tm [t_reply.c:1211]:
>>>>>                 t_should_relay_response(): ->>>>>>>>> T_code=100,
>>>>>                 new_code=408
>>>>>                 DEBUG: tm [t_hooks.c:288]:
>>>>>                 run_trans_callbacks_internal(): DBG:
>>>>>                 trans=0x7f53c1511148, callback type 128, id 0 entered
>>>>>                 DEBUG: acc [acc_logic.c:539]: tmcb_func(): acc
>>>>>                 callback called for t(0x7f53c1511148) event type
>>>>>                 128, reply code 408
>>>>>                 NOTICE: acc [acc.c:279]: acc_log_request(): ACC:
>>>>>                 call missed:
>>>>>                 timestamp=1387019197;method=INVITE;from_tag=wyudf;to_tag=;call_id=cjfbdfydrjielti at X340saucy;code=408;reason=RequestTimeout;src_user=kelvin;src_domain=2X8.1X1.3X.2X;src_ip=1X5.2X2.1X7.1X0;dst_ouser=14X88X72X2X;dst_user=14X88X72X2X;dst_domain=100.200.30.40;callrate=0.007600000000
>>>>>                 <mailto:timestamp=1387019197;method=INVITE;from_tag=wyudf;to_tag=;call_id=cjfbdfydrjielti at X340saucy;code=408;reason=RequestTimeout;src_user=kelvin;src_domain=2X8.1X1.3X.2X;src_ip=1X5.2X2.1X7.1X0;dst_ouser=14X88X72X2X;dst_user=14X88X72X2X;dst_domain=100.200.30.40;callrate=0.007600000000>
>>>>>
>>>>>
>>>>>                 Kelvin Chua
>>>>>
>>>>>
>>>>>                 _______________________________________________
>>>>>                 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>>>                 sr-users at lists.sip-router.org  <mailto:sr-users at lists.sip-router.org>
>>>>>                 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>                 -- 
>>>>                 Daniel-Constantin Mierla -http://www.asipto.com
>>>>                 http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 SIP Express Router (SER) and Kamailio (OpenSER) -
>>>>                 sr-users mailing list
>>>>                 sr-users at lists.sip-router.org
>>>>                 <mailto:sr-users at lists.sip-router.org>
>>>>                 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>>             -- 
>>>             Daniel-Constantin Mierla -http://www.asipto.com
>>>             http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>>>
>>
>>         -- 
>>         Daniel-Constantin Mierla -http://www.asipto.com
>>         http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>>
>
>     -- 
>     Daniel-Constantin Mierla -http://www.asipto.com
>     http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131220/643d93d3/attachment-0001.html>


More information about the sr-users mailing list