- sr-users - kamailio.org

Audio stops after resuming call from hold
by gerry kernan 16 Apr '18

16 Apr '18

Hi Hoping someone can point me in the right direction. I have a Kamailio Ver: 4.2.3-1.1 running in front of a few asterisk servers Ver: 13.17.2 sip is routed to an asterisk server depending the domain name in the sip request, all working as expected . but if a call is put on hold after resuming the call the party that placed the call on hold can't hear any audio. The other party can hear . do I need to do anything special to handle re-invites for calls put on hold? Gerry Kernan Infinity IT | 17 The Mall | Beacon Court | Sandyford | Dublin D18 E3C8 | Ireland Tel: +353 - (0)1 - 293 0090 | E-Mail: <mailto:gerry.kernan@infinityit.ie> gerry.kernan(a)infinityit.ie Managed IT Services Infinity IT - <http://www.infinityit.ie/> www.infinityit.ie IP Telephony Asterisk Consulting - <http://www.asteriskconsulting.com> www.asteriskconsulting.com Contact Centre Total Interact - <http://www.totalinteract.com> www.totalinteract.com

3 8

Help me!
by Do Quang Trung 15 Apr '18

15 Apr '18

I use kamailio 5.1.1 with openssl-1.0.2n. I built openssl with gost engine supported and the result when i list cipher list as follow: .................... GOST2001-GOST89-GOST89:GOST94-GOST89-GOST89:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA::GOST94-GOST89-GOST89:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA: ................ i must use exactly GOST2001-GOST89-GOST89 in kamailio to protect sip protocol. Please help me to resolve my problem. Best regards, Trung.

3 2

Kamailio 4.2.8 has crashed
by igor.potjevlesch＠gmail.com 13 Apr '18

13 Apr '18

