sr-dev July 2014

sr-dev@lists.kamailio.org

25 participants
140 discussions

Outbound flow failure handling merged to master

by Hugh Waite

Hello, As you will see I have merged my branch back into master. These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction. The event_route uses a new route type BRANCH_ROUTE which limits the functions that can be run in the route. The functions t_check_status(), t_next_contact_flow(), t_relay() and unregister() can be used in this route. A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry. The following example route can be used on a registrar to handle failed or invalid flows: event_route[tm:branch-failure] { xlog("L_INFO", "event_route[tm:branch-failure]\n"); if (t_check_status("430|403")) { if (!unregister("location", "$tu", "$T_reply_ruid")) { xlog("L_WARN", "failed to unregister $tu with ruid $T_reply_ruid\n"); } if (!t_next_contact_flow()) { xlog("L_INFO", "No more flows\n"); } else { xlog("L_INFO", "Next flow\n"); t_relay(); } } } Any bugs, memory leaks etc. let me know! Hugh -- Hugh Waite Principal Design Engineer Crocodile RCS Ltd.

8 years

TM possible deadlock

by Jason Penton

Hi All, I have been experiencing a deadlock when a timeout occurs on a t_relayed() INVITE. Going through the code I have noticed a possible chance of deadlock (without re-entrant enabled). Here is my thinking: t_should_relay_response() is called with REPLY_LOCK when the timer process fires on the fr_inv_timer (no response from the INVITE that was relayed, other than 100 provisional) and a 408 is generated. However, from within that function there are calls to run_failure_handlers() which in turn *could* try and lock the reply (viz. somebody having a t_reply() call in the cfg file - in failure route block). This would result in another lock on the same transaction's REPLY_LOCK.... Has anybody else experienced something like this? this is on master btw. Cheers Jason

9 years, 8 months

Fw: query related to NOTIFY message size

by Piyush.Bansal＠relianceada.com

please help ----- Forwarded by Piyush Bansal/RCOM/RelianceADA on 10/10/2013 10:51 AM ----- From: Piyush Bansal/RCOM/RelianceADA To: serusers(a)iptel.org, serdev(a)iptel.org Date: 10/09/2013 12:14 PM Subject: query related to NOTIFY message size Hi there, I have certain queries regarding batch SUBSCRIBE and NOTIFY. I have a user who has 100 buddies in his buddy list. If any of his buddy changes his/her presence status, that user gets a NOTIFY message with presence status of all the 100 buddies. In that case, the message size is exceeding 500 KB. Thats quite a higher value for a UDP packet. Can anybody suggest- 1. If there is any way to restrict the size of the packet. 2. How to ensure that the packet is received correctly by the client. Thanks and Regards, --Piyush Bansal The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

10 years, 2 months

RFC: updating default values

by Daniel-Constantin Mierla

Hello, I am opening this discussion to decide if there is need to adjust some of the default values we have in Kamailio. Many of them were set even like 10 years ago, so they might not be very actual anymore. The main goal is to get the best possible settings for common usage. To start with, here are some values that should be reviewed: - default private memory is 4MB - if the config is not that small, it might not be sufficient free pkg to play with (e.g., for sql_query() result, storage of $var(...) values). Should it be increased to 8MB or other value? Debian/Centos have startup script that sets its value to 8 via command line - default shared memory is 32MB - for a decent deployment with tm, location, lcr/dispatcher, permissions, and anti-flood, it might leave not much free space. Should we double it or set to a different value - usrloc - db_ops_ruid should enabled (1) - seems stable, without it there are problems updating/deleting location records when UA changes the call-id for same contact address. - usrloc - hash_size - now is 9, which results in 512 slots, meaning is ok for few thousands of registered users, for more, performance will decrease when doing save/lookup location -- should it be made 10 (1024 slots for internal hash table)? - auth_db - load_credentials defaults to 'rpid', meaning that the query to get the password will retrieve also the rpid column. I haven't see rpid being used that much lately (replaced by PAI/PPI). I would make this parameter empty by default to avoid querying for an extra column that is likely to be empty. Perhaps there are more, I just wanted to get started. Reply with your comments to above list as well as add new items you thinks their default values should be adjusted. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

