sr-dev November 2014

sr-dev@lists.kamailio.org

38 participants
207 discussions

Outbound flow failure handling merged to master

by Hugh Waite

Hello, As you will see I have merged my branch back into master. These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction. The event_route uses a new route type BRANCH_ROUTE which limits the functions that can be run in the route. The functions t_check_status(), t_next_contact_flow(), t_relay() and unregister() can be used in this route. A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry. The following example route can be used on a registrar to handle failed or invalid flows: event_route[tm:branch-failure] { xlog("L_INFO", "event_route[tm:branch-failure]\n"); if (t_check_status("430|403")) { if (!unregister("location", "$tu", "$T_reply_ruid")) { xlog("L_WARN", "failed to unregister $tu with ruid $T_reply_ruid\n"); } if (!t_next_contact_flow()) { xlog("L_INFO", "No more flows\n"); } else { xlog("L_INFO", "Next flow\n"); t_relay(); } } } Any bugs, memory leaks etc. let me know! Hugh -- Hugh Waite Principal Design Engineer Crocodile RCS Ltd.

7 years, 12 months

Re: [sr-dev] Is there a sense in calling run_onsend() after the msg_send() function?

by Lucian Balaceanu

Hi Daniel, I must admit this run_onsend() patch for stateful replies creation was not quite a success story. However, I think it serves a practical purpose, for example in Homer tracing and could be useful for the community. Again, I propose my past solution, with some questions: 1. I am unsure if the place I introduced the run_onsend call is appropriate since the buf used for msg_send is constructed build_res_buf_from_sip_req and build_res_buf_from_sip_res calls. 2. Also, we can maybe unite these if call branches I created: send_res = msg_send(&uas_rb->dst, buf, res_len); send_res = SEND_PR_BUFFER( uas_rb, buf, res_len ); 3. Do you think a get_send_socket snippet as follows should be inserted before the /*if (onsend_route_enabled(SIP_REPLY)){*/ : if(dst.send_sock == NULL) { dst.send_sock=get_send_socket(msg, &dst.to, dst.proto); if (dst.send_sock==0){ LM_ERR("cannot forward reply\n"); } } Thank you, Lucian On 10/29/2014 02:15 PM, Daniel-Constantin Mierla wrote: > Hello Lucian, > > I applied your patch with some fixes. > > I haven't checked with stateful replies, at some point a function from > core should be used. You can go ahead and see if it works, if not, let > me know and I can look into it as well. You can follow the callbacks > for TMCB_RESPONSE_OUT or TMCB_RESPONSE_FWDED inside tm code, they > should lead to the place where a sip response is going to be sent out. > > Cheers, > Daniel > > On 27/10/14 12:51, Lucian Balaceanu wrote: >> Hello Daniel, >> >> I must admit I only saw your mail last Friday. Until the 10th of >> October I was also on vacation. I know that you actually committed >> some of the changes together with your comments on the 12th this month. >> >> I don't know if we can consider the topic of the patch closed. As far >> as I understand, the state-full replies have not been addressed, >> right? (There should be a change in the t_reply.c) I followed the >> code to the relay_reply but I did not yet come to find the send >> function. Should I pursue further? >> >> Thank you, >> Lucian Balaceanu >> >>> Hi Lucian, >>> >>> somehow I forgot to follow up on this. But we need to get sorted out >>> soon, before we release, so it works as expected with the new >>> version. See more comments inline. >>> >>> >>> On 17/09/14 18:09, Lucian Balaceanu wrote: >>>> Hi Daniel, >>>> >>>> Please forgive me for my delay in responding to your mail. >>>> Please find attached a second version of the onsend_route_reply >>>> patch (which again has some problems). As per your previous >>>> indications I did the following: >>>> >>>> *Issue1* >>>>> From performances point of view, there can be added a config >>>>> parameter to enable running of onsend_route for replies: >>>>> >>>>> onsend_route_reply = 0|1 >>>> >>>> Following >>>> http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters I >>>> have tried to add onsend_route_reply parameter. The code compiles, >>>> but when trying to start kamailio with this parameter inside, the >>>> parsing fails with syntax errors signaling: >>>> >>>> / 0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse error in config >>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >>>> column 0: syntax error >>>> 0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse error in config >>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >>>> column 0: >>>> ERROR: bad config file (2 errors)/ >>> >>> The issue is: >>> >>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); >>> + yy_number_str=yytext; return NUMBER; } >>> >>> It should be: >>> >>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); >>> + yy_number_str=yytext; return ONSEND_RT_REPLY; } >>> >>>> >>>> *Issue2* >>>>> #define onsend_enabled(rtype) >>>>> (onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0) >>>> That is to say you see it best to take the chek for >>>> onsend_rt.list[DEFAULT_RT] from inside run_onsend() function and >>>> call this onsend_enabled(...) before the run_onsend()? >>> >>> This is to detect whether the onsend_route should be executed for >>> SIP replies. The condition being: >>> >>> - if is a sip reply and onsend_route is set and the >>> onsend_route_reply parameter is 1 >>>> >>>> *Issue3* >>>>> On the other hand, is onsend_route also executed for local >>>>> requests? I had in mind it is only for received requests that are >>>>> forwarded ... Iirc, on onsend_route, the sip message is the one >>>>> received, the outgoing content being accessible via $snd(buf). >>>>> >>>> I agree with you with taking out the locally generated requests and >>>> only left the run_onsend call in do_forward_reply function (inside >>>> forward.c). >>>> Could you point me to the reply relaying function that is called >>>> for state-full processing? >>> Stateful processing for replies is mainly done in t_reply.c from tm >>> module. At some point there should be a send buffer function call. >>> >>> Cheers, >>> Daniel >>>> >>>> Thank you and sorry again for my late answer, >>>> Lucian >>> >>> -- >>> Daniel-Constantin Mierla >>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda >>> >>> >> > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

