sr-dev July 2014

sr-dev@lists.kamailio.org

25 participants
141 discussions

Fwd: [SR-Users] kamailio routes packets with invalid From/To headers with uac.restore_mode=auto when incoming packet does not use exact same replaced From/To header
by Alex Villacís Lasso 31 Jul '14

31 Jul '14

-------- Mensaje original -------- Return-Path: <sr-users-bounces(a)lists.sip-router.org> Delivered-To: <a_villacis(a)palosanto.com> Received: from palosanto.com by mail.palosanto.com (Dovecot) with LMTP id 1RBBAn9f2VPPOgAA3RMWGw for <a_villacis(a)palosanto.com>; Wed, 30 Jul 2014 16:14:09 -0500 Received: from localhost (mail.palosanto.com [127.0.0.1]) by palosanto.com (Postfix) with ESMTP id BD82513C027E for <a_villacis(a)palosanto.com>; Wed, 30 Jul 2014 16:14:09 -0500 (ECT) X-Virus-Scanned: Debian amavisd-new at mail.palosanto.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-1000 required=6.31 tests=[AWL=-0.333, BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, WEIRD_PORT=0.001] autolearn=unavailable Received: from palosanto.com ([127.0.0.1]) by localhost (mail.palosanto.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEfbzVEOoMof for <a_villacis(a)palosanto.com>; Wed, 30 Jul 2014 16:14:04 -0500 (ECT) Received: from www.kamailio.org (main.kamailio.org [193.22.119.66]) by palosanto.com (Postfix) with ESMTPS id 4412B13C0280 for <a_villacis(a)palosanto.com>; Wed, 30 Jul 2014 16:13:56 -0500 (ECT) Received: from localhost ([127.0.0.1] helo=main.kamailio.org ident=list) by www.kamailio.org with esmtp (Exim 4.72) (envelope-from <sr-users-bounces(a)lists.sip-router.org>) id 1XCbCY-0000J5-PL; Wed, 30 Jul 2014 23:14:22 +0200 Received: from lab2.palosanto.com ([201.234.196.173] helo=palosanto.com) by www.kamailio.org with esmtp (Exim 4.72) (envelope-from <a_villacis(a)palosanto.com>) id 1XCbCU-0000II-SD for sr-users(a)lists.sip-router.org; Wed, 30 Jul 2014 23:14:19 +0200 Received: from localhost (mail.palosanto.com [127.0.0.1]) by palosanto.com (Postfix) with ESMTP id 5BC5613C0280 for <sr-users(a)lists.sip-router.org>; Wed, 30 Jul 2014 16:13:43 -0500 (ECT) X-Virus-Scanned: Debian amavisd-new at mail.palosanto.com Received: from palosanto.com ([127.0.0.1]) by localhost (mail.palosanto.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY5HkVjL2_h0 for <sr-users(a)lists.sip-router.org>; Wed, 30 Jul 2014 16:13:39 -0500 (ECT) Received: from avillacis.palosanto.com (avillacis.palosanto.com [192.168.3.2]) by palosanto.com (Postfix) with ESMTPSA id 3DFFD13C0279 for <sr-users(a)lists.sip-router.org>; Wed, 30 Jul 2014 16:13:39 -0500 (ECT) Message-ID: <53D96020.2040508(a)palosanto.com> Date: Wed, 30 Jul 2014 16:14:08 -0500 From: Alex Villacís Lasso <a_villacis(a)palosanto.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org> Content-Type: multipart/mixed; boundary="------------030501020507030206060205" Subject: [SR-Users] kamailio routes packets with invalid From/To headers with uac.restore_mode=auto when incoming packet does not use exact same replaced From/To header X-BeenThere: sr-users(a)lists.sip-router.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org> List-Id: "Kamailio $SER$ - Users Mailing List" <sr-users.lists.sip-router.org> List-Unsubscribe: <http://lists.sip-router.org/cgi-bin/mailman/options/sr-users>, <mailto:sr-users-request@lists.sip-router.org?subject=unsubscribe> List-Archive: <http://lists.sip-router.org/pipermail/sr-users> List-Post: <mailto:sr-users@lists.sip-router.org> List-Help: <mailto:sr-users-request@lists.sip-router.org?subject=help> List-Subscribe: <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>, <mailto:sr-users-request@lists.sip-router.org?subject=subscribe> Sender: sr-users-bounces(a)lists.sip-router.org Errors-To: sr-users-bounces(a)lists.sip-router.org I am currently handling a system that runs kamailio and asterisk in the same machine. The kamailio instances are being used to emulate multiple SIP domains, by means of From/To mangling of incoming packets, which are then routed to Asterisk. The attached kamailio.cfg does this work. There is an problem when handling SUBSCRIBE requests (as required for BLF and voicemail indications). My configuration is written so that these SUBSCRIBE requests are not handled by kamailio, but instead routed to asterisk. There is a failure to check From/To headers to see whether NOTIFY packets generated as part of a subscription can be restored using the information in Record-Route. The end result is that kamailio ends up sending packets with garbled tags that are (rightly) rejected by the SIP endpoint. The following is an example that demonstrates the issue (using Jitsi as endpoint): After registration, Jitsi sends a SUBSCRIBE request: SUBSCRIBE sip:avillacisIM@pbx.villacis.com SIP/2.0 Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 2 SUBSCRIBE From: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=bf427f4a To: "avillacisIM" <sip:avillacisIM@pbx.villacis.com> Max-Forwards: 70 Contact: "avillacisIM" <sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com> User-Agent: Jitsi2.5.5255Linux Event: message-summary Accept: application/simple-message-summary Expires: 3600 Via: SIP/2.0/UDP 192.168.3.2:5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f Proxy-Authorization: Digest username="avillacisIM",realm="pbx.villacis.com",nonce="U9lZJlPZV/r06Xep/ukc1UzAIO0V3TbS",uri="sip:avillacisIM@pbx.villacis.com",response="0e18f4913c2693f6154c91f158fb17fe" Content-Length: 0 This packet is mangled by the configuration, and is sent to asterisk like this: SUBSCRIBE sip:avillacisIM@pbx.villacis.com SIP/2.0 Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes> Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes> Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 2 SUBSCRIBE From: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=bf427f4a To: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080> Max-Forwards: 69 Contact: "avillacisIM" <sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com> User-Agent: Jitsi2.5.5255Linux Event: message-summary Accept: application/simple-message-summary Expires: 3600 Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bKd941.2ab9cf36e41dc48855ae2cbe9a309d0a.0 Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f Content-Length: 0 The asterisk response for the SUBSCRIBE: SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bKd941.2ab9cf36e41dc48855ae2cbe9a309d0a.0;received=127.0.0.1;rport=5060 Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes> Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes> From: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=bf427f4a To: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=as5562e95e Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 2 SUBSCRIBE Server: Asterisk PBX 11.11.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Expires: 3600 Contact: <sip:avillacisIM@127.0.0.1:5080>;expires=3600 Content-Length: 0 This is in turn transformed back by kamailio, and sent to Jitsi like this: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes> Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes> From: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=bf427f4a To: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=as5562e95e Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 2 SUBSCRIBE Server: Asterisk PBX 11.11.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Expires: 3600 Contact: <sip:avillacisIM@127.0.0.1:5080;alias=127.0.0.1~5080~1>;expires=3600 Content-Length: 0 Now asterisk wants to send a NOTIFY to the endpoint for the subscription. The NOTIFY looks like this: NOTIFY sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK658fa5fc;rport Max-Forwards: 70 Route: <sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>,<sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes> From: "asterisk" <sip:asterisk@127.0.0.1:5080>;tag=as5562e95e To: <sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>;tag=bf427f4a Contact: <sip:asterisk@127.0.0.1:5080> Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 102 NOTIFY User-Agent: Asterisk PBX 11.11.0 Event: message-summary Content-Type: application/simple-message-summary Subscription-State: active Content-Length: 89 Messages-Waiting: no Message-Account: sip:*97@127.0.0.1:5080 Voice-Message: 0/0 (0/0) Here is where the bug appears. The autoprocessing does not recognize that the From header (From: "asterisk" <sip:asterisk@127.0.0.1:5080>;tag=as5562e95e) from the above request has nothing to do with the saved information (vsf parameter). Instead, it blindly mangles the From header, and does not even run a sanity check on the result before routing it. The end result is shown below. NOTIFY sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0 Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=as5562e95e> Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=as5562e95e> Via: SIP/2.0/UDP 192.168.2.18;branch=z9hG4bK8333.8bfe7bc2bd554a8631f0d00d463b28ee.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK658fa5fc;rport=5080 Max-Forwards: 69 From: "asterisk" <sip:asterisk@12(.0.0.1:5080.....@127.0.0.1:5080>;tag=as5562e95e To: <sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>;tag=bf427f4a Contact: <sip:asterisk@127.0.0.1:5080> Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0 CSeq: 102 NOTIFY User-Agent: Asterisk PBX 11.11.0 Event: message-summary Content-Type: application/simple-message-summary Subscription-State: active Content-Length: 89 Messages-Waiting: no Message-Account: sip:*97@127.0.0.1:5080 Voice-Message: 0/0 (0/0) From examination of the source code, the vsf and vst strings are base64 encodings of the result of XORing the byte strings of the old and new tags. For this to work, the headers of future packets should match. However, here kamailio does not realize that the header does not match (by the ftag), and also does not check that the resulting "restored" header is a valid header.

1 0

[tracker] Comment added: "unsupported route type: 64" after calling event route dialog:end
by sip-router 31 Jul '14

31 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#456 - "unsupported route type: 64" after calling event route dialog:end User who did this - Daniel-Constantin Mierla (miconda) ---------- Actually I discovered it was not backported. I just did it now. The commit on master was 4fab97fb54334a55b1fce4e0d2f417fda5727c3a ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=456#comment1568 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

git:4.1: dialog: backup and restore exiting route type when executing dialog event_route blocks
by Daniel-Constantin Mierla 31 Jul '14

31 Jul '14

Module: sip-router Branch: 4.1 Commit: 4eb7b5b0d4b2d914f488d15d637e4448102d6d63 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4eb7b5b… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Jun 13 12:00:21 2014 +0200 dialog: backup and restore exiting route type when executing dialog event_route blocks - reported by Nuno Miguel Reis (cherry picked from commit 4fab97fb54334a55b1fce4e0d2f417fda5727c3a) --- modules/dialog/dlg_handlers.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/modules/dialog/dlg_handlers.c b/modules/dialog/dlg_handlers.c index 21c4391..778f97b 100644 --- a/modules/dialog/dlg_handlers.c +++ b/modules/dialog/dlg_handlers.c @@ -1454,6 +1454,7 @@ void dlg_run_event_route(dlg_cell_t *dlg, sip_msg_t *msg, int ostate, int nstate { sip_msg_t *fmsg; int rt; + int bkroute; if(dlg==NULL) return; @@ -1483,11 +1484,13 @@ void dlg_run_event_route(dlg_cell_t *dlg, sip_msg_t *msg, int ostate, int nstate dlg_ref(dlg, 1); dlg_set_ctx_iuid(dlg); LM_DBG("executing event_route %d on state %d\n", rt, nstate); + bkroute = get_route_type(); set_route_type(LOCAL_ROUTE); run_top_route(event_rt.rlist[rt], fmsg, 0); dlg_reset_ctx_iuid(); exec_post_script_cb(fmsg, LOCAL_CB_TYPE); dlg_unref(dlg, 1); + set_route_type(bkroute); } }

1 0

[tracker] Comment added: "unsupported route type: 64" after calling event route dialog:end
by sip-router 31 Jul '14

31 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#456 - "unsupported route type: 64" after calling event route dialog:end User who did this - Andrew Pogrebennyk (marduk) ---------- I see, thanks. Was it fixed by commit fbe7347 - dialog: execute internal event_route blocks under local_route type (7 weeks ago) <Daniel-Constantin Mierla> and only this commit? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=456#comment1567 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Comment added: "unsupported route type: 64" after calling event route dialog:end
by sip-router 31 Jul '14

31 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#456 - "unsupported route type: 64" after calling event route dialog:end User who did this - Daniel-Constantin Mierla (miconda) ---------- This should be fixed in branch 4.1, to be part of 4.1.5 next week. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=456#comment1566 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Task opened: "unsupported route type: 64" after calling event route dialog:end
by sip-router 31 Jul '14

31 Jul '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Andrew Pogrebennyk (marduk) Attached to Project - sip-router Summary - "unsupported route type: 64" after calling event route dialog:end Task Type - Bug Report Category - Core Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - We are using event route dialog:end to execute some lua scripts: event_route[dialog:end] { if (!lua_run("del_dlg_profile", "$ci")) { xlog("L_ERROR", "Failed to decrease redis counters - R=$ru ID=$ci\n"); } else { xlog("L_INFO", "removed redis counters - R=$ru ID=$ci\n"); } } The problem is that when we have a BYE message, which triggers the event route above and is then processed by the loose_route() and finally goes to t_relay(), Jul 31 15:56:44 prx01a proxy[12447]: NOTICE: <script>: New request - M=BYE R=sip:172.30.52.132:5080;prxroute=1 F=sip:sipwise-test2@172.30.52.103 T=sip:43991001@172.30.52.103 IP=172.17.135.86:41748 (172.30.52.135:5060) ID=0ik1N5ahpzAzCaIQmtMeqkeA1yoK1l4j Jul 31 15:56:44 prx01a proxy[12447]: INFO: <script>: removed redis counters - R=sip:172.30.52.132:5080;prxroute=1 ID=0ik1N5ahpzAzCaIQmtMeqkeA1yoK1l4j Jul 31 15:56:44 prx01a proxy[12447]: INFO: <script>: Stop mediaproxy for all branches - R=sip:172.30.52.132:5080;prxroute=1 ID=0ik1N5ahpzAzCaIQmtMeqkeA1yoK1l4j Jul 31 15:56:44 prx01a proxy[12447]: INFO: <script>: Relaying request, du='<null>' - R=sip:172.30.52.132:5080;prxroute=1 ID=0ik1N5ahpzAzCaIQmtMeqkeA1yoK1l4j the t_relay fails with "unsupported route type: 64": Jul 31 15:56:44 prx01a proxy[12447]: : tm [tm.c:1518]: _w_t_relay_to(): ERROR: w_t_relay_to: unsupported route type: 64 it looks like event route dialog:end does not clear breaks internal state of the kamailio process. When UAC retransmits the BYE there is no event route called and there is no problem. root@prx01a:~# kamailio -V version: kamailio 4.1.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 20:52:15 Jul 24 2014 with gcc 4.7.2 More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=456 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

Re: [sr-dev] [SR-Users] Obscuring SIP traffic and using with NoSIP
by Muhammad Shahzad 30 Jul '14

30 Jul '14

The key purpose of ITV encryption is to avoid making a pattern of any sort. If you encrypt same text / packet 10 times you will get completely different encrypted text / packet each time. This happens due to the fact that the encryption key changes dynamically with each new encryption done, see the readme file for more details https://github.com/mshary/itv/blob/master/README.md Secondly with v2.0, it uses non-deterministic random source as well as auto-learning, so it can adopt to new symbols and words encountered while encrypting and update itself to use them. So technically, it can also be used for binary data such as RTP, however RTP uses UDP which has possibility of packet loss and thus not suitable for ITV encryption (at least for now, this is a hot discussion within my researchers circle and we are actively looking for a solution for this). See release notes for v2.0 here, https://github.com/mshary/itv/releases/tag/v2.0 Anyways, the current target is to use kamailio as SIP proxy and doubango as SIP client for iPhone and Android. Once it is achieved it will be available free / open source to public and then it can be actually tested against all possible voip blocking and sniffing scenarios which we hope it would be able to solve with minimal possible overhead. So far the prototype works pretty good in a few voip blocked countries and GSM operators where we have tested it. Thank you. On Wed, Jul 30, 2014 at 5:32 PM, Daniel Tryba <daniel(a)pocos.nl> wrote: > On Wednesday 30 July 2014 06:37:31 Muhammad Shahzad wrote: > > Humm, no reply so far, may be because my email was very long and no body > > bothered to read it all. Anyways, here is the shorter more direct version > > of it. > > I read it all and my only though was: use a VPN. > > If someone wants to stop SIP, it has an easy to spot pattern. > If someone wants to stop VPN, they will drop every non clear connection > which > doesn't match a known non-VPN pattern. > > If I was afraid of my telco listening in on my SIP dialogs, I'd also want > to > encrypt RTP. Which is much more resource intensive than encrypting a few > SIP > messages. So if you think standard tls is to intensive you'll also have to > create some custom lightweight rtp mangling. > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >

1 0

Dialog module issue on OS/X
by Olle E. Johansson 30 Jul '14

30 Jul '14

I could not load the dialog module, because of a linking problem with the symbol destroy_dlg. Found that it's declared "inline" twice which may cause an issue. With this change, that I don't dare to commit myself, I could load dialog and explore it. Can someone take a look at this, someone that understands dialog and stuff? This was on OS/X. Thanks /O diff --git a/modules/dialog/dlg_hash.h b/modules/dialog/dlg_hash.h index 6994256..174ef15 100644 --- a/modules/dialog/dlg_hash.h +++ b/modules/dialog/dlg_hash.h @@ -214,7 +214,7 @@ static inline void unlink_unsafe_dlg(dlg_entry_t *d_entry, dlg_cell_t *dlg) * \brief Destroy a dialog, run callbacks and free memory * \param dlg destroyed dialog */ -inline void destroy_dlg(dlg_cell_t *dlg); +void destroy_dlg(dlg_cell_t *dlg); /*!

2 3

git:master: dialog: documentation for timer_procs parameter
by Daniel-Constantin Mierla 30 Jul '14

30 Jul '14

Module: sip-router Branch: master Commit: fcdf5f9cfff634ebfa736d7084d5e5483a36355b URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=fcdf5f9… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Jul 30 15:27:09 2014 +0200 dialog: documentation for timer_procs parameter --- modules/dialog/README | 317 ++++++++++++++++++++--------------- modules/dialog/doc/dialog_admin.xml | 21 +++ 2 files changed, 199 insertions(+), 139 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=fcd…

1 0

git:master: dialog: option to run dialog main timer tasks via dedicated process
by Daniel-Constantin Mierla 30 Jul '14

30 Jul '14

Module: sip-router Branch: master Commit: 1157db7c72b1629b72f4d06bd01c5bc694a816b2 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1157db7… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Jul 30 15:15:40 2014 +0200 dialog: option to run dialog main timer tasks via dedicated process - timer_procs - new parameter, if set to 1, a dedicated timer process is used, if set to 0 (default), the core timer is used (existing behavior) - to add: option to work with many dedicated timer processes --- modules/dialog/dialog.c | 20 +++++++++++++++++--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/modules/dialog/dialog.c b/modules/dialog/dialog.c index 4495625..1baa714 100644 --- a/modules/dialog/dialog.c +++ b/modules/dialog/dialog.c @@ -109,6 +109,7 @@ str dlg_extra_hdrs = {NULL,0}; static int db_fetch_rows = 200; int initial_cbs_inscript = 1; int dlg_wait_ack = 1; +static int dlg_timer_procs = 0; int dlg_event_rt[DLG_EVENTRT_MAX]; @@ -285,6 +286,7 @@ static param_export_t mod_params[]={ { "ka_timer", INT_PARAM, &dlg_ka_timer }, { "ka_interval", INT_PARAM, &dlg_ka_interval }, { "timeout_noreset", INT_PARAM, &dlg_timeout_noreset }, + { "timer_procs", PARAM_INT, &dlg_timer_procs }, { 0,0,0 } }; @@ -614,9 +616,13 @@ static int mod_init(void) return -1; } - if ( register_timer( dlg_timer_routine, 0, 1)<0 ) { - LM_ERR("failed to register timer \n"); - return -1; + if(dlg_timer_procs<=0) { + if ( register_timer( dlg_timer_routine, 0, 1)<0 ) { + LM_ERR("failed to register timer \n"); + return -1; + } + } else { + register_sync_timers(1); } /* init handlers */ @@ -692,6 +698,14 @@ static int child_init(int rank) dlg_db_mode = dlg_db_mode_param; if(rank==PROC_MAIN) { + if(dlg_timer_procs>0) { + if(fork_sync_timer(PROC_TIMER, "Dialog Main Timer", 1 /*socks flag*/, + dlg_timer_routine, NULL, 1 /*every sec*/)<0) { + LM_ERR("failed to start main timer routine as process\n"); + return -1; /* error */ + } + } + if(dlg_ka_timer>0 && dlg_ka_interval>0) { if(fork_sync_timer(PROC_TIMER, "Dialog KA Timer", 1 /*socks flag*/, dlg_ka_timer_exec, NULL, dlg_ka_timer /*sec*/)<0) {

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2014