10 years, 2 months

git:master: acc: fix cdr extra2strar allocation issues

by Lucian Balaceanu

Module: sip-router Branch: master Commit: 295716363562d88bce3db39e0f1bc605b1cc8257 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=2957163… Author: Pawel.Kuzak <pawel.kuzak(a)1und1.de> Committer: lucian balanceanu <lucian.balanceanu(a)1and1.ro> Date: Wed Jul 30 13:59:49 2014 +0300 acc: fix cdr extra2strar allocation issues - for more than 10 string cdr_extra parameters, the addresses used by the new parameters overwrite the previous ones; our solution is to allocate memory for the cdr extra params with pkg_malloc() and free it once it is no longer needed. --- modules/acc/acc.c | 7 ++++++- modules/acc/acc_cdr.c | 27 ++++++++++++++++++++------- modules/acc/acc_extra.c | 39 ++++++++++++++++++--------------------- modules/acc/acc_extra.h | 12 ++++++++++++ modules/acc/acc_mod.c | 3 --- 5 files changed, 56 insertions(+), 32 deletions(-) diff --git a/modules/acc/acc.c b/modules/acc/acc.c index 418e709..51dfde5 100644 --- a/modules/acc/acc.c +++ b/modules/acc/acc.c @@ -229,6 +229,7 @@ int acc_log_request( struct sip_msg *rq) char *p; int n; int m; + int o = 0; int i; struct tm *t; @@ -236,7 +237,9 @@ int acc_log_request( struct sip_msg *rq) m = core2strar( rq, val_arr, int_arr, type_arr); /* get extra values */ - m += extra2strar( log_extra, rq, val_arr+m, int_arr+m, type_arr+m); + o += extra2strar( log_extra, rq, val_arr+m, int_arr+m, type_arr+m); + + m += o; for ( i=0,p=log_msg ; i<m ; i++ ) { if (p+1+log_attrs[i].len+1+val_arr[i].len >= log_msg_end) { @@ -314,6 +317,8 @@ int acc_log_request( struct sip_msg *rq) acc_env.text.len, acc_env.text.s,(unsigned long)acc_env.ts, log_msg); } + /* free memory allocated by extra2strar */ + free_strar_mem( &(type_arr[m-o]), &(val_arr[m-o]), o, m); return 1; } diff --git a/modules/acc/acc_cdr.c b/modules/acc/acc_cdr.c index c8d2684..bc2e66b 100644 --- a/modules/acc/acc_cdr.c +++ b/modules/acc/acc_cdr.c @@ -131,6 +131,7 @@ static int db_write_cdr( struct dlg_cell* dialog, struct sip_msg* message) { int m = 0; + int n = 0; int i; db_func_t *df=NULL; db1_con_t *dh=NULL; @@ -163,11 +164,12 @@ static int db_write_cdr( struct dlg_cell* dialog, /* get extra values */ if (message) { - m += extra2strar( cdr_extra, + n += extra2strar( cdr_extra, message, cdr_value_array + m, cdr_int_array + m, cdr_type_array + m); + m += n; } else if (cdr_expired_dlg_enable){ LM_WARN( "fallback to dlg_only search because of message doesn't exist.\n"); m += extra2strar_dlg_only( cdr_extra, @@ -187,27 +189,34 @@ static int db_write_cdr( struct dlg_cell* dialog, if (df->use_table(dh, &acc_cdrs_table /*table*/) < 0) { LM_ERR("error in use_table\n"); - return -1; + goto error; } if(acc_db_insert_mode==1 && df->insert_delayed!=NULL) { if (df->insert_delayed(dh, db_cdr_keys, db_cdr_vals, m) < 0) { LM_ERR("failed to insert delayed into database\n"); - return -1; + goto error; } } else if(acc_db_insert_mode==2 && df->insert_async!=NULL) { if (df->insert_async(dh, db_cdr_keys, db_cdr_vals, m) < 0) { LM_ERR("failed to insert async into database\n"); - return -1; + goto error; } } else { if (df->insert(dh, db_cdr_keys, db_cdr_vals, m) < 0) { LM_ERR("failed to insert into database\n"); - return -1; + goto error; } } + /* Free memory allocated by acc_extra.c/extra2strar */ + free_strar_mem( &(cdr_type_array[m-n]), &(cdr_value_array[m-n]), n, m); return 0; + +error: + /* Free memory allocated by acc_extra.c/extra2strar */ + free_strar_mem( &(cdr_type_array[m-n]), &(cdr_value_array[m-n]), n, m); + return -1; } #endif @@ -221,6 +230,7 @@ static int log_write_cdr( struct dlg_cell* dialog, 2;// -2 because of the string ending '\n\0' char* message_position = NULL; int message_index = 0; + int extra_index = 0; int counter = 0; if(cdr_log_enable==0) @@ -235,7 +245,7 @@ static int log_write_cdr( struct dlg_cell* dialog, /* get extra values */ if (message) { - message_index += extra2strar( cdr_extra, + extra_index += extra2strar( cdr_extra, message, cdr_value_array + message_index, cdr_int_array + message_index, @@ -249,7 +259,7 @@ static int log_write_cdr( struct dlg_cell* dialog, cdr_type_array + message_index, &dlgb); } - + message_index += extra_index; for( counter = 0, message_position = cdr_message; counter < message_index ; @@ -296,6 +306,9 @@ static int log_write_cdr( struct dlg_cell* dialog, LM_GEN2( cdr_facility, log_level, "%s", cdr_message); + /* free memory allocated by extra2strar, nothing is done in case no extra strings were found by extra2strar */ + free_strar_mem( &(cdr_type_array[message_index-extra_index]), &(cdr_value_array[message_index-extra_index]), + extra_index, message_index); return 0; } diff --git a/modules/acc/acc_extra.c b/modules/acc/acc_extra.c index 4847109..e9b6e4d 100644 --- a/modules/acc/acc_extra.c +++ b/modules/acc/acc_extra.c @@ -63,16 +63,6 @@ /* here we copy the strings returned by int2str (which uses a static buffer) */ static char int_buf[INT2STR_MAX_LEN*MAX_ACC_INT_BUF]; -static char *static_detector = 0; - -void init_acc_extra(void) -{ - int i; - /* ugly trick to get the address of the static buffer */ - static_detector = int2str( (unsigned long)3, &i) + i; -} - - struct acc_extra *parse_acc_leg(char *extra_str) { struct acc_extra *legs; @@ -249,10 +239,10 @@ int extra2strar(struct acc_extra *extra, struct sip_msg *rq, str *val_arr, { pv_value_t value; int n; - int r; + int i; n = 0; - r = 0; + i = 0; while (extra) { /* get the value */ @@ -272,15 +262,22 @@ int extra2strar(struct acc_extra *extra, struct sip_msg *rq, str *val_arr, val_arr[n].len = 0; type_arr[n] = TYPE_NULL; } else { - /* set the value into the acc buffer */ - if (value.rs.s+value.rs.len==static_detector) { - val_arr[n].s = int_buf + r*INT2STR_MAX_LEN; - val_arr[n].len = value.rs.len; - memcpy(val_arr[n].s, value.rs.s, value.rs.len); - r++; - } else { - val_arr[n] = value.rs; - } + val_arr[n].s = (char *)pkg_malloc(value.rs.len); + if (val_arr[n].s == NULL ) { + LM_ERR("extra2strar: out of memory.\n"); + /* Cleanup already allocated memory and + return that we didn't do anything */ + for (i = 0; i < n ; i++) { + if (NULL != val_arr[i].s){ + pkg_free(val_arr[i].s); + val_arr[i].s = NULL; + } + } + n = 0; + goto done; + } + memcpy(val_arr[n].s, value.rs.s, value.rs.len); + val_arr[n].len = value.rs.len; if (value.flags&PV_VAL_INT) { int_arr[n] = value.ri; type_arr[n] = TYPE_INT; diff --git a/modules/acc/acc_extra.h b/modules/acc/acc_extra.h index 13112b9..c906683 100644 --- a/modules/acc/acc_extra.h +++ b/modules/acc/acc_extra.h @@ -43,6 +43,7 @@ #ifndef _ACC_EXTRA_H_ #define _ACC_EXTRA_H_ +#include "acc_api.h" #include "../../str.h" #include "../../pvar.h" #include "../../parser/msg_parser.h" @@ -72,5 +73,16 @@ int extra2int( struct acc_extra *extra, int *attrs ); int extra2attrs( struct acc_extra *extra, struct attr *attrs, int offset); #endif +static inline void free_strar_mem( char* type_arr, str* alloc_arr, int dim_arr, int dim_ext){ + int i = 0; + for ( i = 0; i < dim_arr; i ++ ) { + if (( TYPE_NULL != type_arr[i] ) && ( NULL != alloc_arr[i].s)) { + LM_DBG("Freeing memory, type is %d, message_index %d, index i %d\n", + type_arr[i], dim_ext - dim_arr, i); + pkg_free( alloc_arr[i].s) ; + alloc_arr[i].s = NULL; + } + } +} #endif diff --git a/modules/acc/acc_mod.c b/modules/acc/acc_mod.c index acd620c..831a137 100644 --- a/modules/acc/acc_mod.c +++ b/modules/acc/acc_mod.c @@ -528,9 +528,6 @@ static int mod_init( void ) return -1; } - /* init the extra engine */ - init_acc_extra(); - /* configure multi-leg accounting */ if (leg_info_str && (leg_info=parse_acc_leg(leg_info_str))==0 ) { LM_ERR("failed to parse multileg_info param\n");

10 years, 4 months

planning the release of v4.1.5

by Daniel-Constantin Mierla

Hello, I am considering to release v4.1.5 sometime next week, most likely on the 6th of August. Checking the 4.1 branch, there are not many fixes, few are on my list for backporting. That's good, indicating a high level of stability. If anyone is aware of issues not reported on tracker or patches that have not been backported, add to the tracker or write a message to sr-dev mailing list. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

10 years, 4 months

Kamailio on OS/X Mavericks

by Olle E. Johansson

Hi! Kamailio by default doesn't compile on OS/X Mavericks. $ make generating autover.h ... /Applications/Xcode.app/Contents/Developer/usr/bin/make --no-print-directory -wC . cfg-defs target architecture <x86_64>, host architecture <x86_64> making config... CC (gcc) [kamailio] action.o error: invalid value '9' in '-O9' make: *** [action.o] Error 1 $ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix Anyone that has found an optimal way to patch the Makefile? /O

10 years, 4 months

[tracker] Comment added: db_unixodbc cannot load more than 1024 bytes from a database field (patch supplied) (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#443 - db_unixodbc cannot load more than 1024 bytes from a database field (patch supplied) User who did this - Alex Villacis Lasso (a_villacis) ---------- I have made a new version of the patch: * db_unixodbc_load_cell() now returns an error code that is checked in the recordset loops * With the previous patch, two additional problems became apparent. First, BLOB columns are read with SQL_C_CHAR, resulting in an unwanted conversion to an hexadecimal string. Second, even if the database column is converted to a TEXT datatype, the driver still considers it a DB1_BLOB. This results in all length calculations including the extra NULL byte at the end of the string. This extra byte appears in XCAP responses and breaks at least Jitsi. Both problems are now solved by passing an additional parameter to db_unixodbc_load_cell() telling what column type is supposed to be read. Also, the buflen field is trusted to have the actual value length, and this is used to convert the row instead of a strlen(). * In db_unixodbc_list_insert(), memcpy is used instead of strncpy, in order to cope with fields with embedded nulls from BLOB columns. Also, the method was shortened by factoring out commonalities between the cases of inserting a first node vs inserting a non-first node. ---------- One or more files have been attached. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=443#comment1569 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.

10 years, 4 months

Fwd: [SR-Users] SIGUSR1 for memory status not working as documented - only one process reports back

by Alex Villacís Lasso

10 years, 4 months

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

-------- 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.

10 years, 4 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2014