sr-users

sr-users@lists.kamailio.org

22 participants
37493 discussions

Start a nNew thread

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

Jump to page:

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