Hello, I had a crash on one Kamailio instance with the following backtrace: Core was generated by `/usr/local/sbin/kamailio -m 704 -M 128 -P /run/kamailio/kamailio.pid'. Program terminated with signal 6, Aborted. #0 0x00007f92366761f7 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.168-8.el7.x86_64 glibc-2.17-196.el7_4.2.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-8.el7.x86_64 libacl-2.2.51-12.el7.x86_64 libattr-2.4.46-12.el7.x86_64 libcap-2.22-9.el7.x86_64 libcom_err-1.42.9-10.el7.x86_64 libdb-5.3.21-21.el7_4.x86_64 libgcc-4.8.5-16.el7_4.1.x86_64 libselinux-2.5-11.el7.x86_64 libstdc++-4.8.5-16.el7_4.1.x86_64 lm_sensors-libs-3.4.0-4.20160601gitf9185e5.el7.x86_64 lua-5.1.4-15.el7.x86_64 mariadb-libs-5.5.56-2.el7.x86_64 net-snmp-agent-libs-5.7.2-28.el7_4.1.x86_64 net-snmp-libs-5.7.2-28.el7_4.1.x86_64 nspr-4.13.1-1.0.el7_3.x86_64 nss-3.28.4-15.el7_4.x86_64 nss-softokn-freebl-3.28.3-8.el7_4.x86_64 nss-util-3.28.4-3.el7.x86_64 openssl-libs-1.0.2k-8.el7.x86_64 pcre-8.32-17.el7.x86_64 perl-libs-5.16.3-292.el7.x86_64 popt-1.13-16.el7.x86_64 rpm-libs-4.11.3-25.el7.x86_64 tcp_wrappers-libs-7.6-77.el7.x86_64 xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-17.el7.x86_64 (gdb) backtrace #0 0x00007f92366761f7 in raise () from /lib64/libc.so.6 #1 0x00007f92366778e8 in abort () from /lib64/libc.so.6 #2 0x000000000061fb2c in qm_free (qm=0x7f91f4eaf000, p=0x7f92110d0300, file=0x7f9226dd7072 "dialog: dlg_hash.c", func=0x7f9226dd9aeb <__FUNCTION__.12761> "destroy_dlg", line=381) at mem/q_malloc.c:474 #3 0x00007f9226d6fb62 in destroy_dlg (dlg=0x7f920f775598) at dlg_hash.c:381 #4 0x00007f9226d75681 in dlg_unref (dlg=0x7f920f775598, cnt=2) at dlg_hash.c:874 #5 0x00007f9226da14d5 in dlg_ontimeout (tl=0x7f920f7755f8) at dlg_handlers.c:1488 #6 0x00007f9226db1e67 in dlg_timer_routine (ticks=8621904, attr=0x0) at dlg_timer.c:283 #7 0x00000000004af537 in compat_old_handler (ti=137950479, tl=0x7f91f7ad8cc8, data=0x7f91f7ad8cc8) at timer.c:1011 #8 0x00000000004aff14 in slow_timer_main () at timer.c:1145 #9 0x000000000052a2af in main_loop () at main.c:1684 #10 0x000000000052fe71 in main (argc=7, argv=0x7fff51f21418) at main.c:2581 (gdb) Is there enough information to understand the reason of the crash? Regards, Igor.

3 5

Help needed to compile and install kamailio 5.1.2
by vinay kumar 13 Apr '18

13 Apr '18

Hi All, can anyone share me the installtion steps for kamailio 5.1.2? can i compile and run kamailio 5.1.2 on ubuntu 14.04? i have already used 4.3.6 with polaris configuration to bringup kamailio and i wanna upgrade to kamailio 5.1.2 and the same way can i use 5.1.2 with polaris configuration? I have used polaris scripts to bringup kamailio 5.1.2 and its failing with status kamailio service with Result resources. if i use latest debian packages , are polaris configurations are compatible with latest packages?? Please help me out. Thanks in advance. Regards, vinay

1 0

Is RTPProxy the way to go?
by Robert Johnson 12 Apr '18

12 Apr '18

I'm encountering a situation where an endpoint will renegotiate it's RTP ports but RTPProxy does not honor the new ports and continues to send audio to the old ports. I realize that I'm running a (very) old version of RTPProxy and that I should upgrade before submitting any bugs or asking for help with the program. My question is, is RTPProxy still the way to go? And if so, is v2.0.0 the best version to go with? https://github.com/sippy/rtpproxy/releases At a basic level, the network looks like this +---------------+ +--------------+ | | | | | Priv. Network | | Pub. Network | | | | | +------+ +---------+--+ +---+-------+--+ +--+--------+ | | | | | | | | | PSTN <---> Softswitch <--------> Kamailio + <--------> EndPoints | | | | | | RTPProxy | | | +------+ +---------+--+ | | +--+--------+ | +---+-------+--+ | | | | | +---------------+ +--------------+

2 1

Kamailio + tls
by Do Quang Trung 12 Apr '18

12 Apr '18

Plz help me. I want config kamailio 5.1 support tls using gost89 cipher to protect data.

2 3

Re: [SR-Users] MSILO: SIP stored offline MESSAGE repetitive delivery
by Abdul Basit 12 Apr '18

12 Apr '18

Hi Team, My issue for IM handling has been resolved. @MS helped to look into the matter. From to the example https://www.kamailio.org/docs/modules/5.1.x/modules/msilo.html#idp45433036 # -- tm params -- modparam("tm", "fr_timer", 10 ) modparam("tm", "fr_inv_timer", 15 ) modparam("tm", "wt_timer", 10 ) I replaced it as below # -- tm params -- modparam("tm", "fr_timer", 10000 ) modparam("tm", "fr_inv_timer", 15 ) modparam("tm", "wt_timer", 10 ) Lower fr_timer was initiating 408 without waiting for 200 OK from destination because 10ms is too low. This was confusing msilo module and the sender device that MESSAGE sent was failed. Increasing the fr_timer value resolved the issue. This also resolved a ripple effect. i.e, kamailio delivery of offline messages from DB store to the destination party. Since kamailio was get message delivery error, it was executing failure_route[1] that was storing the message again in DB store as offline message and so on. lower fr_timer values are also exits in 3.x, 4.x, 5x and dev branches documentation. Correction is required. -- regards, abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445 > > On 9 April 2018 at 19:34, Abdul Basit <basit.engg(a)gmail.com> wrote: > >> Dear Team, >> >> I have added traces via pasetbin >> >> MESSAGE Stored When B is OffLine https://pastebin.com/NLwMePmf >> >> [trace screenshot removed] >> >> Next this messages should be delivered when B party REGISTER with the >> server >> >> *Issue 1*: Message was delivered to B-party but it didn't remove form DB >> and as a result MESSAGE deliver to B-party as many times it come line >> https://pastebin.com/7pb0wCKx >> [trace screenshot removed] >> >> Now next issue is >> *Issue 2*: Messages deliver to B-party when its already online without >> storing in DB. B-party receive MESSAGE successfully but A-party gets >> MESSAGE delivery failed. >> https://pastebin.com/zgDbK4F6 >> >> [trace screenshot removed] >> >> I intentionally modified the 202 - description for better troubleshooting. >> >> See if attachments were received properly through mailing list. >> >> For convenience I have attached the pcap as well. >> >> MESSAGE: 1: Accepted and Stored as expected >> MESSAGE: 2: Server delivered Message when B comes online >> MESSAGE: 3: Both A & B are online. A-party receives MESSAGE delivery >> failure where as B-party receives MESSAGE successfully >> >> >> Modified default kamailio.cfg is https://pastebin.com/thZig5RC >> It looks that mingled up the configuration. >> >> Please see whats gone wrong here. >> >> >> -- >> regards, >> >> abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445 >> >> On 9 April 2018 at 18:20, Abdul Basit <basit.engg(a)gmail.com> wrote: >> >>> Dear team, >>> >>> Thank you for your reply. >>> >>> @MS & @ Davld, Let me test again and share traces. >>> >>> @Zaka, I will check the save() result as you suggested. Location is >>> being saved and properly looked up because messages are being delivered >>> (and not stored in DB ) when both parties are online. >>> >>> -- >>> regards, >>> >>> abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445 >>> >>> On 9 April 2018 at 16:38, Muhammad Zaka <muhammad.zaka(a)cloudcall.com> >>> wrote: >>> >>>> Please check the return value of save and replace the logic: - >>>> >>>> >>>> >>>> $var(save_result) = save("location") ; >>>> >>>> if ($var(save_result) <= -1) { >>>> >>>> xlogl("L_ERROR", "[$rm] -> Unable to save user location \n"); >>>> sl_reply_error(); >>>> >>>> exit(); >>>> >>>> } >>>> >>>> >>>> >>>> >>>> >>>> if ($var(save_result) == 1) { >>>> >>>> xlogl("L_INFO", "[$rm] -> dumping messages with MSILO \n"); >>>> # MSILO - dumping user's offline messages to user >>>> if (m_dump("$fu")) { >>>> xlogl("L_NOTICE", "MSILO: offline messages for $fu dumped - if >>>> they were \n"); >>>> } >>>> else { >>>> xlogl("L_NOTICE", "MSILO: no offline messages dumped \n"); >>>> }; >>>> } >>>> >>>> >>>> >>>> This means dump the message only when it is not re-registration. >>>> >>>> >>>> >>>> Thanks >>>> >>>> >>>> >>>> Regards >>>> >>>> Muhammad Zaka >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:* sr-users [mailto:sr-users-bounces@lists.kamailio.org] *On >>>> Behalf Of *Abdul Basit >>>> *Sent:* 08 April 2018 18:43 >>>> *To:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>; >>>> Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org> >>>> *Subject:* Re: [SR-Users] MSILO: SIP stored offline MESSAGE repetitive >>>> delivery >>>> >>>> >>>> >>>> Dear Team, >>>> >>>> Still stuck with the issue. Kindly suggest where i did wrong. >>>> >>>> >>>> >>>> >>>> -- >>>> regards, >>>> >>>> >>>> abdul basit | p: +92 32 1416 4196 | o: +92 30 0841 1445 >>>> >>>> >>>> >>>> On 6 April 2018 at 20:50, Abdul Basit <basit.engg(a)gmail.com> wrote: >>>> >>>> Hi team, >>>> >>>> I am facing an issue while setting up IM server based on kamailio. >>>> >>>> SIP-SIP online messaging is fine. For offline messaging i am using >>>> msilo module which is storing offline messages in 'silo' table. >>>> >>>> >>>> >>>> As B-party come online ... it receive offline messages stored in >>>> database. But >>>> >>>> *Problem is*.. these messages will deliver to B-party as many time it >>>> REGISTER online. >>>> >>>> >>>> >>>> How can I configure msilo module to mark messages delivery status? >>>> or how can i delete the delivered messages so that there will be no >>>> chance of delivering them again on next REGISTER? >>>> >>>> Message parts of kamailio.cfg are >>>> .... >>>> /* add local domain aliases */ >>>> alias="192.168.10.18" >>>> port=9060 >>>> >>>> >>>> # ----- msilo params ----- >>>> modparam("msilo", "db_url", DBURL) >>>> modparam("msilo", "db_table", "silo") >>>> modparam("msilo", "sc_mid", "id") >>>> modparam("msilo","from_address","sip:registrar@192.168.10.18:9060") >>>> modparam("msilo","contact_hdr","Contact: registrar@192.168.10.18:9060;m >>>> silo=yes\r\n") >>>> modparam("msilo","content_type_hdr","Content-Type: text/plain\r\n") >>>> >>>> ........ >>>> >>>> route[MSILO_MESSAGE] { >>>> if (!is_method("MESSAGE")) return; >>>> xlogl("L_NOTICE", "[$rm] r-uri: $ru d-uri: $du \n"); >>>> if (lookup("location")) { >>>> xlogl("L_NOTICE", "[$rm] -> loaction found. Relying message >>>> [[$rb]] to the UAC \n"); >>>> t_relay(); >>>> } else { >>>> if (!t_newtran()) { >>>> xlogl("L_ERROR", "[$rm] -> ERROR creating new transaction >>>> \n"); >>>> sl_reply_error(); >>>> exit; >>>> }; >>>> xlogl("L_NOTICE", "[$rm] -> Storing MSILO_MESSAGE \n >>>> [$ru]-[$tu]-[$ou] \n "); >>>> if (m_store("$ru")) { >>>> xlogl("L_NOTICE", "MSILO: offline message stored! \n"); >>>> if (!t_reply("202", "Accpeted and Strored")) { >>>> xlogl("L_ERROR", "MSILO: Err sending 202 reply... \n"); >>>> sl_reply_error(); >>>> } >>>> } else { >>>> xlogl("L_ERROR", "MSILO: offline message NOT stored... \n"); >>>> if (!t_reply("503", "Service Unavailable")) { >>>> sl_reply_error(); >>>> } >>>> } >>>> } >>>> exit; >>>> } >>>> >>>> ..... >>>> >>>> # Handle SIP registrations >>>> route[REGISTRAR] { >>>> if (!is_method("REGISTER")) return; // discard all non-REGISTER >>>> methods >>>> >>>> if(isflagset(FLT_NATS)) { >>>> setbflag(FLB_NATB); >>>> #!ifdef WITH_NATSIPPING >>>> setbflag(FLB_NATSIPPING); //# do SIP NAT pinging >>>> #!endif >>>> } >>>> $avp(received) = "sip:" + $si + ":" + $sp + ";transport=" + $proto; >>>> xlogl("L_INFO", "[$rm] -> UAC actual location $avp(received) \n"); >>>> if (!save("location",0x04)) { >>>> xlogl("L_ERROR", "[$rm] -> Unable to save user location \n"); >>>> sl_reply_error(); >>>> } >>>> else { >>>> xlogl("L_INFO", "[$rm] -> dumping messages with MSILO \n"); >>>> # MSILO - dumping user's offline messages to user >>>> if (m_dump("$fu")) { >>>> xlogl("L_NOTICE", "MSILO: offline messages for $fu dumped - >>>> if they were \n"); >>>> } >>>> else { >>>> xlogl("L_NOTICE", "MSILO: no offline messages dumped \n"); >>>> }; >>>> } >>>> exit; >>>> } >>>> >>>> Any idea? >>>> >>>> >>>> -- >>>> regards, >>>> >>>> >>>> abdul basit >>>> >>>> >>>> >>>> _______________________________________________ >>>> Kamailio (SER) - Users Mailing List >>>> sr-users(a)lists.kamailio.org >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> >>> >> >

2 1

Limiting Kamailios accepted methods
by Gholamreza Sabery 12 Apr '18

12 Apr '18

Hi, I want to limit Kamailios accepted methods to REGISTER, INVITE and their related methods like BYE and CANCEL. How to do this in Kamailio? Is there a standard way or I should use is_method function? Regards

3 4

Re: [SR-Users] Is 't_newtran()' needed when using reliable TCP/TLS transport?
by Cody Herzog 11 Apr '18

11 Apr '18

Another thought... Perhaps 'async_task_route()' automatically creates a transaction, which is why I was having problems with the calls to 't_newtran()' and 't_release()' after the route had been changed to execute through 'async_task_route()'. If so, then maybe it's safe for my async presence route to not call 't_newtran()' and 't_release()'. Thanks.

1 0

Re: [SR-Users] Is 't_newtran()' needed when using reliable TCP/TLS transport?
by Cody Herzog 11 Apr '18

11 Apr '18

Thanks for the quick reply, Alex. I will try to provide more context information. The route in question is related to presence. Our usage of t_newtran() is very similar to the following presence examples: https://github.com/kamailio/kamailio/blob/master/test/unit/presence.cfg https://lists.kamailio.org/pipermail/sr-users/2016-April/092544.html https://www.kamailio.org/dokuwiki/doku.php/presence:configuration-file (see route[2]) I believe our config was probably based off one of those. In that context, with reliable transport, is 't_newtran()' useful? Thanks.

1 0

Is 't_newtran()' needed when using reliable TCP/TLS transport?
by Cody Herzog 11 Apr '18

11 Apr '18

Hello. I have read that the primary use of 't_newtran()' is to handle SIP retransmissions. Given that, is there any reason to use it when operating over TCP/TLS? I recently changed a route to operate asynchronously through 'async_task_route()'. When I did, calls to 't_newtran()' started failing. I'm hoping that I can safely remove all the calls to 't_newtran()' and the matching calls to 't_release()' on this async route, because I am using TLS as the transport. Does that sound correct? Thanks.

2 1

Kamailio logs in RHEL 7 environment
by igor.potjevlesch＠gmail.com 11 Apr '18

11 Apr '18

Hello ! Since I moved my OS to RHEL 7, the logs management has changed. I cannot have all logs in /var/log/messages as I used to have. Indeed, there is journald/rsyslog which blocked logs to be written after hundreds/thousands of messages. I tried to set these values to 0: vim /etc/systemd/journald.conf [Journal] [.] RateLimitInterval=0 RateLimitBurst=0 But the problem is still present. Anyone has already solved this problem? Regards, Igor.

2 2

Default AUTH route potential issue?
by Володимир Іванець 11 Apr '18

11 Apr '18

Hello all! I'm using Kamailio 5.1.0 on my testing machine. Configuration includes slightly modified AUTH route from http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb route[AUTH] { xlog("L_DBG", "== TRACE. AUTH\n"); # if caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (from_uri!=myself && uri!=myself) { xlog("L_DBG", "== TRACE. AUTH. Not relaying. Exiting.\n"); sl_send_reply("403","Not relaying"); exit; } if(isflagset(TRUSTEDIP)) { xlog("== TRACE. AUTH. TRUSTEDIP. Returning.\n"); return; } if (is_method("REGISTER") || from_uri==myself) { xlog("L_DBG", "== TRACE. AUTH. Method REGISTER\n"); # authenticate requests if (!auth_check("$fd", "sipusers", "1")) { auth_challenge("$fd", "0"); xlog("L_DBG", "== TRACE. AUTH. Exiting.\n"); exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) { xlog("L_DBG", "== TRACE. AUTH. Method is not REGISTER|PUBLISH\n"); consume_credentials(); } } xlog("L_DBG", "== TRACE. AUTH. Returning.\n"); return; } I opened port UDP/5060 to everyone today and started receiving some SIP requests. Most INVITEs were stopped by *auth_challenge* but then I received this one: 2018/04/11 16:32:44.385689 38.91.106.211:5069 -> 172.16.30.205:5060 INVITE sip:100@MY_PUB_IP_ADDRESS SIP/2.0 v: SIP/2.0/UDP 38.91.106.211:5060;branch=z9hG4bK-929181129;rport Content-Length: 0 f: "pbx"<sip:100@1.1.1.1>;tag=3535306165633930313363340131373533363938373235 i: 757925348661465531074812 m: sip:100@38.91.106.211:5069 Accept: application/sdp CSeq: 1 INVITE t: "pbx"<sip:100@1.1.1.1> Max-Forwards: 70 ... and it came through AUTH route. Below are two fragments of Kamailio log: Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <script>: == TRACE. INVITE From: sip:100@1.1.1.1 (IP:38.91.106.211:5069) Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <script>: == TRACE. To: sip:100@1.1.1.1 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: pv [pv_core.c:1286]: pv_get_dsturi(): no destination URI Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <script>: == TRACE. Destination URI : <null> Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <script>: == TRACE. SIP Request header : sip:100@MY_PUB_IP_ADDRESS Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: pv [pv_core.c:966]: pv_get_useragent(): no User-Agent header Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <script>: == TRACE. User Agent header : <null> **************************************************************************************************** Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <script>: == TRACE. request_route ==> AUTH Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <script>: == TRACE. AUTH Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 7==9 && [1.1.1.1] == [127.0.0.1] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 7==13 && [1.1.1.1] == [172.16.30.205] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 7==9 && [1.1.1.1] == [127.0.0.1] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 8088 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/forward.c:412]: check_self(): host != me Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 7==9 && [1.1.1.1] == [127.0.0.1] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 7==13 && [1.1.1.1] == [172.16.30.205] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 7==9 && [1.1.1.1] == [127.0.0.1] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 8088 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/forward.c:412]: check_self(): host != me Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 13==9 && [ MY_PUB_IP_ADDRESS ] == [127.0.0.1] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 13==13 && [ MY_PUB_IP_ADDRESS ] == [172.16.30.205] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 5060 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:564]: grep_sock_info(): checking if host==us: 13==9 && [ MY_PUB_IP_ADDRESS ] == [127.0.0.1] Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <core> [core/socket_info.c:567]: grep_sock_info(): checking if port 8088 (advertise 0) matches port 5060 Apr 11 16:32:44 kamailio-dev /usr/sbin/kamailio[31373]: DEBUG: <script>: == TRACE. AUTH. Returning. As you can see all tests failed to catch this INVITE request and Kamailio continued processing it. And I'm now wondering what would be the best way to identify such packet. Thanks.

2 1

[SOLVED]: rtpengine no voice when working between DTLS-SRTP endpoints
by Aqs Younas 11 Apr '18

11 Apr '18

DTLS=passive solved it. Thanks guys. On Tue, 10 Apr 2018, 11:37 pm Aqs Younas, <aqsyounas(a)gmail.com> wrote: > Sometimes, I see below logs in RTP engine. > > > Apr 10 17:59:21 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: Received command 'answer' from > 127.0.0.1:44933 > Apr 10 17:59:21 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: answer time = 0.000163 sec > Apr 10 17:59:21 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: Replying to 'answer' from > 127.0.0.1:44933 > [1523383161.279950] ERR: [24b95195-3da3-4e12-8400-5fcf908183e5 port > 8268]: SRTP output wanted, but no crypto suite was negotiated > Apr 10 17:59:21 centos-1024mb-nyc-02 rtpengine[65101]: ERR: > [24b95195-3da3-4e12-8400-5fcf908183e5 port 8268]: SRTP output wanted, but > no crypto suite was negotiated > Apr 10 17:59:25 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5 port 8268]: Confirmed peer address > as 72.214.35.171:64834 > [1523383171.481023] ERR: [24b95195-3da3-4e12-8400-5fcf908183e5 port > 8269]: SRTCP output wanted, but no crypto suite was negotiated > Apr 10 17:59:31 centos-1024mb-nyc-02 rtpengine[65101]: ERR: > [24b95195-3da3-4e12-8400-5fcf908183e5 port 8269]: SRTCP output wanted, but > no crypto suite was negotiated > Apr 10 17:59:31 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5 port 8269]: Confirmed peer address > as 72.214.35.171:50108 > [1523383176.025296] ERR: [24b95195-3da3-4e12-8400-5fcf908183e5 port > 8268]: SRTP output wanted, but no crypto suite was negotiated > Apr 10 17:59:36 centos-1024mb-nyc-02 rtpengine[65101]: ERR: > [24b95195-3da3-4e12-8400-5fcf908183e5 port 8268]: SRTP output wanted, but > no crypto suite was negotiated > [1523383186.000280] ERR: [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS > error: 1 (read timeout expired) > [1523383186.000335] ERR: [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS > error on local port 8248 > [1523383186.000419] ERR: [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS > error: 1 (read timeout expired) > [1523383186.000429] ERR: [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS > error on local port 8249 > *Apr 10 17:59:46 centos-1024mb-nyc-02 rtpengine[65101]: ERR: > [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error: 1 (read timeout > expired)* > *Apr 10 17:59:46 centos-1024mb-nyc-02 rtpengine[65101]: ERR: > [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error on local port 8248* > *Apr 10 17:59:46 centos-1024mb-nyc-02 rtpengine[65101]: ERR: > [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error: 1 (read timeout > expired)* > *Apr 10 17:59:46 centos-1024mb-nyc-02 rtpengine[65101]: ERR: > [02d8ccfb-831e-4a81-bd2b-09b007d39209]: DTLS error on local port 8249* > *Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: Closing call due to timeout* > Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: Final packet stats: > Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: --- Tag > 'f6d2237d-f960-4542-b138-f39a7fb52770', created 1:32 ago for branch '', in > dialogue with '6bdf30d1-2da6-4b6d-b917-aaa720c9c1fa' > Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: ------ Media #1 (audio over > UDP/TLS/RTP/SAVP) using unknown codec > *Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: --------- Port 209.182.216.71:8288 > <http://209.182.216.71:8288> <> 100.84.103.245:4002 > <http://100.84.103.245:4002> , SSRC 0, 0 p, 0 b, 0 e, 92 ts* > *Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: --------- Port 209.182.216.71:8289 > <http://209.182.216.71:8289> <> 100.84.103.245:4003 > <http://100.84.103.245:4003> (RTCP), SSRC 0, 0 p, 0 b, 0 e, 92 ts* > Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: --- Tag > '6bdf30d1-2da6-4b6d-b917-aaa720c9c1fa', created 1:32 ago for branch '', in > dialogue with 'f6d2237d-f960-4542-b138-f39a7fb52770' > Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: ------ Media #1 (audio over > UDP/TLS/RTP/SAVP) using G722/8000 > Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: --------- Port > 209.182.216.71:8268 <> 72.214.35.171:64834, SSRC 653128b4, 935 p, > 160820 b, 0 e, 60 ts > Apr 10 18:00:41 centos-1024mb-nyc-02 rtpengine[65101]: INFO: > [24b95195-3da3-4e12-8400-5fcf908183e5]: --------- Port > 209.182.216.71:8269 <> 72.214.35.171:50108 (RTCP), SSRC 653128b4, 3 p, > 278 b, 0 e, 60 ts > > > Any suggestion what might be happening? > > Br, Aqs. > > On 10 April 2018 at 22:59, Aqs Younas <aqsyounas(a)gmail.com> wrote: > >> I could see SRTP packets coming from one device but they never leave >> rtpeninge. >> >> I put a link to Pastebin containing a call trace with the hope that >> someone might help me out. >> >> I could provide more info if required. >> >> https://pastebin.com/tYVpFQAh >> >> Br, Aqs. >> >> >> On 10 April 2018 at 01:39, Aqs Younas <aqsyounas(a)gmail.com> wrote: >> >>> Greetings list, >>> >>> I am trying to make two endpoints talking on DTLS-SRTP. But I hear on >>> audio. >>> >>> Things work perfectly fine if I use RTP or SRTP with TLS. >>> >>> Endpoints are pjsip based application not webrtc based clients. >>> >>> >>> Below are logs from rtpengine. I hope someone could point out amiss. >>> >>> Apr 9 20:02:43 centos-1024mb-nyc-02 rtpengine[58438]: INFO: >>> [66d2da58-21fe-48bd-9999-a1f3a22afa6d]: --------- Port >>> 209.182.216.71:8176 <> 72.214.35.171:63577, SSRC 1234c6eb, 641 p, >>> 110252 b, 0 e, 60 ts >>> Apr 9 20:02:43 centos-1024mb-nyc-02 rtpengine[58438]: INFO: >>> [66d2da58-21fe-48bd-9999-a1f3a22afa6d]: --------- Port >>> 209.182.216.71:8177 <> 72.214.35.171:63056 (RTCP), SSRC 1234c6eb, 4 >>> p, 372 b, 0 e, 60 ts >>> Apr 9 20:12:24 centos-1024mb-nyc-02 rtpengine[58438]: INFO: Version >>> git-master-3ef300b shutting down >>> Apr 9 20:12:37 centos-1024mb-nyc-02 rtpengine[58958]: INFO: Generating >>> new DTLS certificate >>> Apr 9 20:12:37 centos-1024mb-nyc-02 rtpengine[58959]: INFO: Startup >>> complete, version git-master-3ef300b >>> Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Received command 'offer' from >>> 127.0.0.1:57645 >>> Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: NOTICE: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Creating new call >>> Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: offer time = 0.002612 sec >>> Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Replying to 'offer' from >>> 127.0.0.1:57645 >>> Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Received command 'answer' from >>> 127.0.0.1:42309 >>> Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: answer time = 0.000220 sec >>> Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Replying to 'answer' from >>> 127.0.0.1:42309 >>> Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: DTLS: Peer certificate >>> accepted >>> Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: DTLS-SRTP successfully >>> negotiated >>> Apr 9 20:13:57 centos-1024mb-nyc-02 rtpengine[58959]: ERR: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but >>> no crypto suite was negotiated >>> Apr 9 20:14:00 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: Confirmed peer address >>> as 72.214.35.171:58634 >>> Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]: ERR: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: SRTCP output wanted, but >>> no crypto suite was negotiated >>> Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, count=1, >>> payloadtype=200, length=12, ssrc=2045607967, ntp_sec=1379282714, >>> ntp_fractions=439054259, rtp_ts=1838072137, sender_packets=3366262813, >>> sender_bytes=2383498210, ssrc=815258372, fraction_lost=96, >>> packet_loss=13713522, last_seq=3314313929, jitter=2878956247, >>> last_sr=2456273253, delay_since_last_sr=3351655681 >>> Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]: INFO: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: Confirmed peer address >>> as 72.214.35.171:57732 >>> Apr 9 20:14:12 centos-1024mb-nyc-02 rtpengine[58959]: ERR: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but >>> no crypto suite was negotiated >>> Apr 9 20:14:17 centos-1024mb-nyc-02 rtpengine[58959]: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, count=1, >>> payloadtype=200, length=12, ssrc=2045607967, ntp_sec=2811881700, >>> ntp_fractions=4080266212, rtp_ts=371429680, sender_packets=958830616, >>> sender_bytes=2579186043, ssrc=1909756377, fraction_lost=174, >>> packet_loss=11416637, last_seq=3106722675, jitter=758758394, >>> last_sr=2663618457, delay_since_last_sr=1399181077 >>> Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]: ERR: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but >>> no crypto suite was negotiated >>> Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]: ERR: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: SRTCP output wanted, but >>> no crypto suite was negotiated >>> Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]: >>> [a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, cou >>> >>> >>> It is how I have programmed it in my Kamailio configuration. >>> >>> ON INVITE >>> >>> rtpengine_offer("replace-origin replace-session-connection ICE=remove >>> UDP/TLS/RTP/SAVP"); >>> >>> ON 200-ok >>> >>> rtpengine_answer("replace-origin replace-session-connection ICE=remove >>> UDP/TLS/RTP/SAVP"); >>> >>> >>> Best Regards, >>> >>> Aqs Younas >>> >> >> >

1 0

Is it possible to alter SDP content before forwarding the packet?
by Wilkins, Steve 11 Apr '18

11 Apr '18

Hello all, I was curious whether or not it possible to alter SDP content before forwarding the packet? Thank you all as always!

2 1

Re: [SR-Users] Reply Destination
by Duarte Rocha 11 Apr '18

11 Apr '18

It works. Thanks a lot!!

1 0

Reply Destination
by Duarte Rocha 11 Apr '18

11 Apr '18

Hey Is there any variable that retrieves me the destination of a reply? I've used the To header for the domain, but i can't seem to get the destination port. Any help ? Thanks

2 1

Need installation steps for installing kamailio 5.1.2 with debian packages
by vinay kumar 11 Apr '18

11 Apr '18

Hi All, can anyone share me the installtion steps for kamailio 5.1.2 with debian packages on ubuntu. i have used kamailio 4.3.6 with polaris configuration. I want to upgrade latest version of kamailio. And i have installed latest debian packages and i have used polaris scripts to bringup kamailio and its failing with status kamailio service with Result resources. if i use latest debian packages , are polaris configurations are compatible with latest packages?? Please help me out. Thanks in advance. Regards, vinay

1 0

rtpengine
by volga629＠networklab.ca 11 Apr '18

11 Apr '18

Hello Everyone, What flags available on latest rtpegnine to acomplish transcoding and codec manipulation ? Slava.

2 7

ims_dialog default_timeout parameter
by tyd 11 Apr '18

11 Apr '18

Dear all, What's the meaning of ims_dialog default_timeout parameter ? *Default value is 「43200 (12 hours)」* When modparam("ims_dialog", "default_timeout", 600) was set, the situation of Kamailio S-CSCF out of memory was solved and is running smoothly. Debian 8 with Kamailio 4.4.7

2 8

no corresponding socket found for
by Kjeld Flarup 10 Apr '18

10 Apr '18

Hi I have a setup with three kamailio's in the same host but on different ports. client ->5069 -> 5070 -> 5071 -> SIP provider Now I get this error from the 5069 Kamailio when it is routing a 200 Ok to the client: Apr 9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: <core> [forward.c:181]: get_out_socket(): no socket found Apr 9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: <core> [forward.c:183]: get_out_socket(): no corresponding socket found for(udp:192.168.2.101:10120) Apr 9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: <core> [forward.c:808]: do_forward_reply(): cannot forward reply By manipulating the database I can skip the 5070 Kamailio, and then it works. I captured these two 200 Ok packets to the 5069 kamailio *Failing:* No. Time Source Destination Protocol Length Info 4713 21:54:12.814245 127.0.0.1 127.0.0.1 SIP/SDP 2297 Status: 200 OK | Frame 4713: 2297 bytes on wire (18376 bits), 2297 bytes captured (18376 bits) Linux cooked capture Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1 User Datagram Protocol, Src Port: 5070, Dst Port: 5069 Session Initiation Protocol (200) Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 127.0.0.1:5069;rport=5069;branch=z9hG4bK6ef1.0c009dcf5b4965c5d1a13d508e0b31c5.0 Via: SIP/2.0/UDP 192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjIq.uY6jYbHkIqCo03bYLsTzccb7oy9jw Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0CmHdDZWd-w*> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Cq.7Cc-039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**> Record-Route: <sip:127.0.0.8;line=sr-z-yMngmS0-R4LCz2LtZ-Lg02L-JoLNQGn3057t0SntZ5LNL2QD7Vz12-sjkSTtMxTiB.7Cc-0399LtUqzgSGnCQx0gQ56gLG6g0wn5UILt2NziWIO3ooTDcHdDZ*> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Nm.7Cc5039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI7CJx0gZx73Q.7Cc50C9I0goedg9Bzgoedg94OiRbvEynTR7EFm0wFSOZQCOsOiGQs3EIzyUMTi7jnD7qzmWjn-UVT3SwTiJx7NLo0Q**> Record-Route: <sip:127.0.0.1:5071;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.7651> Record-Route: <sip:127.0.0.1:5070;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.01b2> Record-Route: <sip:127.0.0.1:5069;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAAAAAABAAAAAAAAAAAAAAAIMDE-;did=8de.d821> Record-Route: <sip:192.168.2.9:5069;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAAAAAABAAAAAAAAAAAAAAAIMDE-;did=8de.d821> From: "Door" <sip:u1@192.168.2.101>;tag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW To: <sip:004540294149@scantron.viptel.dk:5070>;tag=1865008112 Call-ID: ou8V0cLHn.P7Oca-pgsnMmrWO43kIQX8 CSeq: 5778 INVITE Contact: <sip:127.0.0.8;line=sr-z-yMnrBS7CQM0gqS0CQ2Q3m27FwI73qx0CQo6gJSngJM7gcHODXPdb7Md5XSvjEqzc**> Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE P-AS-Response: 40294149 Content-Type: application/sdp Content-Length: 499 Message Body *OK (Without 5070)* No. Time Source Destination Protocol Length Info 373 21:44:42.955075 127.0.0.1 127.0.0.1 SIP/SDP 2199 Status: 200 OK | Frame 373: 2199 bytes on wire (17592 bits), 2199 bytes captured (17592 bits) Linux cooked capture Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1 User Datagram Protocol, Src Port: 5071, Dst Port: 5069 Session Initiation Protocol (200) Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 127.0.0.1:5069;rport=5069;branch=z9hG4bKeea.431611add9dee6ae89135983a85d3021.0 Via: SIP/2.0/UDP 192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjXjzYAzDU-AJ9ug6mWhSQVI4gwRomuejk Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0CmHdDZWd-w*> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Cq.7Cc-039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**> Record-Route: <sip:127.0.0.8;line=sr-z-yMn4LSntRr0NzI7NQ574XqnC0M7gQ50NJNL4EgTCQ-7imIQD7Vz12-sjkSTtMxTiB.7Cc-0399LtUqzgSGnCQx0gQ56gLG6g0wn5UILt2NziWIO3ooTDcHdDZ*> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Nm.7Cc5039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI7CJx0gZx73Q.7Cc50C9I0goedg9Bzgoedg94OiRbvj7pJJTBsJyFttWTd-XVsSuS75k3EqOEsCOZF3k6YiyQn-UVT3oyLCQx73Z-> Record-Route: <sip:127.0.0.1:5071;r2=on;lr=on;ftag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP;did=ea4.426> Record-Route: <sip:127.0.0.1:5069;r2=on;lr=on;ftag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP;vsf=AAAAAAABAAAAAAAAAAAAAAAIMDE-;did=ea4.7dd2> Record-Route: <sip:192.168.2.9:5069;r2=on;lr=on;ftag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP;vsf=AAAAAAABAAAAAAAAAAAAAAAIMDE-;did=ea4.7dd2> From: "Door" <sip:u1@192.168.2.101>;tag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP To: <sip:004540294149@scantron.viptel.dk:5070>;tag=1402236088 Call-ID: 31a27HAVA7aFhLaX9uZkBxHu31OEZqOz CSeq: 9542 INVITE Contact: <sip:127.0.0.8;line=sr-z-yMnrBS7CQM0gqS0CQ2Q3m27FwI73qx0CQo6gJSngJM7gcHODXPdb7Md5XSvjEqzc**> Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE P-AS-Response: 40294149 Content-Type: application/sdp Content-Length: 500 Message Body Somehow it must be the contents in the 200 Ok package, but I really cant se any significant difference. Anybody knows what that message is caused by? -- -------------------- Med Liberalistiske Hilsner ---------------------- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

2 4

rtpengine no voice when working between DTLS-SRTP endpoints
by Aqs Younas 10 Apr '18

10 Apr '18

Greetings list, I am trying to make two endpoints talking on DTLS-SRTP. But I hear on audio. Things work perfectly fine if I use RTP or SRTP with TLS. Endpoints are pjsip based application not webrtc based clients. Below are logs from rtpengine. I hope someone could point out amiss. Apr 9 20:02:43 centos-1024mb-nyc-02 rtpengine[58438]: INFO: [66d2da58-21fe-48bd-9999-a1f3a22afa6d]: --------- Port 209.182.216.71:8176 <> 72.214.35.171:63577, SSRC 1234c6eb, 641 p, 110252 b, 0 e, 60 ts Apr 9 20:02:43 centos-1024mb-nyc-02 rtpengine[58438]: INFO: [66d2da58-21fe-48bd-9999-a1f3a22afa6d]: --------- Port 209.182.216.71:8177 <> 72.214.35.171:63056 (RTCP), SSRC 1234c6eb, 4 p, 372 b, 0 e, 60 ts Apr 9 20:12:24 centos-1024mb-nyc-02 rtpengine[58438]: INFO: Version git-master-3ef300b shutting down Apr 9 20:12:37 centos-1024mb-nyc-02 rtpengine[58958]: INFO: Generating new DTLS certificate Apr 9 20:12:37 centos-1024mb-nyc-02 rtpengine[58959]: INFO: Startup complete, version git-master-3ef300b Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Received command 'offer' from 127.0.0.1:57645 Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: NOTICE: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Creating new call Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: offer time = 0.002612 sec Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Replying to 'offer' from 127.0.0.1:57645 Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Received command 'answer' from 127.0.0.1:42309 Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: answer time = 0.000220 sec Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Replying to 'answer' from 127.0.0.1:42309 Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: DTLS: Peer certificate accepted Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: DTLS-SRTP successfully negotiated Apr 9 20:13:57 centos-1024mb-nyc-02 rtpengine[58959]: ERR: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but no crypto suite was negotiated Apr 9 20:14:00 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: Confirmed peer address as 72.214.35.171:58634 Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]: ERR: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: SRTCP output wanted, but no crypto suite was negotiated Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, count=1, payloadtype=200, length=12, ssrc=2045607967, ntp_sec=1379282714, ntp_fractions=439054259, rtp_ts=1838072137, sender_packets=3366262813, sender_bytes=2383498210, ssrc=815258372, fraction_lost=96, packet_loss=13713522, last_seq=3314313929, jitter=2878956247, last_sr=2456273253, delay_since_last_sr=3351655681 Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]: INFO: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: Confirmed peer address as 72.214.35.171:57732 Apr 9 20:14:12 centos-1024mb-nyc-02 rtpengine[58959]: ERR: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but no crypto suite was negotiated Apr 9 20:14:17 centos-1024mb-nyc-02 rtpengine[58959]: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, count=1, payloadtype=200, length=12, ssrc=2045607967, ntp_sec=2811881700, ntp_fractions=4080266212, rtp_ts=371429680, sender_packets=958830616, sender_bytes=2579186043, ssrc=1909756377, fraction_lost=174, packet_loss=11416637, last_seq=3106722675, jitter=758758394, last_sr=2663618457, delay_since_last_sr=1399181077 Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]: ERR: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but no crypto suite was negotiated Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]: ERR: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: SRTCP output wanted, but no crypto suite was negotiated Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]: [a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, cou It is how I have programmed it in my Kamailio configuration. ON INVITE rtpengine_offer("replace-origin replace-session-connection ICE=remove UDP/TLS/RTP/SAVP"); ON 200-ok rtpengine_answer("replace-origin replace-session-connection ICE=remove UDP/TLS/RTP/SAVP"); Best Regards, Aqs Younas

1 2

RTPengine - Transcoding example available?
by Carsten Bock 10 Apr '18

10 Apr '18

Hi, Quick (and simple) question: Can someone provide a working RTPengine request, to enable Transcoding? I know, this is possible, but I thought before looking into deep, how this should be configured for the rtpengine_offer() command, could someone provide an example? Thanks, Carsten

6 13

Re: [SR-Users] First Invite
by Duarte Rocha 10 Apr '18

10 Apr '18

Thank you very much!! That seems to be the solution. Cheers

1 0

First Invite
by Duarte Rocha 10 Apr '18

10 Apr '18

Greetings, How can i identify the first Invite received by Kamailio in a dialog. I'm checking for the To-Tag in order to identify the first one. However, if the UA retries the same INVITE (because of a timeout for example), it won't have To Tag and it won't be the first INVITE that i'm receiving in that dialog. Is there any flag or variable that i can use to identify the first Invite received? Thanks in advance

2 1

Kamailio ds_ping_interval Performance
by Atul Thosar 10 Apr '18

10 Apr '18

Hi All, I am using Kamailio ** *v4.4.x* to load balanced traffic to FreeSWITCH servers. I have query regarding ds_ping_interval and ds_probing_threshold. We have very high traffic (around 200-400 (CPS) calls per sec) hitting on Kamailio which then distribute it to 2-3 FreeSWITCH servers. What is the optimal value should I set to ds_ping_interval and ds_probing_threshold? If I set ds_ping_interval=2 and ds_probing_threshold=1 then in every 2 sec, I would come to know if my FreeSWITCH server is down/up. But by setting such low values, I afraid there would be lot of SIP traffic on network. If I set high (say ds_probing_threshold=5) then I may loose high number of calls (200 CPS, I will loose 1000 calls) in case FreeSWITCH server is down. As I said earlier we have very high traffic hitting on Kamailio, can't kamailio use INVITE itself to probe FreeSWITCH server is down/up? In case of low traffic can't it switch over to OPTION mechanism? -- Thanks in Advance , Atul

6 8

Issues on fresh install
by Worth Morrison 10 Apr '18

10 Apr '18

what does it mean when my siremis login looks like this after an install that seems to have been successful? http://pasteall.org/pic/show.php?id=2b72124d5046e2250ad41d14c722c54d the page is completely non-functional. Thanks, *Worth Morrison*

2 1

Calling a mobile SIP client, which needs to update the registration
by Ulrich Henning 09 Apr '18

09 Apr '18

Hi everybody, I am trying to call a sip client on a mobile cellphone, which is registered fine at my Kamailio instance. Everything is working fine if the phone is awake and the mobile app is not sleeping (e.g. energy saving by OS). If the device is sleeping, the cellphone gets a wakeup request call via apple push kit and wakes the app. Currently my app is doing a Register after each wakeup, because the device does not know if the cellular network changed (external IPv4 address with Carrier Grade NAT). At this point an incoming call already got routed to any existing user registrations in userloc db. In this case, if the cellular provided network address changed, the sip client on the device won't receive any invite of this last call. Instead all last known Contact-URIs are tried to be called until this sip invite times out because no response message is received back in time. I tried to delay the incoming invite message, but this doesn't seem the right way to go, since I can't know if the mobile device is actually reachable and this method would potentially delay every call. What is the best approach to solve this issue? I am looking forward for any comment or suggestion. BR, Henning

3 2

MSILO: SIP stored offline MESSAGE repetitive delivery
by Abdul Basit 09 Apr '18

09 Apr '18

Hi team, I am facing an issue while setting up IM server based on kamailio. SIP-SIP online messaging is fine. For offline messaging i am using msilo module which is storing offline messages in 'silo' table. As B-party come online ... it receive offline messages stored in database. But *Problem is*.. these messages will deliver to B-party as many time it REGISTER online. How can I configure msilo module to mark messages delivery status? or how can i delete the delivered messages so that there will be no chance of delivering them again on next REGISTER? Message parts of kamailio.cfg are .... /* add local domain aliases */ alias="192.168.10.18" port=9060 # ----- msilo params ----- modparam("msilo", "db_url", DBURL) modparam("msilo", "db_table", "silo") modparam("msilo", "sc_mid", "id") modparam("msilo","from_address","sip:registrar@192.168.10.18:9060") modparam("msilo","contact_hdr","Contact: registrar@192.168.10.18:9060; msilo=yes\r\n") modparam("msilo","content_type_hdr","Content-Type: text/plain\r\n") ........ route[MSILO_MESSAGE] { if (!is_method("MESSAGE")) return; xlogl("L_NOTICE", "[$rm] r-uri: $ru d-uri: $du \n"); if (lookup("location")) { xlogl("L_NOTICE", "[$rm] -> loaction found. Relying message [[$rb]] to the UAC \n"); t_relay(); } else { if (!t_newtran()) { xlogl("L_ERROR", "[$rm] -> ERROR creating new transaction \n"); sl_reply_error(); exit; }; xlogl("L_NOTICE", "[$rm] -> Storing MSILO_MESSAGE \n [$ru]-[$tu]-[$ou] \n "); if (m_store("$ru")) { xlogl("L_NOTICE", "MSILO: offline message stored! \n"); if (!t_reply("202", "Accpeted and Strored")) { xlogl("L_ERROR", "MSILO: Err sending 202 reply... \n"); sl_reply_error(); } } else { xlogl("L_ERROR", "MSILO: offline message NOT stored... \n"); if (!t_reply("503", "Service Unavailable")) { sl_reply_error(); } } } exit; } ..... # Handle SIP registrations route[REGISTRAR] { if (!is_method("REGISTER")) return; // discard all non-REGISTER methods if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); #!ifdef WITH_NATSIPPING setbflag(FLB_NATSIPPING); //# do SIP NAT pinging #!endif } $avp(received) = "sip:" + $si + ":" + $sp + ";transport=" + $proto; xlogl("L_INFO", "[$rm] -> UAC actual location $avp(received) \n"); if (!save("location",0x04)) { xlogl("L_ERROR", "[$rm] -> Unable to save user location \n"); sl_reply_error(); } else { xlogl("L_INFO", "[$rm] -> dumping messages with MSILO \n"); # MSILO - dumping user's offline messages to user if (m_dump("$fu")) { xlogl("L_NOTICE", "MSILO: offline messages for $fu dumped - if they were \n"); } else { xlogl("L_NOTICE", "MSILO: no offline messages dumped \n"); }; } exit; } Any idea? -- regards, abdul basit

4 6

Problem capturing packets from kamailio to homer sip-capture
by Arik Halperin 07 Apr '18

07 Apr '18

Hello, My kamailio is listening to TCP, so when I try to duplicate packets to homer, It tries to send them as TCP. From the log I see: Apr 5 08:21:45 kamprod /usr/local/sbin/kamailio[16309]: ERROR: <core> [core/forward.c:181]: get_out_socket(): no socket found Apr 5 08:21:45 kamprod /usr/local/sbin/kamailio[16309]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:10.168.10.229:5090) Apr 5 08:21:45 kamprod /usr/local/sbin/kamailio[16309]: ERROR: siptrace [siptrace.c:1940]: trace_send_hep2_duplicate(): can't forward to af 2, proto 1 no correspondi Which is rather strange to me, because the protocol is defined to be UDP for HEP: corresponding socket found for(udp:10.168.10.229:5090) How can I fix this? Thanks, Arik

4 3

Dialog Profile Value Name Limit
by Duarte Rocha 06 Apr '18

06 Apr '18

Greetings, I'm using the Dialog module and the profile functions in order to limit the number of channels that a Calling Number can use. I'm using profile with values and the number in E164. However it doesn't work correctly and the value are not correctly updated. I've tried to give a a value with only 5 digits and everything seems to work fine. Does the set_dlg_profile and unset_dlg_profile have a size limit for it's value ? Thanks

1 0

Issue in cdr generation in seconds format
by Narayan P 06 Apr '18

06 Apr '18

Hello Sir, I need your expertise for kamailio cdr generation in seconds format. I have a requirement to generate cdr duration in second format.Now I am getting second.milliseconds format.Below is the log where duration is 18.676 but I want this to be 19.(suppose where duration =18.234, I need it to be 18). Mar 16 10:38:22 vm11-kamailio /usr/local/sbin/kamailio[20787]: NOTICE: acc [acc_cdr.c:352]: log_write_cdr(): start_time=1521196683.464; end_time=1521196702.140; duration=18.676; src_user=71097345; src_domain=185.122.XXX.XXX; src_ip=185.122.XXX.XXX; dst_user=; dst_ouser=91786042XXXX; dst_domain=185.122.XXX.XXX; sip_code=; sip_reason=; callid=LVHyTCFWYBpEFp.sFpY204aBdx.nez9B; dst_ip=185.122.XXX.XXX My kamailio configuration related to cdr is like this; /* what special events should be accounted ? */ modparam("acc", "db_url", "flatstore:/var/log/cdr.log") #modparam("acc", "cdr_extra", "c1=$dlg_var(caller);c2=$dlg_var(callee)") modparam("acc", "log_facility", "LOG_DAEMON") modparam("acc", "cdr_enable", 1) modparam("acc", "cdr_start_on_confirmed", 1) modparam("acc", "cdr_log_enable", 1) modparam("acc", "time_mode", 0) modparam("acc", "time_attr", "seconds") modparam("acc", "cdr_start_id", "start_time") modparam("acc", "cdr_end_id", "end_time") modparam("acc", "cdr_duration_id", "duration") #modparam("acc", "cdr_flag", 3) #modparam("acc", "early_media", 0) #modparam("acc", "report_ack", 0) #modparam("acc", "report_cancels", 0) #modparam("dialog", "enable_stats", 1) modparam("dialog", "hash_size", 1024) modparam("dialog", "dlg_flag", 3) modparam("dialog", "db_url", DBURL) /* by default ww do not adjust the direct of the sequential requests. * if you enable this parameter, be sure the enable "append_fromtag" * in "rr" module */ modparam("acc", "detect_direction", 0) /* account triggers (flags) */ #modparam("acc", "log_flag", FLT_ACC) #modparam("acc", "log_missed_flag", FLT_ACCMISSED) #modparam("acc", "log_extra", # "src_user=$fU;src_domain=$fd;src_ip=$si;" # "dst_user=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "cdr_extra","src_user=$fU;src_domain=$fd;src_ip=$si;dst_user=$rU;dst_ouser=$tU;dst_domain=$rd;sip_code=$rs;sip_reason=$rr;callid=$dlg(callid);dst_ip=$Ri") Please suggest me what to configure more in kamailio to achieve cdr in second format. Thanks, Narayan

3 5

Install IMS Modules over KAMAILIO 5.1
by Roi Arias Salve 06 Apr '18

06 Apr '18

Hi all. I would like to thank you all the documents you have to install a Kamailio server. It's quite easy and fast. Currently I'm working on Azure, witha Debian 9 OS, and I'd followed the instructions to install the Kamailio OPENSER, and everything Works perfect. But now I'm stuck on my next step. I would like to install all the IMS components, P-cscf/I-cscf/S-cscf/Fhoss following this document https://www.kamailio.org/wiki/tutorials/ims/installation-howto But, I have no success. Maybe I've a mistake on the selection for the Debian OS installed on the server. I say this because of this sentence: " Note: This document is work in progress and yet unfinished! This is a short installation howto for Debian Wheezy (stable). " So, I asume that maybe here I have a problem with the OS version, I'll try to summarize where I have problems: 1.- I've installed the , P-cscf/I-cscf/S-cscf not a problem. 2.- I am not able to follow this steps related to the repository: First, install the Key for our repository: wget -O - http://repository.ng-voice.com/PublicKey | apt-key add - Then add the repository to your "/etc/apt/sources.list": echo "deb http://repository.ng-voice.com jessie ims rtpproxy" >> /etc/apt/sources.list and also I have problems with this action over the repository Note: You will need to add the "non-free" packages to your repository: deb http://ftp.de.debian.org/debian lenny main non-free deb http://security.debian.org/ lenny/updates main non-free 3.- I decided to install directly the modules from an apt-get install action, because I followed the instructions on the Log created on the Kamailio starting box, where you can find all the steps related to IMS modules, and the suggestion there it is to compile your own modules. On this step I detected a problem related with the dialog_ng module, according to the .log document on the Starting box, you have to include all the modules before you execute the make all instruction: modify modules.lst for included modules and excluded modules (use saved file) - include: ims_auth ims_charging ims_icscf ims_isc ims_qos ims_registrar_pcscf ims_registrar_scscf ims_usrloc_pcscf ims_usrloc_scscf dialog_ng cdp cdp_avp 4.- After this issue, I tried to install FHOSS, but here I can't go further, I am not able to compile it, neither doing my own compilation following this step ant compile deploy | tee ant_compile_deploy.txt nor following apt-get install openimscore-fhoss I was no table to get connected to the repository, so I can't go further. I'm sorry for all this information, can anyone help? Any suggestion? Regards Roi --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

2 1

SIPT append_body_part \x00 how to?..
by Sergey Basov 06 Apr '18

06 Apr '18

Hi All! I have some troubles with encoding hex string to use as ISUP part. I have next line: append_body_part("\x01\x10\x48*\x00*\x0a*\x00* \x02\x09\x07\x03\x90\x90\x13\x71\x32\x20\x0a\x04\x02\x13\x73\x12*\x00* ","application/isup;version=itu-t92+","signal;handling=optional"); Problem is in the *\x00 *kamailio reads this string till first \x00 May be there is some workaround? Currently I have added some C code into SIPT module to change values in this pisitions first to 00 then make other changes. My current input string is append_body_part("\x01\x10\x48*\x01*\x0a*\x01* \x02\x09\x07\x03\x90\x90\x13\x71\x32\x20\x0a\x04\x02\x13\x73\x12*\x01* ","application/isup;version=itu-t92+","signal;handling=optional"); I first make replacement \x01 to \x00 while executing sipt_destination May be there is better solution? Thank you. -- Best regards, Sergey Basov e-mail: sergey.v.basov(a)gmail.com

2 8

When I disconnect a call from callee side. FS Send the BYE to Kamailio PUBLIC IP instead of Private IP. So Caller is not able to receive BYE.
by Suresh Talasaniya 06 Apr '18

06 Apr '18

Hello All, When I disconnect a call from callee side. FS Send the BYE to Kamailio PUBLIC IP instead of Private IP. So Caller is not able to receive BYE. *# Call Flow:* *Caller User -----> Kamailio(Bind on Private IP) ----> Freeswitch(Bind on Private IP) -------> Kamailio(Bind on Private IP) ----> Callee User* *Kamailio Public IP:* KAM_PUBLIC_IP:9000 *Kamailio Private IP:* 172.28.198.123:9000 *FS Private IP:* 172.28.198.128:5060 How to resolve the issue? Please find attached SIP Message and Sample kamailio.cfg. In advance Thank you. -- Regards, Suresh Talasaniya. Contact : +91-9724264776 Skype : suresh.talsaniya

2 1

SQLOps module + KEMI
by Igor Olhovskiy 05 Apr '18

05 Apr '18

Hi! Seems calling function KSR.sqlops.sql_num_rows(«sql_res») crashes Kamailio. At least I got this at 5.1.2 from debian repos with LUA. Getting smth like dev1 kernel: [5780693.247255] kamailio[20659]: segfault at 50b300000004 ip 00007f34d2f46fd6 sp 00007ffe1f0ac310 error 4 in sqlops.so[7f34d2f42000+1c000] Regards, Igor

2 16

nightly builds
by Aleksandar Sosic 05 Apr '18

05 Apr '18

Hi everyone, I'm trying the install of the nightly build via apt. In my sources list: deb http://deb.kamailio.org/kamailiodev-nightly xenial main deb-src http://deb.kamailio.org/kamailiodev-nightly xenial main but the apt installs an older version and the upgrade gives: ```kamailio is already the newest version (5.2.0~dev4+0~20180310010216.1064+xenial).``` What am I doing wrong? -- Aleksandar Sosic mail: alex.sosic(a)timenet.it skype: alex.sosic cell: +385 91 2505 146

1 1

Kamailio send 2 INVITE(lookup rewrite r-uri and append branch) request for Client behind NAT
by amit Kumar 04 Apr '18

04 Apr '18

Hi All, Kamailio send 2 INVITE(lookup rewrite r-uri and append branch) request for Client behind NAT. Due to this reason for one request,Client respond with 486 Busy here. we only want to send 1 INVITE request. Following are the AOR for client at kamailio.if field(ip port) in CONTACT and RECEIVED differ then kamailio send 2 INVITE request. FOLLOWING INVITE HAS BEEN GENERATED AFTER LOOKUP FUNCTION(one from contact and one from Received field). INVITE:sip:123@192.168.230.124:45672 INVITE:sip:123@204.192.206.208:45672 I want only ONE INVITE request to be generated.Please suggest how do solve this issue or if there is any config change or any code change required to achieve this? AOR:: 123 Contact:: sip:123@192.168.230.124:45672 Q=1 Expires:: 894 Callid:: 003A8EC4-12351(a)192.168.230.124 Cseq:: 2 User-agent:: SIPPER for 3CX Phone Received:: sip:204.192.206.208: 45672 State:: CS_NEW Flags:: 0 Cflag:: 192 Socket:: udp:172.12.120.88:5060 Methods:: 4294967295 Ruid:: uloc-5aba112d-7fce-5 Reg-Id:: 0 Last-Keepalive:: 1522144583 Last-Modified:: 1522144583 thanks, amit

2 1

Re: [SR-Users] rare crash at kamailio 5.0.1
by David Escartin 04 Apr '18

04 Apr '18

hello Daniel we have seen today another case, unfortunately i dont have the sip trace but i have the core hope it's useful, it seems the same type of call with the request retransmisions and crashing after a 481 to the last retransmitted request is received (gdb) bt #0 0x00000036e8a32925 in raise () from /lib64/libc.so.6 #1 0x00000036e8a34105 in abort () from /lib64/libc.so.6 #2 0x0000000000654c24 in qm_free (qmp=0x7fab0240a000, p=0x7fabc3405258, file=0x7fabc258cd86 "tm: h_table.c", func=0x7fabc258d070 "free_cell_helper", line=187, mname=0x7fabc258c780 "tm") at core/mem/q_malloc.c:471 #3 0x00007fabc24bbf70 in free_cell_helper (dead_cell=0x7fab09d46d58, silent=0, fname=0x7fabc259da80 "timer.c", fline=651) at h_table.c:187 #4 0x00007fabc2508148 in wait_handler (ti=1191213061, wait_tl=0x7fab09d46dd8, data=0x7fab09d46d58) at timer.c:651 #5 0x0000000000629578 in timer_list_expire (t=1191213061, h=0x7fab02488dc0, slow_l=0x7fab0248a278, slow_mark=22824) at core/timer.c:874 #6 0x00000000006299d4 in timer_handler () at core/timer.c:939 #7 0x0000000000629e73 in timer_main () at core/timer.c:978 #8 0x0000000000422d4e in main_loop () at main.c:1690 #9 0x0000000000429732 in main (argc=13, argv=0x7fff08856238) at main.c:2639 (gdb) frame 4 #4 0x00007fabc2508148 in wait_handler (ti=1191213061, wait_tl=0x7fab09d46dd8, data=0x7fab09d46d58) at timer.c:651 651 UNREF_FREE(p_cell); (gdb) info locals p_cell = 0x7fab09d46d58 ret = 1 (gdb) p *p_cell $1 = {next_c = 0x0, prev_c = 0x0, hash_index = 46289, label = 120110834, flags = 4132, nr_of_outgoings = 2, ref_count = {val = 0}, from = { s = 0x7fab0aeef8f9 "From: <sip:+2917120052@89.221.46.77;user=phone>;tag=SDee0r999-2aabeeae-001e-018f-0000-0000\r\nCall-ID: 4d69d51a-4b78-412f-bd72-114e841a6773\r\nCSeq: 121082247 BYE\r\nMax-Forwards: 68\r\nReason: Q.850; cause=1"..., len = 92}, callid = { s = 0x7fab0aeef955 "Call-ID: 4d69d51a-4b78-412f-bd72-114e841a6773\r\nCSeq: 121082247 BYE\r\nMax-Forwards: 68\r\nReason: Q.850; cause=16\r\nContent-Length: 0\r\nRoute: <sip:200.200.200.176;lr=on;ftag=te9m1e81p4SQp;did=7cc.f229>\r\n\r\n", len = 47}, cseq_n = {s = 0x7fab0aeef984 "CSeq: 121082247 BYE\r\nMax-Forwards: 68\r\nReason: Q.850; cause=16\r\nContent-Length: 0\r\nRoute: <sip:200.200.200.176;lr=on;ftag=te9m1e81p4SQp;did=7cc.f229>\r\n\r\n", len = 15}, to = { s = 0x7fab0aeef893 "To: \"+525768760155\" <sip:+525768760155@200.200.200.176;user=phone;noa=international>;tag=te9m1e81p4SQp\r\nFrom: <sip:+2917120052@89.221.46.77;user=phone>;tag=SDee0r999-2aabeeae-001e-018f-0000-0000\r\nCall-I"..., len = 102}, method = { s = 0x7fab0aeef810 "BYE sip:525768760155@100.100.100.166:5080 SIP/2.0\r\nVia: SIP/2.0/UDP 89.221.46.77:5060;branch=z9hG4bKdjs2la00d06jtanp6sp0sd7od2p32.1\r\nTo: \"+525768760155\" <sip:+525768760155@200.200.200.176;user=phone;noa=i"..., len = 3}, tmcb_hl = {first = 0x7fab028ecf60, reg_types = 131714}, wait_timer = {next = 0x0, prev = 0x0, expire = 1191213061, initial_timeout = 80, data = 0x7fab09d46d58, f = 0x7fabc2508097 <wait_handler>, flags = 513, slow_idx = 0}, uas = {request = 0x7fab0aeef120, end_request = 0x7fab0aef01c8 "\300\300\300\300", response = {activ_type = 481, flags = 128, t_active = 0 '\000', branch = 0, buffer_len = 551, buffer = 0x7fab095c41d0 "SIP/2.0 481 Call Does Not Exist\r\nVia: SIP/2.0/UDP 89.221.46.77:5060;branch=z9hG4bKdjs2la00d06jtanp6sp0sd7od2p32.1\r\nFrom: <sip:+2917120052@89.221.46.77;user=phone>;tag=SDee0r999-2aabeeae-001e-018f-0000"..., my_T = 0x7fab09d46d58, timer = {next = 0x0, prev = 0x0, expire = 0, initial_timeout = 0, data = 0x0, f = 0x7fabc2507b4b <retr_buf_handler>, flags = 0, slow_idx = 0}, dst = {send_sock = 0x7fabc30abb78, to = {s = { sa_family = 2, sa_data = "\023\304Y\335.M\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 1294916953}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 1294916953, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, id = 0, proto = 1 '\001', send_flags = {f = 0 '\000', blst_imask = 0 '\000'}}, retr_expire = 0, fr_expire = 0}, local_totag = {s = 0x0, len = 0}, cancel_reas = 0x0, status = 481}, uac = 0x7fab09d46f60, async_backup = { backup_route = 1, backup_branch = 4294967295, blind_uac = 0, ruri_new = 1}, fwded_totags = 0x0, uri_avps_from = 0x0, uri_avps_to = 0x0, user_avps_from = 0x0, user_avps_to = 0x0, domain_avps_from = 0x0, domain_avps_to = 0x0, xavps_list = 0x0, reply_mutex = {val = 0}, reply_locker_pid = {val = 0}, reply_rec_lock_level = 0, fr_timeout = 480, fr_inv_timeout = 1920, rt_t1_timeout_ms = 650, rt_t2_timeout_ms = 4000, end_of_life = 1191213094, relayed_reply_branch = 1, on_failure = 0, on_branch_failure = 0, on_reply = 0, on_branch = 0, on_branch_delayed = 0, md5 = 0x7fab09d46d58 ""} (gdb) frame 3 #3 0x00007fabc24bbf70 in free_cell_helper (dead_cell=0x7fab09d46d58, silent=0, fname=0x7fabc259da80 "timer.c", fline=651) at h_table.c:187 187 sip_msg_free_unsafe(rpl); (gdb) info locals b = 0x0 i = 1 rpl = 0x7fabc3404fc0 tt = 0x0 foo = 0x7fab02609330 cbs = 0x0 cbs_tmp = 0x7fab02f8f160 __FUNCTION__ = "free_cell_helper" (gdb) p *rpl $2 = {id = 3275772056, pid = 32683, tval = {tv_sec = 320, tv_usec = 140375688591576}, fwd_send_flags = {f = 2 '\002', blst_imask = 0 '\000'}, rpl_send_flags = {f = 0 '\000', blst_imask = 0 '\000'}, first_line = {type = 2116, flags = -16723, len = 32683, u = {request = {method = {s = 0x7 <Address 0x7 out of bounds>, len = 0}, uri = {s = 0x0, len = 1}, version = {s = 0x8381 <Address 0x8381 out of bounds>, len = -1022510864}, method_value = 0}, reply = {version = {s = 0x7 <Address 0x7 out of bounds>, len = 0}, status = {s = 0x0, len = 1}, reason = {s = 0x8381 <Address 0x8381 out of bounds>, len = -1022510864}, statuscode = 0}}}, via1 = 0x0, via2 = 0x7fabc3405038, headers = 0x7fff08852000, last_header = 0x1, parsed_flag = 140375615146059, h_via1 = 0x2, h_via2 = 0x7fabbead084d, callid = 0x8, to = 0xa00000002, cseq = 0x0, from = 0x7fabc30db8f0, contact = 0x0, maxforwards = 0x0, route = 0x7fabc3405258, record_route = 0x7fff08852000, content_type = 0x0, content_length = 0x0, authorization = 0x0, expires = 0x0, proxy_auth = 0x0, supported = 0x0, require = 0x0, proxy_require = 0x0, unsupported = 0x0, allow = 0x0, event = 0x0, accept = 0x0, accept_language = 0x0, organization = 0x0, priority = 0x0, subject = 0x0, user_agent = 0x0, server = 0x0, content_disposition = 0x0, diversion = 0x0, rpid = 0x0, refer_to = 0x0, session_expires = 0x0, min_se = 0x0, sipifmatch = 0x0, subscription_state = 0x0, date = 0x0, identity = 0x0, identity_info = 0x0, pai = 0x0, ppi = 0x0, path = 0x0, privacy = 0x0, min_expires = 0x0, body = 0x0, eoh = 0x0, unparsed = 0x0, rcv = {src_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, dst_ip = {af = 3233857728, len = 0, u = {addrl = {2882400237, 0}, addr32 = {2882400237, 0, 0, 0}, addr16 = {61421, 43981, 0, 0, 0, 0, 0, 0}, addr = "\355\357ͫ", '\000' <repeats 11 times>}}, src_port = 0, dst_port = 0, proto_reserved1 = 0, proto_reserved2 = 536, src_su = {s = { sa_family = 0, sa_data = "\000\000 \266\rë\177\000\000\030\002\000"}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 3272455712}, sin_zero = "\253\177\000\000\030\002\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 3272455712, sin6_addr = {__in6_u = {__u6_addr8 = "\253\177\000\000\030\002\000\000\000\000\000\000\210T@", <incomplete sequence \303>, __u6_addr16 = {32683, 0, 536, 0, 0, 0, 21640, 49984}, __u6_addr32 = {32683, 536, 0, 3275773064}}}, sin6_scope_id = 32683}}, bind_address = 0x7fabbe8bebb0, proto = 32 ' '}, buf = 0x7fabbe8beba6 "rtpengine", len = 139, new_uri = { s = 0xf0f0f0f0 <Address 0xf0f0f0f0 out of bounds>, len = -1019194352}, dst_uri = {s = 0x48 <Address 0x48 out of bounds>, len = -1019195456}, parsed_uri_ok = 4, parsed_uri = {user = {s = 0x7fabbe8beba2 "d", len = 1}, passwd = {s = 0x7fabbe8beba0 "e", len = 1}, host = {s = 0x360000000d <Address 0x360000000d out of bounds>, len = 1}, port = {s = 0x7fabc30db8f0 "\004", len = -1019194448}, params = {s = 0x7fabc3405658 "\002", len = -1019193512}, sip_params = {s = 0x7fff08852000 "\260\305@ë\177", len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, transport = {s = 0x0, len = 0}, ttl = { s = 0x7fabc3405538 "\001", len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x7fabc34055f8 "\001", len = 0}, r2 = {s = 0x7fabc34053b0 "\001", len = 0}, gr = { s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = { s = 0x1 <Address 0x1 out of bounds>, len = -1095956394}, r2_val = {s = 0x2 <Address 0x2 out of bounds>, len = -1095956392}, gr_val = {s = 0x6 <Address 0x6 out of bounds>, len = 2}}, parsed_orig_ruri_ok = 0, parsed_orig_ruri = {user = {s = 0x7fabc3405258 "\004", len = 0}, passwd = {s = 0x0, len = -1019194152}, host = {s = 0x7fff08852000 "\260\305@ë\177", len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 49344, proto = 49344, type = ERROR_URI_T, flags = 2882400237, transport = {s = 0x0, len = 0}, ttl = {s = 0x218 <Address 0x218 out of bounds>, len = -1019195512}, user_param = {s = 0x218 <Address 0x218 out of bounds>, len = -1019193592}, maddr = {s = 0x7fabbe8bebb0 "rtpengine: bencode.c", len = -1098125280}, method = {s = 0x7fabbe8beba6 "rtpengine", len = 139}, lr = {s = 0xf0f0f0f0 <Address 0xf0f0f0f0 out of bounds>, len = -1019193672}, r2 = {s = 0x20 <Address 0x20 out of bounds>, len = -1019194816}, gr = {s = 0x1 <Address 0x1 out of bounds>, len = -1095956386}, transport_val = { s = 0x2 <Address 0x2 out of bounds>, len = -1095956384}, ttl_val = {s = 0x4 <Address 0x4 out of bounds>, len = 2}, user_param_val = {s = 0x0, len = -1019194792}, maddr_val = {s = 0x0, len = 0}, method_val = { s = 0x7fabc3405538 "\001", len = 142942208}, lr_val = {s = 0x1 <Address 0x1 out of bounds>, len = -1095956380}, r2_val = {s = 0x2 <Address 0x2 out of bounds>, len = -1095956378}, gr_val = { s = 0x7 <Address 0x7 out of bounds>, len = 2}}, add_rm = 0x0, body_lumps = 0x7fabc3405258, reply_lump = 0x0, add_to_branch_s = "\000\000\000\000\000\000\000\000\230U@ë\177\000\000\000 \205\b\377\177\000\000\001\000\000\000\000\000\000\000m\b\255\276\253\177\000\000\003\000\000\000\000\000\000\000p\b\255\276\253\177\000\000\r", add_to_branch_len = 0, hash_index = 2, msg_flags = 16, flags = 0, set_global_address = {s = 0x7fabc3405258 "\004", len = 0}, set_global_port = {s = 0x0, len = -1019193864}, force_send_socket = 0x7fff08852000, path_vec = { s = 0x1 <Address 0x1 out of bounds>, len = -1095956355}, instance = {s = 0x2 <Address 0x2 out of bounds>, len = -1095956353}, reg_id = 4, ruid = {s = 0x600000002 <Address 0x600000002 out of bounds>, len = 0}, location_ua = { s = 0x7fabc3405258 "\004", len = 0}, ldv = {flow = {decoded = 0, rcv = {src_ip = {af = 3275773528, len = 32683, u = {addrl = {140733336330240, 2}, addr32 = {142942208, 32767, 2, 0}, addr16 = {8192, 2181, 32767, 0, 2, 0, 0, 0}, addr = "\000 \205\b\377\177\000\000\002\000\000\000\000\000\000"}}, dst_ip = {af = 3199010947, len = 32683, u = {addrl = {7, 0}, addr32 = {7, 0, 0, 0}, addr16 = {7, 0, 0, 0, 0, 0, 0, 0}, addr = "\a", '\000' <repeats 14 times>}}, src_port = 0, dst_port = 0, proto_reserved1 = 0, proto_reserved2 = 1, src_su = {s = {sa_family = 7, sa_data = "\000\000\273\203\000\000\000\000\000\000XR@", <incomplete sequence \303>}, sin = {sin_family = 7, sin_port = 0, sin_addr = {s_addr = 33723}, sin_zero = "\000\000\000\000XR@", <incomplete sequence \303>}, sin6 = {sin6_family = 7, sin6_port = 0, sin6_flowinfo = 33723, sin6_addr = {__in6_u = {__u6_addr8 = "\000\000\000\000XR@ë\177\000\000\000\000\000", __u6_addr16 = {0, 0, 21080, 49984, 32683, 0, 0, 0}, __u6_addr32 = {0, 3275772504, 32683, 0}}}, sin6_scope_id = 0}}, bind_address = 0x0, proto = 0 '\000'}}}} best regards david On 02/04/18 09:33, David Escartin wrote: > > hello Daniel > > > here you have > > > best regards > > david > > > On 02/04/18 08:26, Daniel-Constantin Mierla wrote: >> >> Hello, >> >> do you have the pcap for such call? >> >> Cheers, >> Daniel >> >> >> On 30.03.18 09:14, David Escartin wrote: >>> >>> Hello all >>> >>> last March 26th we experienced a crash on a 5.0.1 kamailio server >>> and a core was generated. >>> Seems that the call involved in the core generated was doing several >>> retransmisions of a request (expected) and when it finally forwarded >>> the request upstream, seems fter receiving a 481 from a-side, it >>> crashed. >>> >>> here you have the backtrace >>> >>> <154>Mar 26 19:54:03 mad-proxy-inout-1 >>> /usr/local/kamailio/sbin/kamailio[24992]: : <core> >>> [core/mem/q_malloc.c:469]: qm_free(): BUG: qm_free: bad pointer >>> 0x7f247acb5878 (out of memory block!) called from tm: h_table.c: >>> free_cell_helper(187) - aborting >>> >>> (gdb) bt >>> #0 0x00000036e8a32925 in raise () from /lib64/libc.so.6 >>> #1 0x00000036e8a34105 in abort () from /lib64/libc.so.6 >>> #2 0x0000000000654c24 in qm_free (qmp=0x7f23b9cba000, >>> p=0x7f247acb5878, file=0x7f2479e3cd86 "tm: h_table.c", >>> func=0x7f2479e3d070 "free_cell_helper", line=187, >>> mname=0x7f2479e3c780 "tm") at core/mem/q_malloc.c:471 >>> #3 0x00007f2479d6bf16 in free_cell_helper (dead_cell=0x7f23c54fea50, >>> silent=0, fname=0x7f2479e4da80 "timer.c", fline=651) at h_table.c:187 >>> #4 0x00007f2479db8148 in wait_handler (ti=1503818844, >>> wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651 >>> #5 0x0000000000629578 in timer_list_expire (t=1503818844, >>> h=0x7f23b9d38dc0, slow_l=0x7f23b9d3b0c8, slow_mark=43533) at >>> core/timer.c:874 >>> #6 0x00000000006299d4 in timer_handler () at core/timer.c:939 >>> #7 0x0000000000629e73 in timer_main () at core/timer.c:978 >>> #8 0x0000000000422d4e in main_loop () at main.c:1690 >>> #9 0x0000000000429732 in main (argc=13, argv=0x7fff2b9f8088) at >>> main.c:2639 >>> >>> >>> (gdb) frame 4 >>> #4 0x00007f2479db8148 in wait_handler (ti=1503818844, >>> wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651 >>> 651 UNREF_FREE(p_cell); >>> >>> (gdb) info locals >>> p_cell = 0x7f23c54fea50 >>> ret = 1 >>> >>> (gdb) p *p_cell >>> $1 = {next_c = 0x0, prev_c = 0x0, hash_index = 28196, label = >>> 341555146, flags = 4132, nr_of_outgoings = 2, ref_count = {val = 0}, >>> from = { >>> s = 0x7f23c87c79ed "From: >>> <sip:932687220@100.100.100.177;user=phone;noa=national>;tag=50aa4a46-co11146-INS002\r\nCall-ID: >>> b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601 >>> BYE\r\nUser-Agent: ENSR3.0.67.10-IS2-RMRG1119-RG2040"..., len = 89}, >>> callid = { >>> s = 0x7f23c87c7a46 "Call-ID: >>> b8997821-2814-46d3-b8f7-cf690f50f640\r\nCSeq: 1114601 >>> BYE\r\nUser-Agent: >>> ENSR3.0.67.10-IS2-RMRG1119-RG2040-CPI1-CPO2612\r\nContent-Length: >>> 0\r\n\r\n", len = 47}, cseq_n = { >>> s = 0x7f23c87c7a75 "CSeq: 1114601 BYE\r\nUser-Agent: >>> ENSR3.0.67.10-IS2-RMRG1119-RG2040-CPI1-CPO2612\r\nContent-Length: >>> 0\r\n\r\n", len = 13}, to = { >>> s = 0x7f23c87c799e "To: >>> \"34676893111\"<sip:34676893111@100.100.100.134;user=phone>;tag=64jNUpSZK8mSp\r\nFrom: >>> <sip:932687220@100.100.100.177;user=phone;noa=national>;tag=50aa4a46-co11146-INS002\r\nCall-ID: >>> b8997821-2814-46d3-b8f7"..., len = 79}, method = { >>> s = 0x7f23c87c78c8 "BYE sip:34676893111@100.100.100.134:5080 >>> SIP/2.0\r\nVia: SIP/2.0/UDP >>> 200.200.200.78:5060;branch=z9hG4bK2d5c0cb4e11bb1503BYE50aa466c2b8a\r\nMax-Forwards: >>> 34\r\nRoute: <sip:100.100.100.177;lr;ftag=64jNUpSZK8mSp;d"..., len = >>> 3}, tmcb_hl = {first = 0x7f23bd9f7818, reg_types = 131714}, >>> wait_timer = { >>> next = 0x0, prev = 0x0, expire = 1503818844, initial_timeout = 80, >>> data = 0x7f23c54fea50, f = 0x7f2479db8097 <wait_handler>, flags = >>> 513, slow_idx = 0}, >>> uas = {request = 0x7f23c87c71d8, end_request = 0x7f23c87c8288 >>> "\300\300\300\300", response = {activ_type = 481, flags = 128, >>> t_active = 0 '\000', branch = 0, >>> buffer_len = 526, >>> buffer = 0x7f23bef07b18 "SIP/2.0 481 Call Does Not Exist\r\nVia: >>> SIP/2.0/UDP >>> 200.200.200.78:5060;branch=z9hG4bK2d5c0cb4e11bb1503BYE50aa466c2b8a\r\nFrom: >>> <sip:932687220@100.100.100.177;user=phone;noa=national>;tag=50aa4a46-co11146-I"..., >>> my_T = 0x7f23c54fea50, timer = {next = 0x0, prev = 0x0, expire = 0, >>> initial_timeout = 0, data = 0x0, f = 0x7f2479db7b4b >>> <retr_buf_handler>, flags = 0, slow_idx = 0}, dst = {send_sock = >>> 0x7f247a95be78, to = {s = { >>> sa_family = 2, sa_data = >>> "\023\304\325\300\313N\000\000\000\000\000\000\000"}, sin = >>> {sin_family = 2, sin_port = 50195, sin_addr = { >>> s_addr = 1321976021}, sin_zero = "\000\000\000\000\000\000\000"}, >>> sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 1321976021, >>> sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, >>> __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, >>> sin6_scope_id = 0}}, id = 0, proto = 1 '\001', send_flags = {f = 0 >>> '\000', blst_imask = 0 '\000'}}, retr_expire = 0, fr_expire = 0}, >>> local_totag = { >>> s = 0x0, len = 0}, cancel_reas = 0x0, status = 481}, uac = >>> 0x7f23c54fec58, async_backup = {backup_route = 1, backup_branch = >>> 4294967295, blind_uac = 0, >>> ruri_new = 1}, fwded_totags = 0x0, uri_avps_from = 0x0, uri_avps_to >>> = 0x0, user_avps_from = 0x0, user_avps_to = 0x0, domain_avps_from = >>> 0x0, >>> domain_avps_to = 0x0, xavps_list = 0x0, reply_mutex = {val = 0}, >>> reply_locker_pid = {val = 0}, reply_rec_lock_level = 0, fr_timeout = >>> 480, >>> fr_inv_timeout = 1920, rt_t1_timeout_ms = 650, rt_t2_timeout_ms = >>> 4000, end_of_life = 1503819200, relayed_reply_branch = 1, on_failure >>> = 0, >>> on_branch_failure = 0, on_reply = 0, on_branch = 0, >>> on_branch_delayed = 0, md5 = 0x7f23c54fea50 ""} >>> >>> (gdb) frame 3 >>> #3 0x00007f2479d6bf16 in free_cell_helper (dead_cell=0x7f23c54fea50, >>> silent=0, fname=0x7f2479e4da80 "timer.c", fline=651) at h_table.c:187 >>> 187 sip_msg_free_unsafe(rpl); >>> >>> (gdb) info locals >>> b = 0x0 >>> i = 1 >>> rpl = 0x7f247acb4fc0 >>> tt = 0x0 >>> foo = 0x7f23b9e2bd90 >>> cbs = 0x0 >>> cbs_tmp = 0x7f23c60c16b0 >>> __FUNCTION__ = "free_cell_helper" >>> >>> (gdb) p *rpl >>> $3 = {id = 2060145040, pid = 32548, tval = {tv_sec = 72, tv_usec = >>> 139794652378712}, fwd_send_flags = {f = 1 '\001', blst_imask = 0 >>> '\000'}, rpl_send_flags = { >>> f = 0 '\000', blst_imask = 0 '\000'}, first_line = {type = -347, >>> flags = 30263, len = 32548, u = {request = {method = {s = 0x2 >>> <Address 0x2 out of bounds>, >>> len = 1983381159}, uri = {s = 0x5 <Address 0x5 out of bounds>, len = >>> 2}, version = {s = 0x2b <Address 0x2b out of bounds>, len = >>> 2057435688}, >>> method_value = 0}, reply = {version = {s = 0x2 <Address 0x2 out of >>> bounds>, len = 1983381159}, status = {s = 0x5 <Address 0x5 out of >>> bounds>, len = 2}, >>> reason = {s = 0x2b <Address 0x2b out of bounds>, len = 2057435688}, >>> statuscode = 0}}}, via1 = 0x0, via2 = 0x7f247acb5038, headers = >>> 0x7fff2b9f3e50, >>> last_header = 0x4, parsed_flag = 139794576763810, h_via1 = 0x1, >>> h_via2 = 0x7f247616eba0, callid = 0x1, to = 0x270000000b, cseq = >>> 0x1, from = 0x7f247aa1fa28, >>> contact = 0x7f247acb5258, maxforwards = 0x7f247acb54d8, route = 0x0, >>> record_route = 0x7fff2b9f3e50, content_type = 0x7f247acb5318, >>> content_length = 0x0, >>> authorization = 0x0, expires = 0x0, proxy_auth = 0x0, supported = >>> 0x0, require = 0x0, proxy_require = 0x0, unsupported = >>> 0x7f247acb5258, allow = 0x0, >>> event = 0x7f247acb53d8, accept = 0x0, accept_language = 0x0, >>> organization = 0x0, priority = 0x0, subject = 0x0, user_agent = 0x0, >>> server = 0x0, >>> content_disposition = 0x0, diversion = 0x0, rpid = 0x0, refer_to = >>> 0x0, session_expires = 0x0, min_se = 0x0, sipifmatch = 0x0, >>> subscription_state = 0x0, >>> date = 0x0, identity = 0x0, identity_info = 0x0, pai = 0x0, ppi = >>> 0x0, path = 0x7f247a98b6d0, privacy = 0x0, min_expires = 0x0, body = >>> 0x7f247acb5258, >>> eoh = 0x7fff2b9f3e50 "@f\313z$\177", unparsed = 0x0, rcv = {src_ip = >>> {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 >>> = {0, 0, 0, 0, 0, >>> 0, 0, 0}, addr = '\000' <repeats 15 times>}}, dst_ip = {af = >>> 3233857728, len = 0, u = {addrl = {2882400237, 0}, addr32 = >>> {2882400237, 0, 0, 0}, >>> addr16 = {61421, 43981, 0, 0, 0, 0, 0, 0}, addr = "\355\357ͫ", >>> '\000' <repeats 11 times>}}, src_port = 0, dst_port = 0, >>> proto_reserved1 = 0, >>> proto_reserved2 = 536, src_su = {s = {sa_family = 0, sa_data = >>> "\000\000 \266\230z$\177\000\000\030\002\000"}, sin = {sin_family = >>> 0, sin_port = 0, >>> sin_addr = {s_addr = 2056828448}, sin_zero = >>> "$\177\000\000\030\002\000"}, sin6 = {sin6_family = 0, sin6_port = >>> 0, sin6_flowinfo = 2056828448, >>> sin6_addr = {__in6_u = {__u6_addr8 = >>> "$\177\000\000\030\002\000\000\000\000\000\000\210T\313z", >>> __u6_addr16 = {32548, 0, 536, 0, 0, 0, 21640, 31435}, >>> __u6_addr32 = {32548, 536, 0, 2060145800}}}, sin6_scope_id = >>> 32548}}, bind_address = 0x7f247616ebb0, proto = 32 ' '}, >>> buf = 0x7f247616eba6 "rtpengine", len = 139, new_uri = {s = >>> 0xf0f0f0f0 <Address 0xf0f0f0f0 out of bounds>, len = 2060145720}, >>> dst_uri = { >>> s = 0x20 <Address 0x20 out of bounds>, len = 2060144576}, >>> parsed_uri_ok = 1, parsed_uri = {user = { >>> s = 0x7f247637fead >>> "7:packetsi32e5:bytesi1896e6:errorsi0eeee5:flagsl11:initialized4:send4:recveeeee6:totalsd3:RTPd7:packetsi4951e5:bytesi158432e6:errorsi0ee4:RTCPd7:packetsi32e5:bytesi1896e6:errorsi0eee6:result2:oke", >>> len = 2}, passwd = { >>> s = 0x7f247637feaf >>> "packetsi32e5:bytesi1896e6:errorsi0eeee5:flagsl11:initialized4:send4:recveeeee6:totalsd3:RTPd7:packetsi4951e5:bytesi158432e6:errorsi0ee4:RTCPd7:packetsi32e5:bytesi1896e6:errorsi0eee6:result2:oke", >>> len = 7}, host = {s = 0x900000002 <Address 0x900000002 out of >>> bounds>, len = 1}, port = { >>> s = 0x7f247acb5038 "\004", len = 0}, params = {s = 0x0, len = >>> 2060145336}, sip_params = {s = 0x7fff2b9f3e50 "@f\313z$\177", len = >>> 2}, headers = { >>> s = 0x7f247637feb6 >>> "i32e5:bytesi1896e6:errorsi0eeee5:flagsl11:initialized4:send4:recveeeee6:totalsd3:RTPd7:packetsi4951e5:bytesi158432e6:errorsi0ee4:RTCPd7:packetsi32e5:bytesi1896e6:errorsi0eee6:result2:oke", >>> len = 4}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, >>> transport = { >>> s = 0x400000001 <Address 0x400000001 out of bounds>, len = 32}, ttl >>> = {s = 0x7f247acb5038 "\004", len = 0}, user_param = {s = 0x0, len = >>> 2060145432}, >>> maddr = {s = 0x7fff2b9f3e50 "@f\313z$\177", len = 1}, method = { >>> s = 0x7f247637feba >>> "5:bytesi1896e6:errorsi0eeee5:flagsl11:initialized4:send4:recveeeee6:totalsd3:RTPd7:packetsi4951e5:bytesi158432e6:errorsi0ee4:RTCPd7:packetsi32e5:bytesi1896e6:errorsi0eee6:result2:oke", >>> len = 2}, lr = { >>> s = 0x7f247637febc >>> "bytesi1896e6:errorsi0eeee5:flagsl11:initialized4:send4:recveeeee6:totalsd3:RTPd7:packetsi4951e5:bytesi158432e6:errorsi0ee4:RTCPd7:packetsi32e5:bytesi1896e6:errorsi0eee6:result2:oke", >>> len = 5}, r2 = {s = 0x700000002 <Address 0x700000002 out of bounds>, >>> len = 1522079939}, gr = { >>> s = 0x7f247acb5038 "\004", len = 0}, transport_val = {s = 0x0, len = >>> 2060145528}, ttl_val = {s = 0x7fff2b9f3e50 "@f\313z$\177", len = 2}, >>> user_param_val = { >>> s = 0x7f247637fec1 >>> "i1896e6:errorsi0eeee5:flagsl11:initialized4:send4:recveeeee6:totalsd3:RTPd7:packetsi4951e5:bytesi158432e6:errorsi0ee4:RTCPd7:packetsi32e5:bytesi1896e6:errorsi0eee6:result2:oke", >>> len = 6}, maddr_val = {s = 0x0, len = 0}, method_val = {s = >>> 0x600000001 <Address 0x600000001 out of bounds>, >>> len = 1896}, lr_val = {s = 0x7f247acb5038 "\004", len = 0}, r2_val = >>> {s = 0x0, len = 2060145624}, gr_val = {s = 0x7fff2b9f3e50 >>> "@f\313z$\177", len = 1}}, >>> parsed_orig_ruri_ok = 1983381191, parsed_orig_ruri = {user = {s = >>> 0x2 <Address 0x2 out of bounds>, len = 1983381193}, passwd = { >>> s = 0x6 <Address 0x6 out of bounds>, len = 2}, host = {s = 0x0, len >>> = 2060144696}, port = {s = 0x0, len = 0}, params = {s = >>> 0x7f247acb54d8 "\002", >>> ---Type <return> to continue, or q <return> to quit--- >>> len = 731856464}, sip_params = {s = 0x0, len = 0}, headers = {s = >>> 0x0, len = 0}, port_no = 49344, proto = 49344, type = ERROR_URI_T, >>> flags = 2882400237, >>> transport = {s = 0x0, len = 0}, ttl = {s = 0x218 <Address 0x218 out >>> of bounds>, len = 2060144520}, user_param = {s = 0x218 <Address >>> 0x218 out of bounds>, >>> len = 2060146440}, maddr = {s = 0x7f247616ebb0 "rtpengine: >>> bencode.c", len = 1981214752}, method = {s = 0x7f247616eba6 >>> "rtpengine", len = 139}, lr = { >>> s = 0xf0f0f0f0 <Address 0xf0f0f0f0 out of bounds>, len = >>> 2060146360}, r2 = {s = 0x20 <Address 0x20 out of bounds>, len = >>> 2060145216}, gr = { >>> s = 0x2 <Address 0x2 out of bounds>, len = 1983381199}, >>> transport_val = {s = 0x3 <Address 0x3 out of bounds>, len = 0}, >>> ttl_val = {s = 0x0, len = 1}, >>> user_param_val = {s = 0x0, len = 2060144696}, maddr_val = {s = 0x0, >>> len = 0}, method_val = {s = 0x0, len = 731856464}, lr_val = { >>> s = 0x1 <Address 0x1 out of bounds>, len = 1983381205}, r2_val = {s >>> = 0x2 <Address 0x2 out of bounds>, len = 1983381207}, gr_val = { >>> s = 0x5 <Address 0x5 out of bounds>, len = 2}}, add_rm = >>> 0x7f247acb5878, body_lumps = 0x7f247aa43300, reply_lump = 0x0, >>> add_to_branch_s = >>> "\000\000\000\000\000\000\000\000\230U\313z$\177\000\000P>\237+\377\177\000\000\003\000\000\000\000\000\000\000\244\353\026v$\177\000\000\001\000\000\000\000\000\000\000\240\353\026v$\177\000\000\001", >>> add_to_branch_len = 0, hash_index = 8, msg_flags = 28, flags = >>> 2060162240, set_global_address = { >>> s = 0x7f247aa43300 "\004", len = 2060146168}, set_global_port = {s = >>> 0x7f247acb5758 "\001", len = 0}, force_send_socket = 0x7fff2b9f3e50, >>> path_vec = { >>> s = 0x1 <Address 0x1 out of bounds>, len = 1983381213}, instance = >>> {s = 0x3 <Address 0x3 out of bounds>, len = 1983381216}, reg_id = >>> 11, ruid = { >>> s = 0xe00000002 <Address 0xe00000002 out of bounds>, len = 0}, >>> location_ua = {s = 0x7f247acb5598 "\003", len = 0}, ldv = {flow = >>> {decoded = 0, rcv = { >>> src_ip = {af = 2060146264, len = 32548, u = {addrl = >>> {140733925244496, 30064771073}, addr32 = {731856464, 32767, 1, 7}, >>> addr16 = {15952, 11167, 32767, >>> 0, 1, 0, 7, 0}, addr = >>> "P>\237+\377\177\000\000\001\000\000\000\a\000\000"}}, dst_ip = {af >>> = 1983381227, len = 32548, u = {addrl = {2, >>> 139794578931437}, addr32 = {2, 0, 1983381229, 32548}, addr16 = {2, >>> 0, 0, 0, 65261, 30263, 32548, 0}, >>> addr = "\002\000\000\000\000\000\000\000\355\376\067v$\177\000"}}, >>> src_port = 4, dst_port = 0, proto_reserved1 = 0, proto_reserved2 = >>> 2, src_su = { >>> s = {sa_family = 6, sa_data = >>> "\000\000P>\237+\377\177\000\000\230U\313z"}, sin = {sin_family = 6, >>> sin_port = 0, sin_addr = {s_addr = 731856464}, >>> sin_zero = "\377\177\000\000\230U\313z"}, sin6 = {sin6_family = 6, >>> sin6_port = 0, sin6_flowinfo = 731856464, sin6_addr = {__in6_u = { >>> __u6_addr8 = "\377\177\000\000\230U\313z$\177\000\000\000\000\000", >>> __u6_addr16 = {32767, 0, 21912, 31435, 32548, 0, 0, 0}, __u6_addr32 = { >>> 32767, 2060146072, 32548, 0}}}, sin6_scope_id = 0}}, bind_address = >>> 0x0, proto = 88 'X'}}}} >>> (gdb) >>> >>> (gdb) bt full >>> #0 0x00000036e8a32925 in raise () from /lib64/libc.so.6 >>> No symbol table info available. >>> #1 0x00000036e8a34105 in abort () from /lib64/libc.so.6 >>> No symbol table info available. >>> #2 0x0000000000654c24 in qm_free (qmp=0x7f23b9cba000, >>> p=0x7f247acb5878, file=0x7f2479e3cd86 "tm: h_table.c", >>> func=0x7f2479e3d070 "free_cell_helper", line=187, >>> mname=0x7f2479e3c780 "tm") at core/mem/q_malloc.c:471 >>> qm = 0x7f23b9cba000 >>> f = 0x7f23bc87a2c8 >>> size = 528 >>> next = 0x400 >>> prev = 0x7fff2b9f7920 >>> __FUNCTION__ = "qm_free" >>> #3 0x00007f2479d6bf16 in free_cell_helper (dead_cell=0x7f23c54fea50, >>> silent=0, fname=0x7f2479e4da80 "timer.c", fline=651) at h_table.c:187 >>> b = 0x0 >>> i = 1 >>> rpl = 0x7f247acb4fc0 >>> tt = 0x0 >>> foo = 0x7f23b9e2bd90 >>> cbs = 0x0 >>> cbs_tmp = 0x7f23c60c16b0 >>> __FUNCTION__ = "free_cell_helper" >>> #4 0x00007f2479db8148 in wait_handler (ti=1503818844, >>> wait_tl=0x7f23c54fead0, data=0x7f23c54fea50) at timer.c:651 >>> p_cell = 0x7f23c54fea50 >>> ret = 1 >>> #5 0x0000000000629578 in timer_list_expire (t=1503818844, >>> h=0x7f23b9d38dc0, slow_l=0x7f23b9d3b0c8, slow_mark=43533) at >>> core/timer.c:874 >>> tl = 0x7f23c54fead0 >>> ret = 0 >>> #6 0x00000000006299d4 in timer_handler () at core/timer.c:939 >>> saved_ticks = 1503818844 >>> run_slow_timer = 0 >>> i = 525 >>> __FUNCTION__ = "timer_handler" >>> #7 0x0000000000629e73 in timer_main () at core/timer.c:978 >>> No locals. >>> #8 0x0000000000422d4e in main_loop () at main.c:1690 >>> i = 1 >>> pid = 0 >>> si = 0x0 >>> si_desc = "udp receiver child=0 sock=100.100.100.169:5060", '\000' >>> <repeats 16 times>, >>> "\001\000\000\000\340|\237+\377\177\000\000W\327e\000\000\000\000\000\200\335u\000\000\000\000\000\250\065\313zo\000\000\000\316\357u\000\000\000\000\000\205\335u\000\000\000\000\000\004\000\000\000\000\000\000\000\000\240˹#\177---Type >>> <return> to continue, or q <return> to quit--- >>> \000" >>> nrprocs = 1 >>> woneinit = 1 >>> __FUNCTION__ = "main_loop" >>> #9 0x0000000000429732 in main (argc=13, argv=0x7fff2b9f8088) at >>> main.c:2639 >>> cfg_stream = 0x1f8f010 >>> c = -1 >>> r = 0 >>> tmp = 0x7fff2b9f8742 "" >>> tmp_len = 54 >>> port = -398323320 >>> proto = 54 >>> options = 0x732e78 >>> ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" >>> ret = -1 >>> seed = 3083103015 >>> rfd = 4 >>> debug_save = 0 >>> debug_flag = 0 >>> dont_fork_cnt = 0 >>> n_lst = 0x36e8a90687 >>> p = 0x7fff2b9f7f88 "\200\200\237+\377\177" >>> st = {st_dev = 2307, st_ino = 9183277, st_nlink = 3, st_mode = >>> 16832, st_uid = 522, st_gid = 501, __pad0 = 0, st_rdev = 0, st_size >>> = 4096, >>> st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1496231473, >>> tv_nsec = 0}, st_mtim = {tv_sec = 1520405673, tv_nsec = 0}, st_ctim = { >>> tv_sec = 1520405673, tv_nsec = 0}, __unused = {0, 0, 0}} >>> __FUNCTION__ = "main" >>> (gdb) >>> >>> i dont know if you can help us to know the reason of the crash, >>> because the call trace seemed quite normal, and we don't know if the >>> cause was from the rtpengine responses of the bye requests, or was >>> caused by the request retransmisions, which would be rare because we >>> sometimes have those type of calls. >>> >>> thanks a lot and regards >>> >>> david >>> >>> >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users(a)lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> Daniel-Constantin Mierla >> www.twitter.com/miconda --www.linkedin.com/in/miconda >> Kamailio Advanced Training - April 16-18, 2018, Berlin -www.asipto.com >> Kamailio World Conference - May 14-16, 2018 -www.kamailioworld.com >

2 1

In-dialog BYE request, how to return back to original sender ?
by Loic Chabert 04 Apr '18

04 Apr '18

Hi list, I'm facing an routing issue with the following sip infrastructure: ASTERISK 1 ---\___ Kamailio proxy ____ Kamailio frontend ___ IPBX ASTERISK 2 ---/ And please find below desired call-flow: 1 - An asterisk 1 server send a call to a proxy 2 - This proxy make a location lookup, and send it to kamailio frontend proxy 3 - Frontend proxy relay to Wazo PBX (for example) 4 - Callee respond ... 5 - Callee hangup the call, so Wazo PBX send a BYE request to kamailio frontend proxy 6 - Based on Route headers, frontend forward BYE request to proxy 7 - ... here cames issues ... Question is simple (but answer will be probably more complex): how can i sent in dialog BYE request to ASTERISK 1, and not asterisk 2. Should i use dispatcher module ? Should i use specials headers to send back to Asterisk 1 the BYE request ? What is the normal behaviour for in-dialog requests ? I can't find any answers on SIP RFCs or any archived messages on mailing list. Thanks in advance, Best regards.

2 3

subnet match
by volga629＠networklab.ca 03 Apr '18

03 Apr '18

Hello Everyone, Not sure what I am missing, but can't match ip address to subnet Log says INFO: <script>: Subnets not match processing rtp...destination ip [10.0.1.242] and sourceip [10.0.1.241] if(is_method("INVITE")) { $avp(destip)=$(du{s.select,1,:}); $avp(subnet) = $avp(destip) + "/16"; xlog("L_INFO", "Initial Request: [$rm] destination ip [$avp(destip)] and sourceip [$si]\n"); if(!is_in_subnet("$si", "$avp(subnet)")) { xlog("L_INFO", "Subnets not match processing rtp...destination ip [$avp(subnet)] and source ip [$si]\n"); route(RTP_MANAGE); } } [root@prx00 ~]# rpm -qa | grep kamailio kamailio-mysql-5.1.2-2.git4c840b7e9.fc27.x86_64 kamailio-5.1.2-2.git4c840b7e9.fc27.x86_64 Slava.

3 12

KEMI get_body_part
by Igor Olhovskiy 02 Apr '18

02 Apr '18

Hi! I’m trying to get SDP body in my var. I’m using smth like this if (KSR.textops.has_body() ~= -1 and KSR.textops.has_body_type("application/sdp") ~= -1) then KSR.textops.get_body_part("application/sdp", "$var(pbody)») local sdp_body = KSR.pv.get("$var(pbody)") …. end But in logs i see this LUA {INVITE}: 7(20794) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=470 LUA {INVITE}: 7(20794) DEBUG: app_lua [app_lua_sr.c:1496]: sr_kemi_lua_exec_func_ex(): param[0] for: has_body_type is str: application/sdp LUA {INVITE}: 7(20794) DEBUG: textops [textops.c:3083]: has_body_helper(): content type is 196611 LUA {INVITE}: 7(20794) DEBUG: app_lua [app_lua_sr.c:1496]: sr_kemi_lua_exec_func_ex(): param[0] for: get_body_part is str: application/sdp LUA {INVITE}: 7(20794) DEBUG: app_lua [app_lua_sr.c:1496]: sr_kemi_lua_exec_func_ex(): param[1] for: get_body_part is str: $var(pbody) LUA {INVITE}: 7(20794) DEBUG: <core> [core/pvapi.c:396]: pv_cache_lookup(): pvar [$var(pbody)] found in cache LUA {INVITE}: 7(20794) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header LUA {INVITE}: 7(20794) INFO: <core> [core/msg_translator.c:1694]: get_boundary(): Content-Type hdr has no params <application/sdp> LUA {INVITE}: 7(20794) ERROR: textops [textops.c:2468]: ki_get_body_part_helper(): Cannot get boundary. Is body multipart? So, in sdp_body var i got 0. What is wrong here? Regards, Igor

2 3

topos redis -> failed to store
by Abdoul Osséni 02 Apr '18

02 Apr '18

Hello list, I activated topos and topos_redis backend. Now, I have the following errors: Jan 6 07:34:11 sd-110402 /usr/local/sbin/kamailio[30288]: {1 102 NOTIFY 645f4b58537f9df53b9ce65f4937d652@163.172.83.169:5064} ERROR: topos [tps_storage.c:394]: tps_storage_record(): failed to store Jan 6 07:34:11 sd-110402 /usr/local/sbin/kamailio[30292]: {1 102 NOTIFY 5b678085378e62c12c6f18154501feb3@163.172.83.169:5064} INFO: topos_redis [topos_redis_storage.c:163]: tps_redis_insert_dialog(): no uuid for this message Jan 6 07:34:11 sd-110402 /usr/local/sbin/kamailio[30292]: {1 102 NOTIFY 5b678085378e62c12c6f18154501feb3@163.172.83.169:5064} ERROR: topos [tps_storage.c:394]: tps_storage_record(): failed to store Jan 6 07:34:18 sd-110402 /usr/local/sbin/kamailio[30287]: {1 102 NOTIFY 2799d4a61e9defbc66dc67735e1c6e6c@163.172.83.169:5064} INFO: topos_redis [topos_redis_storage.c:163]: tps_redis_insert_dialog(): no uuid for this message Jan 6 07:34:18 sd-110402 /usr/local/sbin/kamailio[30287]: {1 102 NOTIFY 2799d4a61e9defbc66dc67735e1c6e6c@163.172.83.169:5064} ERROR: topos [tps_storage.c:394]: tps_storage_record(): failed to store Jan 6 07:34:18 sd-110402 /usr/local/sbin/kamailio[30290]: {1 102 NOTIFY 760fe2ce3427748514441de25cade2e4@163.172.83.169:5064} INFO: topos_redis [topos_redis_storage.c:163]: tps_redis_insert_dialog(): no uuid for this message Jan 6 07:34:18 sd-110402 /usr/local/sbin/kamailio[30290]: {1 102 NOTIFY 760fe2ce3427748514441de25cade2e4@163.172.83.169:5064} ERROR: topos [tps_storage.c:394]: tps_storage_record(): failed to store Jan 6 07:34:33 sd-110402 /usr/local/sbin/kamailio[30291]: {1 102 NOTIFY 7464fc2b503427423b0aba925fb13bc7@163.172.83.169:5064} INFO: topos_redis [topos_redis_storage.c:163]: tps_redis_insert_dialog(): no uuid for this message Jan 6 07:34:33 sd-110402 /usr/local/sbin/kamailio[30291]: {1 102 NOTIFY 7464fc2b503427423b0aba925fb13bc7@163.172.83.169:5064} ERROR: topos [tps_storage.c:394]: tps_storage_record(): failed to store Jan 6 07:34:35 sd-110402 /usr/local/sbin/kamailio[30287]: {1 102 NOTIFY 581e88181527f4221fbc7f893a564d6a@163.172.83.169:5064} INFO: topos_redis [topos_redis_storage.c:163]: tps_redis_insert_dialog(): no uuid for this message Jan 6 07:34:35 sd-110402 /usr/local/sbin/kamailio[30287]: {1 102 NOTIFY 581e88181527f4221fbc7f893a564d6a@163.172.83.169:5064} ERROR: topos [tps_storage.c:394]: tps_storage_record(): failed to store Could you help me to fix it? Abdoul OSSENI

3 8

How to extract SIP-I ISUP parameters
by Eugene Prokopiev 02 Apr '18

02 Apr '18

Hi, I need to extract ISUP parameter 'Redirecting number' from SIP-I INVITE request and add it as SIP header with 'X-' prefix to process in FreeSWITCH. I tried to read https://kamailio.org/docs/modules/5.1.x/modules/sipt.html (but it is about updating headers) and https://kamailio.org/docs/modules/5.1.x/modules/ss7ops.html (but I have only ISUP encapsulated in SIP), so not found any solution. Help me to find it please. -- WBR, Eugene Prokopiev

2 7

audio issues
by Atux Atux 02 Apr '18

02 Apr '18

Hi. I am doing my first steps with Kamailio and i have installed it according to the http://kb.asipto.com/kamailio:skype-like-service-in-less-than-one-hour. i did create 3 users 1100,1101,1102 and then in windows PC i did install the jitsi application. Even though the accounts on Jitsi show as online on each PC i have audio issues. All PCs are in the same LAN -Device 1101 calls 1102 and on 1102 i cannot hear anything. 1102 talks and it cannot be heard -Device 1102 calls device 1101 and on 1101 PC i hear a ringing tone. Then i answer from 1101. 1102 speaks and it can be heard, not the other way around. any ideas, please?

2 1

KEMI and SQL - best practices
by Igor Olhovskiy 02 Apr '18

02 Apr '18

Hi! Is there any suggestions, best practices of using SQL connections in KEMI? Main idea - not to open connection to database in every route (cause it’s really expensive operation in terms of time) and reuse existing, for ex, created in some kind of startup route? Or maybe use some else technique? Regards, Igor

2 1

Russian meddling in Kamailio project
by Alex Balashov 01 Apr '18

01 Apr '18

(Filed by the Geostrategic Open Source Alliance.) ATLANTA, GA (1 April 2018)--In a twist of events that has shocked the global technical community, the well-known open-source VoIP professional Alex Balashov has revealed himself to be a deep cover intelligence operative of the GRU (Main Intelligence Directorate of the military of the Russian Federation) and the FSB (the Federal Security Bureau, the successor agency to the Soviet-era KGB). Balashov was reported to be seeking US political asylum and immunity from prosecution in return for an exposé of the ways in which the Russian foreign intelligence apparatus has sought to influence the direction of the open-source communications project "Kamailio", widely used in telecommunications carrier, service provider and enterprise environments to deliver high-scalability routing services and other SIP (Session Initiation Protocol) platform building blocks. In connection with these sensitive ongoing negotiations, Balashov was debriefed on behalf of the US Government by Fred Posner of The Palner Group, a counterintelligence think tank and security consulting firm based in Gainesville, Florida. This debriefing was coordinated with the German BND (Bundesnachrichtendienst) agency and other agencies representing security cooperation partners of the European Union and NATO. GOSA have been able to obtain exclusive excerpts from the portions of this interview not deemed top secret: POSNER: Please state your full name, age, place of birth, physical characteristics, serial number and any other relevant professional asset identification markers. BALASHOV: [redacted] POSNER: You have made the claim that Kamailio has been infiltrated by Russian spy agencies. Given that it's an open-source project, that's a bold and provocative claim. Where's the evidence? BALASHOV: Infiltration is perhaps strong word from spy novels. Reality is less thrilling. As you are knowing from controversy about election of our Donald, covert global influence today is mainly question of soft power. POSNER: Is there an obvious way in which this applies to the Kamailio project you can show us? I remind you that you have staked your personal freedom on this issue. BALASHOV: Influence is delicate matter. Da, of course there are some superficial indications... POSNER: Such as? BALASHOV: For example module to support language Squirrel. What is Squirrel? Who uses it? If you take a look at code is a bit complicated, da? What does it do? POSNER: It is a bit complicated, But I'm not convinced. Sell me. BALASHOV: It was in fact committed to GitHub by former Eastern Bloc personality, yes? Very complicated code for unknown mystery language support from Eastern Europe... POSNER: Yes, from the main developer and leader of the project. BALASHOV: Hmm. POSNER: What else? BALASHOV: There is a Ukranian [redacted] who is in charge of many SIP captures with system which diverts them to central database, yes? Something with name from ancient Greek troubadour or myths maybe? POSNER: We'll have to look into that. BALASHOV: Kamailio World is held every year in East Berlin. Every year back to Berlin. POSNER: So what? BALASHOV: Where do most guests of it spend their night? POSNER: [audible crack of pistol whip] This is not a quiz show! I ask the questions here. BALASHOV: Yes, yes, okay, they are at the Park Inn at Alexanderplatz. POSNER: And? BALASHOV: The history of this hotel in East German times and Stasi presence there... POSNER: That aspect of history is well-known. BALASHOV: Da... then is clear. POSNER: What are the strategic goals of Russia with regard to open source communication infrastructure? BALASHOV: From news lately can be seen that is soft power leveraging and economic sabotage. POSNER: Economic sabotage? How will they achieve that with open source? BALASHOV: Again is question of delicate influence in small ways. This is not time of Arab dignitaries visiting KGB hotels in Moscow in 1970s or this kind of naked and obvious trick. POSNER: [raises pistol] You are here to provide specifics. BALASHOV: Yes yes, okay. Well, I am not policy architect at Khoroshovskoe Shosse, but general point of view with colleagues is that best approach to Western countries is to encourage kind of "boondoggles" [air quotes] which consume large economic resources with very little benefit. POSNER: Does Russia create boondoggles in America? BALASHOV: No no. We don't have this level of direct influence to create per se. You can see from recent activities of Internet Research Agency for example that the successful approach is the one which will amplify or grow existing boondoggles which lead to kind of systemic dysfunction, through for example injection of kind of "memes" [air quote gesture] and "trolls" [air quote gesture]. POSNER: Where has Russia been successful at this specifically as it relates to the Kamailio, the VoIP industry, and real-time communications? BALASHOV: The GRU are very successful at disinformation campaign to convince business executives about cloud things. They are always listening to our "thought leadership" [air quote gesture] to move to cloud, mostly Amazon Web Services, which is great for us since is worst possible approach. At industry events our people are always pushing very much cloud cloud cloud, you know, like a stampede of rhinoceroses to cloud, don't miss out on cloud! Don't be left on the ground, fly away to cloud! We have great podcas-- POSNER: --stop. But there is a legitimate value proposition for service providers in moving to the cloud, isn't there? BALASHOV: Yes, for some maybe, but for example AWS is platform not designed at all for telecom, is kind of Node.js and Ruby on Rails hosting service. POSNER: Where is the economic sabotage? BALASHOV: Well they are spending one month $30,000 to Amazon, next month $35,000, next month $40,000, always bigger instances, bigger, bigger, to handle even very basic work. Official sexy seduction mythology is you can fire all the system admins and no longer replace hard drives at 3 AM and forget all this messing with hardware. Is very hard to resist for big business leaders who follow classical Western management consulting sermon from 90s about "divest yourself of non-core competencies" [air quote gesture]. You know, it is same advice they come to give to us in Gaidar and Yeltsin days. From my memory was not working out well until First Marshal Putin took different approach... POSNER: Let's stay focused. Surely companies can run the numbers for themselves and see if it makes sense for them? BALASHOV: Maybe, but where we have the success is in the exploit of the fear of missing out, I think is called "FOMO" [air quote gesture] nowadays. Everyone is moving to cloud, don't get left behind, even if unit economics of it are disaster for your product and your company. Have you heard about the cloud? It's future! POSNER: And this has been successful? BALASHOV: Hard to measure but for example there is major increase in mailing list posts about putting Kamailio in Amazon EC2, EC2, endless EC2 from people for whom it is obviously wrong thing. Lots of wheels spinnink, spinnik, making fire and sparks, light and heat going into cold, empty outer space, to keep warm our GLONASS satellites. But where is result? All cost increase. And still the $3000/mo instance does not process small amount of packets that is nothing for bare metal server. Meanwhile spendink, spendink, solvink big amounts of kind of fake problems... I heard this expression once in Atlanta, "keep up with Jones" [air quote gesture]. I don't know who is Jones but everyone agrees is very important to keep up with h-- POSNER: --back up. Fake problems? BALASHOV: Maybe is better word: unnecessary problems that come from way AWS inside workings. Stupid network constraints, stupid puzzles for puzzle-solvers. What is American term, "eager beaver" [air quote gesture]? POSNER: Apart from tying up resources, how does this enthusiasm for AWS help Russia? BALASHOV: Well it should be obvious that having whole industry pay huge premium price to centralise their infrastructure at one entity is both economically wasteful and precarious. Fragile and expensive setup is like our Soviet economy at end of eighties. Also havink resemblance to old-times mainframe computing is top secret irony nobody sees. POSNER: Where else is Russia seeding economically harmful memes? BALASHOV: Other big initiative is encourage huge overinvestment in WebRTC because is supposedly future of real-time communications. POSNER: But WebRTC is real. BALASHOV: Da, of course, sometimes workink fine, but eats up big engineering capital and talent fighting always browser bugs and incompatible implementations and always changink changink changink. Meanwhile who is caring for fundamental SIP services? POSNER: And this is a form of economic sabotage? BALASHOV: Of course is sabotage. If you can make much of a sector of economy to obsess always about some toy and create kind of echo chamber of "visionary" [air quote gesture] commentary about it it is negative for GDP and innovation. "Vision" has shown the big success for us; is perfect concept in hand of intelligence agency because nobody is knowing what it is but everyone so desperate to show they have it. POSNER: So a large-scale movement of VoIP service providers to the cloud and big development around WebRTC represent Russian attempts at sabotage of the Western real-time communications industry? BALASHOV: Well again, these tendencies are existing before. It is more question of amplifying and boosting and promoting them so many actors are distracted from important things. American business guys are very vulnerable to it; every time they are asking, "this does not seem to be worth it for us?", always they hear from friends at country club, "you need more bold vision and company culture of innovation, my friend". We have learned after some years and applying KGB psychology training to exploit their big personal insecurities about many things. For example they see competitor have Cloud Business Analytics, they too must have now Cloud Business Analytics, not for any reason, just fear, insecurity, the angst about not having enough "Big Data" [air quote gesture]. POSNER: What else? BALASHOV: In recent years can be found thought leadership to remove direct sales because is inefficient, too high customer acquisition cost and so forth. Always now resellers, channel partners this and master agents that. Common sense shows industry cannot support chain with big depth of reseller of reseller of reseller with everyone wanting to be reseller and nobody selling actual products to the real people. POSNER: That's not new to telecom. BALASHOV: No, no, but now new twist! They are now having everything "as a service" [air quote gesture], platform-aaS, infrastructure-aaS... POSNER: Okay? BALASHOV: But also now infrastructure management-as-a-service and kind of meta approach, management-of-management-of-platform-aaS. Resellers of resale platforms of platforms of platforms. Maybe not quite clear, but this is special recursive sense of humour tradition in Russia. Put endless things inside things inside things like matryoshka doll. Again-- POSNER: --matryoshka? Like the Russian nesting doll? BALASHOV: Yes yes, nesting doll. As I was saying key point is lots of "activity and buzz" [air quote gesture] which is parasitism by another name. Lots of energy and enthusiasm, big banners, hype from UC press, LinkedIn Pulse CTO insights, cheerleadink, but where is result? POSNER: How is this all tied to Kamailio? BALASHOV: Some of it is not directly tied. It is more idea that Kamailio is tool for executing "big ideas" [air quote gesture] and "platform plays" [air quote gesture]. When you are reading mailing list post like, "how to scale up with Kamailio to deliver cloud WebRTC solutions for the enterprise?" and wonder with yourself "from where this small guy got such 'big ideas'?" is often result of Russian-sponsored so-called thought leadership. Who is he? He does not have enterprise! POSNER: What's wrong with that question? BALASHOV: Well from our point of view nothing; great question, bold and inspiring! We are encouraging them always to go build grandiose megalomania ideas, telling to them, yes, "boil the ocean", "be disruptor 2.0", etc. Have you seen ITEXPO? Ideally also raising some venture capital to erase value from fund limited partners portfolio, like pension funds, university endowments. Although sometimes we feel sorry, knowink they will not meet the success, and almost have heart to tell them is just trollink, but our government is clear about goal: work hard every day to suck money out of American economy. POSNER: So it is in Russia's interest to see big ideas funded in America? BALASHOV: Oh yes yes! Bigger is better! First mover advantage and network effect, go big or go home trailblazink! On every time someone gets the Series A for "completely transforming the way you do the business with UCaaS" [air quote gesture] or like "a new kind of next-gen VoIP peering" [air quote gesture] we are having another champagne bottle at the headquarters. POSNER: This does not really sound like traditional intelligence work. BALASHOV: Is not. We are livink in Internet cultural moment, is about memes, engineering perceptions and mass behaviour, new kind of value creation. Likewise destruction. POSNER: We will consider your asylum application in detail. In the meantime, you will be detained at [redacted] as before. BALASHOV: This is famous American tradition of "customer service"? POSNER: We call it "customer success" nowadays.

6 7

Re: [SR-Users] BIG NEWS: Launching NODAILIO - Arcticficial Intelligence (tm) SIP Server
by Carsten Bock 01 Apr '18

01 Apr '18

Hi, Is this the new 5G, Block-Chain powered, self driving vehicle, everybody's been talking about? Thanks, Carsten P.S.: Since the stock value likely just doubled: Do I have any stock-options? Alex Balashov <abalashov(a)evaristesys.com> schrieb am So., 1. Apr. 2018, 18:36: > Most important thing about Nodailio is that it has no security > vulnerabilities. > > None whatsoever. > > -- Alex > > -- > Sent via mobile, please forgive typos and brevity. > > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users(a)lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >

2 1

BIG NEWS: Launching NODAILIO - Arcticficial Intelligence (tm) SIP Server
by Daniel-Constantin Mierla 01 Apr '18

01 Apr '18

With Kamailio being compromised after Alex Balashov's exposure earlier today, it is the time to launch the next generation SIP server named: NODAILIO It is built in NODE.js for NODE.js, with an Arcticficial Intelligence engine at its core (easy to spot: nod.AI.lio), therefore it is capable of all the present and *future* features of Kamailio. Full source code has been made public from second 0 to avoid any interference from alexiens. Usage guidelines and more details are available at: * https://github.com/miconda/nodailio Thanks for sailing nodailio! Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

3 3

statistics (ASR and ACD) by destination/country
by Abdoul Osséni 30 Mar '18

30 Mar '18

Hello dear list, I am looking for a tool that will provide me call statistics (ASR and ACD) by destination/country with alerting by emails. I try to detect when a sip provider does not work well in order to route the traffic to another sip provider. Thank you. Abdoul OSSENI AfriCallShop

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users