sr-dev April 2015

sr-dev@lists.kamailio.org

36 participants
248 discussions

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

[kamailio] core parsing of SIP message failed errors (#107)
by jcohn25 26 Aug '15

26 Aug '15

I finally got everything working but see to consistently receive the following 3 errors (see below) over and over when a call is being collected? Versions: Homer 3.6 kamailio 4.3.0-dev4 Captagent 4.2.0 Any assistance would be appreciated. Errors: Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<HEP3#004>> Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9921]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (127.0.0.1:33264/1) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<HEP3#002Ü> Mar 8 22:04:47 ce-homer2 /usr/local/kamailio/sbin/kamailio[9922]: ERROR: <core> [receive.c:129]: receive_msg(): core parsing of SIP message failed (127.0.0.1:33264/1) --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/107

3 3

[kamailio] UAC trouble with REGISTER to provider (#140)
by ovoshlook 15 Jul '15

15 Jul '15

Hello. We use UAC for RGISTER some trunks After fiew days normally work we have an issue that UAC not respond to 401 reply with WWW-Authenticate with reREGISTER with WWW. We have only 2 packets- REGISTR and 401. IP 10.0.1.12.5068 > 1.2.3.4.5060: UDP, length 467 E.......@..F ...............REGISTER sip:provider.com SIP/2.0 Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bKdb22.edd7eac5000000000000000000000000.0 To: <sip:login@provider.com> From: <sip:login@provider.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-bfba CSeq: 10 REGISTER Call-ID: 5e171580088d170a-9952(a)10.0.1.12 Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0-dev5 (x86_64/linux)) Contact: <sip:login@my.service.com:5068> Expires: 360 IP 1.2.3.4.5060 > 10.0.1.12.5068: UDP, length 571 Q.......-. ........C.NSIP/2.0 401 Unauthorized Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bKdb22.edd7eac5000000000000000000000000.0;received=23.100.24.250 From: <sip:login@provider.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-bfba To: <sip:login@provider.com>;tag=as1550511c Call-ID: 5e171580088d170a-9952(a)10.0.1.12 CSeq: 10 REGISTER Server: FastTel SoftSwitch Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm="provider.com", nonce="109104dc" Content-Length: 0 We have another trunk and reREGISTER is correctly REGISTER sip:another_prov.com SIP/2.0 Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bK7fd1.3d7c2fd7000000000000000000000000.0 To: <sip:login_to_another_prov@another_prov.com> From: <sip:login_to_another_prov@another_prov.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-f8ba CSeq: 10 REGISTER Call-ID: 5e171580088d1edd-9952(a)10.0.1.12 Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0-dev5 (x86_64/linux)) Contact: <sip:login_to_another_prov@my.service.com:5068> Expires: 360 IP another_prov.com.5060 > 10.0.1.12.5068: UDP, length 544 E..<F...$. .6... ........(..SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bK7fd1.3d7c2fd7000000000000000000000000.0;rport=5068;received=23.100.28.126 To: <sip:login_to_another_prov@another_prov.com>;tag=04e2a294d0728b89107e081a19babab4.d569 From: <sip:login_to_another_prov@another_prov.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-f8ba CSeq: 10 REGISTER Call-ID: 5e171580088d1edd-9952(a)10.0.1.12 WWW-Authenticate: Digest realm="another_prov.com", nonce="VTifD1U4neNLMSYRoxNlOpD7hPSu3ET3" Server: kamailio (4.2.1 (x86_64/linux)) Content-Length: 0 IP 10.0.1.12.5068 > another_prov.com.5060: UDP, length 690 E...uT..@... ...6...........REGISTER sip:another_prov.com SIP/2.0 Via: SIP/2.0/UDP my.service.com:5068;branch=z9hG4bK8fd1.ea73d070000000000000000000000000.0 To: <sip:login_to_another_prov@another_prov.com> From: <sip:login_to_another_prov@another_prov.com>;tag=6a39af2190f8b2c99cc63bfeb3a3959c-f8ba CSeq: 11 REGISTER Call-ID: 5e171580088d1edd-9952(a)10.0.1.12 Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.3.0-dev5 (x86_64/linux)) Contact: <sip:login_to_another_prov@my.service.com:5068> Expires: 360 Authorization: Digest username="login_to_another_prov", realm="another_prov.com", nonce="VTifD1U4neNLMSYRoxNlOpD7hPSu3ET3", uri="sip:another_prov.com", response="2ee14a437173700e88056279b854749f", algorithm=MD5 --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/140

