Re: [SR-Users] Branching GIT repository for 5.2.x release series
Very good Dear Daniel but The sooner the better.thank you very much for support Best Regards Iman Mohammadi On Fri, Nov 2, 2018, 15:05 Daniel-Constantin Mierla Hello, > > if there is no other opinion, I am considering to create git branch 5.2 > at the beginning of next week (likely on Monday evening), to be used for > 5.2.x release series. > > From that moment, the master branch can get new features and the > appropriate bug fixes have to be backported to branch 5.2 as well. > > With this step, the first release in 5.2.x series, respectively v5.2.0, > should be out in about 2-3 weeks. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference -- www.kamailioworld.com > Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Crash ims_diameter_server
That's Great,Thank you very much Dear Carsten Best Regards Iman Mohammadi On Fri, Nov 2, 2018, 10:31 Carsten Bock Hi, > > my colleague implemented a fix for this some months ago, but we haven't > pushed it upstream. I will talk to him to fix this in the official Repo > also. > > Thanks, > Carsten > -- > > Carsten Bock > CEO (Geschäftsführer) > > ng-voice GmbH > Millerntorplatz 1 > 20359 Hamburg / Germany > > http://www.ng-voice.com > mailto:cars...@ng-voice.com > > Office +49 40 5247593-40 > Fax +49 40 5247593-99 > > Sitz der Gesellschaft: Hamburg > Registergericht: Amtsgericht Hamburg, HRB 120189 > Geschäftsführer: Carsten Bock > Ust-ID: DE279344284 > > Hier finden Sie unsere handelsrechtlichen Pflichtangaben: > http://www.ng-voice.com/imprint/ > > > Am Do., 1. Nov. 2018 um 06:55 Uhr schrieb Iman Mohammadi < > iman.mohammadi.tele...@gmail.com>: > >> Hi >> I tried it before,it must be list for our purpose,int or string doesnt >> meet our purpose >> >> thanks >> >> On Thu, Nov 1, 2018 at 9:00 AM Mojtaba wrote: >> >>> Hi. >>> There are some reason for this issue. >>> The three nested json is not reason for crash ims_diameter. >>> Let try this senario. >>> Chenge type of the last indoor level of json from List to other >>> type(like int or ...). >>> Then check the lamailio is crashed or not? >>> With Regards.Mojtaba >>> >>> >>> On Wed, 31 Oct 2018 21:56 Iman Mohammadi, < >>> iman.mohammadi.tele...@gmail.com> wrote: >>> When the below format is sent from rest , kamailio crashes List[{ List[{ List[{ ]} ]} ]} (Json with 3 nested lists), With 2 lists it works properly, When diameter is translated to json with 3 lists by this module it also works properly, Json format is correct too. gdb: gdb) bt full #0 0x7f5e23c4a11e in diameterserver_add_avp (m=0x0, d=0x7f5e1b5c2240 "", len=12, avp_code=431, flags=64, vendorid=0, data_do=2, func=0x7f5e23c51d6c <__FUNCTION__.20148> "parselist") at avp_helper.c:208 avp = 0x7f5e1b5c3bd0 __FUNCTION__ = "diameterserver_add_avp" #1 0x7f5e23c4d0c8 in parselist (response=0x0, list=0x7fff9f21a8d0, item=0x11b67d0, level=2) at avp_helper.c:309 i = 1 flags = 64 x = "p\250!\237" avp_list = {head = 0x0, tail = 0x0} avp_list_s = {s = 0x7f5e1b5c2240 "", len = 12} __FUNCTION__ = "parselist" #2 0x7f5e23c4cffc in parselist (response=0x7f5e1b5c3ab8, list=0x0, item=0x11b6550, level=1) at avp_helper.c:304 subitem = 0x11b67d0 i = 0 flags = 64 x = "\000\000\000" avp_list = {head = 0x0, tail = 0x0} avp_list_s = {s = 0x7fff9f21a8f0 "@\251!\237\377\177", len = 600070897} __FUNCTION__ = "parselist" #3 0x7f5e23c4db3a in addAVPsfromJSON (response=0x7f5e1b5c3ab8, json=0x7f5e23e53950 ) at avp_helper.c:349 subitem = 0x11b6550 i = 4 __FUNCTION__ = "addAVPsfromJSON" root = 0x11b4210 #4 0x7f5e23c3fbdb in callback_cdp_request (request_in=0x7f5e1b5c19b0, param=0x0) at ims_diameter_server.c:193 fmsg = 0xab7840 <_faked_msg> backup_rt = 1 ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = {{__jmpbuf = {1, -5713032302318786866, 7971288, 7971288, 140042162528420, 0, -5713032302339758386, 5712822384154044110}, __mask_was_saved = 0, __saved_mask = {__val = { 140735863172072, 127, 0, 140042162532340, 140042389578761, 4222451713, 140042162532340, 140042162532340, 140042162532340, 140042162532340, 140042162532358, 140042162532467, 140042162532340, 140042162532467, 0, 0} response = 0x7f5e1b5c3ab8 __FUNCTION__ = "callback_cdp_request" #5 0x7f5e24a705c0 in api_callback (p=0x7f5e1b598f50, msg=0x7f5e1b5c19b0, ptr=0x0) at api_process.c:83 t = 0x7f5e1b598f50 auto_drop = 32767 h = 0x7f5e1b5b3358 ---Type to continue, or q to quit--- x = {type = (unknown: 2669784000), handler = {requestHandler = 0x7f5e23c3eed1 , responseHandler = 0x7f5e23c3eed1 }, param = 0x3ee9f21ac10, next = 0x7f5e1b5988b8, prev = 0x19f210069} type = REQUEST_HANDLER rsp = 0x7f5e1b5c19b0 __FUNCTION__ = "api_callback" #6 0x7f5e24a857d7 in worker_process (id=5) at worker.c:346 t = {p = 0x7f5e1b598f50, msg = 0x7f5e1b5c19b0} cb = 0x7f5e1b59df30 r = 128 __FUNCTION__ = "worker_process" #7 0x7f5e24a62a8e in diameter_peer_start (blocking=0) at diameter_peer.c:242 pid = 0 k = 5 p
[SR-Users] Branching GIT repository for 5.2.x release series
Hello, if there is no other opinion, I am considering to create git branch 5.2 at the beginning of next week (likely on Monday evening), to be used for 5.2.x release series. From that moment, the master branch can get new features and the appropriate bug fixes have to be backported to branch 5.2 as well. With this step, the first release in 5.2.x series, respectively v5.2.0, should be out in about 2-3 weeks. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Store TLS handshake date from Kamailio to an external DB
Hello , Thanks for you answer. I re-formulate my questions: - How can I tell Kamailio to store the TLS Data in an external DB? - How can I configure Kamailio to read (without re-use) data from DB and verify if there was a TLS session established before? Many Thanks in advance. Best regards, Toffi Am Donnerstag, 1. November 2018, 12:10:57 MEZ hat Daniel Tryba Folgendes geschrieben: On Thu, Nov 01, 2018 at 09:20:46AM +, Toffi Bossol wrote: > my use case will be: > > - We use two Kamailio instances (A and B) > > - A Client registers to a Kamailio A using TLS (SIP over TLS). The TLS >session data shall be stored into an external DB. > - Kamailio A is now unreachable. > - The client sends a register to Kamailio B over TLS. > - Kamailio B shall look into the external DB and checks that there is >already a TLS session data and can reuse it. In order to make a SIP over TLS handshake, there has to be a new handshake. So the old data is stale and unusable. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Diversion headers access and message too long error
Thanks for your help Henning. The error was on Asterisk, now everything is working like a charm. On Thu, Nov 1, 2018 at 11:29 AM Henning Westerholt wrote: > Am Donnerstag, 1. November 2018, 11:18:37 CET schrieb Joan Salvatella: > > Thanks for your quick response. Kamailio is complaining about a too long > > SIP message so migrating to TCP makes sense (I hadn't thought about it). > > > > I have enabled TCP in kamailio.cfg: > > disable_tcp=no > > > > I am using the dispatchers module to identify the gateway endpoints and I > > have updated it accordingly: > > > > 1 sip:10.0.1.69:5080;transport=tcp > > > > and in my invite resolver I am forcing the sending socket to be tcp as > > well. > > [..] > >$fs = "tcp:PRIVATE_IP:5080"; > > [..] > > Are there any resources that I can check to make sure that I am not > missing > > anything? Since this is not working, I am suspecting it is related with > the > > Asterisk side of things but that should be handled in another mail list. > > > [..] > > Hello Joan, > > on a first sight it looks fine. Do you get an error from the asterisk > side? > Then indeed it would be good to ask on the asterisk user list about that. > > If you get also errors in the Kamailio log, we would need more details > about > this to continue here. > > Best regards, > > Henning > > -- > Henning Westerholt - https://skalatan.de/blog/ > Kamailio services - https://skalatan.de/services > Kamailio security assessment - https://skalatan.de/de/assessment > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Diversion headers access and message too long error
Hello Henning, Thanks for your quick response. Kamailio is complaining about a too long SIP message so migrating to TCP makes sense (I hadn't thought about it). I have enabled TCP in kamailio.cfg: disable_tcp=no I am using the dispatchers module to identify the gateway endpoints and I have updated it accordingly: 1 sip:10.0.1.69:5080;transport=tcp and in my invite resolver I am forcing the sending socket to be tcp as well. route[INVITE_RESOLVER] { xlog("L_DBG", "[R-INVITE-RESOLVER:$ci] Entering INVITE resolver\n"); route(CHECK_DID); # Use main asterisk dispatcher set $var(disp_set) = 1; # Store diversion reason redis_cmd("abn", "SET $fd-div $dir", "r"); # Trim SIP messages of useless headers remove_hf_re("^X-"); $fs = "tcp:PRIVATE_IP:5080"; xlog("L_INFO", "[R-INVITE-RESOLVER:$ci] Processing dispatcher set $var(disp_set)\n"); if(!ds_select_domain("$var(disp_set)", "4")) { # This should only happen if the route set is empty. sl_send_reply("503", "Out of Gateways"); xlog("L_ERR", "[R-INVITE-RESOLVER:$ci] !> " "No gateways available!\n"); exit; } xlog("L_INFO", "[R-INVITE-RESOLVER:$ci] -> " "Selected gateway: $rd:$rp\n"); t_on_failure("DISPATCHER_ROLLOVER"); route(INVITE_POSTROUTE); } Are there any resources that I can check to make sure that I am not missing anything? Since this is not working, I am suspecting it is related with the Asterisk side of things but that should be handled in another mail list. Thanks for your support, On Tue, Oct 30, 2018 at 9:29 PM Henning Westerholt wrote: > Am Montag, 29. Oktober 2018, 17:27:27 CET schrieb Joan Salvatella: > > [..] > >- *Message Too Long Error:* Since Twilio uses long URIs to define its > >resources, the SIP messages being handled by Kamailio are sometimes > too > > big and generate a "Message Too Long error". I have been able to > > temporarily patch this removing unused headers using remove_hf_re and > > remove_hf but it still fails from time to time. Is there a way to split > the > > UDP packet to mitigate this issue? or what other options could be > > considered? > > Hello Joan, > > I don't understand the error description completely. Does Kamailio > complain > about a to long header field or a too long SIP message? > > About the question regarding the options - have you thought about using > TCP? > > Best regards, Henning > > -- > Henning Westerholt - https://skalatan.de/blog/ > Kamailio security assessment - https://skalatan.de/de/assessment > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Fwd: Fw: kamailio5.0.0 support presence
Hi Kamailio expert, i want to use kamailio to simulate presence server, after receive subscribe, i need kamailio reply 200 OK, and then send out Notify, but now, it just forward the subscribe, don't reply, could you help check my cfg? thanks in advance. BRs kamailio.cfg Description: Binary data ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Installing rtpengine from RPM on CentOS
Hello. Rtpengine has spec file here https://github.com/sipwise/rtpengine/tree/master/el/rtpengine.spec It is perfectly builds with this spec on Centos 7. In spec file I added variable %global with_transcoding 1 If you don't need transcoding change it to 0. So you don't need any special dependencies to build it. If you need transcoding, leave it 1. Then you'll need to find or to build some ffmpeg libs. -- Best regards Alexey Vasilyev чт, 1 нояб. 2018 г. в 15:01, Pan Christensen : > That’s the kamailio module to control rtpengine, not the rtpengine itself. > > > > > > *Pan B. Christensen * > Developer > > Phonect AS > > Mail: pan.christen...@phonect.no > + 47 41 88 88 00 > > [image: mail_footer] > > > > *From:* sr-users * On Behalf Of *Sergey > Safarov > *Sent:* torsdag 1. november 2018 13:37 > *To:* Kamailio (SER) - Users Mailing List > *Subject:* Re: [SR-Users] Installing rtpengine from RPM on CentOS > > > > This is packaged in main kamailio rpm package > > https://github.com/kamailio/kamailio/blob/master/pkg/kamailio/obs/kamailio.spec#L1453-L1454 > > > > чт, 1 нояб. 2018 г. в 14:33, Pan Christensen : > > Hello! > > > > According to > https://github.com/sipwise/rtpengine/blob/master/el/README.el.md , we > should be able to install rtpengine from a CentOS repository using yum. > We’re unable to find the packages. Any suggestions? > > > > > > *Pan B. Christensen * > Developer > > Phonect AS > > Mail: pan.christen...@phonect.no > + 47 41 88 88 00 > > [image: mail_footer] > > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Crash ims_diameter_server
Hi, my colleague implemented a fix for this some months ago, but we haven't pushed it upstream. I will talk to him to fix this in the official Repo also. Thanks, Carsten -- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Millerntorplatz 1 20359 Hamburg / Germany http://www.ng-voice.com mailto:cars...@ng-voice.com Office +49 40 5247593-40 Fax +49 40 5247593-99 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/ Am Do., 1. Nov. 2018 um 06:55 Uhr schrieb Iman Mohammadi < iman.mohammadi.tele...@gmail.com>: > Hi > I tried it before,it must be list for our purpose,int or string doesnt > meet our purpose > > thanks > > On Thu, Nov 1, 2018 at 9:00 AM Mojtaba wrote: > >> Hi. >> There are some reason for this issue. >> The three nested json is not reason for crash ims_diameter. >> Let try this senario. >> Chenge type of the last indoor level of json from List to other type(like >> int or ...). >> Then check the lamailio is crashed or not? >> With Regards.Mojtaba >> >> >> On Wed, 31 Oct 2018 21:56 Iman Mohammadi, < >> iman.mohammadi.tele...@gmail.com> wrote: >> >>> When the below format is sent from rest , kamailio crashes >>> >>> List[{ >>> List[{ >>> List[{ >>> ]} >>> ]} >>> ]} >>> (Json with 3 nested lists), >>> With 2 lists it works properly, >>> When diameter is translated to json with 3 lists by this module it also >>> works properly, >>> Json format is correct too. >>> >>> gdb: >>> >>> gdb) bt full >>> #0 0x7f5e23c4a11e in diameterserver_add_avp (m=0x0, d=0x7f5e1b5c2240 >>> "", len=12, avp_code=431, flags=64, vendorid=0, data_do=2, >>> func=0x7f5e23c51d6c <__FUNCTION__.20148> "parselist") at >>> avp_helper.c:208 >>> avp = 0x7f5e1b5c3bd0 >>> __FUNCTION__ = "diameterserver_add_avp" >>> #1 0x7f5e23c4d0c8 in parselist (response=0x0, list=0x7fff9f21a8d0, >>> item=0x11b67d0, level=2) at avp_helper.c:309 >>> i = 1 >>> flags = 64 >>> x = "p\250!\237" >>> avp_list = {head = 0x0, tail = 0x0} >>> avp_list_s = {s = 0x7f5e1b5c2240 "", len = 12} >>> __FUNCTION__ = "parselist" >>> #2 0x7f5e23c4cffc in parselist (response=0x7f5e1b5c3ab8, list=0x0, >>> item=0x11b6550, level=1) at avp_helper.c:304 >>> subitem = 0x11b67d0 >>> i = 0 >>> flags = 64 >>> x = "\000\000\000" >>> avp_list = {head = 0x0, tail = 0x0} >>> avp_list_s = {s = 0x7fff9f21a8f0 "@\251!\237\377\177", len = >>> 600070897} >>> __FUNCTION__ = "parselist" >>> #3 0x7f5e23c4db3a in addAVPsfromJSON (response=0x7f5e1b5c3ab8, >>> json=0x7f5e23e53950 ) at avp_helper.c:349 >>> subitem = 0x11b6550 >>> i = 4 >>> __FUNCTION__ = "addAVPsfromJSON" >>> root = 0x11b4210 >>> #4 0x7f5e23c3fbdb in callback_cdp_request (request_in=0x7f5e1b5c19b0, >>> param=0x0) at ims_diameter_server.c:193 >>> fmsg = 0xab7840 <_faked_msg> >>> backup_rt = 1 >>> ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = >>> {{__jmpbuf = {1, -5713032302318786866, 7971288, 7971288, >>> 140042162528420, 0, -5713032302339758386, >>> 5712822384154044110}, __mask_was_saved = 0, __saved_mask = {__val = { >>> 140735863172072, 127, 0, 140042162532340, >>> 140042389578761, 4222451713, 140042162532340, 140042162532340, >>> 140042162532340, >>> 140042162532340, 140042162532358, 140042162532467, >>> 140042162532340, 140042162532467, 0, 0} >>> response = 0x7f5e1b5c3ab8 >>> __FUNCTION__ = "callback_cdp_request" >>> #5 0x7f5e24a705c0 in api_callback (p=0x7f5e1b598f50, >>> msg=0x7f5e1b5c19b0, ptr=0x0) at api_process.c:83 >>> t = 0x7f5e1b598f50 >>> auto_drop = 32767 >>> h = 0x7f5e1b5b3358 >>> ---Type to continue, or q to quit--- >>> x = {type = (unknown: 2669784000), handler = {requestHandler = >>> 0x7f5e23c3eed1 , >>> responseHandler = 0x7f5e23c3eed1 }, param >>> = 0x3ee9f21ac10, next = 0x7f5e1b5988b8, prev = 0x19f210069} >>> type = REQUEST_HANDLER >>> rsp = 0x7f5e1b5c19b0 >>> __FUNCTION__ = "api_callback" >>> #6 0x7f5e24a857d7 in worker_process (id=5) at worker.c:346 >>> t = {p = 0x7f5e1b598f50, msg = 0x7f5e1b5c19b0} >>> cb = 0x7f5e1b59df30 >>> r = 128 >>> __FUNCTION__ = "worker_process" >>> #7 0x7f5e24a62a8e in diameter_peer_start (blocking=0) at >>> diameter_peer.c:242 >>> pid = 0 >>> k = 5 >>> p = 0x36 >>> __FUNCTION__ = "diameter_peer_start" >>> #8 0x7f5e24a559bc in cdp_child_init (rank=0) at cdp_mod.c:243 >>> __FUNCTION__ = "cdp_child_init" >>> #9 0x00547e54 in init_mod_child (m=0x7f5e28656fb8, rank=0) at >>> core/sr_module.c:943 >>>
Re: [SR-Users] Parse Header error when send Register to P-CSCF using ims-pcscf
Hello, Would you paste the register flow SIP message in wireshark or tcpdump? And Please paste the XML senario that you used to generate SIP message. Thank With Regards.Mojtaba On Sun, Oct 28, 2018 at 10:20 PM Hưng Nguyễn Tiến wrote: > > Hi, i'm newbie in kamailio, > I tried installed ims kamailio from ng-repository packages, > > Then when I tried to send register to SIP server using SIPp, > I received this log > [Proxy-CSCF][28505]: ERROR: [core/parser/msg_parser.c:331]: > parse_headers(): bad header field [(null)] > [Proxy-CSCF][28500]: ERROR: [core/parser/msg_parser.c:331]: > parse_headers(): bad header field [(null)] > [Proxy-CSCF][28496]: WARNING: [core/receive.c:192]: receive_msg(): > parsing relevant headers failed > [Proxy-CSCF][28505]: message repeated 2 times: [ WARNING: > [core/receive.c:192]: receive_msg(): parsing relevant headers failed] > [Proxy-CSCF][28492]: ERROR: [core/parser/msg_parser.c:675]: > parse_msg(): ERROR: parse_msg: > message=<#002#020#002#021#023�#023���z'��z'#006��[%�#007> > > Thank you > -- > Nguyễn Tiến Hưng > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- --Mojtaba Esfandiari.S ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users