9 years, 2 months

TM possible deadlock

by Jason Penton

Hi All, I have been experiencing a deadlock when a timeout occurs on a t_relayed() INVITE. Going through the code I have noticed a possible chance of deadlock (without re-entrant enabled). Here is my thinking: t_should_relay_response() is called with REPLY_LOCK when the timer process fires on the fr_inv_timer (no response from the INVITE that was relayed, other than 100 provisional) and a 408 is generated. However, from within that function there are calls to run_failure_handlers() which in turn *could* try and lock the reply (viz. somebody having a t_reply() call in the cfg file - in failure route block). This would result in another lock on the same transaction's REPLY_LOCK.... Has anybody else experienced something like this? this is on master btw. Cheers Jason

9 years, 7 months

topoh and locally-generated requests

by Alex Balashov

Hello, I have found that topoh does not seem to operate correctly on locally-generated requests, such as dialog timeout-fired BYEs. e.g. Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10357]: INFO: [R-TM-LOCAL-REQUEST:1-4289383-6930886-1692777-3284@127.0.1.1] Local request BYE to sip:sipp@127.0.1.1:5060 Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10357]: INFO: [R-TM-LOCAL-REQUEST:1-4289383-6930886-1692777-3284@127.0.1.1] Local request BYE to sip:172.30.110.5:5060;transport=UDP Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10348]: ERROR: topoh [th_mask.c:165]: th_mask_decode(): invalid input string"1-4289383-6930886-1692777-3284(a)127.0.1.1" Nov 17 17:20:16 centosity6 /usr/local/sbin/kamailio[10348]: ERROR: topoh [th_msg.c:484]: th_unmask_callid(): cannot decode callid You can see these BYEs are not TOPOH'd at all: 17:23:34.097128 IP 172.30.110.4.sip > 127.0.1.1.sip: SIP, length: 346 E..v....@.?]..n..........b..BYE sip:sipp@127.0.1.1:5060 SIP/2.0 Via: SIP/2.0/UDP 172.30.110.4;branch=z9hG4bK00ac.30df1375000000000000000000000000.0 To: <sip:4916095083616@127.0.1.1:5060>;tag=3287SIPpTag001 From: <sip:17069950290@172.30.110.4:5060>;tag=2117SIPpTag015 CSeq: 1 BYE Call-ID: 1-4289383-6930886-1692777-3287(a)127.0.1.1 Content-Length: 0 Max-Forwards: 70 17:23:34.097239 IP 172.30.110.4.sip > 172.30.110.5.sip: SIP, length: 358 E.......@.V...n...n......n5.BYE sip:172.30.110.5:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 172.30.110.4;branch=z9hG4bKdf9c.08ed9677000000000000000000000000.0 To: <sip:17069950290@172.30.110.4:5060>;tag=2117SIPpTag015 From: <sip:4916095083616@127.0.1.1:5060>;tag=3287SIPpTag001 CSeq: 2 BYE Call-ID: 1-4289383-6930886-1692777-3287(a)127.0.1.1 Content-Length: 0 Max-Forwards: 70 in contrast to the other messages in this dialog: 7:23:30.871062 IP 172.30.110.5.sip > 172.30.110.4.sip: SIP, length: 844 E..h!5@.@.. ..n...n......Th.SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.110.4;branch=z9hG4bK00ac.127fd0993a0e4c8a82474038472e09d2.0, SIP/2.0/UDP 172.30.110.4;branch=z9hG4bKsr-goq-nEDchKUa9vuehzD2nruchwxHmrgFJru63LarksqBks-Uhz3WnrhFnrPHhKxWmd9D0s97YrRS3LvcjBeUXrqi9E9SwWoEhre2nzPRhu** From: sipp <sip:4916095083616@172.30.110.4>;tag=3287SIPpTag001 To: 17069950290 <sip:17069950290@172.30.110.4:5060>;tag=2117SIPpTag015 Call-ID: CSEVhwoohreOhEeEnzjOhEuxmGjRhzjOhr32JWoEhre2-GPWJWxFnrPch-** Record-Route: <sip:172.30.110.4;lr=on;ftag=3287SIPpTag001;fromcor=ejFwbUZxUmpUUFNBejFwbUZxUm9RUFBfZS5wZ111ZFo-;dlgcor=9c9.77a1> CSeq: 1 INVITE Contact: <sip:172.30.110.5:5060;transport=UDP> Content-Type: application/sdp Content-Length: 135 v=0 o=user1 53655765 2353687637 IN IP4 172.30.110.5 s=- c=IN IP4 172.30.110.5 t=0 0 m=audio 6000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Maybe this is not possible to fix because of where topoh intercepts the messages (transparently to the config script writer) in relation to how the TM API is used to generate spoof requests. I just thought I would report it. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