2 3

[kamailio] Unquoted IPv6 Contact header alias parameter causes issues with Asterisk (PJSIP) & TOPOH module (#120)
by Anthony Messina 15 Jul '15

15 Jul '15

When using Kamailio from the master branch, I'm encountering an issue where IPv6 contact address aliases that are added via ```set_contact_alias()``` for WebSocket connections (for example) are unquoted and create problems for Asterisk: ``` pjsip:0 <?>: sip_transport. Error processing 3633 bytes packet from UDP 10.0.0.1:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 11 col 129: ``` and TOPOH garbles the Request-URI when processing the ACK: ``` WARNING: sanity [sanity.c:236]: check_ruri_scheme(): failed to parse request uri [�a�{1me▒s�na@50�9��1.�8:�2v0;i��a��=11>7�n7x>10O�2v0~1] ``` I have tested this with CSipSimple nightly branch (PJSIP) Asterisk 13.2.0 (PJSIP), Google Chrome 41.0.2272.118, and Firefox 37 and all fail to handle the Contact alias parameter properly. An example of an invite that shows this issue follows (this INVITE is without TOPOH on). ``` INVITE sip:testuser@example.com SIP/2.0 Record-Route: <sip:10.0.0.1;r2=on;lr=on;ftag=t5r2736hf9;nat=yes> Record-Route: <sip:[2001:db8::98]:5061;transport=ws;r2=on;lr=on;ftag=t5r2736hf9;nat=yes> Via: SIP/2.0/UDP 10.0.0.1;branch=z9hG4bKa3e8.2bb6508fbc0cf8cc55c1eb6c0eca0b38.0 Via: SIP/2.0/WSS 2e6orc23ptjv.invalid;rport=43691;received=2001:db8::99;branch=z9hG4bK450538 Max-Forwards: 69 To: <sip:testuser@example.com> From: "WS Test User 1" <sip:wstest1@example.com>;tag=t5r2736hf9 Call-ID: uugmpjgjpoklrnf0um56 CSeq: 7244 INVITE Contact: <sip:wstest1@example.com;gr=urn:uuid:2e54e8a2-66e4-433a-a024-b57f3665a44b;alias=[2001:db8::99]~43691~6> Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE Content-Type: application/sdp Supported: gruu,outbound User-Agent: SIP.js/0.6.4 Content-Length: 2768 v=0 o=- 867554869709517848 2 IN IP4 10.0.0.1 s=- t=0 0 a=msid-semantic: WMS livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH m=audio 30158 RTP/SAVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 10.0.0.1 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:1444733772 cname:CuBdEZ9bIWQc1sE+ a=ssrc:1444733772 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH ebd0066b-73b9-467c-b696-36e0fa7d72b7 a=ssrc:1444733772 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:1444733772 label:ebd0066b-73b9-467c-b696-36e0fa7d72b7 a=sendrecv a=rtcp:30159 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/fmyETo1BwAlupltb64sy5Za6e37BW0p5jMmvqHU a=setup:actpass a=fingerprint:sha-1 76:27:60:1E:64:94:B4:6E:8A:64:72:2D:41:2C:B8:F3:FF:4C:1D:56 a=ice-ufrag:U4XlaM4U a=ice-pwd:HqnTPTU5DY3j1yB4XVEL9rs1tn a=candidate:vVzo18e51E8EXCNy 1 UDP 2130706431 10.0.0.1 30158 typ host a=candidate:vVzo18e51E8EXCNy 2 UDP 2130706430 10.0.0.1 30159 typ host a=candidate:xCpWH2paVucFSQXn 1 UDP 2130706175 2001:db8::1 30158 typ host a=candidate:xCpWH2paVucFSQXn 2 UDP 2130706174 2001:db8::1 30159 typ host m=video 30196 RTP/SAVP 100 116 117 96 c=IN IP4 10.0.0.1 a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=rtpmap:96 rtx/90000 a=fmtp:96 apt=100 a=ssrc-group:FID 616715905 3177427003 a=ssrc:616715905 cname:CuBdEZ9bIWQc1sE+ a=ssrc:616715905 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:616715905 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:616715905 label:bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:3177427003 cname:CuBdEZ9bIWQc1sE+ a=ssrc:3177427003 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:3177427003 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:3177427003 label:bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=sendrecv a=rtcp:30197 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qQRmOwum0YFHgKKzt2dRX0uAQhSwlmxscI3P3JUI a=setup:actpass a=fingerprint:sha-1 76:27:60:1E:64:94:B4:6E:8A:64:72:2D:41:2C:B8:F3:FF:4C:1D:56 a=ice-ufrag:ISaptX08 a=ice-pwd:mxP343kHexU8SwtbCeRj4WyMNI a=candidate:vVzo18e51E8EXCNy 1 UDP 2130706431 10.0.0.1 30196 typ host a=candidate:vVzo18e51E8EXCNy 2 UDP 2130706430 10.0.0.1 30197 typ host a=candidate:xCpWH2paVucFSQXn 1 UDP 2130706175 2001:db8::1 30196 typ host a=candidate:xCpWH2paVucFSQXn 2 UDP 2130706174 2001:db8::1 30197 typ host ``` I believe that the Contact header alias parameter might need quotes in order to properly handle the bracketed IPv6 alias address, something like the following, but unfortunately I haven't been able to find evidence to be certain that this is the fix, though I do notice that parameters in headers with special characters like brackets are often quoted. ``` Contact: <sip:wstest1@example.com;gr=urn:uuid:2e54e8a2-66e4-433a-a024-b57f3665a44b;alias="[2001:db8::99]~43691~6"> ``` --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120

2 7

[kamailio] Errors work BLF modules pua and presence (#104)
by klistrod 15 Jul '15

15 Jul '15

Errors work BLF modules pua and presence: loadmodule "presence.so" loadmodule "presence_xml.so" loadmodule "presence_dialoginfo.so" loadmodule "pua.so" loadmodule "pua_dialoginfo.so" modparam("presence", "db_url", DBURL) modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) modparam("presence_dialoginfo", "force_single_dialog", 1) 5(18085) ERROR: presence [publish.c:139]: msg_presentity_clean(): event not found 5(18085) ERROR: db_mysql [km_dbase.c:123]: db_mysql_submit_query(): driver error on query: Duplicate entry 'a.1425449702.18081.57.5---' for key 'pua_idx' 5(18085) ERROR: <core> [db_query.c:335]: db_do_update(): error while submitting query 5(18085) ERROR: pua [pua.c:1079]: db_update(): while updating in database --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/104

2 3

[kamailio] lookup_branches and rtpengine_manage (#53)
by ovoshlook 04 Jun '15

04 Jun '15

Hello. I need parallel forking calls with the same username. (Call to all contacts with name for example User123), my endpoints may be WebSocket based and standart UDP endpoints. And I use rtpengine_manage for managing calls wor webphones and standart softh/hard phones. I get all contacts manually and than at the branch route set rtpengine_manage settings for every call. It works fine but it works for one kamailio server. When I use 2 kamailio servers as load balansers Server that handle call get all endpoints from location but call to only one, that registred only at ths server for example I call user123 I have 3 contacts user123(a)1.2.3.4 - was registered at kamailio 1 user123(a)3.2.1.4 - was registered at kamailio 2 user123(a)4.3.2.1 - was registered at kamailio 1 So if call goes through kamailio 1 it call only to user123(a)1.2.3.4 and user123(a)4.3.2.1 I use this settings for usrloc at 2 kamailios to share all table between 2 servers modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 3) modparam("usrloc", "user_column", "username") modparam("usrloc", "contact_column", "contact") modparam("usrloc", "expires_column", "expires") modparam("usrloc", "q_column", "q") modparam("usrloc", "callid_column", "callid") modparam("usrloc", "cseq_column", "cseq") modparam("usrloc", "methods_column", "methods") modparam("usrloc", "cflags_column", "cflags") modparam("usrloc", "user_agent_column", "user_agent") modparam("usrloc", "received_column", "received") modparam("usrloc", "socket_column", "socket") modparam("usrloc", "path_column", "path") modparam("usrloc", "ruid_column", "ruid") modparam("usrloc", "instance_column", "instance") modparam("usrloc", "use_domain", 1) and this code for calling them [GET_CONTACTS] { sql_query("ca", "select contact from location where username='$tU'", "ra"); xlog("rows: $dbr(ra=>rows) cols: $dbr(ra=>cols)\n"); if($dbr(ra=>rows)>0){ $var(i)=0; while($var(i)<$dbr(ra=>rows)){ xlog("L_INFO","SQL query return contact {$dbr(ra=>[$var(i),0])} for {$tU} at step {$var(i)}\n"); if ($dbr(ra=>[$var(i),0])=~"transport=ws"){ xlog("L_INFO", "This is a Websocket call to endpoint"); sql_pvquery("ca", "select received from location where contact='$dbr(ra=>[$var(i),0])'","$var(recieved)"); $du=$var(recieved); xlog("L_INFO","SQL query return recieved {$var(recieved)} for {$tU}. Destination is {$du}\n"); append_branch("sip:$tU@$(du{s.select,1,:})"); } else { xlog("L_INFO", "This is a classic UDP call to endpoint"); $var(recieved)=''; sql_pvquery("ca", "select received from location where contact='$dbr(ra=>[$var(i),0])'","$var(recieved)"); xlog("L_INFO", "SQL query return RECIEVED {$var(recieved)}"); if ($var(recieved)==0){ xlog("L_INFO", "Recieved string is EMPTY"); $du="sip:"+$(dbr(ra=>[$var(i),0]){s.select,1,@}); } else { xlog("L_INFO", "Recieved string is {$var(recieved)}"); $du=$var(recieved); } $var(UDP_contact)="sip:"+$(dbr(ra=>[$var(i),0]){s.select,1,@}); append_branch("sip:$tU@$(du{s.select,1,:})"); xlog("L_INFO","Classic Destination URI is {$dbr(ra=>[$var(i),0])} for {$tU}}. Destination is {$du}\n"); } $var(i) = $var(i) + 1; } } t_on_branch("1"); return; } } } branch_route[1]{ if($du=~"transport=ws"){ xlog("L_INFO","Websocket Branch is {$du} for {$tU}\n"); rtpengine_manage("internal extenal force trust-address replace-origin replace-session-connection ICE=force RTP/SAVPF"); t_on_reply("REPLY_FROM_WS"); } else{ xlog("L_INFO","UDP Branch is {$du)} for {$tU}\n"); rtpengine_manage("replace-origin replace-session-connection ICE=remove RTP/AVP"); t_on_reply("MANAGE_CLASSIC_REPLY"); } } When it try to branch endpoint without registration at server that handle call I get errors that tm module can not build Via header *via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found* *ERROR: <core> [msg_translator.c:1725]: build_req_buf_from_sip_req(): could not create Via header* *ERROR: <core> [forward.c:607]: forward_request(): ERROR: forward_request: building failed* UDP calls get errors something like above (sorry than can not share error code, This situation not often). So I think I have this trouble because I use manually handling call and tried to substitute to lookup_branches function. but I have no Idea how to set rtpengine_manage paraments for each endpoint depending this is websocket or standart call. IF there is write problem for callings thhrough 2 kamailios as load balansers please let me know about how to set rtpengine_manage parametrs wor endpoints for every fork. If not- can you tell me how I can call to all endpoints endepending of registration server (kamailio 1 or 2). But with another side I can not understand why kamailio 2 don't see registrations at kamailio1 (or 1 from 2). May be this is trouble of usrloc module. That's why I write this problem here. Thanks. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/53

