November 2014 - sr-dev - kamailio.org

[tracker] Assignee added: Assignment operators don't work
by sip-router 04 Sep '26

04 Sep '26

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#100 - Assignment operators don't work User who did this - Alex Hermann (axlh) http://sip-router.org/tracker/index.php?do=details&task_id=100 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.

11 10

git:master: pv: use suip2a(...) for $snd(..)
by Daniel-Constantin Mierla 04 Dec '25

04 Dec '25

Module: sip-router Branch: master Commit: e151a9e99b1fed7805eaed5d16ca3d6466e1f517 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e151a9e… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Mon Jul 18 22:37:07 2011 +0200 pv: use suip2a(...) for $snd(..) - fixes FS#140, reported by Klaus Darilion --- modules_k/pv/pv_branch.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules_k/pv/pv_branch.c b/modules_k/pv/pv_branch.c index a9dd1bc..4081429 100644 --- a/modules_k/pv/pv_branch.c +++ b/modules_k/pv/pv_branch.c @@ -395,7 +395,7 @@ int pv_get_sndto(struct sip_msg *msg, pv_param_t *param, (int)snd_inf->len); default: /* 0 - ip */ - s.s = su2a(snd_inf->to, sizeof(*snd_inf->to)); + s.s = suip2a(snd_inf->to, sizeof(*snd_inf->to)); s.len = strlen(s.s); return pv_get_strval(msg, param, res, &s); }

2 1

Outbound flow failure handling merged to master
by Hugh Waite 23 Nov '16

23 Nov '16

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.

4 11

Re: [sr-dev] Is there a sense in calling run_onsend() after the msg_send() function?
by Lucian Balaceanu 08 Sep '15

08 Sep '15

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

2 6

TM possible deadlock
by Jason Penton 09 Apr '15

09 Apr '15

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

2 16

topoh and locally-generated requests
by Alex Balashov 13 Jan '15

13 Jan '15

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/

2 2

[tracker] Comment added: dialplan: allow match/subst rules with variables
by sip-router 09 Dec '14

09 Dec '14

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.

2 1

contact with gruu and websockets
by Luis Azedo 04 Dec '14

04 Dec '14

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

2 1

kamcmd dialplan.dump
by Olle E. Johansson 01 Dec '14

01 Dec '14

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 } } }

2 1

[tracker] Comment added: Some modules not being generated in RPM Build
by sip-router 30 Nov '14

30 Nov '14

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.

1 0