9 years, 10 months

[tracker] Comment added: dialplan: allow match/subst rules with variables

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#429 - dialplan: allow match/subst rules with variables User who did this - Daniel-Constantin Mierla (miconda) ---------- I pushed to master branch an alternative implementation. It took a while to analyze the patch, being quite big -- there are couple of issues that could have been fixed (such as: module might be used by workers with negative rank, like timer or rpc -- there is a mi/rpc command for translation; return at first pv detected in a string to mark it as a string with vars; handling ending $ and allowing $$ in values), but the main issue is that cloning data in private memory is not really feasible always, because can be tons of dialplan db records. It would mean to have each process with a lot of pkg memory. Only parsing of values can be cached (to have the broken down list of static strings and variables). But given that parsed values have to be searched anyhow in a hash table, I expected to be no real performance difference than parsing every time. Evaluating the value at runtime, compiling and freeing PCRE have to be done for each attempt to match in dialplan rules. Considering the complexity of managing a private cache of parsed values, my patch is parsing the values at runtime, if they are detected to have variables at load time. In summary, the way it was done: - detection stops at first variable found in a value -- the function has been added in dialplan to cope properly with $ at the end of values - each value for match and subst is marked with a flag during load if there is a var inside it - when it is a var in a value that ends with a single $, in memory it is stored with $$ at the end (one more $ is added at the end), so at runtime the evaluation results in a single $. It avoids keeping other flags and doing more conditions at runtime to cope with single $ parsing - parsing of values to tokenize variables is done at runtime, with compile of PCRE and afferent freeing afterwards - there is a module parameter 'match_dynamic' that has to be set to 1 in order to enable this feature Let me know if anyone has comments on this approach, if not, I will close this item. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=429#comment1661 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

9 years, 11 months

contact with gruu and websockets

by Luis Azedo