3 3

[kamailio] introduce RUN_DIR (#80)
by Victor Seva 03 Jun '15

03 Jun '15

In order to get rid of any occurrence of ```/tmp``` in modules, introduce a ```RUN_DIR``` make option and every module should honor it default could be ```/var/run/$(NAME)``` Related to #48 --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/80

2 3

[kamailio] multiple /tmp file vulnerabilities (#48)
by Victor Seva 21 May '15

21 May '15

Reported by: Helmut Grohne <helmut(a)subdivi.de> The kamailio package now installs /etc/kamailio/kamailio-basic.cfg which can be selected via the CFGFILE= setting in /etc/default/kamailio. The configuration contains: ``` modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") ``` This setting is insecure and may allow local users to elevate privileges to the kamailio user. The issue extends to kamailio-advanced.cfg. It seems that this is due to an incomplete fix of #712083. Looking further, the state of /tmp file vulnerabilities in kamailio looks worrisome. Most of the results of the following command (to be executed in the kamailio source) are likely vulnerable if executed: ``` grep '/tmp/[a-z0-9_.-]\+$\$\$$\?$[" ]\|$$' -r . ``` Granted, some of the results are examples, documentation or obsolete. But quite a few reach the default settings: * kamcmd defaults to connecting to unixs:/tmp/kamailio_ctl. * The kamailio build definitely is vulnerable as can be seen in utils/kamctl/Makefile. More research clearly is required here. Given these findings, the security team may want to veto the inclusion of kamailio in a stable release, which would be very unfortunate as kamailio is quite a unique piece of software with little competitors in its field. Helmut https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775681 --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/48

8 15

[kamailio] kamailio doesn't provide number of registered users stat when usrloc in db_mode=3 (#113)
by mading087 21 May '15

21 May '15

Running latest 4.2 with usrloc in db_mode=3. It seems "kamctl stats usrloc" or "kamctl ul show" always shows 0 registered users even when there are registered users (location table has entries). This looks like a bug? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/113

8 11

Crash bug
by Alex Balashov 11 May '15

11 May '15

Hello, I'm running kamailio:4.2:df86f2a9a09339687af5914b85fe8bd8f8f1f575 and am getting a periodic crash, once every few days, in response to a CANCEL message. The basic back trace is like this: (gdb) where #0 0x000000000044fed2 in del_nonshm_lump (lump_list=0x7f48f5681440) at data_lump.c:677 #1 0x00007f48f5404a15 in free_faked_req (faked_req=0x7f48f5680ea0, t=0x7f46ee6faeb0) at t_reply.c:975 #2 0x00007f48f5405bdf in run_failure_handlers (t=0x7f46ee6faeb0, rpl=0xffffffffffffffff, code=487, extra_flags=0) at t_reply.c:1061 #3 0x00007f48f54084e4 in t_should_relay_response (Trans=0x7f46ee6faeb0, new_code=487, branch=0, should_store=0x7fffce5605e0, should_relay=0x7fffce5605e4, cancel_data=0x7fffce5606b0, reply=0xffffffffffffffff) at t_reply.c:1406 #4 0x00007f48f540b045 in relay_reply (t=0x7f46ee6faeb0, p_msg=0xffffffffffffffff, branch=0, msg_status=487, cancel_data=0x7fffce5606b0, do_put_on_wait=1) at t_reply.c:1809 #5 0x00007f48f5386832 in cancel_branch (t=0x7f46ee6faeb0, branch=0, reason=0x0, flags=10) at t_cancel.c:276 #6 0x00007f48f53aff4a in e2e_cancel (cancel_msg=0x7f48f68d69d8, t_cancel=0x7f46ee8d9c30, t_invite=0x7f46ee6faeb0) at t_fwd.c:1373 #7 0x00007f48f53b4bd0 in t_relay_cancel (p_msg=0x7f48f68d69d8) at t_fwd.c:1967 #8 0x00007f48f53deaa7 in w_t_relay_cancel (p_msg=0x7f48f68d69d8, _foo=0x0, _bar=0x0) at tm.c:1743 #9 0x000000000041d364 in do_action (h=0x7fffce560fc0, a=0x7f48f6689f70, msg=0x7f48f68d69d8) at action.c:1088 #10 0x0000000000429a7a in run_actions (h=0x7fffce560fc0, a=0x7f48f6689f70, msg=0x7f48f68d69d8) at action.c:1583 #11 0x000000000042a0df in run_actions_safe (h=0x7fffce5622b0, a=0x7f48f6689f70, msg=0x7f48f68d69d8) at action.c:1648 #12 0x0000000000541158 in rval_get_int (h=0x7fffce5622b0, msg=0x7f48f68d69d8, i=0x7fffce561498, rv=0x7f48f668a1e0, cache=0x0) at rvalue.c:924 #13 0x0000000000545390 in rval_expr_eval_int (h=0x7fffce5622b0, msg=0x7f48f68d69d8, res=0x7fffce561498, rve=0x7f48f668a1d8) at rvalue.c:1918 #14 0x0000000000545786 in rval_expr_eval_int (h=0x7fffce5622b0, msg=0x7f48f68d69d8, res=0x7fffce561920, rve=0x7f48f668a948) at rvalue.c:1926 #15 0x000000000041ce4e in do_action (h=0x7fffce5622b0, a=0x7f48f668c260, msg=0x7f48f68d69d8) at action.c:1064 #16 0x0000000000429a7a in run_actions (h=0x7fffce5622b0, a=0x7f48f6689808, msg=0x7f48f68d69d8) at action.c:1583 #17 0x000000000041d2cd in do_action (h=0x7fffce5622b0, a=0x7f48f668c960, msg=0x7f48f68d69d8) at action.c:1079 #18 0x0000000000429a7a in run_actions (h=0x7fffce5622b0, a=0x7f48f667c628, msg=0x7f48f68d69d8) at action.c:1583 #19 0x000000000042a1a7 in run_top_route (a=0x7f48f667c628, msg=0x7f48f68d69d8, c=0x0) at action.c:1669 #20 0x0000000000507e1a in receive_msg ( buf=0xa6f760 "CANCEL sip:yyy@xxx:5060 SIP/2.0\r\nVia: SIP /2.0/UDP xxx:5060;branch=z9hG4bK08f.3dc6f0e1.0\r\nFrom: \"yyy\" <sip:yyy@xxx>;tag=D78eD8FB3SDgc\r\nCall-ID: e5e48a99-48dd-1233-96b7-782bcb13da6a\r\nTo: <sip:xxx@xxx:5060>\r\nCSeq: 73049624 CANCEL\r\nMax-Forwards: 32\r\nUser-Agent: OpenSIPS (1.9.1-notls (x86_64/linux))\r\nContent-Length: 0\r\n\r\n", len=394, rcv_info=0x7fffce5625a0) at receive.c:216 #21 0x00000000006074ae in udp_rcv_loop () at udp_server.c:521 #22 0x00000000004a5f0b in main_loop () at main.c:1629 #23 0x00000000004ab8bf in main (argc=11, argv=0x7fffce5629c8) at main.c:2578 I'll send a 'thread apply all bt full' privately due to the amount of private addresses in there, but a quick glance suggests a possible problem is here: #5 0x00007f48f5386832 in cancel_branch (t=0x7f46ee6faeb0, branch=0, reason=0x0, flags=10) at t_cancel.c:276 cancel = 0x1 <Address 0x1 out of bounds> len = 32584 crb = 0x7f46ee6fb0b0 irb = 0x7f46ee6fb028 ret = 1 tmp_cd = {cancel_bitmap = 0, reason = {cause = 0, u = {text = { s = 0x0, len = 0}, e2e_cancel = 0x0, packed_hdrs = {s = 0x0, len = 0}}}} pcbuf = 0x7f46ee6fb0c0 __FUNCTION__ = "cancel_branch" #6 0x00007f48f53aff4a in e2e_cancel (cancel_msg=0x7f48f68d69d8, t_cancel=0x7f46ee8d9c30, t_invite=0x7f46ee6faeb0) at t_fwd.c:1373 cancel_bm = 1 reason = 0x0 free_reason = 0 i = 0 lowest_error = 0 ret = 32584 tmcb = {req = 0x137f66ce710, rpl = 0x7f48f68d69d8, param = 0xf48ab828, code = -158504488, flags = 32584, branch = 0, t_rbuf = 0xf80f668f9a0, dst = 0xce5622b0, send_buf = { s = 0x1ffffffff <Address 0x1ffffffff out of bounds>, len = -304107664}} __FUNCTION__ = "e2e_cancel" #7 0x00007f48f53b4bd0 in t_relay_cancel (p_msg=0x7f48f68d69d8) at t_fwd.c:1967 t_invite = 0x7f46ee6faeb0 t = 0x7f46ee8d9c30 ret = -323705680 new_tran = 1 Thanks, -- Alex -- Alex Balashov - Principal Evariste Systems LLC 303 Perimeter Center North Suite 300 Atlanta, GA 30346 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/

3 42

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2015