- sr-users - kamailio.org

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

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