Hi, when using sip.js websocket client i got this sequence REGISTER sip:mysip.com SIP/2.0 Via: SIP/2.0/WSS 1pds95dm7slp.invalid;branch=z9hG4bK1393343 Max-Forwards: 70 To: <sip:1096@mysip.com> From: <sip:1096@mysip.com>;tag=99i9ka9951 Call-ID: 1agj9ujebn5k2006qvosg7 CSeq: 82 REGISTER Authorization: Digest algorithm=MD5, username="1096", realm="mysip.com", nonce="VHiXFFR4legH+zdoSro9zybQQclvFtcR", uri="sip:mysip.com", response="2d9843d09d94f295d0ebfa323233783c" Contact: <sip:n7o5lk6u@1pds95dm7slp.invalid;transport=ws>;reg-id=1;+sip.instance="<urn:uuid:d68a53c4-37e7-4f5c-87f2-68d7cca14b93>";expires=600 Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE,MESSAGE Supported: path,gruu,100rel,outbound User-Agent: SIP.js/0.6.3 Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/WSS sg6h3at19h29.invalid;branch=z9hG4bK4876180;rport=65377;received=X.X.X.X To: <sip:1096@mysip.com>;tag=78e678a5264e254e660865f4df24edf3.e69b From: <sip:1096@mysip.com>;tag=j39lvle827 Call-ID: c0ofajiui4u2vtem662rdh CSeq: 86 REGISTER Contact: <sip:8umlvk34@sg6h3at19h29.invalid;transport=ws>;expires=600;pub-gruu="sip:1096@mysip.com;gr=urn:uuid:876de649-281f-4f7f-9a3e-7b2a7e11f3cc";temp-gruu="sip:uloc-5478bf26-4504-1-7fd4326@mysip.com;gr";+sip.instance="<urn:uuid:876de649-281f-4f7f-9a3e-7b2a7e11f3cc>";reg-id=1 Content-Length: 0 INVITE sip:2134@mysip.com SIP/2.0 Via: SIP/2.0/WSS sg6h3at19h29.invalid;branch=z9hG4bK1752419 Max-Forwards: 70 To: <sip:2134@mysip.com> From: <sip:1096@mysip.com>;tag=6vii55tc02 Call-ID: i3hndju3tgsge7ctnvo2 CSeq: 4782 INVITE Contact: <sip:1096@mysip.com;gr=urn:uuid:876de649-281f-4f7f-9a3e-7b2a7e11f3cc> Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE,MESSAGE Content-Type: application/sdp Supported: gruu,100rel,outbound User-Agent: SIP.js/0.6.3 Content-Length: 2585 i issued kamctl show to view the registered user AOR:: 1096(a)mysip.com Contact:: sip:8umlvk34@sg6h3at19h29.invalid;transport=ws Q= Expires:: 177 Callid:: c0ofajiui4u2vtem662rdh Cseq:: 86 User-agent:: SIP.js/0.6.3 Received:: sip:X.X.X.X:65377;transport=WS State:: CS_SYNC Flags:: 0 Cflag:: 6 Socket:: tls:Y.Y.Y.Y:8443 Methods:: 927 Ruid:: uloc-5478bf26-4504-1 Instance:: <urn:uuid:876de649-281f-4f7f-9a3e-7b2a7e11f3cc> Reg-Id:: 1 Last-Keepalive:: 1417200609 Last-Modified:: 1417200609 what is the best way to check if the INVITE is from a registered user and how to get usrloc properties for the registered user ? i tried this reg_fetch_contacts("location", "$fu", "caller"); $var(i) = 0; $var(found) = 0; $var(contact) = $(ct{nameaddr.uri}); while($var(found) == 0 && $var(i) < $(ulc(caller=>count))) { xlog("L_INFO", "$ci|log| checking against $(ulc(caller=>addr)[$var(i)])"); if($var(contact) == $(ulc(caller=>addr)[$var(i)])) { $var(found) = 1; $var(caller_idx) = $var(i); $var(userlocid) = $(ulc(caller=>ruid)[$var(i)]); } else $var(i) = $var(i) + 1; } the problem i see is that the INVITE Contact doesn't match the one registered. is this a problem with sip.js or am i missing something in kamailio.cfg or should kamailio save the contact info as sip.js is sending? Thank you

9 years, 11 months

kamcmd dialplan.dump

by Olle E. Johansson

Hi! I've written code that dumps one dialplan over the RPC interface. I think it's a useful addition. Ok to commit? Cheers, /O /usr/local/sbin/kamcmd dialplan.dump 100 { DPID: 100 ENTRIES: { ENTRY: { PRIO: 1 MATCHOP: 1 MATCHEXP: ^sip:edvina@.*$ MATCHLEN: 0 SUBSTEXP: ^(.*)$ REPLEXP: sip:pinefrog1@sipguru.no ATTRS: Pepparkaka blåbär } ENTRY: { PRIO: 1 MATCHOP: 1 MATCHEXP: ^sip:oej@.*$ MATCHLEN: 0 SUBSTEXP: ^(.*)$ REPLEXP: sip:pinefrog1@sipguru.no ATTRS: Pinefrogalias } ENTRY: { PRIO: 2 MATCHOP: 2 MATCHEXP: Blåbär.* MATCHLEN: 0 SUBSTEXP: Subst REPLEXP: Replace me ATTRS: hej attribute hey hey hey 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 } ENTRY: { PRIO: 20 MATCHOP: 0 MATCHEXP: Hej* MATCHLEN: 0 SUBSTEXP: REPLEXP: ATTRS: pelle } ENTRY: { PRIO: 25 MATCHOP: 1 MATCHEXP: MATCHLEN: 0 SUBSTEXP: REPLEXP: ATTRS: gurka } } }

9 years, 11 months

[tracker] Comment added: Some modules not being generated in RPM Build

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#488 - Some modules not being generated in RPM Build User who did this - Olle Johansson (oej) ---------- Can we statically link carrier route or does this break RPM guidelines? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=488#comment1710 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

9 years, 11 months

[tracker] User took ownership: tm module README lacks exported RPC commands section

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. Olle Johansson has taken ownership of the following task: FS#469 - tm module README lacks exported RPC commands section More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=469 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

9 years, 11 months

[tracker] Comment added: Configuration Directives: Five Syntaxes: kamailio.cfg:

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#320 - Configuration Directives: Five Syntaxes: kamailio.cfg: User who did this - Olle Johansson (oej) ---------- Important feedback. While we want the example config to actually show different ways of doing things, it can be very confusing. Now that we have multiple example configs we could try to clean up the basic one. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=320#comment1709 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

9 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2014