From andrew at rwts.com.au Sun May 2 05:13:12 2021 From: andrew at rwts.com.au (Andrew Yager) Date: Sun, 2 May 2021 15:13:12 +1000 Subject: [OpenSIPS-Users] TLS NOTIFY transmit fails Message-ID: Hi All, Hoping someone can help me with this - I think it should be pretty simple. We're using mid_registrar to provide a Proxy between Asterisk and clients (mixed UDP, TCP and TLS). Calls in/out work fine, but I'm having some difficulties with NOTIFY messages being transmitted back to the client a "period" of time after the register event. This period of time seems to be 2 minutes or so. It looks like even though the $ru is set correctly, it's not reusing the TLS socket, but instead trying to create a new transaction/socket which doesn't work. I'm assuming from the logs the important thing is the "DBG:tm:t_lookup_request: no transaction found"; and that what has happened is the original register transaction has "expired" and so it needs to create a new one, despite the TCP_NO_CONNECT bflag being set. INVITEs are properly relayed and reuse the socket without fail; it "seems" it's only NOTIFY messages that are causing me grief. Our config looks like this: ... tcp_no_new_conn_bflag = TCP_NO_CONNECT tcp_keepidle = 30 ... loadmodule "tm.so" modparam("tm", "fr_timeout", 5) modparam("tm", "fr_inv_timeout", 30) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ modparam("mid_registrar", "outgoing_expires", 3600) modparam("mid_registrar", "contact_id_insertion", "ct-param") modparam("mid_registrar", "tcp_persistent_flag", "TCP_PERSIST_REGISTRATIONS") ... if ($si == "asterisk.ip" && $sp == 5060) { xlog("about to do mid_registrar_lookup\n"); if (!mid_registrar_lookup("location")) { xlog("mid registrar lookup failed\n"); xlog("RU is $ru FU is $fu TU is $tu\n"); $ru = "sip:"+$tU+"@asterisk.ip"; xlog("Rewrote to $ru\n"); # This deal with NOTIFY requests that don't have the user in the SIP message if (!mid_registrar_lookup("location")) { xlog("Could not find user, going to reply 404 and drop the request.\n"); sl_send_reply(404,"Contact is not here anymore"); exit; } } } else { fix_nated_contact(); $ru = "sip:"+$tU+"@asterisk.ip:5060"; } if ( is_method("NOTIFY")) { setbflag("TCP_NO_CONNECT"); xlog("Notify with to tag\n"); xlog("Ru is $ru\n"); sl_send_reply(200, "OK, we got this!"); t_relay(); exit; } ... Debug Logs: May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: about to do mid_registrar_lookup May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:unescape_user: unescaped string is <> May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:mid_registrar:lookup: '' Not found in usrloc May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: mid registrar lookup failed May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:parse_to_param: tag=f7a75172-f02b-419e-89a0-ad2481768e88 May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:_parse_to: end of header reached, state=29 May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:_parse_to: display={}, ruri={sip:1014 at x.x.x.x} May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: RU is sip:y,y,y,y,y:5061;transport=tls;lr;r2=on;ftag=2210321712 FU is sip:1014 at x.x.x.x TU is sip:1003-test at x.x.x.x May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: Rewrote to sip:1003-test at x.x.x.x May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:unescape_user: unescaped string is <1003-test> May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:mid_registrar:select_contacts: ct: sip:1003-test at z.z.z.z :3353;transport=TLS May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:mid_registrar:push_branch: setting msg R-URI May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: Notify with to tag May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: Ru is sip:1003-test at z.z.z.z:3353;transport=TLS May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:parse_headers: flags=ffffffffffffffff May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:parse_headers: flags=ffffffffffffffff May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:parse_headers: flags=78 May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:tm:t_lookup_request: start searching: hash=65460, isACK=0 May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:tm:matching_3261: RFC3261 transaction matching failed May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:tm:t_lookup_request: no transaction found May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:mk_proxy: doing DNS lookup... May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:parse_headers: flags=2000 May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: DBG:core:parse_headers: flags=ffffffffffffffff May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: ERROR:tm:msg_send: send() to x.x.x.x:5061 for proto tls/3 failed May 2 04:59:42 hvprxy /usr/sbin/opensips[96845]: ERROR:tm:t_forward_nonack: sending request failed Any help would be appreciated :) Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at rwts.com.au Mon May 3 06:04:35 2021 From: andrew at rwts.com.au (Andrew Yager) Date: Mon, 3 May 2021 16:04:35 +1000 Subject: [OpenSIPS-Users] TLS NOTIFY transmit fails In-Reply-To: References: Message-ID: I believe I have resolved this issue, with one of… * Made sure that NOTIFY and SUBSCRIBE messages were executing record_route. It looks like some cases would bypass this in the logic, and this is possibly cause for the confusion * Setting the branch flag on the pre-branch options * Removing the stateless replies (as they are now being forwarded) I suspect in multi-contact scenarios this will currently break, but we're prepared to accept this I think. Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon May 3 08:50:21 2021 From: miha at softnet.si (Miha) Date: Mon, 3 May 2021 10:50:21 +0200 Subject: [OpenSIPS-Users] opensips-cli issue with DB creation Message-ID: <09920984-9b76-ba3b-970e-24c82f2637db@softnet.si> Hello I have config for opensips-cli like this in /etc/opensips-cli.cfg database_modules: ALL log_level: WARNING prompt_name: opensips-cli prompt_intro: Welcome to OpenSIPS at SECUREVOIP prompt_emptyline_repeat_cmd: False history_file: ~/.opensips-cli.history history_file_size: 1000 output_type: pretty-print communication_type: fifo fifo_file: /tmp/opensips_fifo database_path: /tmp/opensips-3.1/scripts database_name: opensips database_admin_url: mysql://root:xxxx at localhost:3306/opensips database_url: mysql://opensips:opensipsrw at localhost:3306/opensips When i run in opensips-cli shell "database create" i get: ERROR: failed to connect to DB as opensips, please provide or fix the 'database_url' I can see data DB opensips was created and also opensips user was created. thank you miha -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon May 3 10:00:24 2021 From: miha at softnet.si (Miha) Date: Mon, 3 May 2021 12:00:24 +0200 Subject: [OpenSIPS-Users] opensips-cli issue with DB creation In-Reply-To: <09920984-9b76-ba3b-970e-24c82f2637db@softnet.si> References: <09920984-9b76-ba3b-970e-24c82f2637db@softnet.si> Message-ID: <2be27039-4e75-6986-74df-564049413fc5@softnet.si> Pasting also log:  database create DEBUG: running command 'create' '[]' DEBUG: db_name: 'opensips' Password for admin MySQL user (root): DEBUG: read password: 'xxx' DEBUG: admin DB URL: 'mysql://root:xxx at localhost' DEBUG: connecting to mysql://root:xxx at localhost DEBUG: check database URL 'mysql://root:xxx at localhost/opensips' DEBUG: DB does not exist DEBUG: Create Database 'opensips' for dialect 'mysql' ... DEBUG: success DEBUG: DB URL: 'mysql://opensips:opensipsrw at localhost' DEBUG: connecting to mysql://opensips:opensipsrw at localhost/opensips INFO: creating access user for opensips ... /usr/local/lib/python3.7/dist-packages/SQLAlchemy-1.3.3-py3.7-linux-x86_64.egg/sqlalchemy/engine/default.py:552: Warning: (3163, "Authorization ID 'opensips'@'%' already exists.")   cursor.execute(statement, parameters) INFO: created user 'opensips' INFO: set password 'o********w' for 'opensips' (MySQL) INFO: granted access to user 'opensips' on DB 'opensips' INFO: flushed privileges DEBUG: connecting to mysql://opensips:opensipsrw at localhost/opensips ERROR: failed to connect to DB as opensips, please provide or fix the 'database_url' Miha via Users je 5/3/2021 ob 10:50 AM napisal: > Hello > > I have config for opensips-cli like this in /etc/opensips-cli.cfg > > database_modules: ALL > > log_level: WARNING > prompt_name: opensips-cli > prompt_intro: Welcome to OpenSIPS at SECUREVOIP > prompt_emptyline_repeat_cmd: False > history_file: ~/.opensips-cli.history > history_file_size: 1000 > output_type: pretty-print > communication_type: fifo > fifo_file: /tmp/opensips_fifo > database_path: /tmp/opensips-3.1/scripts > database_name: opensips > database_admin_url: mysql://root:xxxx at localhost:3306/opensips > database_url: mysql://opensips:opensipsrw at localhost:3306/opensips > > When i run in opensips-cli shell "database create" i get: > > ERROR: failed to connect to DB as opensips, please provide or fix the > 'database_url' > > I can see data DB opensips was created and also opensips user was created. > > > thank you > miha > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon May 3 11:21:20 2021 From: miha at softnet.si (Miha) Date: Mon, 3 May 2021 13:21:20 +0200 Subject: [OpenSIPS-Users] opensips-cli issue with DB creation In-Reply-To: <2be27039-4e75-6986-74df-564049413fc5@softnet.si> References: <09920984-9b76-ba3b-970e-24c82f2637db@softnet.si> <2be27039-4e75-6986-74df-564049413fc5@softnet.si> Message-ID: <32d5569d-9747-c889-dd4c-369136d0f3fc@softnet.si> hello i changed config to like this and now it works: [default] #database_modules: acc clusterer dialog dialplan dispatcher domain rtpproxy usrloc database_modules: ALL log_level: WARNING #prompt_name: opensips-cli #prompt_intro: Welcome to OpenSIPS #prompt_emptyline_repeat_cmd: False #history_file: ~/.opensips-cli.history #history_file_size: 1000 #output_type: pretty-print communication_type: fifo fifo_file: /tmp/opensips_fifo #[mysql] database_path: /tmp/opensips-3.1/scripts database_name: opensips database_admin_url: mysql://root:xxx at localhost database_url: mysql://opensips:opensipsrw at localhost database_schema_path: /tmp/opensips-3.1/scripts Miha via Users je 5/3/2021 ob 12:00 PM napisal: > Pasting also log: > >  database create > DEBUG: running command 'create' '[]' > DEBUG: db_name: 'opensips' > Password for admin MySQL user (root): > DEBUG: read password: 'xxx' > DEBUG: admin DB URL: 'mysql://root:xxx at localhost' > DEBUG: connecting to mysql://root:xxx at localhost > DEBUG: check database URL 'mysql://root:xxx at localhost/opensips' > DEBUG: DB does not exist > DEBUG: Create Database 'opensips' for dialect 'mysql' ... > DEBUG: success > DEBUG: DB URL: 'mysql://opensips:opensipsrw at localhost' > DEBUG: connecting to mysql://opensips:opensipsrw at localhost/opensips > INFO: creating access user for opensips ... > /usr/local/lib/python3.7/dist-packages/SQLAlchemy-1.3.3-py3.7-linux-x86_64.egg/sqlalchemy/engine/default.py:552: > Warning: (3163, "Authorization ID 'opensips'@'%' already exists.") >   cursor.execute(statement, parameters) > INFO: created user 'opensips' > INFO: set password 'o********w' for 'opensips' (MySQL) > INFO: granted access to user 'opensips' on DB 'opensips' > INFO: flushed privileges > DEBUG: connecting to mysql://opensips:opensipsrw at localhost/opensips > ERROR: failed to connect to DB as opensips, please provide or fix the > 'database_url' > > Miha via Users je 5/3/2021 ob 10:50 AM napisal: >> Hello >> >> I have config for opensips-cli like this in /etc/opensips-cli.cfg >> >> database_modules: ALL >> >> log_level: WARNING >> prompt_name: opensips-cli >> prompt_intro: Welcome to OpenSIPS at SECUREVOIP >> prompt_emptyline_repeat_cmd: False >> history_file: ~/.opensips-cli.history >> history_file_size: 1000 >> output_type: pretty-print >> communication_type: fifo >> fifo_file: /tmp/opensips_fifo >> database_path: /tmp/opensips-3.1/scripts >> database_name: opensips >> database_admin_url: mysql://root:xxxx at localhost:3306/opensips >> database_url: mysql://opensips:opensipsrw at localhost:3306/opensips >> >> When i run in opensips-cli shell "database create" i get: >> >> ERROR: failed to connect to DB as opensips, please provide or fix the >> 'database_url' >> >> I can see data DB opensips was created and also opensips user was >> created. >> >> >> thank you >> miha >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quick at smartvox.co.uk Wed May 5 14:16:56 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Wed, 5 May 2021 15:16:56 +0100 Subject: [OpenSIPS-Users] opensips-cli database create crashes if username is not opensips Message-ID: <001a01d741b9$51f38cf0$f5daa6d0$@smartvox.co.uk> I am new to v3 and just started learning how to use opensips-cli. With the old v2.4 opensipsdbctl utility it was possible to change the username before creating the database and the dbctl utility would create a new user in MySQL with the specified name and password, giving them appropriate privileges for r/w access to the data in the tables. When I try to do the equivalent in opensips-cli, it creates a new database called opensips (with no tables), then crashes: (osipscli-local): database create Password for admin MySQL user (root): Traceback (most recent call last): File "/usr/lib/python3.7/cmd.py", line 214, in onecmd func = getattr(self, 'do_' + cmd) AttributeError: 'OpenSIPSCLIShell' object has no attribute 'do_database' ... ... I've experimented and confirmed that the 'database create' command works fine as long as the username is left as default "opensips". i.e. if this line is present in the opensips-cli.cfg file then it will crash when I create the database: database_url: mysql://myusername:abc123 at localhost ..but if it looks like this instead then it works okay: database_url: mysql://opensips:abc123 at localhost I tried it with and without the following line, but it made no difference: database_name: opensips I'm using the Debian buster binaries from Nick Altmann's repository. V3.1.1 # opensips-cli -v OpenSIPS CLI 0.1.0 John Quick Smartvox Limited From andrew at rwts.com.au Thu May 6 01:01:42 2021 From: andrew at rwts.com.au (Andrew Yager) Date: Thu, 6 May 2021 11:01:42 +1000 Subject: [OpenSIPS-Users] bla_presentity_spec variable seems to not work? Message-ID: Hi, Hoping someone can give me a pointer on using the bla_presentity_spec setting. I can't seem to get it to have any affect on the subscription as it's reported in the watchers table. loadmodule "presence.so" modparam("presence", "db_url", "mysql://opensips:opensipsrw at 127.0.0.1:3306/opensips") modparam("presence", "fallback2db", 1) modparam("presence", "cluster_pres_events" ,"presence, dialog;sla, message-summary") modparam("presence", "bla_presentity_spec", "$var(bla_pres)") loadmodule "presence_dialoginfo.so" loadmodule "presence_mwi.so" route { if(is_method("SUBSCRIBE")) { xlog("SUBSCRIBE from $si to $ru"); $var(bla_pres)="sip:foo at bar.com" handle_subscribe(); exit; } } … but the active_watcher table has no record anywhere of "foo at bar.com" What I was expecting to be able to do was to modify the presentity_uri or to_user or to_domain, but none of these seem to happen. Running 3.1.1-1 apt package on Ubuntu 20 for this test. Thanks, Andrew From razvan at opensips.org Thu May 6 15:17:52 2021 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 6 May 2021 18:17:52 +0300 Subject: [OpenSIPS-Users] [RELEASE] OpenSIPS 3.1.2 and 2.4.10 minor releases planning In-Reply-To: References: Message-ID: <17f47bd6-a9e0-a1ca-af63-0eb240b0b2db@opensips.org> Hi, everyone! As planned, we have released two new OpenSIPS minor releases: 3.1.2 and 2.4.10. They only contain bug fixes, so you should be able to update without any migration. Happy hacking! Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 4/21/21 12:29 PM, Răzvan Crainea wrote: > Hi, Everyone! > > I am glad to announce you that we have scheduled two new minor releases > of our OpenSIPS stable branches. Therefore, on 6th of May 2021 we will > release OpenSIPS 3.1.2 and 2.4.10! > These new releases contain the latest bug fixes, and are fully > compatible with previous versions. > In order to increase releases' stability, we decided to freeze the code > for two weeks - during this period the community is encouraged to fully > test the upcoming releases and report any urgent matters, that we can > eventually get fixed by the time of the release. The freeze starts > tomorrow, 22nd of April 2021 and will last till the time of release, 6th > of May 2021. > > Happy hacking! From miha at softnet.si Fri May 7 11:18:17 2021 From: miha at softnet.si (Miha) Date: Fri, 7 May 2021 13:18:17 +0200 Subject: [OpenSIPS-Users] utimer task already scheduled Message-ID: <41479ce9-fd59-c5e2-be39-5c408d940faa@softnet.si> Hi I have falow opensips configuration from your blog regarding MsTeams. Version that I am using is: (opensips-cli): mi  version {     "Server": "OpenSIPS (3.1.1 (x86_64/linux))" } ay  7 13:15:06 mtsbc opensips[1966]: WARNING:core:utimer_ticker: utimer task already scheduled 100 ms ago (now 155250 ms), delaying execution May  7 13:15:06 mtsbc opensips[1966]: WARNING:core:utimer_ticker: utimer task already scheduled 200 ms ago (now 155350 ms), delaying execution May  7 13:15:06 mtsbc opensips[1966]: WARNING:core:utimer_ticker: utimer task already scheduled 290 ms ago (now 155440 ms), delaying execution What could cause this behaviour? On opensips for now nothing is running, this starts from the beginning when opensips start. thank you miha -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Fri May 7 17:07:27 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Fri, 07 May 2021 18:07:27 +0100 Subject: [OpenSIPS-Users] routing function variable scope In-Reply-To: <341ea76e-10c6-40f0-1cc2-6c7da67635e4@opensips.org> References: <927c304f4e603c4330f5329b00e66a4493dc0f2b.camel@dns99.co.uk> <341ea76e-10c6-40f0-1cc2-6c7da67635e4@opensips.org> Message-ID: <943404b70d9ba7abccd6c5f8787bdc9bfa67aa20.camel@dns99.co.uk> On Wed, 2021-04-28 at 15:27 +0300, Liviu Chircu wrote: > On 28.04.2021 15:19, Kingsley Tart wrote: > > Is there a better way, apart from trying to make sure that > > variables in > > each function don't share names with variables in other functions? > > No, you have to manage those iterator names and make sure the logic > still holds during nested calls. Hi, I have now ran into the opposite problem! Given that values seem to be globally shared, I am now trying to use a sub-function to set the value of a $var() variable from a parent function, but the changed value gets lost when the sub function quits. Here is the code: route[bhah] { xlog("ALLOW BEFORE=\"$var(N9_hdrval)\"\n"); route(csv_filter, $var(N9_hdrval), "(?i)^ *(OPTIONS|INVITE|ACK|BYE|CANCEL|UPDATE|PRACK|MESSAGE) *$", "N9_hdrval"); xlog("ALLOW AFTER=\"$var(N9_hdrval)\"\n"); } route[csv_filter] { $var(N11_srcCSV) = $param(1); $var(N11_filter_regex) = $param(2); $var(N11_resultvar_name) = $param(3); $var(N11_result) = ""; $var(N11_pos) = $(var(N11_srcCSV){csv.count}) - 1; while ($var(N11_pos) >= 0) { $var(N11_element) = $(var(N11_srcCSV){csv.value,$var(N11_pos)}); if (pcre_match($var(N11_element), $var(N11_filter_regex))) { $var(N11_result) = $var(N11_element) + "," + $var(N11_result); } $var(N11_pos) = $var(N11_pos) - 1; } $var(N11_resultLen) = $(var(N11_result){s.len}) - 1; $var($var(N11_resultvar_name)) = $(var(N11_result){s.substr,0,$var(N11_resultLen)}); xlog("FILTERED var($var(N11_resultvar_name))=\"$var($var(N11_resultvar_name))\"\n"); } But this is what gets logged: opensips[21955]: ALLOW BEFORE="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE" opensips[21955]: FILTERED var(N9_hdrval)="OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE" opensips[21955]: ALLOW AFTER="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE" This is what I was hoping to get: opensips[21955]: ALLOW BEFORE="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE" opensips[21955]: FILTERED var(N9_hdrval)="OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE" opensips[21955]: ALLOW AFTER="OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE" Have I done something silly here? Cheers, Kingsley. From Ben.Newlin at genesys.com Fri May 7 17:32:00 2021 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 7 May 2021 17:32:00 +0000 Subject: [OpenSIPS-Users] routing function variable scope In-Reply-To: <943404b70d9ba7abccd6c5f8787bdc9bfa67aa20.camel@dns99.co.uk> References: <927c304f4e603c4330f5329b00e66a4493dc0f2b.camel@dns99.co.uk> <341ea76e-10c6-40f0-1cc2-6c7da67635e4@opensips.org>, <943404b70d9ba7abccd6c5f8787bdc9bfa67aa20.camel@dns99.co.uk> Message-ID: Kingsley, I think the issue here is the nested variable name references. I think within route csv_filter, you are actually setting a variable called “$var(N11_resultvar_name)”, not a variable with the name of the contents of that variable. I believe you can easily confirm this with two things: * Remove (or ignore) the parameter providing the variable name and hardcode it to “N9_hdrval” in csv_filter for a test. You should see the variable is now set when printed after. and/or * Add another log after csv_filter that prints the contents of $var($var(N11_resultvar_name)). I think you will find it also contains the correct value. Ben Newlin From: Users on behalf of Kingsley Tart Date: Friday, May 7, 2021 at 1:08 PM To: Liviu Chircu , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] routing function variable scope On Wed, 2021-04-28 at 15:27 +0300, Liviu Chircu wrote: > On 28.04.2021 15:19, Kingsley Tart wrote: > > Is there a better way, apart from trying to make sure that > > variables in > > each function don't share names with variables in other functions? > > No, you have to manage those iterator names and make sure the logic > still holds during nested calls. Hi, I have now ran into the opposite problem! Given that values seem to be globally shared, I am now trying to use a sub-function to set the value of a $var() variable from a parent function, but the changed value gets lost when the sub function quits. Here is the code: route[bhah] { xlog("ALLOW BEFORE=\"$var(N9_hdrval)\"\n"); route(csv_filter, $var(N9_hdrval), "(?i)^ *(OPTIONS|INVITE|ACK|BYE|CANCEL|UPDATE|PRACK|MESSAGE) *$", "N9_hdrval"); xlog("ALLOW AFTER=\"$var(N9_hdrval)\"\n"); } route[csv_filter] { $var(N11_srcCSV) = $param(1); $var(N11_filter_regex) = $param(2); $var(N11_resultvar_name) = $param(3); $var(N11_result) = ""; $var(N11_pos) = $(var(N11_srcCSV){csv.count}) - 1; while ($var(N11_pos) >= 0) { $var(N11_element) = $(var(N11_srcCSV){csv.value,$var(N11_pos)}); if (pcre_match($var(N11_element), $var(N11_filter_regex))) { $var(N11_result) = $var(N11_element) + "," + $var(N11_result); } $var(N11_pos) = $var(N11_pos) - 1; } $var(N11_resultLen) = $(var(N11_result){s.len}) - 1; $var($var(N11_resultvar_name)) = $(var(N11_result){s.substr,0,$var(N11_resultLen)}); xlog("FILTERED var($var(N11_resultvar_name))=\"$var($var(N11_resultvar_name))\"\n"); } But this is what gets logged: opensips[21955]: ALLOW BEFORE="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE" opensips[21955]: FILTERED var(N9_hdrval)="OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE" opensips[21955]: ALLOW AFTER="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE" This is what I was hoping to get: opensips[21955]: ALLOW BEFORE="OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE" opensips[21955]: FILTERED var(N9_hdrval)="OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE" opensips[21955]: ALLOW AFTER="OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE" Have I done something silly here? Cheers, Kingsley. _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at rwts.com.au Sun May 9 09:54:26 2021 From: andrew at rwts.com.au (Andrew Yager) Date: Sun, 9 May 2021 19:54:26 +1000 Subject: [OpenSIPS-Users] bla_presentity_spec variable seems to not work? In-Reply-To: References: Message-ID: I think I had bridge line appearances and BLF state confused, but regardless the correct way to do what I was trying to do was to update the $ru variable. This updates the presentity_uri value as I expected, and handsets can work correctly. Hope this helps someone else trying to find this in the future. Thanks, Andrew On Thu, 6 May 2021 at 11:01, Andrew Yager wrote: > Hi, > > Hoping someone can give me a pointer on using the bla_presentity_spec > setting. I can't seem to get it to have any affect on the subscription > as it's reported in the watchers table. > > loadmodule "presence.so" > modparam("presence", "db_url", > "mysql://opensips:opensipsrw at 127.0.0.1:3306/opensips") > modparam("presence", "fallback2db", 1) > modparam("presence", "cluster_pres_events" ,"presence, dialog;sla, > message-summary") > modparam("presence", "bla_presentity_spec", "$var(bla_pres)") > > loadmodule "presence_dialoginfo.so" > loadmodule "presence_mwi.so" > > route { > if(is_method("SUBSCRIBE")) > { > xlog("SUBSCRIBE from $si to $ru"); > $var(bla_pres)="sip:foo at bar.com" > handle_subscribe(); > exit; > } > } > > … but the active_watcher table has no record anywhere of "foo at bar.com" > > What I was expecting to be able to do was to modify the presentity_uri > or to_user or to_domain, but none of these seem to happen. > > Running 3.1.1-1 apt package on Ubuntu 20 for this test. > > Thanks, > Andrew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quick at smartvox.co.uk Sun May 9 17:20:58 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Sun, 9 May 2021 18:20:58 +0100 Subject: [OpenSIPS-Users] routing function variable scope Message-ID: <000a01d744f7$b0e7a160$12b6e420$@smartvox.co.uk> Kingsley, I hope you won't be offended, but in my opinion you are at risk of sacrificing code readability in the pursuit of code re-usability. If you accept that variables are in-scope both within the route and the sub-route, then why not just have one variable for the result - set it inside the sub-route and read the result from it immediately after the sub-route has returned. This may not be quite right for a code style perfectionist, but at least it would be easily understood by the rooky programmer who has to maintain your code in 5 years' time. John Quick Smartvox Limited From miha at softnet.si Mon May 10 06:54:11 2021 From: miha at softnet.si (Miha) Date: Mon, 10 May 2021 08:54:11 +0200 Subject: [OpenSIPS-Users] MS team issue Message-ID: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Hello I have used letsenrypt for generating certs for Opensips. Regarding configuration i have fallowed your configuration steps on OpenSips blog. socket=udp:xxx.xxx.xxx.xxx:5060   # CUSTOMIZE ME socket=tls:xxx.xxx.xxx.xxx:5061 ### Proto TLS loadmodule "proto_tls.so" modparam("proto_tls", "tls_handshake_timeout", 300) #### TLS module loadmodule "tls_mgm.so" #modparam("tls_mgm", "db_url", "mysql://root:xxxx at localhost/opensips") modparam("tls_mgm", "client_sip_domain_avp", "mtsbcs.test.com") modparam("tls_mgm", "server_domain", "mt") #modparam("tls_mgm", "match_ip_address", "[mt]xxx.xxx.xxx.xxx:5061") #modparam("tls_mgm", "match_sip_domain", "[mt]mtsbcs.test.com") modparam("tls_mgm", "certificate", "[mt]/etc/letsencrypt/live/mtsbcs.test.com/cert.pem") modparam("tls_mgm", "private_key", "[mt]/etc/letsencrypt/live/mtsbcs.test.com/privkey.pem") modparam("tls_mgm", "ca_list", "[mt]/etc/ssl/certs/ca-certificates.crt") modparam("tls_mgm", "ca_dir", "[mt]/etc/ssl/certs/") modparam("tls_mgm","verify_cert", "[mt]1") modparam("tls_mgm","require_cert", "[mt]1") modparam("tls_mgm","tls_method", "[mt]TLSv1_2") modparam("proto_tls", "tls_max_msg_chunks", 8) #modparam("tls_mgm", "tls_handshake_timeout", 300)         if(is_method("OPTIONS") && is_domain_local("$rd") && check_source_address(0)) {                 xlog("L_INFO", "[MS TEAMS] OPTIONS In");                 send_reply(200, "OK");                 exit;         } local_route {   $var(dst) = "pstnhub.microsoft.com";   xlog("L_INFO","promding TEST");   xlog("TESTING");   if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL))     append_hf("Contact: \r\n");     xlog("L_INFO", "SEDING OPTIONS TO SBC"); } I thnk that the main issue is that OPENSIPS does not send encrypted OPTION to MS teams. Logs: May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: next_hop= May 10 08:53:10 mtsbc opensips[1020]: DBG:core:mk_proxy: doing DNS lookup... May 10 08:53:10 mtsbc opensips[1020]: DBG:core:sip_resolvehost: no port, has proto -> do SRV lookup! May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: resolving [sip.pstnhub.microsoft.com] May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: SRV(_sips._tcp.sip.pstnhub.microsoft.com) = sip.pstnhub.microsoft.com:5061 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing sip2.pstnhub.microsoft.com:5061 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing sip3.pstnhub.microsoft.com:5061 May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: sending socket is 212.13.249.132 May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:print_request_uri: sip:sip.pstnhub.microsoft.com May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: building sip_msg from buffer May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: SIP Request: May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: method:  May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: uri:     May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: version: May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via_param: found param type 232, = ; state=16 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via: end of header reached, state=5 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: via found, flags=ffffffffffffffff May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: this is the first via May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: end of header reached, state=9 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: display={}, ruri={sip:sip.pstnhub.microsoft.com} May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: [31]; uri=[sip:sip.pstnhub.microsoft.com] May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: to body [sip:sip.pstnhub.microsoft.com#015#012] May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: cseq : <14> May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: content_length=0 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: found end of header May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=78 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: Change in local route -> rebuilding buffer May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=2000 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: flags = 15 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 2 extracted as May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 1 extracted as ;tag=a665d66adab06c7308a33b8567de92d6-f627#015#012> May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 8 extracted as May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no open tcp connection found, opening new one May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: using snd buffer of 416 kb May 10 08:53:10 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP keepalive enabled on socket 5 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: new tcp connection to: 52.114.75.24 May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port 5061, proto 3 May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: Creating a whole new ssl connection May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: destroying connection 0x7f45d7e08078, flags 0018 May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [0]: 0x7f45d7e066b0 (1625) May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:timer_routine: timer routine:0,tl=0x7f45d7e066b0 next=(nil), timeout=1625 May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: Cancel sent out, sending 408 (0x7f45d7e06460) May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: T_code=0, new_code=408 May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_pick_branch: picked branch 0, code 408 (prio=800) May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:is_3263_failure: dns-failover test: branch=0, last_recv=408, flags=0 May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: trying DNS-based failover May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:do_dns_failover: new destination available May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: flags=2000 May 10 08:53:15 mtsbc opensips[1020]: DBG:core:build_req_buf_from_sip_req: id added: <;i=0>, rcv proto=3 May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no open tcp connection found, opening new one May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: using snd buffer of 416 kb May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP keepalive enabled on socket 5 May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: new tcp connection to: 52.114.132.46 May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port 5061, proto 3 May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: Creating a whole new ssl connection May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: destroying connection 0x7f45d7e08078, flags 0018 May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no open tcp connection found, opening new one May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384 May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: using snd buffer of 416 kb May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP keepalive enabled on socket 5 May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: new tcp connection to: 52.114.14.70 May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port 5061, proto 3 May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: Creating a whole new ssl connection May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: destroying connection 0x7f45d7e08078, flags 0018 May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: branch=0, save=0, winner=0 May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: local transaction completed May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:run_trans_callbacks: trans=0x7f45d7e06460, callback type 256, id 0 entered May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [2]: 0x7f45d7e064e0 (1630) May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: done Thank you miha -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon May 10 07:31:22 2021 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 10 May 2021 10:31:22 +0300 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> Message-ID: <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> Hi, Kingsley! No, this is not a bug, it's exactly as it has been developped [1]. [1] https://opensips.org/docs/modules/3.1.x/acc.html#overview: If a value is not present in the request, the empty string is accounted instead. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 4/29/21 4:21 PM, Kingsley Tart wrote: > Hi, > > This is with OpenSIPS 3.1. > > I have extra DB fields defined with "extra_fields", and this was > working fine until I tried to turn on multi-leg accounting so that I > could log details of failures, eg endpoint address, SIP response etc. > > I have a failure route set up to try the next endpoint, eg when I get > an INVITE: > > t_on_failure("next_host"); > > and: > > failure_route[next_host] { > # dialog flag 1 means a CANCEL has been received > if (!is_dlg_flag_set(1)) { > $avp(endpoint) = NULL; > if ($avp(endpoint)) { > t_on_failure("next_host"); > acc_new_leg(); > sethost($avp(endpoint)); > route(numheaders_set_for_endpoint); > route(relay); > exit; > } > send_reply(503, "Service unavailable"); > exit; > } > } > > > The problems started when I added acc_new_leg() into the failure route. > I've set this up so that the first few endpoints fail so that I can see > what is happening. > > The problem is that when the BYE is received, I get the following > errors: > > CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1366): Incorrect integer value: '' for column `opensips`.`acc`.`t_ringing` at row 1 > ERROR:core:db_do_insert: error while submitting query > ERROR:acc:acc_db_request: failed to insert into acc table > > The problem here is that t_ringing is an integer column (which defaults > to NULL) so it can't take a string, and OpenSIPS is trying to set the > value to an empty string. > > I tried specifically setting $acc_extra(t_ringing) = NULL but this made > no difference. > > I tried moving t_ringing into "leg_fields" (needed to do that anyway) > and then setting $acc_leg(t_ringing) in the script when needed, but the > same problem persisted. > > These are the DB actions that OpenSIPS performs on the acc and > missed_calls tables: > > Prepare insert into missed_calls (method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created ) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) > > Execute insert into missed_calls (method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created ) values ('INVITE','2007660754','z9hG4bK048.2ac41536.0','1619701113-752375-609080253','401','Unauthorized',TIMESTAMP'2021-04-29 13:58:33','88.151.41.21','00353*9051','01743850850','0018001231234','118118','none','003539994444',NULL,NULL,'1619701113',NULL,NULL,NULL,'1619701113','88.151.41.23',0,TIMESTAMP'2021-04-29 13:58:33') > > Prepare insert into acc (method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created,duration,ms_duration ) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) > > Execute insert into acc (method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created,duration,ms_duration ) values ('INVITE','2007660754',NULL,'1619701113-752375-609080253','503','Service Unavailable',TIMESTAMP'2021-04-29 13:58:33','88.151.41.21','00353*9051','01743850850','0018001231234','118118','none','003539994444',NULL,NULL,'1619701113',NULL,NULL,NULL,'1619701113','88.151.41.23',0,NULL,0,0) > > Query insert into acc (method,from_tag,to_tag,callid,sip_code,sip_reason,time,srcAddr,numFrom,numTo,numPAI,numPPI,hdrPrivacy,numRPID,hdrRPIDprivacy,hdrRPIDscreen,t_start,t_ringing,t_progress,t_answer,t_clear,dstAddr,setuptime,created,duration,ms_duration ) values ('INVITE','2007660754','','1619701113-752375-609080253','503','Service Unavailable','2021-04-29 13:58:33','88.151.41.21','00353*9051','01743850850','0018001231234','118118','none','003539994444','','','1619701113','','','','1619701113','88.151.41.24',0,NULL,0,0) > > Is this a bug? > > I would prefer any fields not set in my script to be either set as > NULL, or perhaps even better not even mentione in the query at all. > > From razvan at opensips.org Mon May 10 07:39:39 2021 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 10 May 2021 10:39:39 +0300 Subject: [OpenSIPS-Users] MS team issue In-Reply-To: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> References: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Message-ID: Hi, Miha! According to your logs, opensips is 100% sending the OPTIONS through tls, but I am not sure it is using the right certificate. You can try to setup sip trace and see the communication between opensips and MSTeams. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 5/10/21 9:54 AM, Miha via Users wrote: > Hello > > I have used letsenrypt for generating certs for Opensips. > > Regarding configuration i have fallowed your configuration steps on > OpenSips blog. > > socket=udp:xxx.xxx.xxx.xxx:5060   # CUSTOMIZE ME > socket=tls:xxx.xxx.xxx.xxx:5061 > > > > > ### Proto TLS > loadmodule "proto_tls.so" > modparam("proto_tls", "tls_handshake_timeout", 300) > #### TLS module > loadmodule "tls_mgm.so" > #modparam("tls_mgm", "db_url", "mysql://root:xxxx at localhost/opensips") > modparam("tls_mgm", "client_sip_domain_avp", "mtsbcs.test.com") > modparam("tls_mgm", "server_domain", "mt") > #modparam("tls_mgm", "match_ip_address", "[mt]xxx.xxx.xxx.xxx:5061") > #modparam("tls_mgm", "match_sip_domain", "[mt]mtsbcs.test.com") > modparam("tls_mgm", "certificate", > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/cert.pem") > modparam("tls_mgm", "private_key", > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/privkey.pem") > modparam("tls_mgm", "ca_list", "[mt]/etc/ssl/certs/ca-certificates.crt") > modparam("tls_mgm", "ca_dir", "[mt]/etc/ssl/certs/") > modparam("tls_mgm","verify_cert", "[mt]1") > modparam("tls_mgm","require_cert", "[mt]1") > modparam("tls_mgm","tls_method", "[mt]TLSv1_2") > modparam("proto_tls", "tls_max_msg_chunks", 8) > #modparam("tls_mgm", "tls_handshake_timeout", 300) > >         if(is_method("OPTIONS") && is_domain_local("$rd") && > check_source_address(0)) { >                 xlog("L_INFO", "[MS TEAMS] OPTIONS In"); >                 send_reply(200, "OK"); >                 exit; >         } > > > local_route { >   $var(dst) = "pstnhub.microsoft.com"; >   xlog("L_INFO","promding TEST"); >   xlog("TESTING"); >   if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL)) >     append_hf("Contact: \r\n"); >     xlog("L_INFO", "SEDING OPTIONS TO SBC"); > } > > > I thnk that the main issue is that OPENSIPS does not send encrypted > OPTION to MS teams. > > Logs: > > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: > next_hop= > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:mk_proxy: doing DNS lookup... > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:sip_resolvehost: no port, > has proto -> do SRV lookup! > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: resolving > [sip.pstnhub.microsoft.com] > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: > SRV(_sips._tcp.sip.pstnhub.microsoft.com) = sip.pstnhub.microsoft.com:5061 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing > sip2.pstnhub.microsoft.com:5061 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing > sip3.pstnhub.microsoft.com:5061 > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: sending socket is > 212.13.249.132 > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:print_request_uri: > sip:sip.pstnhub.microsoft.com > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: building > sip_msg from buffer > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: SIP Request: > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: method:  > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: uri: > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: version: > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: > flags=ffffffffffffffff > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via_param: found > param type 232, = ; state=16 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via: end of header > reached, state=5 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: via found, > flags=ffffffffffffffff > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: this is > the first via > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: end of header > reached, state=9 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: display={}, > ruri={sip:sip.pstnhub.microsoft.com} > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: [31]; > uri=[sip:sip.pstnhub.microsoft.com] > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: to body > [sip:sip.pstnhub.microsoft.com#015#012] > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: cseq > : <14> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: > content_length=0 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: found end > of header > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: > flags=ffffffffffffffff > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=78 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: > flags=ffffffffffffffff > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: Change in > local route -> rebuilding buffer > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=2000 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: > flags=ffffffffffffffff > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: flags = 15 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 2 > extracted as > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 1 > extracted as ;tag=a665d66adab06c7308a33b8567de92d6-f627#015#012> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 8 > extracted as > May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no > open tcp connection found, opening new one > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > getsockopt: snd is initially 16384 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > using snd buffer of 416 kb > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP > keepalive enabled on socket 5 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: > new tcp connection to: 52.114.75.24 > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port > 5061, proto 3 > May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: > Creating a whole new ssl connection > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: > destroying connection 0x7f45d7e08078, flags 0018 > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [0]: > 0x7f45d7e066b0 (1625) > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:timer_routine: timer > routine:0,tl=0x7f45d7e066b0 next=(nil), timeout=1625 > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: > Cancel sent out, sending 408 (0x7f45d7e06460) > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: > T_code=0, new_code=408 > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_pick_branch: picked > branch 0, code 408 (prio=800) > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:is_3263_failure: > dns-failover test: branch=0, last_recv=408, flags=0 > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: > trying DNS-based failover > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:do_dns_failover: new > destination available > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: flags=2000 > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:build_req_buf_from_sip_req: id added: <;i=0>, rcv proto=3 > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: > flags=ffffffffffffffff > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no > open tcp connection found, opening new one > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > getsockopt: snd is initially 16384 > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > using snd buffer of 416 kb > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP > keepalive enabled on socket 5 > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: > new tcp connection to: 52.114.132.46 > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port > 5061, proto 3 > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: > Creating a whole new ssl connection > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: > destroying connection 0x7f45d7e08078, flags 0018 > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no > open tcp connection found, opening new one > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > getsockopt: snd is initially 16384 > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > using snd buffer of 416 kb > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP > keepalive enabled on socket 5 > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: > new tcp connection to: 52.114.14.70 > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port > 5061, proto 3 > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: > Creating a whole new ssl connection > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: > destroying connection 0x7f45d7e08078, flags 0018 > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: branch=0, > save=0, winner=0 > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: local > transaction completed > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:run_trans_callbacks: > trans=0x7f45d7e06460, callback type 256, id 0 entered > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [2]: > 0x7f45d7e064e0 (1630) > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: done > > > > Thank you > miha > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From kingsley at dns99.co.uk Mon May 10 08:27:34 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Mon, 10 May 2021 09:27:34 +0100 Subject: [OpenSIPS-Users] routing function variable scope In-Reply-To: <000a01d744f7$b0e7a160$12b6e420$@smartvox.co.uk> References: <000a01d744f7$b0e7a160$12b6e420$@smartvox.co.uk> Message-ID: <4e9301c14ee4a109a39468f0f1d4fd65497baf94.camel@dns99.co.uk> Hi John, I'm not offended at all, don't worry. Personally I think it's counter-intuitive for a function to change things outside of its scope. For example you wouldn't expect a call to dp_translate() to change any of your own variables, apart from the AVP into which you've told it to put the result. I don't see how having locally scoped variables reduces readability but as you note it does allow code re-use, which can be very useful. Rookie programmers shouldn't be going anywhere near my OpenSIPS scripts :) But they need to learn how to better program, and having a language that can behave like many other popular ones is not something I see as confusing for a learner. Cheers, Kingsley. On Sun, 2021-05-09 at 18:20 +0100, John Quick wrote: > Kingsley, > > I hope you won't be offended, but in my opinion you are at risk of > sacrificing code readability in the pursuit of code re-usability. > If you accept that variables are in-scope both within the route and the > sub-route, then why not just have one variable for the result - set it > inside the sub-route and read the result from it immediately after the > sub-route has returned. This may not be quite right for a code style > perfectionist, but at least it would be easily understood by the rooky > programmer who has to maintain your code in 5 years' time. > > John Quick > Smartvox Limited > > From kingsley at dns99.co.uk Mon May 10 10:41:04 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Mon, 10 May 2021 11:41:04 +0100 Subject: [OpenSIPS-Users] routing function variable scope In-Reply-To: References: <927c304f4e603c4330f5329b00e66a4493dc0f2b.camel@dns99.co.uk> <341ea76e-10c6-40f0-1cc2-6c7da67635e4@opensips.org> , <943404b70d9ba7abccd6c5f8787bdc9bfa67aa20.camel@dns99.co.uk> Message-ID: Hi Ben, Thanks for that - yes you're right, that is exactly what is happening. It plays nicer if I use an AVP so I'll have to use that. Thanks once again :) Cheers, Kingsley. On Fri, 2021-05-07 at 17:32 +0000, Ben Newlin wrote: > Kingsley, > > I think the issue here is the nested variable name references. I > think within route csv_filter, you are actually setting a variable > called “$var(N11_resultvar_name)”, not a variable with the name of > the contents of that variable. > > I believe you can easily confirm this with two things: > Remove (or ignore) the parameter providing the variable name and > hardcode it to “N9_hdrval” in csv_filter for a test. You should see > the variable is now set when printed after. > and/or > Add another log after csv_filter that prints the contents of > $var($var(N11_resultvar_name)). I think you will find it also > contains the correct value. > > > Ben Newlin [snip] From kaduww at gmail.com Mon May 10 14:06:51 2021 From: kaduww at gmail.com (Carlos Eduardo) Date: Mon, 10 May 2021 11:06:51 -0300 Subject: [OpenSIPS-Users] MS team issue In-Reply-To: References: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Message-ID: Hey all, About using the right certificate, is it possible to ensure opensips is going to use the right one when multiple are set in tls_mgm? Em seg., 10 de mai. de 2021 às 04:41, Răzvan Crainea escreveu: > Hi, Miha! > > According to your logs, opensips is 100% sending the OPTIONS through > tls, but I am not sure it is using the right certificate. > You can try to setup sip trace and see the communication between > opensips and MSTeams. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 5/10/21 9:54 AM, Miha via Users wrote: > > Hello > > > > I have used letsenrypt for generating certs for Opensips. > > > > Regarding configuration i have fallowed your configuration steps on > > OpenSips blog. > > > > socket=udp:xxx.xxx.xxx.xxx:5060 # CUSTOMIZE ME > > socket=tls:xxx.xxx.xxx.xxx:5061 > > > > > > > > > > ### Proto TLS > > loadmodule "proto_tls.so" > > modparam("proto_tls", "tls_handshake_timeout", 300) > > #### TLS module > > loadmodule "tls_mgm.so" > > #modparam("tls_mgm", "db_url", "mysql://root:xxxx at localhost/opensips") > > modparam("tls_mgm", "client_sip_domain_avp", "mtsbcs.test.com") > > modparam("tls_mgm", "server_domain", "mt") > > #modparam("tls_mgm", "match_ip_address", "[mt]xxx.xxx.xxx.xxx:5061") > > #modparam("tls_mgm", "match_sip_domain", "[mt]mtsbcs.test.com") > > modparam("tls_mgm", "certificate", > > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/cert.pem") > > modparam("tls_mgm", "private_key", > > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/privkey.pem") > > modparam("tls_mgm", "ca_list", "[mt]/etc/ssl/certs/ca-certificates.crt") > > modparam("tls_mgm", "ca_dir", "[mt]/etc/ssl/certs/") > > modparam("tls_mgm","verify_cert", "[mt]1") > > modparam("tls_mgm","require_cert", "[mt]1") > > modparam("tls_mgm","tls_method", "[mt]TLSv1_2") > > modparam("proto_tls", "tls_max_msg_chunks", 8) > > #modparam("tls_mgm", "tls_handshake_timeout", 300) > > > > if(is_method("OPTIONS") && is_domain_local("$rd") && > > check_source_address(0)) { > > xlog("L_INFO", "[MS TEAMS] OPTIONS In"); > > send_reply(200, "OK"); > > exit; > > } > > > > > > local_route { > > $var(dst) = "pstnhub.microsoft.com"; > > xlog("L_INFO","promding TEST"); > > xlog("TESTING"); > > if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL)) > > append_hf("Contact: \r\n"); > > xlog("L_INFO", "SEDING OPTIONS TO SBC"); > > } > > > > > > I thnk that the main issue is that OPENSIPS does not send encrypted > > OPTION to MS teams. > > > > Logs: > > > > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: > > next_hop= > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:mk_proxy: doing DNS > lookup... > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:sip_resolvehost: no port, > > has proto -> do SRV lookup! > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: resolving > > [sip.pstnhub.microsoft.com] > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: > > SRV(_sips._tcp.sip.pstnhub.microsoft.com) = > sip.pstnhub.microsoft.com:5061 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing > > sip2.pstnhub.microsoft.com:5061 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing > > sip3.pstnhub.microsoft.com:5061 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: sending socket is > > 212.13.249.132 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:print_request_uri: > > sip:sip.pstnhub.microsoft.com > > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: building > > sip_msg from buffer > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: SIP Request: > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: method: > > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: uri: > > > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: version: > > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: > > flags=ffffffffffffffff > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via_param: found > > param type 232, = ; state=16 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via: end of header > > reached, state=5 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: via found, > > flags=ffffffffffffffff > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: this is > > the first via > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: end of header > > reached, state=9 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: display={}, > > ruri={sip:sip.pstnhub.microsoft.com} > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: [31]; > > uri=[sip:sip.pstnhub.microsoft.com] > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: to body > > [sip:sip.pstnhub.microsoft.com#015#012 > ] > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: cseq > > : <14> > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: > > content_length=0 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: found end > > of header > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: > > flags=ffffffffffffffff > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=78 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: > > flags=ffffffffffffffff > > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: Change in > > local route -> rebuilding buffer > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=2000 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: > > flags=ffffffffffffffff > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: flags = > 15 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 2 > > extracted as > > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 1 > > extracted as > >;tag=a665d66adab06c7308a33b8567de92d6-f627#015#012> > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 8 > > extracted as > > > May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no > > open tcp connection found, opening new one > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > > getsockopt: snd is initially 16384 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > > using snd buffer of 416 kb > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP > > keepalive enabled on socket 5 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: > > new tcp connection to: 52.114.75.24 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port > > 5061, proto 3 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: > > Creating a whole new ssl connection > > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: > > destroying connection 0x7f45d7e08078, flags 0018 > > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [0]: > > 0x7f45d7e066b0 (1625) > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:timer_routine: timer > > routine:0,tl=0x7f45d7e066b0 next=(nil), timeout=1625 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: > > Cancel sent out, sending 408 (0x7f45d7e06460) > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: > > T_code=0, new_code=408 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_pick_branch: picked > > branch 0, code 408 (prio=800) > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:is_3263_failure: > > dns-failover test: branch=0, last_recv=408, flags=0 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: > > trying DNS-based failover > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:do_dns_failover: new > > destination available > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: flags=2000 > > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:build_req_buf_from_sip_req: id added: <;i=0>, rcv proto=3 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: > > flags=ffffffffffffffff > > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no > > open tcp connection found, opening new one > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > > getsockopt: snd is initially 16384 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > > using snd buffer of 416 kb > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP > > keepalive enabled on socket 5 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: > > new tcp connection to: 52.114.132.46 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port > > 5061, proto 3 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: > > Creating a whole new ssl connection > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: > > destroying connection 0x7f45d7e08078, flags 0018 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no > > open tcp connection found, opening new one > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > > getsockopt: snd is initially 16384 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: > > using snd buffer of 416 kb > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP > > keepalive enabled on socket 5 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: > > new tcp connection to: 52.114.14.70 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port > > 5061, proto 3 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: > > Creating a whole new ssl connection > > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: > > destroying connection 0x7f45d7e08078, flags 0018 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: branch=0, > > save=0, winner=0 > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: local > > transaction completed > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:run_trans_callbacks: > > trans=0x7f45d7e06460, callback type 256, id 0 entered > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [2]: > > 0x7f45d7e064e0 (1630) > > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: done > > > > > > > > Thank you > > miha > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *Carlos E. Wagner* *Tecnólogo em Telecomunicações, Opensips Certified Professional* *Fone: +55 48 99981-0894* *E-mail:* kaduww at gmail.com *LinkedIn:* https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at altmann.pro Mon May 10 14:41:44 2021 From: nick at altmann.pro (Nick Altmann) Date: Mon, 10 May 2021 16:41:44 +0200 Subject: [OpenSIPS-Users] MS team issue In-Reply-To: References: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Message-ID: Yes. You can use avp for this. https://opensips.org/docs/modules/3.1.x/tls_mgm.html#param_client_sip_domain_avp -- Nick пн, 10 мая 2021 г. в 16:09, Carlos Eduardo : > Hey all, > > About using the right certificate, is it possible to ensure opensips is > going to use the right one when multiple are set in tls_mgm? > > Em seg., 10 de mai. de 2021 às 04:41, Răzvan Crainea > escreveu: > >> Hi, Miha! >> >> According to your logs, opensips is 100% sending the OPTIONS through >> tls, but I am not sure it is using the right certificate. >> You can try to setup sip trace and see the communication between >> opensips and MSTeams. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.com >> >> On 5/10/21 9:54 AM, Miha via Users wrote: >> > Hello >> > >> > I have used letsenrypt for generating certs for Opensips. >> > >> > Regarding configuration i have fallowed your configuration steps on >> > OpenSips blog. >> > >> > socket=udp:xxx.xxx.xxx.xxx:5060 # CUSTOMIZE ME >> > socket=tls:xxx.xxx.xxx.xxx:5061 >> > >> > >> > >> > >> > ### Proto TLS >> > loadmodule "proto_tls.so" >> > modparam("proto_tls", "tls_handshake_timeout", 300) >> > #### TLS module >> > loadmodule "tls_mgm.so" >> > #modparam("tls_mgm", "db_url", "mysql://root:xxxx at localhost/opensips") >> > modparam("tls_mgm", "client_sip_domain_avp", "mtsbcs.test.com") >> > modparam("tls_mgm", "server_domain", "mt") >> > #modparam("tls_mgm", "match_ip_address", "[mt]xxx.xxx.xxx.xxx:5061") >> > #modparam("tls_mgm", "match_sip_domain", "[mt]mtsbcs.test.com") >> > modparam("tls_mgm", "certificate", >> > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/cert.pem") >> > modparam("tls_mgm", "private_key", >> > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/privkey.pem") >> > modparam("tls_mgm", "ca_list", "[mt]/etc/ssl/certs/ca-certificates.crt") >> > modparam("tls_mgm", "ca_dir", "[mt]/etc/ssl/certs/") >> > modparam("tls_mgm","verify_cert", "[mt]1") >> > modparam("tls_mgm","require_cert", "[mt]1") >> > modparam("tls_mgm","tls_method", "[mt]TLSv1_2") >> > modparam("proto_tls", "tls_max_msg_chunks", 8) >> > #modparam("tls_mgm", "tls_handshake_timeout", 300) >> > >> > if(is_method("OPTIONS") && is_domain_local("$rd") && >> > check_source_address(0)) { >> > xlog("L_INFO", "[MS TEAMS] OPTIONS In"); >> > send_reply(200, "OK"); >> > exit; >> > } >> > >> > >> > local_route { >> > $var(dst) = "pstnhub.microsoft.com"; >> > xlog("L_INFO","promding TEST"); >> > xlog("TESTING"); >> > if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL)) >> > append_hf("Contact: > ;transport=tls>\r\n"); >> > xlog("L_INFO", "SEDING OPTIONS TO SBC"); >> > } >> > >> > >> > I thnk that the main issue is that OPENSIPS does not send encrypted >> > OPTION to MS teams. >> > >> > Logs: >> > >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: >> > next_hop= >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:mk_proxy: doing DNS >> lookup... >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:sip_resolvehost: no >> port, >> > has proto -> do SRV lookup! >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: resolving >> > [sip.pstnhub.microsoft.com] >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: >> > SRV(_sips._tcp.sip.pstnhub.microsoft.com) = >> sip.pstnhub.microsoft.com:5061 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing >> > sip2.pstnhub.microsoft.com:5061 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing >> > sip3.pstnhub.microsoft.com:5061 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: sending socket is >> > 212.13.249.132 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:print_request_uri: >> > sip:sip.pstnhub.microsoft.com >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: building >> > sip_msg from buffer >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: SIP Request: >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: method: >> >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: uri: >> > >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: version: >> >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >> > flags=ffffffffffffffff >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via_param: found >> > param type 232, = ; state=16 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via: end of header >> > reached, state=5 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: via >> found, >> > flags=ffffffffffffffff >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: this is >> > the first via >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: end of header >> > reached, state=9 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: display={}, >> > ruri={sip:sip.pstnhub.microsoft.com} >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: >> [31]; >> > uri=[sip:sip.pstnhub.microsoft.com] >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: to body >> > [sip:sip.pstnhub.microsoft.com#015#012 >> ] >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: cseq >> > : <14> >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: >> > content_length=0 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: found end >> > of header >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >> > flags=ffffffffffffffff >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=78 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >> > flags=ffffffffffffffff >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: Change in >> > local route -> rebuilding buffer >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=2000 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >> > flags=ffffffffffffffff >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: flags >> = 15 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 2 >> > extracted as > > >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 1 >> > extracted as > > > >;tag=a665d66adab06c7308a33b8567de92d6-f627#015#012> >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 8 >> > extracted as > > >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no >> > open tcp connection found, opening new one >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >> > getsockopt: snd is initially 16384 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >> > using snd buffer of 416 kb >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP >> > keepalive enabled on socket 5 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: >> > new tcp connection to: 52.114.75.24 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port >> > 5061, proto 3 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: >> > Creating a whole new ssl connection >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: >> > destroying connection 0x7f45d7e08078, flags 0018 >> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [0]: >> > 0x7f45d7e066b0 (1625) >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:timer_routine: timer >> > routine:0,tl=0x7f45d7e066b0 next=(nil), timeout=1625 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: >> > Cancel sent out, sending 408 (0x7f45d7e06460) >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: >> > T_code=0, new_code=408 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_pick_branch: picked >> > branch 0, code 408 (prio=800) >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:is_3263_failure: >> > dns-failover test: branch=0, last_recv=408, flags=0 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: >> > trying DNS-based failover >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:do_dns_failover: new >> > destination available >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: flags=2000 >> > May 10 08:53:15 mtsbc opensips[1020]: >> > DBG:core:build_req_buf_from_sip_req: id added: <;i=0>, rcv proto=3 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: >> > flags=ffffffffffffffff >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no >> > open tcp connection found, opening new one >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >> > getsockopt: snd is initially 16384 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >> > using snd buffer of 416 kb >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP >> > keepalive enabled on socket 5 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: >> > new tcp connection to: 52.114.132.46 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port >> > 5061, proto 3 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: >> > Creating a whole new ssl connection >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: >> > destroying connection 0x7f45d7e08078, flags 0018 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no >> > open tcp connection found, opening new one >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >> > getsockopt: snd is initially 16384 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >> > using snd buffer of 416 kb >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: TCP >> > keepalive enabled on socket 5 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: >> > new tcp connection to: 52.114.14.70 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port >> > 5061, proto 3 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: >> > Creating a whole new ssl connection >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: >> > destroying connection 0x7f45d7e08078, flags 0018 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: branch=0, >> > save=0, winner=0 >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: local >> > transaction completed >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:run_trans_callbacks: >> > trans=0x7f45d7e06460, callback type 256, id 0 entered >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [2]: >> > 0x7f45d7e064e0 (1630) >> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: >> done >> > >> > >> > >> > Thank you >> > miha >> > >> > >> > _______________________________________________ >> > Users mailing list >> > Users at lists.opensips.org >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > *Carlos E. Wagner* > *Tecnólogo em Telecomunicações, Opensips Certified Professional* > > *Fone: +55 48 99981-0894* > *E-mail:* kaduww at gmail.com > *LinkedIn:* https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaduww at gmail.com Mon May 10 14:45:32 2021 From: kaduww at gmail.com (Carlos Eduardo) Date: Mon, 10 May 2021 11:45:32 -0300 Subject: [OpenSIPS-Users] MS team issue In-Reply-To: References: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Message-ID: Thank you Nick. I've read these docs lots of times and didn't pay attention on it. Em seg., 10 de mai. de 2021 às 11:44, Nick Altmann escreveu: > Yes. You can use avp for this. > https://opensips.org/docs/modules/3.1.x/tls_mgm.html#param_client_sip_domain_avp > > -- > Nick > > пн, 10 мая 2021 г. в 16:09, Carlos Eduardo : > >> Hey all, >> >> About using the right certificate, is it possible to ensure opensips is >> going to use the right one when multiple are set in tls_mgm? >> >> Em seg., 10 de mai. de 2021 às 04:41, Răzvan Crainea >> escreveu: >> >>> Hi, Miha! >>> >>> According to your logs, opensips is 100% sending the OPTIONS through >>> tls, but I am not sure it is using the right certificate. >>> You can try to setup sip trace and see the communication between >>> opensips and MSTeams. >>> >>> Best regards, >>> >>> Răzvan Crainea >>> OpenSIPS Core Developer >>> http://www.opensips-solutions.com >>> >>> On 5/10/21 9:54 AM, Miha via Users wrote: >>> > Hello >>> > >>> > I have used letsenrypt for generating certs for Opensips. >>> > >>> > Regarding configuration i have fallowed your configuration steps on >>> > OpenSips blog. >>> > >>> > socket=udp:xxx.xxx.xxx.xxx:5060 # CUSTOMIZE ME >>> > socket=tls:xxx.xxx.xxx.xxx:5061 >>> > >>> > >>> > >>> > >>> > ### Proto TLS >>> > loadmodule "proto_tls.so" >>> > modparam("proto_tls", "tls_handshake_timeout", 300) >>> > #### TLS module >>> > loadmodule "tls_mgm.so" >>> > #modparam("tls_mgm", "db_url", "mysql://root:xxxx at localhost/opensips") >>> > modparam("tls_mgm", "client_sip_domain_avp", "mtsbcs.test.com") >>> > modparam("tls_mgm", "server_domain", "mt") >>> > #modparam("tls_mgm", "match_ip_address", "[mt]xxx.xxx.xxx.xxx:5061") >>> > #modparam("tls_mgm", "match_sip_domain", "[mt]mtsbcs.test.com") >>> > modparam("tls_mgm", "certificate", >>> > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/cert.pem") >>> > modparam("tls_mgm", "private_key", >>> > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/privkey.pem") >>> > modparam("tls_mgm", "ca_list", >>> "[mt]/etc/ssl/certs/ca-certificates.crt") >>> > modparam("tls_mgm", "ca_dir", "[mt]/etc/ssl/certs/") >>> > modparam("tls_mgm","verify_cert", "[mt]1") >>> > modparam("tls_mgm","require_cert", "[mt]1") >>> > modparam("tls_mgm","tls_method", "[mt]TLSv1_2") >>> > modparam("proto_tls", "tls_max_msg_chunks", 8) >>> > #modparam("tls_mgm", "tls_handshake_timeout", 300) >>> > >>> > if(is_method("OPTIONS") && is_domain_local("$rd") && >>> > check_source_address(0)) { >>> > xlog("L_INFO", "[MS TEAMS] OPTIONS In"); >>> > send_reply(200, "OK"); >>> > exit; >>> > } >>> > >>> > >>> > local_route { >>> > $var(dst) = "pstnhub.microsoft.com"; >>> > xlog("L_INFO","promding TEST"); >>> > xlog("TESTING"); >>> > if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL)) >>> > append_hf("Contact: >> ;transport=tls>\r\n"); >>> > xlog("L_INFO", "SEDING OPTIONS TO SBC"); >>> > } >>> > >>> > >>> > I thnk that the main issue is that OPENSIPS does not send encrypted >>> > OPTION to MS teams. >>> > >>> > Logs: >>> > >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: >>> > next_hop= >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:mk_proxy: doing DNS >>> lookup... >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:sip_resolvehost: no >>> port, >>> > has proto -> do SRV lookup! >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: >>> resolving >>> > [sip.pstnhub.microsoft.com] >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:do_srv_lookup: >>> > SRV(_sips._tcp.sip.pstnhub.microsoft.com) = >>> sip.pstnhub.microsoft.com:5061 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing >>> > sip2.pstnhub.microsoft.com:5061 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:a2dns_node: storing >>> > sip3.pstnhub.microsoft.com:5061 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: sending socket is >>> > 212.13.249.132 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:print_request_uri: >>> > sip:sip.pstnhub.microsoft.com >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: building >>> > sip_msg from buffer >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: SIP Request: >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: method: >>> >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: uri: >>> > >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_msg: version: >>> >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >>> > flags=ffffffffffffffff >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via_param: found >>> > param type 232, = ; state=16 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_via: end of >>> header >>> > reached, state=5 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: via >>> found, >>> > flags=ffffffffffffffff >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: this is >>> > the first via >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: end of >>> header >>> > reached, state=9 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:_parse_to: display={}, >>> > ruri={sip:sip.pstnhub.microsoft.com} >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: >>> [31]; >>> > uri=[sip:sip.pstnhub.microsoft.com] >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: to body >>> > [sip:sip.pstnhub.microsoft.com#015#012 >>> ] >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: cseq >>> > : <14> >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: >>> > content_length=0 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:get_hdr_field: found >>> end >>> > of header >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >>> > flags=ffffffffffffffff >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: flags=78 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >>> > flags=ffffffffffffffff >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:run_local_route: Change >>> in >>> > local route -> rebuilding buffer >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >>> flags=2000 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:parse_headers: >>> > flags=ffffffffffffffff >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: flags >>> = 15 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 2 >>> > extracted as >> > >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 1 >>> > extracted as >> > >> >;tag=a665d66adab06c7308a33b8567de92d6-f627#015#012> >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:extract_ftc_hdrs: hdr 8 >>> > extracted as >> > >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no >>> > open tcp connection found, opening new one >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >>> > getsockopt: snd is initially 16384 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >>> > using snd buffer of 416 kb >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: >>> TCP >>> > keepalive enabled on socket 5 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: >>> > new tcp connection to: 52.114.75.24 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port >>> > 5061, proto 3 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: >>> > Creating a whole new ssl connection >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: >>> > destroying connection 0x7f45d7e08078, flags 0018 >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [0]: >>> > 0x7f45d7e066b0 (1625) >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:timer_routine: timer >>> > routine:0,tl=0x7f45d7e066b0 next=(nil), timeout=1625 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: >>> > Cancel sent out, sending 408 (0x7f45d7e06460) >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: >>> > T_code=0, new_code=408 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_pick_branch: picked >>> > branch 0, code 408 (prio=800) >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:is_3263_failure: >>> > dns-failover test: branch=0, last_recv=408, flags=0 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:t_should_relay_response: >>> > trying DNS-based failover >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:do_dns_failover: new >>> > destination available >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: >>> flags=2000 >>> > May 10 08:53:15 mtsbc opensips[1020]: >>> > DBG:core:build_req_buf_from_sip_req: id added: <;i=0>, rcv proto=3 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:parse_headers: >>> > flags=ffffffffffffffff >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no >>> > open tcp connection found, opening new one >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >>> > getsockopt: snd is initially 16384 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >>> > using snd buffer of 416 kb >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: >>> TCP >>> > keepalive enabled on socket 5 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: >>> > new tcp connection to: 52.114.132.46 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port >>> > 5061, proto 3 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: >>> > Creating a whole new ssl connection >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: >>> > destroying connection 0x7f45d7e08078, flags 0018 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:proto_tls_send: no >>> > open tcp connection found, opening new one >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >>> > getsockopt: snd is initially 16384 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:probe_max_sock_buff: >>> > using snd buffer of 416 kb >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:init_sock_keepalive: >>> TCP >>> > keepalive enabled on socket 5 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:print_ip: tcpconn_new: >>> > new tcp connection to: 52.114.14.70 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_new: on port >>> > 5061, proto 3 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:proto_tls:tls_conn_init: >>> > Creating a whole new ssl connection >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:core:tcpconn_destroy: >>> > destroying connection 0x7f45d7e08078, flags 0018 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: branch=0, >>> > save=0, winner=0 >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:local_reply: local >>> > transaction completed >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:run_trans_callbacks: >>> > trans=0x7f45d7e06460, callback type 256, id 0 entered >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:insert_timer_unsafe: [2]: >>> > 0x7f45d7e064e0 (1630) >>> > May 10 08:53:15 mtsbc opensips[1020]: DBG:tm:final_response_handler: >>> done >>> > >>> > >>> > >>> > Thank you >>> > miha >>> > >>> > >>> > _______________________________________________ >>> > Users mailing list >>> > Users at lists.opensips.org >>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> > >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> -- >> *Carlos E. Wagner* >> *Tecnólogo em Telecomunicações, Opensips Certified Professional* >> >> *Fone: +55 48 99981-0894* >> *E-mail:* kaduww at gmail.com >> *LinkedIn:* https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *Carlos E. Wagner* *Tecnólogo em Telecomunicações, Opensips Certified Professional* *Fone: +55 48 99981-0894* *E-mail:* kaduww at gmail.com *LinkedIn:* https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Mon May 10 15:33:23 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Mon, 10 May 2021 16:33:23 +0100 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> Message-ID: <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> Hi. I tried setting the fields to NULL in the routing script, and then when that didn't make any difference I tried setting them to 0. That didn't help either. I'll have to look over what I did to see if I can reproduce the issue I was having. Cheers, Kingsley. On Mon, 2021-05-10 at 10:31 +0300, Răzvan Crainea wrote: > Hi, Kingsley! > > No, this is not a bug, it's exactly as it has been developped [1]. > > [1] https://opensips.org/docs/modules/3.1.x/acc.html#overview: If a > value is not present in the request, the empty string is accounted > instead. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > From liviu at opensips.org Mon May 10 16:15:07 2021 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 10 May 2021 19:15:07 +0300 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> Message-ID: <349cfaa9-d216-9a9a-6232-8a871d113526@opensips.org> On 10.05.2021 18:33, Kingsley Tart wrote: > I tried setting the fields to NULL in the routing script, and then when > that didn't make any difference I tried setting them to 0. That didn't > help either. Why not just convert all custom (extra, leg) accounting columns to VARCHAR(64) or VARCHAR(128), for example?  While most SQL databases auto-convert integer types to strings, the opposite is _not_ true, hence all of the errors you've been running into. Best, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS eBootcamp 2021 | www.opensips.org/training From kingsley at dns99.co.uk Mon May 10 16:19:28 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Mon, 10 May 2021 17:19:28 +0100 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: <349cfaa9-d216-9a9a-6232-8a871d113526@opensips.org> References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> <349cfaa9-d216-9a9a-6232-8a871d113526@opensips.org> Message-ID: <89c333792f949f604e29c9f897150df52a6be71d.camel@dns99.co.uk> I could do, but I was hoping to avoid that as it feels like bad practice and it's inefficient - more of a workaround than a proper fix. I was really hoping that OpenSIPS would simply not define fields in the query if the value had not been specified. It seems to do as I wish if I don't use multi-leg accounting. Cheers, Kingsley. On Mon, 2021-05-10 at 19:15 +0300, Liviu Chircu wrote: > On 10.05.2021 18:33, Kingsley Tart wrote: > > I tried setting the fields to NULL in the routing script, and then > > when > > that didn't make any difference I tried setting them to 0. That > > didn't > > help either. > > Why not just convert all custom (extra, leg) accounting columns to > VARCHAR(64) or VARCHAR(128), for example? While most SQL databases > auto-convert integer types to strings, the opposite is _not_ true, > hence > all of the errors you've been running into. > > Best, > From liviu at opensips.org Mon May 10 16:25:41 2021 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 10 May 2021 19:25:41 +0300 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: <89c333792f949f604e29c9f897150df52a6be71d.camel@dns99.co.uk> References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> <349cfaa9-d216-9a9a-6232-8a871d113526@opensips.org> <89c333792f949f604e29c9f897150df52a6be71d.camel@dns99.co.uk> Message-ID: On 10.05.2021 19:19, Kingsley Tart wrote: > I could do, but I was hoping to avoid that as it feels like bad > practice and it's inefficient - more of a workaround than a proper fix. Speaking for myself, I don't think I've ever seen a non-VARCHAR custom accounting column with the "acc" module.  Also, if you think about it, writing the 1 integer value requires only 25% of the space if you're writing "1" instead of 1.  So, YMMV with regards to efficiency, we're talking bits and pieces of data here, as the fields themselves are not that large, it's their sheer number required in the CDRs that's often problematic. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS eBootcamp 2021 | www.opensips.org/training From miha at softnet.si Mon May 10 17:23:20 2021 From: miha at softnet.si (Miha) Date: Mon, 10 May 2021 19:23:20 +0200 Subject: [OpenSIPS-Users] MS team issue In-Reply-To: References: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Message-ID: Hello it seems for me that this works now. I only do not know why after 200 ok, opensips sends OPTIONS also to it self, which is quite wird. pasting logs. y 10 19:20:26 mtsbc opensips[7582]: DBG:tm:print_request_uri: sip:sip.pstnhub.microsoft.com May 10 19:20:26 mtsbc opensips[7582]: DBG:tm:run_local_route: building sip_msg from buffer May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_msg: SIP Request: May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_msg: method: May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_msg: uri: May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_msg: version: May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_via_param: found param type 232, = ; state=16 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_via: end of header reached, state=5 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: via found, flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: this is the first via May 10 19:20:26 mtsbc opensips[7582]: DBG:core:_parse_to: end of header reached, state=9 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:_parse_to: display={}, ruri={sip:sip.pstnhub.microsoft.com} May 10 19:20:26 mtsbc opensips[7582]: DBG:core:get_hdr_field: [31]; uri=[sip:sip.pstnhub.microsoft.com] May 10 19:20:26 mtsbc opensips[7582]: DBG:core:get_hdr_field: to body [sip:sip.pstnhub.microsoft.com#015#012] May 10 19:20:26 mtsbc opensips[7582]: DBG:core:get_hdr_field: cseq : <14> May 10 19:20:26 mtsbc opensips[7582]: DBG:core:get_hdr_field: content_length=0 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:get_hdr_field: found end of header May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: flags=78 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_to_param: tag=a665d66adab06c7308a33b8567de92d6-7c10 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:_parse_to: end of header reached, state=29 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:_parse_to: display={}, ruri={sip:prober at localhost} May 10 19:20:26 mtsbc opensips[7582]: DBG:sipcapture:w_sip_capture: src_ip: [xxx.xxx.xxx.xxx] May 10 19:20:26 mtsbc opensips[7582]: DBG:sipcapture:w_sip_capture: dst_ip: [xxx.xxx.xxx.xxx] May 10 19:20:26 mtsbc opensips[7582]: DBG:sipcapture:w_sip_capture: dst_port: [5061] May 10 19:20:26 mtsbc opensips[7582]: DBG:sipcapture:w_sip_capture: src_port: [5061] May 10 19:20:26 mtsbc opensips[7582]: DBG:sipcapture:w_sip_capture: DONE May 10 19:20:26 mtsbc opensips[7582]: DBG:sipcapture:db_sync_store: storing info... May 10 19:20:26 mtsbc opensips[7582]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7f60225e6108 (tail=140050870197640) MC=0x7f60225e6218 May 10 19:20:26 mtsbc opensips[7582]: DBG:db_mysql:db_mysql_do_prepared_query: new query=|insert into sip_capture (date,micro_ts,method,reply_reason,ruri,ruri_user,from_user,from_tag,to_user,to_tag,pid_user,contact_user,auth_user,callid,callid_aleg,via_1,via_1_branch,cseq,reason,content_type,auth,user_agent,source_ip,source_port,destination_ip,destination_port,contact_ip,contact_port,originator_ip,originator_port,proto,family,rtp_stat,type,node,correlation_id,from_domain,to_domain,ruri_domain,msg,custom_field1,custom_field2,custom_field3 ) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)| May 10 19:20:26 mtsbc opensips[7582]: DBG:db_mysql:re_init_statement: query is , ptr=(nil) May 10 19:20:26 mtsbc opensips[7582]: DBG:tm:run_local_route: Change in local route -> rebuilding buffer May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: flags=2000 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7582]: DBG:core:extract_ftc_hdrs: flags = 15 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:extract_ftc_hdrs: hdr 2 extracted as May 10 19:20:26 mtsbc opensips[7582]: DBG:core:extract_ftc_hdrs: hdr 1 extracted as ;tag=a665d66adab06c7308a33b8567de92d6-7c10#015#012> May 10 19:20:26 mtsbc opensips[7582]: DBG:core:extract_ftc_hdrs: hdr 8 extracted as May 10 19:20:26 mtsbc opensips[7582]: DBG:core:tcp_conn_get: con found in state 0 May 10 19:20:26 mtsbc opensips[7582]: DBG:core:tcp_conn_get: tcp connection found (0x7f6005804fc8), acquiring fd May 10 19:20:26 mtsbc opensips[7582]: DBG:core:tcp_conn_get: c= 0x7f6005804fc8, n=16, Usock=123 May 10 19:20:26 mtsbc opensips[7583]: DBG:core:handle_worker: read response= 7f6005804fc8, 1, fd -1 from 17 (7582) May 10 19:20:26 mtsbc opensips[7582]: DBG:core:tcp_conn_get: after receive_fd: c= 0x7f6005804fc8 n=8 fd=5 May 10 19:20:26 mtsbc opensips[7582]: DBG:proto_tls:proto_tls_send: sending via fd 5... May 10 19:20:26 mtsbc opensips[7582]: DBG:proto_tls:tls_update_fd: New fd is 5 May 10 19:20:26 mtsbc opensips[7582]: DBG:proto_tls:tls_write: write was successful (423 bytes) May 10 19:20:26 mtsbc opensips[7582]: DBG:proto_tls:proto_tls_send: after write: c= 0x7f6005804fc8 n=423 fd=5 May 10 19:20:26 mtsbc opensips[7582]: DBG:proto_tls:proto_tls_send: buf=#012OPTIONS sip:sip.pstnhub.microsoft.com SIP/2.0#015#012Via: SIP/2.0/TLS xxx.xxx.xxx.xxx:5061;branch=z9hG4bK2c5c.fa46c831.0#015#012To: sip:sip.pstnhub.microsoft.com#015#012From: ;tag=a665d66adab06c7308a33b8567de92d6-7c10#015#012CSeq: 14 OPTIONS#015#012Call-ID: 63f6e4340443163b-7582 at xxx.xxx.xxx.xxx#015#012Max-Forwards: 70#015#012Content-Length: 0#015#012User-Agent: OpenSIPS (3.1.1 (x86_64/linux))#015#012Contact: #015#012#015#012 May 10 19:20:26 mtsbc opensips[7582]: DBG:tm:insert_timer_unsafe: [0]: 0x7f6005838b78 (13415) May 10 19:20:26 mtsbc opensips[7574]: DBG:proto_tls:tls_read_req: Using the global ( per process ) buff May 10 19:20:26 mtsbc opensips[7574]: DBG:proto_tls:tls_update_fd: New fd is 5 May 10 19:20:26 mtsbc opensips[7574]: DBG:proto_tls:_tls_read: 383 bytes read May 10 19:20:26 mtsbc opensips[7574]: DBG:proto_tls:tcp_handle_req: content-length= 0 May 10 19:20:26 mtsbc opensips[7574]: DBG:proto_tls:tcp_handle_req: Nothing more to read on TCP conn 0x7f6005804fc8, currently in state 0 May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_msg: SIP Reply (status): May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_msg: version: May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_msg: status: <200> May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_msg: reason: May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7574]: DBG:core:_parse_to: end of header reached, state=10 May 10 19:20:26 mtsbc opensips[7574]: DBG:core:_parse_to: display={}, ruri={sip:sip.pstnhub.microsoft.com} May 10 19:20:26 mtsbc opensips[7574]: DBG:core:get_hdr_field: [33]; uri=[sip:sip.pstnhub.microsoft.com] May 10 19:20:26 mtsbc opensips[7574]: DBG:core:get_hdr_field: to body [#015#012] May 10 19:20:26 mtsbc opensips[7574]: DBG:core:get_hdr_field: cseq : <14> May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_via_param: found param type 232, = ; state=16 May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_via: end of header reached, state=5 May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_headers: via found, flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_headers: this is the first via May 10 19:20:26 mtsbc opensips[7574]: DBG:core:get_hdr_field: content_length=0 May 10 19:20:26 mtsbc opensips[7574]: DBG:core:get_hdr_field: found end of header May 10 19:20:26 mtsbc opensips[7574]: DBG:core:receive_msg: After parse_msg... May 10 19:20:26 mtsbc opensips[7574]: DBG:core:forward_reply: found module tm, passing reply to it May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_check: start=0xffffffffffffffff May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_headers: flags=22 May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_reply_matching: hash 50626 label 327967919 branch 0 May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_reply_matching: REF_UNSAFE:[0x7f6005838928] after is 1 May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_reply_matching: reply matched (T=0x7f6005838928)! May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_check: end=0x7f6005838928 May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:reply_received: org. status uas=0, uac[0]=0 local=2 is_invite=0) May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_should_relay_response: T_code=0, new_code=200 May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:local_reply: branch=0, save=0, winner=0 May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:local_reply: local transaction completed May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:run_trans_callbacks: trans=0x7f6005838928, callback type 256, id 0 entered May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:cleanup_uac_timers: RETR/FR timers reset May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:insert_timer_unsafe: [2]: 0x7f60058389a8 (13415) May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_unref: UNREF_UNSAFE: [0x7f6005838928] after is 0 May 10 19:20:26 mtsbc opensips[7574]: DBG:core:destroy_avp_list: destroying list (nil) May 10 19:20:26 mtsbc opensips[7574]: DBG:core:receive_msg: cleaning up May 10 19:20:26 mtsbc opensips[7574]: DBG:proto_tls:tls_read_req: tls_read_req end May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:tls_read_req: Using the global ( per process ) buff May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:tls_update_fd: New fd is 5 May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:_tls_read: 503 bytes read May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:tcp_handle_req: content-length= 0 May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:tcp_handle_req: Nothing more to read on TCP conn 0x7f60058267d0, currently in state 0 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_msg: SIP Request: May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_msg: method: May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_msg: uri: May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_msg: version: May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7575]: DBG:core:_parse_to: end of header reached, state=10 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:_parse_to: display={}, ruri={sip:prober at localhost} May 10 19:20:26 mtsbc opensips[7575]: DBG:core:get_hdr_field: [24]; uri=[sip:prober at localhost] May 10 19:20:26 mtsbc opensips[7575]: DBG:core:get_hdr_field: to body [#015#012] May 10 19:20:26 mtsbc opensips[7575]: DBG:core:get_hdr_field: cseq : <1> May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_via_param: found param type 232, = ; state=16 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_via: end of header reached, state=5 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_headers: via found, flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_headers: this is the first via May 10 19:20:26 mtsbc opensips[7575]: DBG:core:get_hdr_field: content_length=0 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:get_hdr_field: found end of header May 10 19:20:26 mtsbc opensips[7575]: DBG:core:receive_msg: After parse_msg... May 10 19:20:26 mtsbc opensips[7575]: DBG:core:receive_msg: preparing to run routing scripts... May 10 19:20:26 mtsbc opensips[7575]: DBG:maxfwd:is_maxfwd_present: value = 70 May 10 19:20:26 mtsbc opensips[7575]: DBG:sipmsgops:has_totag: no totag May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_headers: flags=78 May 10 19:20:26 mtsbc opensips[7575]: DBG:tm:t_lookup_request: start searching: hash=62537, isACK=0 May 10 19:20:26 mtsbc opensips[7575]: DBG:tm:matching_3261: RFC3261 transaction matching failed May 10 19:20:26 mtsbc opensips[7575]: DBG:tm:t_lookup_request: no transaction found May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_to_param: tag=dd7d4e13-28ca-405e-9108-d83d4ea81f40 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:_parse_to: end of header reached, state=29 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:_parse_to: display={}, ruri={sip:sip-du-a-eu.pstnhub.microsoft.com:5061} May 10 19:20:26 mtsbc opensips[7575]: DBG:core:grep_sock_info_ext: checking if host==us: 33==14 && [sip-du-a-eu.pstnhub.microsoft.com] == [xxx.xxx.xxx.xxx] May 10 19:20:26 mtsbc opensips[7575]: DBG:core:grep_sock_info_ext: checking if host==us: 33==14 && [sip-du-a-eu.pstnhub.microsoft.com] == [xxx.xxx.xxx.xxx] May 10 19:20:26 mtsbc opensips[7575]: DBG:core:check_self: host != me May 10 19:20:26 mtsbc opensips[7575]: DBG:core:grep_sock_info_ext: checking if host==us: 16==14 && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] May 10 19:20:26 mtsbc opensips[7575]: DBG:core:grep_sock_info_ext: checking if host==us: 16==14 && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] May 10 19:20:26 mtsbc opensips[7575]: DBG:core:tcp_conn_get: con found in state 0 May 10 19:20:26 mtsbc opensips[7575]: DBG:tls_mgm:tls_is_peer_verified: corresponding TLS/TCP connection found. s=125, fd=5, id=926084752 May 10 19:20:26 mtsbc opensips[7575]: DBG:tls_mgm:tls_is_peer_verified: peer is successfully verified... done May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_headers: flags=200 May 10 19:20:26 mtsbc opensips[7575]: DBG:rr:find_first_route: No Route headers found May 10 19:20:26 mtsbc opensips[7575]: DBG:rr:loose_route: There is no Route HF May 10 19:20:26 mtsbc opensips[7575]: DBG:permissions:check_src_addr: Looking for : May 10 19:20:26 mtsbc opensips[7575]: DBG:permissions:hash_match: no match in the hash table May 10 19:20:26 mtsbc opensips[7575]: DBG:permissions:match_subnet_table: subnet table is empty May 10 19:20:26 mtsbc opensips[7575]: DBG:core:grep_sock_info_ext: checking if host==us: 16==14 && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] May 10 19:20:26 mtsbc opensips[7575]: DBG:core:grep_sock_info_ext: checking if host==us: 16==14 && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] May 10 19:20:26 mtsbc opensips[7575]: DBG:core:MD5StringArray: MD5 calculated: 8217c8258ec89ff4f5427ff311954104 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_headers: flags=ffffffffffffffff May 10 19:20:26 mtsbc opensips[7575]: DBG:core:tcp_conn_get: con found in state 0 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:tcp_conn_get: tcp connection found (0x7f60058267d0) already in this process ( 10 ) , fd = 5 May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:proto_tls_send: sending via fd 5... May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:tls_update_fd: New fd is 5 May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:tls_write: write was successful (380 bytes) May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:proto_tls_send: after write: c= 0x7f60058267d0 n=380 fd=5 May 10 19:20:26 mtsbc opensips[7575]: DBG:proto_tls:proto_tls_send: buf=#012SIP/2.0 484 Address Incomplete#015#012FROM: ;tag=dd7d4e13-28ca-405e-9108-d83d4ea81f40#015#012TO: ;tag=bd3a.8217c8258ec89ff4f5427ff311954104#015#012CSEQ: 1 OPTIONS#015#012CALL-ID: bf155f68-8a4c-4f18-b5f5-1340da0d618d#015#012VIA: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK9fe9fb55#015#012Server: OpenSIPS (3.1.1 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012 May 10 19:20:26 mtsbc opensips[7575]: DBG:core:destroy_avp_list: destroying list (nil) On Mon, 10 May 2021 11:45:32 -0300 Carlos Eduardo wrote: > Thank you Nick. > > I've read these docs lots of times and didn't pay > attention on it. > > > Em seg., 10 de mai. de 2021 às 11:44, Nick Altmann > > escreveu: > > > Yes. You can use avp for this. > > > https://opensips.org/docs/modules/3.1.x/tls_mgm.html#param_client_sip_domain_avp > > > > -- > > Nick > > > > пн, 10 мая 2021 г. в 16:09, Carlos Eduardo > : > > > >> Hey all, > >> > >> About using the right certificate, is it possible to > ensure opensips is > >> going to use the right one when multiple are set in > tls_mgm? > >> > >> Em seg., 10 de mai. de 2021 às 04:41, Răzvan Crainea > > >> escreveu: > >> > >>> Hi, Miha! > >>> > >>> According to your logs, opensips is 100% sending the > OPTIONS through > >>> tls, but I am not sure it is using the right > certificate. > >>> You can try to setup sip trace and see the > communication between > >>> opensips and MSTeams. > >>> > >>> Best regards, > >>> > >>> Răzvan Crainea > >>> OpenSIPS Core Developer > >>> http://www.opensips-solutions.com > >>> > >>> On 5/10/21 9:54 AM, Miha via Users wrote: > >>> > Hello > >>> > > >>> > I have used letsenrypt for generating certs for > Opensips. > >>> > > >>> > Regarding configuration i have fallowed your > configuration steps on > >>> > OpenSips blog. > >>> > > >>> > socket=udp:xxx.xxx.xxx.xxx:5060 # CUSTOMIZE ME > >>> > socket=tls:xxx.xxx.xxx.xxx:5061 > >>> > > >>> > > >>> > > >>> > > >>> > ### Proto TLS > >>> > loadmodule "proto_tls.so" > >>> > modparam("proto_tls", "tls_handshake_timeout", 300) > >>> > #### TLS module > >>> > loadmodule "tls_mgm.so" > >>> > #modparam("tls_mgm", "db_url", > "mysql://root:xxxx at localhost/opensips") > >>> > modparam("tls_mgm", "client_sip_domain_avp", > "mtsbcs.test.com") > >>> > modparam("tls_mgm", "server_domain", "mt") > >>> > #modparam("tls_mgm", "match_ip_address", > "[mt]xxx.xxx.xxx.xxx:5061") > >>> > #modparam("tls_mgm", "match_sip_domain", > "[mt]mtsbcs.test.com") > >>> > modparam("tls_mgm", "certificate", > >>> > > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/cert.pem") > >>> > modparam("tls_mgm", "private_key", > >>> > > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/privkey.pem") > >>> > modparam("tls_mgm", "ca_list", > >>> "[mt]/etc/ssl/certs/ca-certificates.crt") > >>> > modparam("tls_mgm", "ca_dir", > "[mt]/etc/ssl/certs/") > >>> > modparam("tls_mgm","verify_cert", "[mt]1") > >>> > modparam("tls_mgm","require_cert", "[mt]1") > >>> > modparam("tls_mgm","tls_method", "[mt]TLSv1_2") > >>> > modparam("proto_tls", "tls_max_msg_chunks", 8) > >>> > #modparam("tls_mgm", "tls_handshake_timeout", 300) > >>> > > >>> > if(is_method("OPTIONS") && > is_domain_local("$rd") && > >>> > check_source_address(0)) { > >>> > xlog("L_INFO", "[MS TEAMS] OPTIONS > In"); > >>> > send_reply(200, "OK"); > >>> > exit; > >>> > } > >>> > > >>> > > >>> > local_route { > >>> > $var(dst) = "pstnhub.microsoft.com"; > >>> > xlog("L_INFO","promding TEST"); > >>> > xlog("TESTING"); > >>> > if (is_method("OPTIONS") && ($(ru{s.index, > $var(dst)}) != NULL)) > >>> > append_hf("Contact: >>> ;transport=tls>\r\n"); > >>> > xlog("L_INFO", "SEDING OPTIONS TO SBC"); > >>> > } > >>> > > >>> > > >>> > I thnk that the main issue is that OPENSIPS does > not send encrypted > >>> > OPTION to MS teams. > >>> > > >>> > Logs: > >>> > > >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: > >>> > next_hop= > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:mk_proxy: doing DNS > >>> lookup... > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:sip_resolvehost: no > >>> port, > >>> > has proto -> do SRV lookup! > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:do_srv_lookup: > >>> resolving > >>> > [sip.pstnhub.microsoft.com] > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:do_srv_lookup: > >>> > SRV(_sips._tcp.sip.pstnhub.microsoft.com) = > >>> sip.pstnhub.microsoft.com:5061 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:a2dns_node: storing > >>> > sip2.pstnhub.microsoft.com:5061 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:a2dns_node: storing > >>> > sip3.pstnhub.microsoft.com:5061 > >>> > May 10 08:53:10 mtsbc opensips[1020]: DBG:tm:t_uac: > sending socket is > >>> > 212.13.249.132 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:tm:print_request_uri: > >>> > sip:sip.pstnhub.microsoft.com > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:tm:run_local_route: building > >>> > sip_msg from buffer > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_msg: SIP Request: > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_msg: method: > >>> > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_msg: uri: > >>> > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_msg: version: > >>> > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_headers: > >>> > flags=ffffffffffffffff > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_via_param: found > >>> > param type 232, = > ; state=16 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_via: end of > >>> header > >>> > reached, state=5 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_headers: via > >>> found, > >>> > flags=ffffffffffffffff > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_headers: this is > >>> > the first via > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:_parse_to: end of > >>> header > >>> > reached, state=9 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:_parse_to: display={}, > >>> > ruri={sip:sip.pstnhub.microsoft.com} > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:get_hdr_field: > >>> [31]; > >>> > uri=[sip:sip.pstnhub.microsoft.com] > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:get_hdr_field: to body > >>> > [sip:sip.pstnhub.microsoft.com#015#012 > >>> ] > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:get_hdr_field: cseq > >>> > : <14> > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:get_hdr_field: > >>> > content_length=0 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:get_hdr_field: found > >>> end > >>> > of header > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_headers: > >>> > flags=ffffffffffffffff > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_headers: flags=78 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_headers: > >>> > flags=ffffffffffffffff > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:tm:run_local_route: Change > >>> in > >>> > local route -> rebuilding buffer > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_headers: > >>> flags=2000 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:parse_headers: > >>> > flags=ffffffffffffffff > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:extract_ftc_hdrs: flags > >>> = 15 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:extract_ftc_hdrs: hdr 2 > >>> > extracted as sip:sip.pstnhub.microsoft.com#015#012 > >>> > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:extract_ftc_hdrs: hdr 1 > >>> > extracted as >>> > >>> >;tag=a665d66adab06c7308a33b8567de92d6-f627#015#012> > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:extract_ftc_hdrs: hdr 8 > >>> > extracted as 12e30be047c27077-1020 at 212.13.249.132#015#012 > >>> > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:proto_tls:proto_tls_send: no > >>> > open tcp connection found, opening new one > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:probe_max_sock_buff: > >>> > getsockopt: snd is initially 16384 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:probe_max_sock_buff: > >>> > using snd buffer of 416 kb > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:init_sock_keepalive: > >>> TCP > >>> > keepalive enabled on socket 5 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:print_ip: tcpconn_new: > >>> > new tcp connection to: 52.114.75.24 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:tcpconn_new: on port > >>> > 5061, proto 3 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:proto_tls:tls_conn_init: > >>> > Creating a whole new ssl connection > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:core:tcpconn_destroy: > >>> > destroying connection 0x7f45d7e08078, flags 0018 > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:tm:insert_timer_unsafe: [0]: > >>> > 0x7f45d7e066b0 (1625) > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:timer_routine: timer > >>> > routine:0,tl=0x7f45d7e066b0 next=(nil), > timeout=1625 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:final_response_handler: > >>> > Cancel sent out, sending 408 (0x7f45d7e06460) > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:t_should_relay_response: > >>> > T_code=0, new_code=408 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:t_pick_branch: picked > >>> > branch 0, code 408 (prio=800) > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:is_3263_failure: > >>> > dns-failover test: branch=0, last_recv=408, flags=0 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:t_should_relay_response: > >>> > trying DNS-based failover > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:do_dns_failover: new > >>> > destination available > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:parse_headers: > >>> flags=2000 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > >>> > DBG:core:build_req_buf_from_sip_req: id added: > <;i=0>, rcv proto=3 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:parse_headers: > >>> > flags=ffffffffffffffff > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:proto_tls:proto_tls_send: no > >>> > open tcp connection found, opening new one > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:probe_max_sock_buff: > >>> > getsockopt: snd is initially 16384 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:probe_max_sock_buff: > >>> > using snd buffer of 416 kb > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:init_sock_keepalive: > >>> TCP > >>> > keepalive enabled on socket 5 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:print_ip: tcpconn_new: > >>> > new tcp connection to: 52.114.132.46 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:tcpconn_new: on port > >>> > 5061, proto 3 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:proto_tls:tls_conn_init: > >>> > Creating a whole new ssl connection > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:tcpconn_destroy: > >>> > destroying connection 0x7f45d7e08078, flags 0018 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:proto_tls:proto_tls_send: no > >>> > open tcp connection found, opening new one > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:probe_max_sock_buff: > >>> > getsockopt: snd is initially 16384 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:probe_max_sock_buff: > >>> > using snd buffer of 416 kb > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:init_sock_keepalive: > >>> TCP > >>> > keepalive enabled on socket 5 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:print_ip: tcpconn_new: > >>> > new tcp connection to: 52.114.14.70 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:tcpconn_new: on port > >>> > 5061, proto 3 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:proto_tls:tls_conn_init: > >>> > Creating a whole new ssl connection > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:core:tcpconn_destroy: > >>> > destroying connection 0x7f45d7e08078, flags 0018 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:local_reply: branch=0, > >>> > save=0, winner=0 > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:local_reply: local > >>> > transaction completed > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:run_trans_callbacks: > >>> > trans=0x7f45d7e06460, callback type 256, id 0 > entered > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:insert_timer_unsafe: [2]: > >>> > 0x7f45d7e064e0 (1630) > >>> > May 10 08:53:15 mtsbc opensips[1020]: > DBG:tm:final_response_handler: > >>> done > >>> > > >>> > > >>> > > >>> > Thank you > >>> > miha > >>> > > >>> > > >>> > _______________________________________________ > >>> > Users mailing list > >>> > Users at lists.opensips.org > >>> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>> > > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users at lists.opensips.org > >>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >>> > >> > >> > >> -- > >> *Carlos E. Wagner* > >> *Tecnólogo em Telecomunicações, Opensips Certified > Professional* > >> > >> *Fone: +55 48 99981-0894* > >> *E-mail:* kaduww at gmail.com > >> *LinkedIn:* > https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ > >> _______________________________________________ > >> Users mailing list > >> Users at lists.opensips.org > >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > -- > *Carlos E. Wagner* > *Tecnólogo em Telecomunicações, Opensips Certified > Professional* > > *Fone: +55 48 99981-0894* > *E-mail:* kaduww at gmail.com > *LinkedIn:* > https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ From miha at softnet.si Mon May 10 19:29:50 2021 From: miha at softnet.si (Miha) Date: Mon, 10 May 2021 21:29:50 +0200 Subject: [OpenSIPS-Users] MS team issue In-Reply-To: References: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Message-ID: found an issue. It was missing ip in addresses. Is there any easier way to put all servers from Ms to addresses, maybe just domain with "*."? thank you On Mon, 10 May 2021 19:23:20 +0200 Miha via Users wrote: > Hello > > it seems for me that this works now. I only do not know > why > after 200 ok, opensips sends OPTIONS also to it self, > which > is quite wird. > > pasting logs. > > y 10 19:20:26 mtsbc opensips[7582]: > DBG:tm:print_request_uri: sip:sip.pstnhub.microsoft.com > May 10 19:20:26 mtsbc opensips[7582]: > DBG:tm:run_local_route: building sip_msg from buffer > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_msg: > SIP Request: > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_msg: > method: > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_msg: > uri: > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_msg: > version: > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_via_param: found param type 232, > = > ; state=16 > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:parse_via: > end of header reached, state=5 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: via found, flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: this is the first via > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:_parse_to: > end of header reached, state=9 > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:_parse_to: > display={}, ruri={sip:sip.pstnhub.microsoft.com} > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:get_hdr_field: [31]; > uri=[sip:sip.pstnhub.microsoft.com] > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:get_hdr_field: to body > [sip:sip.pstnhub.microsoft.com#015#012] > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:get_hdr_field: cseq : <14> > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:get_hdr_field: content_length=0 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:get_hdr_field: found end of header > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: flags=78 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_to_param: > tag=a665d66adab06c7308a33b8567de92d6-7c10 > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:_parse_to: > end of header reached, state=29 > May 10 19:20:26 mtsbc opensips[7582]: DBG:core:_parse_to: > display={}, ruri={sip:prober at localhost} > May 10 19:20:26 mtsbc opensips[7582]: > DBG:sipcapture:w_sip_capture: src_ip: [xxx.xxx.xxx.xxx] > May 10 19:20:26 mtsbc opensips[7582]: > DBG:sipcapture:w_sip_capture: dst_ip: [xxx.xxx.xxx.xxx] > May 10 19:20:26 mtsbc opensips[7582]: > DBG:sipcapture:w_sip_capture: dst_port: [5061] > May 10 19:20:26 mtsbc opensips[7582]: > DBG:sipcapture:w_sip_capture: src_port: [5061] > May 10 19:20:26 mtsbc opensips[7582]: > DBG:sipcapture:w_sip_capture: DONE > May 10 19:20:26 mtsbc opensips[7582]: > DBG:sipcapture:db_sync_store: storing info... > May 10 19:20:26 mtsbc opensips[7582]: > DBG:db_mysql:db_mysql_do_prepared_query: > conn=0x7f60225e6108 (tail=140050870197640) > MC=0x7f60225e6218 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:db_mysql:db_mysql_do_prepared_query: new > query=|insert > into sip_capture > (date,micro_ts,method,reply_reason,ruri,ruri_user,from_user,from_tag,to_user,to_tag,pid_user,contact_user,auth_user,callid,callid_aleg,via_1,via_1_branch,cseq,reason,content_type,auth,user_agent,source_ip,source_port,destination_ip,destination_port,contact_ip,contact_port,originator_ip,originator_port,proto,family,rtp_stat,type,node,correlation_id,from_domain,to_domain,ruri_domain,msg,custom_field1,custom_field2,custom_field3 > ) values > (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)| > May 10 19:20:26 mtsbc opensips[7582]: > DBG:db_mysql:re_init_statement: query is sip_capture > (date,micro_ts,method,reply_reason,ruri,ruri_user,from_user,from_tag,to_user,to_tag,pid_user,contact_user,auth_user,callid,callid_aleg,via_1,via_1_branch,cseq,reason,content_type,auth,user_agent,source_ip,source_port,destination_ip,destination_port,contact_ip,contact_port,originator_ip,originator_port,proto,family,rtp_stat,type,node,correlation_id,from_domain,to_domain,ruri_domain,msg,custom_field1,custom_field2,custom_field3 > ) values > (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)>, > ptr=(nil) > May 10 19:20:26 mtsbc opensips[7582]: > DBG:tm:run_local_route: Change in local route -> > rebuilding > buffer > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: flags=2000 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_headers: flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:extract_ftc_hdrs: flags = 15 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:extract_ftc_hdrs: hdr 2 extracted as sip:sip.pstnhub.microsoft.com#015#012> > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:extract_ftc_hdrs: hdr 1 extracted as ;tag=a665d66adab06c7308a33b8567de92d6-7c10#015#012> > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:extract_ftc_hdrs: hdr 8 extracted as 63f6e4340443163b-7582 at xxx.xxx.xxx.xxx#015#012> > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:tcp_conn_get: con found in state 0 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:tcp_conn_get: tcp connection found > (0x7f6005804fc8), acquiring fd > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:tcp_conn_get: c= 0x7f6005804fc8, n=16, Usock=123 > May 10 19:20:26 mtsbc opensips[7583]: > DBG:core:handle_worker: read response= 7f6005804fc8, 1, > fd > -1 from 17 (7582) > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:tcp_conn_get: after receive_fd: c= > 0x7f6005804fc8 > n=8 fd=5 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:proto_tls:proto_tls_send: sending via fd 5... > May 10 19:20:26 mtsbc opensips[7582]: > DBG:proto_tls:tls_update_fd: New fd is 5 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:proto_tls:tls_write: write was successful (423 bytes) > May 10 19:20:26 mtsbc opensips[7582]: > DBG:proto_tls:proto_tls_send: after write: c= > 0x7f6005804fc8 n=423 fd=5 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:proto_tls:proto_tls_send: buf=#012OPTIONS > sip:sip.pstnhub.microsoft.com SIP/2.0#015#012Via: > SIP/2.0/TLS > xxx.xxx.xxx.xxx:5061;branch=z9hG4bK2c5c.fa46c831.0#015#012To: > sip:sip.pstnhub.microsoft.com#015#012From: > ;tag=a665d66adab06c7308a33b8567de92d6-7c10#015#012CSeq: > 14 OPTIONS#015#012Call-ID: > 63f6e4340443163b-7582 at xxx.xxx.xxx.xxx#015#012Max-Forwards: > 70#015#012Content-Length: 0#015#012User-Agent: OpenSIPS > (3.1.1 (x86_64/linux))#015#012Contact: > #015#012#015#012 > May 10 19:20:26 mtsbc opensips[7582]: > DBG:tm:insert_timer_unsafe: [0]: 0x7f6005838b78 (13415) > May 10 19:20:26 mtsbc opensips[7574]: > DBG:proto_tls:tls_read_req: Using the global ( per > process > ) buff > May 10 19:20:26 mtsbc opensips[7574]: > DBG:proto_tls:tls_update_fd: New fd is 5 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:proto_tls:_tls_read: 383 bytes read > May 10 19:20:26 mtsbc opensips[7574]: > DBG:proto_tls:tcp_handle_req: content-length= 0 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:proto_tls:tcp_handle_req: Nothing more to read on TCP > conn 0x7f6005804fc8, currently in state 0 > May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_msg: > SIP Reply (status): > May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_msg: > version: > May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_msg: > status: <200> > May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_msg: > reason: > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_headers: flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7574]: DBG:core:_parse_to: > end of header reached, state=10 > May 10 19:20:26 mtsbc opensips[7574]: DBG:core:_parse_to: > display={}, ruri={sip:sip.pstnhub.microsoft.com} > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:get_hdr_field: [33]; > uri=[sip:sip.pstnhub.microsoft.com] > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:get_hdr_field: to body > [#015#012] > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:get_hdr_field: cseq : <14> > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_via_param: found param type 232, > = > ; state=16 > May 10 19:20:26 mtsbc opensips[7574]: DBG:core:parse_via: > end of header reached, state=5 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_headers: via found, flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_headers: this is the first via > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:get_hdr_field: content_length=0 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:get_hdr_field: found end of header > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:receive_msg: > After parse_msg... > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:forward_reply: found module tm, passing reply to > it > May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_check: > start=0xffffffffffffffff > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_headers: flags=22 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:t_reply_matching: hash 50626 label 327967919 > branch > 0 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:t_reply_matching: REF_UNSAFE:[0x7f6005838928] > after > is 1 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:t_reply_matching: reply matched > (T=0x7f6005838928)! > May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_check: > end=0x7f6005838928 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:reply_received: org. status uas=0, uac[0]=0 > local=2 > is_invite=0) > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:t_should_relay_response: T_code=0, new_code=200 > May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:local_reply: > branch=0, save=0, winner=0 > May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:local_reply: > local transaction completed > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:run_trans_callbacks: trans=0x7f6005838928, > callback > type 256, id 0 entered > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:cleanup_uac_timers: RETR/FR timers reset > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:insert_timer_unsafe: [2]: 0x7f60058389a8 (13415) > May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_unref: > UNREF_UNSAFE: [0x7f6005838928] after is 0 > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:destroy_avp_list: destroying list (nil) > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:receive_msg: > cleaning up > May 10 19:20:26 mtsbc opensips[7574]: > DBG:proto_tls:tls_read_req: tls_read_req end > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:tls_read_req: Using the global ( per > process > ) buff > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:tls_update_fd: New fd is 5 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:_tls_read: 503 bytes read > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:tcp_handle_req: content-length= 0 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:tcp_handle_req: Nothing more to read on TCP > conn 0x7f60058267d0, currently in state 0 > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_msg: > SIP Request: > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_msg: > method: > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_msg: > uri: > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_msg: > version: > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_headers: flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:_parse_to: > end of header reached, state=10 > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:_parse_to: > display={}, ruri={sip:prober at localhost} > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:get_hdr_field: [24]; > uri=[sip:prober at localhost] > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:get_hdr_field: to body > [#015#012] > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:get_hdr_field: cseq : <1> > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_via_param: found param type 232, > = > ; state=16 > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:parse_via: > end of header reached, state=5 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_headers: via found, flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_headers: this is the first via > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:get_hdr_field: content_length=0 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:get_hdr_field: found end of header > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:receive_msg: > After parse_msg... > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:receive_msg: > preparing to run routing scripts... > May 10 19:20:26 mtsbc opensips[7575]: > DBG:maxfwd:is_maxfwd_present: value = 70 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:sipmsgops:has_totag: no totag > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_headers: flags=78 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:tm:t_lookup_request: start searching: hash=62537, > isACK=0 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:tm:matching_3261: > RFC3261 transaction matching failed > May 10 19:20:26 mtsbc opensips[7575]: > DBG:tm:t_lookup_request: no transaction found > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_to_param: > tag=dd7d4e13-28ca-405e-9108-d83d4ea81f40 > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:_parse_to: > end of header reached, state=29 > May 10 19:20:26 mtsbc opensips[7575]: DBG:core:_parse_to: > display={}, > ruri={sip:sip-du-a-eu.pstnhub.microsoft.com:5061} > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:grep_sock_info_ext: checking if host==us: 33==14 > && [sip-du-a-eu.pstnhub.microsoft.com] == > [xxx.xxx.xxx.xxx] > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:grep_sock_info_ext: checking if host==us: 33==14 > && [sip-du-a-eu.pstnhub.microsoft.com] == > [xxx.xxx.xxx.xxx] > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:check_self: > host != me > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:grep_sock_info_ext: checking if host==us: 16==14 > && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:grep_sock_info_ext: checking if host==us: 16==14 > && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:tcp_conn_get: con found in state 0 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:tls_mgm:tls_is_peer_verified: corresponding TLS/TCP > connection found. s=125, fd=5, id=926084752 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:tls_mgm:tls_is_peer_verified: peer is successfully > verified... done > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_headers: flags=200 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:rr:find_first_route: No Route headers found > May 10 19:20:26 mtsbc opensips[7575]: DBG:rr:loose_route: > There is no Route HF > May 10 19:20:26 mtsbc opensips[7575]: > DBG:permissions:check_src_addr: Looking for : 52.114.75.24, 3, 13248, > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:permissions:hash_match: no match in the hash table > May 10 19:20:26 mtsbc opensips[7575]: > DBG:permissions:match_subnet_table: subnet table is empty > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:grep_sock_info_ext: checking if host==us: 16==14 > && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:grep_sock_info_ext: checking if host==us: 16==14 > && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:MD5StringArray: MD5 calculated: > 8217c8258ec89ff4f5427ff311954104 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_headers: flags=ffffffffffffffff > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:tcp_conn_get: con found in state 0 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:tcp_conn_get: tcp connection found > (0x7f60058267d0) already in this process ( 10 ) , fd = 5 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:proto_tls_send: sending via fd 5... > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:tls_update_fd: New fd is 5 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:tls_write: write was successful (380 bytes) > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:proto_tls_send: after write: c= > 0x7f60058267d0 n=380 fd=5 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:proto_tls:proto_tls_send: buf=#012SIP/2.0 484 Address > Incomplete#015#012FROM: > ;tag=dd7d4e13-28ca-405e-9108-d83d4ea81f40#015#012TO: > ;tag=bd3a.8217c8258ec89ff4f5427ff311954104#015#012CSEQ: > 1 OPTIONS#015#012CALL-ID: > bf155f68-8a4c-4f18-b5f5-1340da0d618d#015#012VIA: > SIP/2.0/TLS > 52.114.75.24:5061;branch=z9hG4bK9fe9fb55#015#012Server: > OpenSIPS (3.1.1 (x86_64/linux))#015#012Content-Length: > 0#015#012#015#012 > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:destroy_avp_list: destroying list (nil) > > > On Mon, 10 May 2021 11:45:32 -0300 > Carlos Eduardo wrote: > > Thank you Nick. > > > > I've read these docs lots of times and didn't pay > > attention on it. > > > > > > Em seg., 10 de mai. de 2021 às 11:44, Nick Altmann > > > > escreveu: > > > > > Yes. You can use avp for this. > > > > > > https://opensips.org/docs/modules/3.1.x/tls_mgm.html#param_client_sip_domain_avp > > > > > > -- > > > Nick > > > > > > пн, 10 мая 2021 г. в 16:09, Carlos Eduardo > > : > > > > > >> Hey all, > > >> > > >> About using the right certificate, is it possible to > > ensure opensips is > > >> going to use the right one when multiple are set in > > tls_mgm? > > >> > > >> Em seg., 10 de mai. de 2021 às 04:41, Răzvan Crainea > > > > >> escreveu: > > >> > > >>> Hi, Miha! > > >>> > > >>> According to your logs, opensips is 100% sending > the > > OPTIONS through > > >>> tls, but I am not sure it is using the right > > certificate. > > >>> You can try to setup sip trace and see the > > communication between > > >>> opensips and MSTeams. > > >>> > > >>> Best regards, > > >>> > > >>> Răzvan Crainea > > >>> OpenSIPS Core Developer > > >>> http://www.opensips-solutions.com > > >>> > > >>> On 5/10/21 9:54 AM, Miha via Users wrote: > > >>> > Hello > > >>> > > > >>> > I have used letsenrypt for generating certs for > > Opensips. > > >>> > > > >>> > Regarding configuration i have fallowed your > > configuration steps on > > >>> > OpenSips blog. > > >>> > > > >>> > socket=udp:xxx.xxx.xxx.xxx:5060 # CUSTOMIZE ME > > >>> > socket=tls:xxx.xxx.xxx.xxx:5061 > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > ### Proto TLS > > >>> > loadmodule "proto_tls.so" > > >>> > modparam("proto_tls", "tls_handshake_timeout", > 300) > > >>> > #### TLS module > > >>> > loadmodule "tls_mgm.so" > > >>> > #modparam("tls_mgm", "db_url", > > "mysql://root:xxxx at localhost/opensips") > > >>> > modparam("tls_mgm", "client_sip_domain_avp", > > "mtsbcs.test.com") > > >>> > modparam("tls_mgm", "server_domain", "mt") > > >>> > #modparam("tls_mgm", "match_ip_address", > > "[mt]xxx.xxx.xxx.xxx:5061") > > >>> > #modparam("tls_mgm", "match_sip_domain", > > "[mt]mtsbcs.test.com") > > >>> > modparam("tls_mgm", "certificate", > > >>> > > > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/cert.pem") > > >>> > modparam("tls_mgm", "private_key", > > >>> > > > > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/privkey.pem") > > >>> > modparam("tls_mgm", "ca_list", > > >>> "[mt]/etc/ssl/certs/ca-certificates.crt") > > >>> > modparam("tls_mgm", "ca_dir", > > "[mt]/etc/ssl/certs/") > > >>> > modparam("tls_mgm","verify_cert", "[mt]1") > > >>> > modparam("tls_mgm","require_cert", "[mt]1") > > >>> > modparam("tls_mgm","tls_method", "[mt]TLSv1_2") > > >>> > modparam("proto_tls", "tls_max_msg_chunks", 8) > > >>> > #modparam("tls_mgm", "tls_handshake_timeout", > 300) > > >>> > > > >>> > if(is_method("OPTIONS") && > > is_domain_local("$rd") && > > >>> > check_source_address(0)) { > > >>> > xlog("L_INFO", "[MS TEAMS] > OPTIONS > > In"); > > >>> > send_reply(200, "OK"); > > >>> > exit; > > >>> > } > > >>> > > > >>> > > > >>> > local_route { > > >>> > $var(dst) = "pstnhub.microsoft.com"; > > >>> > xlog("L_INFO","promding TEST"); > > >>> > xlog("TESTING"); > > >>> > if (is_method("OPTIONS") && ($(ru{s.index, > > $var(dst)}) != NULL)) > > >>> > append_hf("Contact: > > >>> ;transport=tls>\r\n"); > > >>> > xlog("L_INFO", "SEDING OPTIONS TO SBC"); > > >>> > } > > >>> > > > >>> > > > >>> > I thnk that the main issue is that OPENSIPS does > > not send encrypted > > >>> > OPTION to MS teams. > > >>> > > > >>> > Logs: > > >>> > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:tm:t_uac: > > >>> > next_hop= > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:mk_proxy: doing DNS > > >>> lookup... > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:sip_resolvehost: no > > >>> port, > > >>> > has proto -> do SRV lookup! > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:do_srv_lookup: > > >>> resolving > > >>> > [sip.pstnhub.microsoft.com] > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:do_srv_lookup: > > >>> > SRV(_sips._tcp.sip.pstnhub.microsoft.com) = > > >>> sip.pstnhub.microsoft.com:5061 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:a2dns_node: storing > > >>> > sip2.pstnhub.microsoft.com:5061 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:a2dns_node: storing > > >>> > sip3.pstnhub.microsoft.com:5061 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > DBG:tm:t_uac: > > sending socket is > > >>> > 212.13.249.132 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:tm:print_request_uri: > > >>> > sip:sip.pstnhub.microsoft.com > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:tm:run_local_route: building > > >>> > sip_msg from buffer > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_msg: SIP Request: > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_msg: method: > > >>> > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_msg: uri: > > >>> > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_msg: version: > > >>> > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_headers: > > >>> > flags=ffffffffffffffff > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_via_param: found > > >>> > param type 232, = > > ; state=16 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_via: end of > > >>> header > > >>> > reached, state=5 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_headers: via > > >>> found, > > >>> > flags=ffffffffffffffff > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_headers: this is > > >>> > the first via > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:_parse_to: end of > > >>> header > > >>> > reached, state=9 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:_parse_to: display={}, > > >>> > ruri={sip:sip.pstnhub.microsoft.com} > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:get_hdr_field: > > >>> [31]; > > >>> > uri=[sip:sip.pstnhub.microsoft.com] > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:get_hdr_field: to body > > >>> > [sip:sip.pstnhub.microsoft.com#015#012 > > >>> ] > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:get_hdr_field: cseq > > >>> > : <14> > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:get_hdr_field: > > >>> > content_length=0 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:get_hdr_field: found > > >>> end > > >>> > of header > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_headers: > > >>> > flags=ffffffffffffffff > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_headers: flags=78 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_headers: > > >>> > flags=ffffffffffffffff > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:tm:run_local_route: Change > > >>> in > > >>> > local route -> rebuilding buffer > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_headers: > > >>> flags=2000 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:parse_headers: > > >>> > flags=ffffffffffffffff > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:extract_ftc_hdrs: flags > > >>> = 15 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:extract_ftc_hdrs: hdr 2 > > >>> > extracted as > sip:sip.pstnhub.microsoft.com#015#012 > > >>> > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:extract_ftc_hdrs: hdr 1 > > >>> > extracted as > >>> > > >>> > >;tag=a665d66adab06c7308a33b8567de92d6-f627#015#012> > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:extract_ftc_hdrs: hdr 8 > > >>> > extracted as > 12e30be047c27077-1020 at 212.13.249.132#015#012 > > >>> > > > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:proto_tls:proto_tls_send: no > > >>> > open tcp connection found, opening new one > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:probe_max_sock_buff: > > >>> > getsockopt: snd is initially 16384 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:probe_max_sock_buff: > > >>> > using snd buffer of 416 kb > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:init_sock_keepalive: > > >>> TCP > > >>> > keepalive enabled on socket 5 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:print_ip: tcpconn_new: > > >>> > new tcp connection to: 52.114.75.24 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:tcpconn_new: on port > > >>> > 5061, proto 3 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:proto_tls:tls_conn_init: > > >>> > Creating a whole new ssl connection > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:core:tcpconn_destroy: > > >>> > destroying connection 0x7f45d7e08078, flags 0018 > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > DBG:tm:insert_timer_unsafe: [0]: > > >>> > 0x7f45d7e066b0 (1625) > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:timer_routine: timer > > >>> > routine:0,tl=0x7f45d7e066b0 next=(nil), > > timeout=1625 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:final_response_handler: > > >>> > Cancel sent out, sending 408 (0x7f45d7e06460) > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:t_should_relay_response: > > >>> > T_code=0, new_code=408 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:t_pick_branch: picked > > >>> > branch 0, code 408 (prio=800) > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:is_3263_failure: > > >>> > dns-failover test: branch=0, last_recv=408, > flags=0 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:t_should_relay_response: > > >>> > trying DNS-based failover > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:do_dns_failover: new > > >>> > destination available > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:parse_headers: > > >>> flags=2000 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > >>> > DBG:core:build_req_buf_from_sip_req: id added: > > <;i=0>, rcv proto=3 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:parse_headers: > > >>> > flags=ffffffffffffffff > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:proto_tls:proto_tls_send: no > > >>> > open tcp connection found, opening new one > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:probe_max_sock_buff: > > >>> > getsockopt: snd is initially 16384 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:probe_max_sock_buff: > > >>> > using snd buffer of 416 kb > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:init_sock_keepalive: > > >>> TCP > > >>> > keepalive enabled on socket 5 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:print_ip: tcpconn_new: > > >>> > new tcp connection to: 52.114.132.46 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:tcpconn_new: on port > > >>> > 5061, proto 3 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:proto_tls:tls_conn_init: > > >>> > Creating a whole new ssl connection > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:tcpconn_destroy: > > >>> > destroying connection 0x7f45d7e08078, flags 0018 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:proto_tls:proto_tls_send: no > > >>> > open tcp connection found, opening new one > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:probe_max_sock_buff: > > >>> > getsockopt: snd is initially 16384 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:probe_max_sock_buff: > > >>> > using snd buffer of 416 kb > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:init_sock_keepalive: > > >>> TCP > > >>> > keepalive enabled on socket 5 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:print_ip: tcpconn_new: > > >>> > new tcp connection to: 52.114.14.70 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:tcpconn_new: on port > > >>> > 5061, proto 3 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:proto_tls:tls_conn_init: > > >>> > Creating a whole new ssl connection > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:core:tcpconn_destroy: > > >>> > destroying connection 0x7f45d7e08078, flags 0018 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:local_reply: branch=0, > > >>> > save=0, winner=0 > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:local_reply: local > > >>> > transaction completed > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:run_trans_callbacks: > > >>> > trans=0x7f45d7e06460, callback type 256, id 0 > > entered > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:insert_timer_unsafe: [2]: > > >>> > 0x7f45d7e064e0 (1630) > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > DBG:tm:final_response_handler: > > >>> done > > >>> > > > >>> > > > >>> > > > >>> > Thank you > > >>> > miha > > >>> > > > >>> > > > >>> > _______________________________________________ > > >>> > Users mailing list > > >>> > Users at lists.opensips.org > > >>> > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >>> > > > >>> > > >>> _______________________________________________ > > >>> Users mailing list > > >>> Users at lists.opensips.org > > >>> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >>> > > >> > > >> > > >> -- > > >> *Carlos E. Wagner* > > >> *Tecnólogo em Telecomunicações, Opensips Certified > > Professional* > > >> > > >> *Fone: +55 48 99981-0894* > > >> *E-mail:* kaduww at gmail.com > > >> *LinkedIn:* > > > https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ > > >> _______________________________________________ > > >> Users mailing list > > >> Users at lists.opensips.org > > >> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > >> > > > _______________________________________________ > > > Users mailing list > > > Users at lists.opensips.org > > > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > -- > > *Carlos E. Wagner* > > *Tecnólogo em Telecomunicações, Opensips Certified > > Professional* > > > > *Fone: +55 48 99981-0894* > > *E-mail:* kaduww at gmail.com > > *LinkedIn:* > > > https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From aronp at guaranteedplus.com Mon May 10 20:26:31 2021 From: aronp at guaranteedplus.com (Podrigal, Aron) Date: Mon, 10 May 2021 15:26:31 -0500 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> <349cfaa9-d216-9a9a-6232-8a871d113526@opensips.org> <89c333792f949f604e29c9f897150df52a6be71d.camel@dns99.co.uk> Message-ID: Hi Liviu, I have had the same issue for a long time. I opened a github issue/request for this [1]. Using integer columns has benefit for me since I am using extra fields for stats and I am doing arithmetic on them. Casting those text columns to integers is not efficient. With the empty strings it creates even a bigger issue, that I cannot cast them at all and end up with inefficient CASE WHEN field = '' THEN NULL ELSE field::int END. Also, I use other datatypes in postgres like inet for source / dest ip and empty strings are invalid for those datatypes. [1] https://github.com/OpenSIPS/opensips/issues/2205 On Mon, May 10, 2021 at 11:25 AM Liviu Chircu wrote: > On 10.05.2021 19:19, Kingsley Tart wrote: > > I could do, but I was hoping to avoid that as it feels like bad > > practice and it's inefficient - more of a workaround than a proper fix. > > Speaking for myself, I don't think I've ever seen a non-VARCHAR custom > accounting column with the "acc" module. Also, if you think about it, > writing the 1 integer value requires only 25% of the space if you're > writing "1" instead of 1. So, YMMV with regards to efficiency, we're > talking bits and pieces of data here, as the fields themselves are not > that large, it's their sheer number required in the CDRs that's often > problematic. > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > OpenSIPS eBootcamp 2021 | www.opensips.org/training > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- - Aron Podrigal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ugnd.org Mon May 10 21:05:28 2021 From: jeff at ugnd.org (Jeff Pyle) Date: Mon, 10 May 2021 17:05:28 -0400 Subject: [OpenSIPS-Users] Tips for troubleshooting OpenSIPS as a Teams SBC In-Reply-To: <000d01d72ac9$33528c80$99f7a580$@smartvox.co.uk> References: <000d01d72ac9$33528c80$99f7a580$@smartvox.co.uk> Message-ID: John, This is great, especially along side Alexey's blog post. I'm having a problem related to multi-tenant configuration. I suspect it's the result of something basic I've overlooked since I don't see it covered in your article. An ancillary issue that I have is where I must use the FQDN *and* the IP in the added Record-Route header even though it's the same interface in both cases, and the domain resolves to the IP of the local interface. Something goes awry in the call setup, I believe something with replies. I haven't isolated it specifically yet. Calls do set up properly if I use something like record_route_preset( “SBC_FQDN:5061;transport=tls”, “SBC_IP:5061; transport=tls”); however. The more significant issue is related to alias= definitions and customer tenant domains. I've been testing by with aliases defined for my carrier tenant and a single customer tenant domain. So far there's been a reasonable amount of success. The problem occurs when I send a call to Teams on a customer domain I don't have an alias defined for, using that domain in the Record-Route header as is required. Sequential requests' routing fails when OpenSIPS tries to route the call to the domain, which is really to itself but OpenSIPS doesn't realize it's local, and then...badness. Am I missing a way to define a wildcard alias of sorts? I was hoping the dns=yes option would resolve those domains in real time and match the defined IP, but that didn't seem to work either. I feel like I'm missing something simple. Regards, Jeff On Tue, Apr 6, 2021 at 5:44 AM John Quick wrote: > Hello all, > The article I published last week talks about common issues you might > encounter when commissioning a Microsoft Teams SBC solution built using > OpenSIPS. > It is designed to be read alongside the article by Alexey Vasilyev. > > https://kb.smartvox.co.uk/opensips/opensips-as-ms-teams-sbc/ > > John Quick > Smartvox Limited > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Tue May 11 07:50:38 2021 From: miha at softnet.si (Miha) Date: Tue, 11 May 2021 09:50:38 +0200 Subject: [OpenSIPS-Users] MS team issue In-Reply-To: References: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Message-ID: hello i tried to put this in address table: "*.pstnhub.microsoft.com" but it does not work. On Tue, 11 May 2021 09:13:37 +0200 Johan De Clercq wrote: > the pstnhub's can change their ip address. > Therefore you need to use the fqdn. > > Op ma 10 mei 2021 om 21:33 schreef Miha via Users > >: > > > found an issue. It was missing ip in addresses. Is > there > > any easier way to put all servers from Ms to addresses, > > maybe just domain with "*."? > > > > > > thank you > > > > > > On Mon, 10 May 2021 19:23:20 +0200 > > Miha via Users wrote: > > > Hello > > > > > > it seems for me that this works now. I only do not > know > > > why > > > after 200 ok, opensips sends OPTIONS also to it self, > > > which > > > is quite wird. > > > > > > pasting logs. > > > > > > y 10 19:20:26 mtsbc opensips[7582]: > > > DBG:tm:print_request_uri: > sip:sip.pstnhub.microsoft.com > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:tm:run_local_route: building sip_msg from buffer > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_msg: > > > SIP Request: > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_msg: > > > method: > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_msg: > > > uri: > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_msg: > > > version: > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_via_param: found param type 232, > > > > = > > > ; state=16 > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:parse_via: > > > end of header reached, state=5 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: via found, > flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: this is the first via > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:_parse_to: > > > end of header reached, state=9 > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:_parse_to: > > > display={}, ruri={sip:sip.pstnhub.microsoft.com} > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:get_hdr_field: [31]; > > > uri=[sip:sip.pstnhub.microsoft.com] > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:get_hdr_field: to body > > > [sip:sip.pstnhub.microsoft.com#015#012 > > ] > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:get_hdr_field: cseq : <14> > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:get_hdr_field: content_length=0 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:get_hdr_field: found end of header > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: flags=78 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_to_param: > > > tag=a665d66adab06c7308a33b8567de92d6-7c10 > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:_parse_to: > > > end of header reached, state=29 > > > May 10 19:20:26 mtsbc opensips[7582]: > DBG:core:_parse_to: > > > display={}, ruri={sip:prober at localhost} > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:sipcapture:w_sip_capture: src_ip: > [xxx.xxx.xxx.xxx] > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:sipcapture:w_sip_capture: dst_ip: > [xxx.xxx.xxx.xxx] > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:sipcapture:w_sip_capture: dst_port: [5061] > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:sipcapture:w_sip_capture: src_port: [5061] > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:sipcapture:w_sip_capture: DONE > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:sipcapture:db_sync_store: storing info... > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:db_mysql:db_mysql_do_prepared_query: > > > conn=0x7f60225e6108 (tail=140050870197640) > > > MC=0x7f60225e6218 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:db_mysql:db_mysql_do_prepared_query: new > > > query=|insert > > > into sip_capture > > > > > > > > (date,micro_ts,method,reply_reason,ruri,ruri_user,from_user,from_tag,to_user,to_tag,pid_user,contact_user,auth_user,callid,callid_aleg,via_1,via_1_branch,cseq,reason,content_type,auth,user_agent,source_ip,source_port,destination_ip,destination_port,contact_ip,contact_port,originator_ip,originator_port,proto,family,rtp_stat,type,node,correlation_id,from_domain,to_domain,ruri_domain,msg,custom_field1,custom_field2,custom_field3 > > > ) values > > > > > > > > (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)| > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:db_mysql:re_init_statement: query is into > > > sip_capture > > > > > > > > (date,micro_ts,method,reply_reason,ruri,ruri_user,from_user,from_tag,to_user,to_tag,pid_user,contact_user,auth_user,callid,callid_aleg,via_1,via_1_branch,cseq,reason,content_type,auth,user_agent,source_ip,source_port,destination_ip,destination_port,contact_ip,contact_port,originator_ip,originator_port,proto,family,rtp_stat,type,node,correlation_id,from_domain,to_domain,ruri_domain,msg,custom_field1,custom_field2,custom_field3 > > > ) values > > > > > > > > (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)>, > > > ptr=(nil) > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:tm:run_local_route: Change in local route -> > > > rebuilding > > > buffer > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: flags=2000 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:parse_headers: flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:extract_ftc_hdrs: flags = 15 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:extract_ftc_hdrs: hdr 2 extracted as > > sip:sip.pstnhub.microsoft.com#015#012 > > > > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:extract_ftc_hdrs: hdr 1 extracted as > > > > > ;tag=a665d66adab06c7308a33b8567de92d6-7c10#015#012> > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:extract_ftc_hdrs: hdr 8 extracted as > > > 63f6e4340443163b-7582 at xxx.xxx.xxx.xxx#015#012> > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:tcp_conn_get: con found in state 0 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:tcp_conn_get: tcp connection found > > > (0x7f6005804fc8), acquiring fd > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:tcp_conn_get: c= 0x7f6005804fc8, n=16, > Usock=123 > > > May 10 19:20:26 mtsbc opensips[7583]: > > > DBG:core:handle_worker: read response= 7f6005804fc8, > 1, > > > fd > > > -1 from 17 (7582) > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:core:tcp_conn_get: after receive_fd: c= > > > 0x7f6005804fc8 > > > n=8 fd=5 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:proto_tls:proto_tls_send: sending via fd 5... > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:proto_tls:tls_update_fd: New fd is 5 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:proto_tls:tls_write: write was successful (423 > bytes) > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:proto_tls:proto_tls_send: after write: c= > > > 0x7f6005804fc8 n=423 fd=5 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:proto_tls:proto_tls_send: buf=#012OPTIONS > > > sip:sip.pstnhub.microsoft.com SIP/2.0#015#012Via: > > > SIP/2.0/TLS > > > > > > xxx.xxx.xxx.xxx:5061;branch=z9hG4bK2c5c.fa46c831.0#015#012To: > > > sip:sip.pstnhub.microsoft.com#015#012From > > : > > > > > > > >;tag=a665d66adab06c7308a33b8567de92d6-7c10#015#012CSeq: > > > 14 OPTIONS#015#012Call-ID: > > > > > > 63f6e4340443163b-7582 at xxx.xxx.xxx.xxx#015#012Max-Forwards: > > > 70#015#012Content-Length: 0#015#012User-Agent: > OpenSIPS > > > (3.1.1 (x86_64/linux))#015#012Contact: > > > > #015#012#015#012 > > > May 10 19:20:26 mtsbc opensips[7582]: > > > DBG:tm:insert_timer_unsafe: [0]: 0x7f6005838b78 > (13415) > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:proto_tls:tls_read_req: Using the global ( per > > > process > > > ) buff > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:proto_tls:tls_update_fd: New fd is 5 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:proto_tls:_tls_read: 383 bytes read > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:proto_tls:tcp_handle_req: content-length= 0 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:proto_tls:tcp_handle_req: Nothing more to read on > TCP > > > conn 0x7f6005804fc8, currently in state 0 > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_msg: > > > SIP Reply (status): > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_msg: > > > version: > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_msg: > > > status: <200> > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_msg: > > > reason: > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:parse_headers: flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:_parse_to: > > > end of header reached, state=10 > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:_parse_to: > > > display={}, ruri={sip:sip.pstnhub.microsoft.com} > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:get_hdr_field: [33]; > > > uri=[sip:sip.pstnhub.microsoft.com] > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:get_hdr_field: to body > > > [#015#012] > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:get_hdr_field: cseq : <14> > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:parse_via_param: found param type 232, > > > > = > > > ; state=16 > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:core:parse_via: > > > end of header reached, state=5 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:parse_headers: via found, > flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:parse_headers: this is the first via > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:get_hdr_field: content_length=0 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:get_hdr_field: found end of header > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:receive_msg: > > > After parse_msg... > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:forward_reply: found module tm, passing > reply to > > > it > > > May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_check: > > > start=0xffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:parse_headers: flags=22 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:tm:t_reply_matching: hash 50626 label 327967919 > > > branch > > > 0 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:tm:t_reply_matching: REF_UNSAFE:[0x7f6005838928] > > > after > > > is 1 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:tm:t_reply_matching: reply matched > > > (T=0x7f6005838928)! > > > May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_check: > > > end=0x7f6005838928 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:tm:reply_received: org. status uas=0, uac[0]=0 > > > local=2 > > > is_invite=0) > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:tm:t_should_relay_response: T_code=0, > new_code=200 > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:local_reply: > > > branch=0, save=0, winner=0 > > > May 10 19:20:26 mtsbc opensips[7574]: > DBG:tm:local_reply: > > > local transaction completed > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:tm:run_trans_callbacks: trans=0x7f6005838928, > > > callback > > > type 256, id 0 entered > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:tm:cleanup_uac_timers: RETR/FR timers reset > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:tm:insert_timer_unsafe: [2]: 0x7f60058389a8 > (13415) > > > May 10 19:20:26 mtsbc opensips[7574]: DBG:tm:t_unref: > > > UNREF_UNSAFE: [0x7f6005838928] after is 0 > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:destroy_avp_list: destroying list (nil) > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:core:receive_msg: > > > cleaning up > > > May 10 19:20:26 mtsbc opensips[7574]: > > > DBG:proto_tls:tls_read_req: tls_read_req end > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:tls_read_req: Using the global ( per > > > process > > > ) buff > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:tls_update_fd: New fd is 5 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:_tls_read: 503 bytes read > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:tcp_handle_req: content-length= 0 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:tcp_handle_req: Nothing more to read on > TCP > > > conn 0x7f60058267d0, currently in state 0 > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_msg: > > > SIP Request: > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_msg: > > > method: > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_msg: > > > uri: > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_msg: > > > version: > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:parse_headers: flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:_parse_to: > > > end of header reached, state=10 > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:_parse_to: > > > display={}, ruri={sip:prober at localhost} > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:get_hdr_field: [24]; > > > uri=[sip:prober at localhost] > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:get_hdr_field: to body > > > [#015#012] > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:get_hdr_field: cseq : <1> > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:parse_via_param: found param type 232, > > > > = > > > ; state=16 > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:parse_via: > > > end of header reached, state=5 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:parse_headers: via found, > flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:parse_headers: this is the first via > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:get_hdr_field: content_length=0 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:get_hdr_field: found end of header > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:receive_msg: > > > After parse_msg... > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:receive_msg: > > > preparing to run routing scripts... > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:maxfwd:is_maxfwd_present: value = 70 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:sipmsgops:has_totag: no totag > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:parse_headers: flags=78 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:tm:t_lookup_request: start searching: hash=62537, > > > isACK=0 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:tm:matching_3261: > > > RFC3261 transaction matching failed > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:tm:t_lookup_request: no transaction found > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:parse_to_param: > > > tag=dd7d4e13-28ca-405e-9108-d83d4ea81f40 > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:_parse_to: > > > end of header reached, state=29 > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:core:_parse_to: > > > display={}, > > > ruri={sip:sip-du-a-eu.pstnhub.microsoft.com:5061} > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:grep_sock_info_ext: checking if host==us: > 33==14 > > > && [sip-du-a-eu.pstnhub.microsoft.com] == > > > [xxx.xxx.xxx.xxx] > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:grep_sock_info_ext: checking if host==us: > 33==14 > > > && [sip-du-a-eu.pstnhub.microsoft.com] == > > > [xxx.xxx.xxx.xxx] > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:check_self: > > > host != me > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:grep_sock_info_ext: checking if host==us: > 16==14 > > > && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:grep_sock_info_ext: checking if host==us: > 16==14 > > > && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:tcp_conn_get: con found in state 0 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:tls_mgm:tls_is_peer_verified: corresponding > TLS/TCP > > > connection found. s=125, fd=5, id=926084752 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:tls_mgm:tls_is_peer_verified: peer is > successfully > > > verified... done > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:parse_headers: flags=200 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:rr:find_first_route: No Route headers found > > > May 10 19:20:26 mtsbc opensips[7575]: > DBG:rr:loose_route: > > > There is no Route HF > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:permissions:check_src_addr: Looking for : > > > 52.114.75.24, 3, 13248, > > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:permissions:hash_match: no match in the hash > table > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:permissions:match_subnet_table: subnet table is > empty > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:grep_sock_info_ext: checking if host==us: > 16==14 > > > && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:grep_sock_info_ext: checking if host==us: > 16==14 > > > && [mtsbc.test.com] == [xxx.xxx.xxx.xxx] > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:MD5StringArray: MD5 calculated: > > > 8217c8258ec89ff4f5427ff311954104 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:parse_headers: flags=ffffffffffffffff > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:tcp_conn_get: con found in state 0 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:tcp_conn_get: tcp connection found > > > (0x7f60058267d0) already in this process ( 10 ) , fd > = 5 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:proto_tls_send: sending via fd 5... > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:tls_update_fd: New fd is 5 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:tls_write: write was successful (380 > bytes) > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:proto_tls_send: after write: c= > > > 0x7f60058267d0 n=380 fd=5 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:proto_tls:proto_tls_send: buf=#012SIP/2.0 484 > Address > > > Incomplete#015#012FROM: > > > > > > >;tag=dd7d4e13-28ca-405e-9108-d83d4ea81f40#015#012TO: > > > > > > > >;tag=bd3a.8217c8258ec89ff4f5427ff311954104#015#012CSEQ: > > > 1 OPTIONS#015#012CALL-ID: > > > bf155f68-8a4c-4f18-b5f5-1340da0d618d#015#012VIA: > > > SIP/2.0/TLS > > > > 52.114.75.24:5061;branch=z9hG4bK9fe9fb55#015#012Server: > > > OpenSIPS (3.1.1 > (x86_64/linux))#015#012Content-Length: > > > 0#015#012#015#012 > > > May 10 19:20:26 mtsbc opensips[7575]: > > > DBG:core:destroy_avp_list: destroying list (nil) > > > > > > > > > On Mon, 10 May 2021 11:45:32 -0300 > > > Carlos Eduardo wrote: > > > > Thank you Nick. > > > > > > > > I've read these docs lots of times and didn't pay > > > > attention on it. > > > > > > > > > > > > Em seg., 10 de mai. de 2021 às 11:44, Nick Altmann > > > > > > > > escreveu: > > > > > > > > > Yes. You can use avp for this. > > > > > > > > > > > > > > > > > https://opensips.org/docs/modules/3.1.x/tls_mgm.html#param_client_sip_domain_avp > > > > > > > > > > -- > > > > > Nick > > > > > > > > > > пн, 10 мая 2021 г. в 16:09, Carlos Eduardo > > > > : > > > > > > > > > >> Hey all, > > > > >> > > > > >> About using the right certificate, is it > possible to > > > > ensure opensips is > > > > >> going to use the right one when multiple are set > in > > > > tls_mgm? > > > > >> > > > > >> Em seg., 10 de mai. de 2021 às 04:41, Răzvan > Crainea > > > > > > > > >> escreveu: > > > > >> > > > > >>> Hi, Miha! > > > > >>> > > > > >>> According to your logs, opensips is 100% > sending > > > the > > > > OPTIONS through > > > > >>> tls, but I am not sure it is using the right > > > > certificate. > > > > >>> You can try to setup sip trace and see the > > > > communication between > > > > >>> opensips and MSTeams. > > > > >>> > > > > >>> Best regards, > > > > >>> > > > > >>> Răzvan Crainea > > > > >>> OpenSIPS Core Developer > > > > >>> http://www.opensips-solutions.com > > > > >>> > > > > >>> On 5/10/21 9:54 AM, Miha via Users wrote: > > > > >>> > Hello > > > > >>> > > > > > >>> > I have used letsenrypt for generating certs > for > > > > Opensips. > > > > >>> > > > > > >>> > Regarding configuration i have fallowed your > > > > configuration steps on > > > > >>> > OpenSips blog. > > > > >>> > > > > > >>> > socket=udp:xxx.xxx.xxx.xxx:5060 # CUSTOMIZE > ME > > > > >>> > socket=tls:xxx.xxx.xxx.xxx:5061 > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > ### Proto TLS > > > > >>> > loadmodule "proto_tls.so" > > > > >>> > modparam("proto_tls", > "tls_handshake_timeout", > > > 300) > > > > >>> > #### TLS module > > > > >>> > loadmodule "tls_mgm.so" > > > > >>> > #modparam("tls_mgm", "db_url", > > > > "mysql://root:xxxx at localhost/opensips") > > > > >>> > modparam("tls_mgm", "client_sip_domain_avp", > > > > "mtsbcs.test.com") > > > > >>> > modparam("tls_mgm", "server_domain", "mt") > > > > >>> > #modparam("tls_mgm", "match_ip_address", > > > > "[mt]xxx.xxx.xxx.xxx:5061") > > > > >>> > #modparam("tls_mgm", "match_sip_domain", > > > > "[mt]mtsbcs.test.com") > > > > >>> > modparam("tls_mgm", "certificate", > > > > >>> > > > > > > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/cert.pem") > > > > >>> > modparam("tls_mgm", "private_key", > > > > >>> > > > > > > > > > "[mt]/etc/letsencrypt/live/mtsbcs.test.com/privkey.pem") > > > > >>> > modparam("tls_mgm", "ca_list", > > > > >>> "[mt]/etc/ssl/certs/ca-certificates.crt") > > > > >>> > modparam("tls_mgm", "ca_dir", > > > > "[mt]/etc/ssl/certs/") > > > > >>> > modparam("tls_mgm","verify_cert", "[mt]1") > > > > >>> > modparam("tls_mgm","require_cert", "[mt]1") > > > > >>> > modparam("tls_mgm","tls_method", > "[mt]TLSv1_2") > > > > >>> > modparam("proto_tls", "tls_max_msg_chunks", > 8) > > > > >>> > #modparam("tls_mgm", "tls_handshake_timeout", > > > 300) > > > > >>> > > > > > >>> > if(is_method("OPTIONS") && > > > > is_domain_local("$rd") && > > > > >>> > check_source_address(0)) { > > > > >>> > xlog("L_INFO", "[MS TEAMS] > > > OPTIONS > > > > In"); > > > > >>> > send_reply(200, "OK"); > > > > >>> > exit; > > > > >>> > } > > > > >>> > > > > > >>> > > > > > >>> > local_route { > > > > >>> > $var(dst) = "pstnhub.microsoft.com"; > > > > >>> > xlog("L_INFO","promding TEST"); > > > > >>> > xlog("TESTING"); > > > > >>> > if (is_method("OPTIONS") && ($(ru{s.index, > > > > $var(dst)}) != NULL)) > > > > >>> > append_hf("Contact: > > > > > > >>> ;transport=tls>\r\n"); > > > > >>> > xlog("L_INFO", "SEDING OPTIONS TO SBC"); > > > > >>> > } > > > > >>> > > > > > >>> > > > > > >>> > I thnk that the main issue is that OPENSIPS > does > > > > not send encrypted > > > > >>> > OPTION to MS teams. > > > > >>> > > > > > >>> > Logs: > > > > >>> > > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > DBG:tm:t_uac: > > > > >>> > next_hop= > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:mk_proxy: doing DNS > > > > >>> lookup... > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:sip_resolvehost: no > > > > >>> port, > > > > >>> > has proto -> do SRV lookup! > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:do_srv_lookup: > > > > >>> resolving > > > > >>> > [sip.pstnhub.microsoft.com] > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:do_srv_lookup: > > > > >>> > SRV(_sips._tcp.sip.pstnhub.microsoft.com) = > > > > >>> sip.pstnhub.microsoft.com:5061 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:a2dns_node: storing > > > > >>> > sip2.pstnhub.microsoft.com:5061 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:a2dns_node: storing > > > > >>> > sip3.pstnhub.microsoft.com:5061 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > DBG:tm:t_uac: > > > > sending socket is > > > > >>> > 212.13.249.132 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:tm:print_request_uri: > > > > >>> > sip:sip.pstnhub.microsoft.com > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:tm:run_local_route: building > > > > >>> > sip_msg from buffer > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_msg: SIP Request: > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_msg: method: > > > > >>> > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_msg: uri: > > > > >>> > > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_msg: version: > > > > >>> > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: > > > > >>> > flags=ffffffffffffffff > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_via_param: found > > > > >>> > param type 232, = > > > > ; state=16 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_via: end of > > > > >>> header > > > > >>> > reached, state=5 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: via > > > > >>> found, > > > > >>> > flags=ffffffffffffffff > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: this is > > > > >>> > the first via > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:_parse_to: end of > > > > >>> header > > > > >>> > reached, state=9 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:_parse_to: display={}, > > > > >>> > ruri={sip:sip.pstnhub.microsoft.com} > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:get_hdr_field: > > > > >>> [31]; > > > > >>> > uri=[sip:sip.pstnhub.microsoft.com] > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:get_hdr_field: to body > > > > >>> > [sip:sip.pstnhub.microsoft.com#015#012 > > > > > > >>> ] > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:get_hdr_field: cseq > > > > >>> > : <14> > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:get_hdr_field: > > > > >>> > content_length=0 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:get_hdr_field: found > > > > >>> end > > > > >>> > of header > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: > > > > >>> > flags=ffffffffffffffff > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: flags=78 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: > > > > >>> > flags=ffffffffffffffff > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:tm:run_local_route: Change > > > > >>> in > > > > >>> > local route -> rebuilding buffer > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: > > > > >>> flags=2000 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: > > > > >>> > flags=ffffffffffffffff > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:extract_ftc_hdrs: flags > > > > >>> = 15 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:extract_ftc_hdrs: hdr 2 > > > > >>> > extracted as > > > sip:sip.pstnhub.microsoft.com#015#012 > > > > > > >>> > > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:extract_ftc_hdrs: hdr 1 > > > > >>> > extracted as > > > >>> > > > > >>> > > > >;tag=a665d66adab06c7308a33b8567de92d6-f627#015#012> > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:extract_ftc_hdrs: hdr 8 > > > > >>> > extracted as > > > 12e30be047c27077-1020 at 212.13.249.132#015#012 > > > > > > >>> > > > > > > > > > > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:proto_tls:proto_tls_send: no > > > > >>> > open tcp connection found, opening new one > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:probe_max_sock_buff: > > > > >>> > getsockopt: snd is initially 16384 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:probe_max_sock_buff: > > > > >>> > using snd buffer of 416 kb > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:init_sock_keepalive: > > > > >>> TCP > > > > >>> > keepalive enabled on socket 5 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:print_ip: tcpconn_new: > > > > >>> > new tcp connection to: 52.114.75.24 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:tcpconn_new: on port > > > > >>> > 5061, proto 3 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:proto_tls:tls_conn_init: > > > > >>> > Creating a whole new ssl connection > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:core:tcpconn_destroy: > > > > >>> > destroying connection 0x7f45d7e08078, flags > 0018 > > > > >>> > May 10 08:53:10 mtsbc opensips[1020]: > > > > DBG:tm:insert_timer_unsafe: [0]: > > > > >>> > 0x7f45d7e066b0 (1625) > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:timer_routine: timer > > > > >>> > routine:0,tl=0x7f45d7e066b0 next=(nil), > > > > timeout=1625 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:final_response_handler: > > > > >>> > Cancel sent out, sending 408 (0x7f45d7e06460) > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:t_should_relay_response: > > > > >>> > T_code=0, new_code=408 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:t_pick_branch: picked > > > > >>> > branch 0, code 408 (prio=800) > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:is_3263_failure: > > > > >>> > dns-failover test: branch=0, last_recv=408, > > > flags=0 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:t_should_relay_response: > > > > >>> > trying DNS-based failover > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:do_dns_failover: new > > > > >>> > destination available > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: > > > > >>> flags=2000 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > >>> > DBG:core:build_req_buf_from_sip_req: id > added: > > > > <;i=0>, rcv proto=3 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:parse_headers: > > > > >>> > flags=ffffffffffffffff > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:proto_tls:proto_tls_send: no > > > > >>> > open tcp connection found, opening new one > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:probe_max_sock_buff: > > > > >>> > getsockopt: snd is initially 16384 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:probe_max_sock_buff: > > > > >>> > using snd buffer of 416 kb > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:init_sock_keepalive: > > > > >>> TCP > > > > >>> > keepalive enabled on socket 5 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:print_ip: tcpconn_new: > > > > >>> > new tcp connection to: 52.114.132.46 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:tcpconn_new: on port > > > > >>> > 5061, proto 3 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:proto_tls:tls_conn_init: > > > > >>> > Creating a whole new ssl connection > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:tcpconn_destroy: > > > > >>> > destroying connection 0x7f45d7e08078, flags > 0018 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:proto_tls:proto_tls_send: no > > > > >>> > open tcp connection found, opening new one > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:probe_max_sock_buff: > > > > >>> > getsockopt: snd is initially 16384 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:probe_max_sock_buff: > > > > >>> > using snd buffer of 416 kb > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:init_sock_keepalive: > > > > >>> TCP > > > > >>> > keepalive enabled on socket 5 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:print_ip: tcpconn_new: > > > > >>> > new tcp connection to: 52.114.14.70 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:tcpconn_new: on port > > > > >>> > 5061, proto 3 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:proto_tls:tls_conn_init: > > > > >>> > Creating a whole new ssl connection > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:core:tcpconn_destroy: > > > > >>> > destroying connection 0x7f45d7e08078, flags > 0018 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:local_reply: branch=0, > > > > >>> > save=0, winner=0 > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:local_reply: local > > > > >>> > transaction completed > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:run_trans_callbacks: > > > > >>> > trans=0x7f45d7e06460, callback type 256, id 0 > > > > entered > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:insert_timer_unsafe: [2]: > > > > >>> > 0x7f45d7e064e0 (1630) > > > > >>> > May 10 08:53:15 mtsbc opensips[1020]: > > > > DBG:tm:final_response_handler: > > > > >>> done > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > Thank you > > > > >>> > miha > > > > >>> > > > > > >>> > > > > > >>> > > _______________________________________________ > > > > >>> > Users mailing list > > > > >>> > Users at lists.opensips.org > > > > >>> > > > > > > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > >>> > > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Users mailing list > > > > >>> Users at lists.opensips.org > > > > >>> > > > > > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > >>> > > > > >> > > > > >> > > > > >> -- > > > > >> *Carlos E. Wagner* > > > > >> *Tecnólogo em Telecomunicações, Opensips > Certified > > > > Professional* > > > > >> > > > > >> *Fone: +55 48 99981-0894* > > > > >> *E-mail:* kaduww at gmail.com > > > > >> *LinkedIn:* > > > > > > > > > > https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ > > > > >> _______________________________________________ > > > > >> Users mailing list > > > > >> Users at lists.opensips.org > > > > >> > > > > > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > >> > > > > > _______________________________________________ > > > > > Users mailing list > > > > > Users at lists.opensips.org > > > > > > > > > > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > > > > > > > > -- > > > > *Carlos E. Wagner* > > > > *Tecnólogo em Telecomunicações, Opensips Certified > > > > Professional* > > > > > > > > *Fone: +55 48 99981-0894* > > > > *E-mail:* kaduww at gmail.com > > > > *LinkedIn:* > > > > > > > > > > https://www.linkedin.com/in/carlos-eduardo-wagner-96bbb433/ > > > > > > > > > _______________________________________________ > > > Users mailing list > > > Users at lists.opensips.org > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > From kingsley at dns99.co.uk Tue May 11 08:58:45 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 11 May 2021 09:58:45 +0100 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> <349cfaa9-d216-9a9a-6232-8a871d113526@opensips.org> <89c333792f949f604e29c9f897150df52a6be71d.camel@dns99.co.uk> Message-ID: <1e3aa45dd3cebe9da28d8da22810091e7a91e024.camel@dns99.co.uk> On Mon, 2021-05-10 at 19:25 +0300, Liviu Chircu wrote: > On 10.05.2021 19:19, Kingsley Tart wrote: > > I could do, but I was hoping to avoid that as it feels like bad > > practice and it's inefficient - more of a workaround than a proper fix. > > Speaking for myself, I don't think I've ever seen a non-VARCHAR custom > accounting column with the "acc" module. I think this is probably the reason ;) If it's the only way to make it work, people are doing it that way because they have to. > Also, if you think about it, > writing the 1 integer value requires only 25% of the space if you're > writing "1" instead of 1. So, YMMV with regards to efficiency, we're > talking bits and pieces of data here, as the fields themselves are not > that large, it's their sheer number required in the CDRs that's often > problematic. It depends on what you want to do to that column afterwards - see Aron's message for example. SQL databases have different datatypes for a reason. It would be nice if the acc module could play nicer with that. Two possible solutions to this are: 1. the acc module not try to set any fields where the value has not been set in the routing script, or 2. the acc module defaults these fields to NULL instead of an empty string I prefer option 1 if given the choice. -- Cheers, Kingsley. From liviu at opensips.org Tue May 11 09:00:40 2021 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 11 May 2021 12:00:40 +0300 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: <1e3aa45dd3cebe9da28d8da22810091e7a91e024.camel@dns99.co.uk> References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> <349cfaa9-d216-9a9a-6232-8a871d113526@opensips.org> <89c333792f949f604e29c9f897150df52a6be71d.camel@dns99.co.uk> <1e3aa45dd3cebe9da28d8da22810091e7a91e024.camel@dns99.co.uk> Message-ID: On 11.05.2021 11:58, Kingsley Tart wrote: > 2. the acc module defaults these fields to NULL instead of an empty > string I think defaulting to SQL's special DEFAULT value is even better.  The discussion is already ongoing on the tracker, see [1] [1]: https://github.com/OpenSIPS/opensips/issues/2205 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS eBootcamp 2021 | www.opensips.org/training From john.quick at smartvox.co.uk Tue May 11 09:26:52 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 11 May 2021 10:26:52 +0100 Subject: [OpenSIPS-Users] Tips for troubleshooting OpenSIPS as a Teams SBC In-Reply-To: References: <000d01d72ac9$33528c80$99f7a580$@smartvox.co.uk> Message-ID: <001501d74647$caadd050$600970f0$@smartvox.co.uk> Hi Jeff, I think the solution to proper handling of loose routed requests (without having to add a new "alias" every time you sign up another client) is to use the domain table and the domain.so module. You will need to add a record to the domain table for each new client, then reload it. That might seem a little tedious from an admin perspective, but the pros include: * You have a native OpenSIPS DB table containing all the supported sub-domains * You can cross check the INVITE's received from Teams to make sure it is a supported sub-domain * You could use the attrs field to store additional account attributes that might be useful when processing requests John Quick Smartvox Limited From kingsley at dns99.co.uk Tue May 11 10:55:57 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 11 May 2021 11:55:57 +0100 Subject: [OpenSIPS-Users] is this a bug? acc module setting empty string for unset fields In-Reply-To: References: <8ff40ca4ba26e9380e32d64bd73d6b1ce2c6bbea.camel@dns99.co.uk> <69a554d7-0600-8526-5ef9-0b9c751476d0@opensips.org> <812364d5816314d7caa0b40838f6c029f3133c63.camel@dns99.co.uk> <349cfaa9-d216-9a9a-6232-8a871d113526@opensips.org> <89c333792f949f604e29c9f897150df52a6be71d.camel@dns99.co.uk> <1e3aa45dd3cebe9da28d8da22810091e7a91e024.camel@dns99.co.uk> Message-ID: On Tue, 2021-05-11 at 12:00 +0300, Liviu Chircu wrote: > On 11.05.2021 11:58, Kingsley Tart wrote: > > 2. the acc module defaults these fields to NULL instead of an empty > > string > > I think defaulting to SQL's special DEFAULT value is even better. Yes that works for me, and should do the same as not specifying the field at all which was my first suggestion, but is probably easier for you to implement. It's better than setting to NULL I agree. > The discussion is already ongoing on the tracker, see [1] > > [1]: https://github.com/OpenSIPS/opensips/issues/2205 Excellent. This would be a good step forward. -- Cheers, Kingsley. From john.quick at smartvox.co.uk Tue May 11 11:07:21 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 11 May 2021 12:07:21 +0100 Subject: [OpenSIPS-Users] Tips for troubleshooting OpenSIPS as a Teams SBC In-Reply-To: References: <000d01d72ac9$33528c80$99f7a580$@smartvox.co.uk> Message-ID: <001601d74655$d4470e70$7cd52b50$@smartvox.co.uk> Jeff, Regarding the first issue you mention, have you tried: record_route_preset(“SBC_FQDN:5061;transport=tls”); In other words, have you tried it with a single rather than a double RR header? You would need to remove the ";r2=on" parameter of course. In theory, if the SBC_FQDN resolves to the IP address and everything communicating with your SBC is (a) capable of resolving the FQDN and (b) capable of routing to the SBC, then it should work. In my script I added " AS SBC_FQDN:5061" on the end of the tls listen/socket statement. I cannot remember if that was essential for it to work, but I leave it there on the basis that it cannot do any harm and might do some good. John Quick Smartvox Limited From homstr at gmail.com Tue May 11 12:07:02 2021 From: homstr at gmail.com (Alexey Hamstr) Date: Tue, 11 May 2021 14:07:02 +0200 Subject: [OpenSIPS-Users] DLG_lifetime is empty Message-ID: Hi All. I'am trying to setup RADIUS accounting and i want to fill in the Acct-Session-Time by $DLG_lifetime in STOP call as i have found in the list archive http://lists.opensips.org/pipermail/users/2010-August/014120.html but I see that this pseudo variable is null. Can anybody advise me how i can do that? Any help will be appreciated. Regards, Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Tue May 11 12:20:08 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 11 May 2021 13:20:08 +0100 Subject: [OpenSIPS-Users] dialog end reason in CDRs Message-ID: Hi, Is there a version of this that works in OpenSIPS 3.1? modparam("acc", "db_extra_bye", "sip_dlg_end_reason=$DLG_end_reason") I want to log the dialog end reason in the CDRs. -- Cheers, Kingsley. From jeff at ugnd.org Tue May 11 12:42:20 2021 From: jeff at ugnd.org (Jeff Pyle) Date: Tue, 11 May 2021 08:42:20 -0400 Subject: [OpenSIPS-Users] MS team issue In-Reply-To: References: <8a1f3c1f-25d6-4dcc-1c96-95da615c8763@softnet.si> Message-ID: For inbound from Teams, I use the permissions module with the following: MariaDB [opensips_teamsproxy]> select * from address where grp=1; +----+-----+-------------+------+------+-------+---------+--------------+ | id | grp | ip | mask | port | proto | pattern | context_info | +----+-----+-------------+------+------+-------+---------+--------------+ | 1 | 1 | 13.107.64.0 | 18 | 0 | tls | NULL | NULL | | 2 | 1 | 52.120.0.0 | 14 | 0 | tls | NULL | NULL | | 3 | 1 | 52.112.0.0 | 14 | 0 | tls | NULL | NULL | +----+-----+-------------+------+------+-------+---------+--------------+ 3 rows in set (0.001 sec) These are the ranges that Microsoft will send traffic from. In the script, I use if (check_address(1, "$si", 0, "$socket_in(proto)")) { setflag("FROM_MS"); to match inbound traffic to the above table, and then check for the FROM_MS flag to make routing decisions. For outbound to Teams, I use the drouting module with the following (using FQDNs): MariaDB [opensips_teamsproxy]> select gwid,type,address,probe_mode from dr_gateways where gwid like 'ms%'; +------+------+----------------------------+------------+ | gwid | type | address | probe_mode | +------+------+----------------------------+------------+ | ms1 | 0 | sip.pstnhub.microsoft.com | 2 | | ms2 | 0 | sip2.pstnhub.microsoft.com | 2 | | ms3 | 0 | sip3.pstnhub.microsoft.com | 2 | +------+------+----------------------------+------------+ 3 rows in set (0.001 sec) You may need to populate the socket column or others I haven't shown here according to your needs. Also: MariaDB [opensips_teamsproxy]> select * from dr_carriers where carrierid like 'ms%'; +----+------------+-------------+-------+----------+-------+-------+--------------------+ | id | carrierid | gwlist | flags | sort_alg | state | attrs | description | +----+------------+-------------+-------+----------+-------+-------+--------------------+ | 2 | ms_pstnhub | ms1,ms2,ms3 | 0 | N | 0 | NULL | Microsoft PSTN Hub | +----+------------+-------------+-------+----------+-------+-------+--------------------+ 1 row in set (0.001 sec) This gateway ordering makes sense for someone in North America. You'll want to check sip, sip2 and sip3 to see which is closest to you and order the gwlist accordingly. In the script, I use the following with this 'carrier': if (!route_to_carrier("ms_pstnhub")) { xlog("L_NOTICE", "[teamsproxy] NOTICE: couldn't route to 'ms_pstnhub' carrier\n"); send_reply(500, "Internal Server Error - RtC"); exit; } This is just one way to accomplish it. I suspect there are many others that work just as well based on unique needs. - Jeff On Tue, May 11, 2021 at 3:51 AM Miha via Users wrote: > hello > > i tried to put this in address table: > "*.pstnhub.microsoft.com" but it does not work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Tue May 11 13:38:15 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 11 May 2021 14:38:15 +0100 Subject: [OpenSIPS-Users] [SOLVED] Re: dialog end reason in CDRs In-Reply-To: References: Message-ID: <50e8c163ead0c1b8c592b808c7553bc297c1b04e.camel@dns99.co.uk> On Tue, 2021-05-11 at 13:20 +0100, Kingsley Tart wrote: > Hi, > > Is there a version of this that works in OpenSIPS 3.1? > > modparam("acc", "db_extra_bye", "sip_dlg_end_reason=$DLG_end_reason") > > I want to log the dialog end reason in the CDRs. Sorry, managed to figure this one out by doing these things: From kingsley at dns99.co.uk Tue May 11 13:40:23 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 11 May 2021 14:40:23 +0100 Subject: [OpenSIPS-Users] [SOLVED] Re: dialog end reason in CDRs In-Reply-To: References: Message-ID: <971c55e2392ade09ead804dd92f62f2bad44d523.camel@dns99.co.uk> On Tue, 2021-05-11 at 13:20 +0100, Kingsley Tart wrote: > Hi, > > Is there a version of this that works in OpenSIPS 3.1? > > modparam("acc", "db_extra_bye", "sip_dlg_end_reason=$DLG_end_reason") > > I want to log the dialog end reason in the CDRs. Mailer sent message while I was still typing it :-/ This logs the end reason if OpenSIPS sends the BYEs (eg dialog timeouts): local_route { if (is_method("BYE")) { $acc_extra(end_reason) = $DLG_end_reason; } } This does it for normal BYEs in the main routing function: From xaled at web.de Wed May 12 00:28:39 2021 From: xaled at web.de (xaled at web.de) Date: Wed, 12 May 2021 02:28:39 +0200 Subject: [OpenSIPS-Users] b2b_client_new ; transport=xxx string in dest_uri parameter Message-ID: <13f901d746c5$c18f3ad0$44adb070$@web.de> Hi, It seems like b2b_client_new function ignores the ;transport=xxx string in dest_uri parameter. Is this true, or am I missing something? Thanks, Xaled -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Wed May 12 10:32:02 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Wed, 12 May 2021 11:32:02 +0100 Subject: [OpenSIPS-Users] best way to do "foreach" Message-ID: <78139499e2a38fdbf3a270b3b116f1c8cde64c9c.camel@dns99.co.uk> Is there a recommended way to implement a foreach loop with the iterator iterating over a list of known values? For string values that won't themselves contain a comma, I could do this: $var(valCSV) = "string1,string2,string3,string4"; $var(valcount) = $(var(valCSV){csv.count}); $var(valindex) = 0; while ($var($valindex) < $var($valcount)) { $var(thisval) = $(var(valCSV){csv.param,$var(valindex)}); $var(valindex) = $var(valindex) + 1; # more code } or I could use an AVP (also handy if the strings might contain a comma): $avp(vals) = "string4"; $avp(vals) = "string3"; $avp(vals) = "string2"; $avp(vals) = "string1"; $var(valcount) = 4; $var(valindex) = 0; while ($var($valindex) < $var($valcount)) { $var(thisval) = $avp(vals); $avp(vals) = NULL; $var(valindex) = $var(valindex) + 1; # more code } (specifically using an iterator to count through the loop in case something else is already using that AVP - only want to delete what I added in the first place). Is there a perferred way, or better way than these? Cheers, Kingsley. From liviu at opensips.org Wed May 12 10:43:07 2021 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 12 May 2021 13:43:07 +0300 Subject: [OpenSIPS-Users] best way to do "foreach" In-Reply-To: <78139499e2a38fdbf3a270b3b116f1c8cde64c9c.camel@dns99.co.uk> References: <78139499e2a38fdbf3a270b3b116f1c8cde64c9c.camel@dns99.co.uk> Message-ID: <72e87caa-f8ec-ab70-5e64-e3ae7b4cf461@opensips.org> On 12.05.2021 13:32, Kingsley Tart wrote: > Is there a recommended way to implement a foreach loop with the > iterator iterating over a list of known values? Hey Kingsley, There is actually a "foreach" statement available, applicable to any variable that can be indexed [1], so maybe you could write some cleaner code using that, depending on your available inputs. As far as performance is concerned, the differences are negligible.  As long as you follow the rule of "$var is always faster than $avp", you should be writing nearly optimal script code. Ultimately, the bottlenecks will forever be DNS queries, SQL queries, HTTP queries, TCP I/O, SIP retransmission timers, etc., with scripting technique being near the bottom of the optimization priority list... [1]: https://www.opensips.org/Documentation/Script-Statements-3-2#toc4 Cheers, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS eBootcamp 2021 | www.opensips.org/training From liviu at opensips.org Wed May 12 10:46:52 2021 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 12 May 2021 13:46:52 +0300 Subject: [OpenSIPS-Users] best way to do "foreach" In-Reply-To: <78139499e2a38fdbf3a270b3b116f1c8cde64c9c.camel@dns99.co.uk> References: <78139499e2a38fdbf3a270b3b116f1c8cde64c9c.camel@dns99.co.uk> Message-ID: <88191aa3-712f-28b2-9ed5-c8d39bf7dfcf@opensips.org> On 12.05.2021 13:32, Kingsley Tart wrote: > $var(valindex) = $var(valindex) + 1; Also worth mentioning that since 3.1, this statement can be re-written as: $var(valindex) += 1; Additionally, during your iteration, you may also take advantage of the fact that "$(var(valCSV){csv.param,$var(valindex)})" returns NULL on "index out of bounds". Many other "indexable" transformations behave like this as well. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS eBootcamp 2021 | www.opensips.org/training From kingsley at dns99.co.uk Wed May 12 11:12:04 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Wed, 12 May 2021 12:12:04 +0100 Subject: [OpenSIPS-Users] best way to do "foreach" In-Reply-To: <88191aa3-712f-28b2-9ed5-c8d39bf7dfcf@opensips.org> References: <78139499e2a38fdbf3a270b3b116f1c8cde64c9c.camel@dns99.co.uk> <88191aa3-712f-28b2-9ed5-c8d39bf7dfcf@opensips.org> Message-ID: On Wed, 2021-05-12 at 13:46 +0300, Liviu Chircu wrote: > On 12.05.2021 13:32, Kingsley Tart wrote: > > $var(valindex) = $var(valindex) + 1; > > Also worth mentioning that since 3.1, this statement can be re- > written as: > > $var(valindex) += 1; Oh excellent. > Additionally, during your iteration, you may also take advantage of > the fact that "$(var(valCSV){csv.param,$var(valindex)})" returns NULL > on "index out of bounds". Many other "indexable" transformations > behave like this as well. Handy to know, thanks :) > There is actually a "foreach" statement available, applicable to any > variable that can be indexed [1], so maybe you could write some cleaner > code using that, depending on your available inputs. > [1]: https://www.opensips.org/Documentation/Script-Statements-3-2#toc4 Thanks. The reason for actually counting the loop for the AVP version was that it's possible (depending on where this function was called from) that there might already be an AVP with the same name. Specifically counting through the loop ensures I only remove the values I put on, thus leaving it in its original state when the function returns. > As far as performance is concerned, the differences are negligible. As > long as you follow the rule of "$var is always faster than $avp", you > should be writing nearly optimal script code. I do that where I can. > Ultimately, the bottlenecks will forever be DNS queries, SQL queries, > HTTP queries, TCP I/O, SIP retransmission timers, etc., with scripting > technique being near the bottom of the optimization priority list... To help with that, I'm using cachedb_local with cache_store() and cache_fetch(), populating some things in a timer route, and also using dns_cache, so hopefully avoiding as many of those bottlenecks as is reasonably possible to do. Thanks for your help. -- Cheers, Kingsley. From bogdan at opensips.org Thu May 13 12:01:37 2021 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 13 May 2021 15:01:37 +0300 Subject: [OpenSIPS-Users] OpenSIPS Summit Distributed 2021- registration open Message-ID: <749b0098-cfb9-eaf4-7e5d-2b43a2eefc03@opensips.org> OpenSIPS Summit Distributed 2021 Sep 5th-10th, 2021 online *The registration is now open * Register for the online OpenSIPS Summit 2021. Get a free seat for the conference and the workshops. Or consider the one-day OpenSIPS training as an investment into your future. Register now *One-day OpenSIPS training* This year, the training is mainly focused on using OpenSIPS in conjunction with media relayers (such as RTPproxy or RTPengine). The students will learn and practice on how to do RTP relaying for the calls going via OpenSIPS, how to use the new rtp_relay module for doing dialog aware media relaying, how to do SRTP to RTP conversion, media bridging or transcoding. An interesting topic will be the media re-anchoring for the ongoing calls. *Be part of it* Be a part of both OpenSIPS and the Open Source community, be part of the OpenSIPS Summit 2021. *Speak to share* - the Call for Papers is already on, so you can share your wisdom and experience with the world. Interested? Please contact our team or email us! ** -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ugnd.org Thu May 13 17:41:16 2021 From: jeff at ugnd.org (Jeff Pyle) Date: Thu, 13 May 2021 13:41:16 -0400 Subject: [OpenSIPS-Users] Tips for troubleshooting OpenSIPS as a Teams SBC In-Reply-To: <001601d74655$d4470e70$7cd52b50$@smartvox.co.uk> References: <000d01d72ac9$33528c80$99f7a580$@smartvox.co.uk> <001601d74655$d4470e70$7cd52b50$@smartvox.co.uk> Message-ID: John, This has worked brilliantly -- the domain module took care of teaching OpenSIPS what's local. As far as a single versus double RR, the problem turned out to be with a downstream SBC that couldn't resolve the domain name properly. Once fixed, the single RR works as expected. Regards, Jeff On Tue, May 11, 2021 at 7:07 AM John Quick wrote: > Jeff, > > Regarding the first issue you mention, have you tried: > record_route_preset(“SBC_FQDN:5061;transport=tls”); > > In other words, have you tried it with a single rather than a double RR > header? > You would need to remove the ";r2=on" parameter of course. > > In theory, if the SBC_FQDN resolves to the IP address and everything > communicating with your SBC is (a) capable of resolving the FQDN and (b) > capable of routing to the SBC, then it should work. > > In my script I added " AS SBC_FQDN:5061" on the end of the tls > listen/socket statement. I cannot remember if that was essential for it to > work, but I leave it there on the basis that it cannot do any harm and > might do some good. > > John Quick > Smartvox Limited > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Thu May 13 20:21:28 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Thu, 13 May 2021 21:21:28 +0100 Subject: [OpenSIPS-Users] opposite of {s.int} ? Message-ID: Hi. Is there a transformation or something else that can convert an integer to a string? ie do the opposite of {s.int} ? I wanted to maintain a leg sequence number (with multi-leg accounting) with a dialog variable, but dialog variables can only contain strings. So I did $dlg_val(dstSeq) = "1"; at the start. But in the failure route for next endpoint, I wanted to do this: $var(tmp) = $(dlg_val(dstSeq){s.int}) + 1; $dlg_val(dstSeq) = $var(tmp); but it doesn't like assigning an integer, so I tried $dlg_val(dstSeq) = "$var(tmp)"; but that then assigned that literal string to the dialog variable. So then I tried $dlg_val(dstSeq) = $var(tmp) + ""; but that complained about type mismatching, so in the end O had to do $avp(tmp) = $var(tmp); $dlg_val(dstSeq) = $avp(tmp); $avp(tmp) = NULL; which feels messy. From osas at voipembedded.com Thu May 13 20:24:10 2021 From: osas at voipembedded.com (Ovidiu Sas) Date: Thu, 13 May 2021 16:24:10 -0400 Subject: [OpenSIPS-Users] opposite of {s.int} ? In-Reply-To: References: Message-ID: Try the other way around: $dlg_val(dstSeq) = "" + $var(tmp); -ovidiu On Thu, May 13, 2021 at 4:22 PM Kingsley Tart wrote: > > Hi. > > Is there a transformation or something else that can convert an integer > to a string? ie do the opposite of {s.int} ? > > I wanted to maintain a leg sequence number (with multi-leg accounting) > with a dialog variable, but dialog variables can only contain strings. > > So I did > > $dlg_val(dstSeq) = "1"; > > at the start. But in the failure route for next endpoint, I wanted to > do this: > > $var(tmp) = $(dlg_val(dstSeq){s.int}) + 1; > $dlg_val(dstSeq) = $var(tmp); > > but it doesn't like assigning an integer, so I tried > > $dlg_val(dstSeq) = "$var(tmp)"; > > but that then assigned that literal string to the dialog variable. So > then I tried > > $dlg_val(dstSeq) = $var(tmp) + ""; > > but that complained about type mismatching, so in the end O had to do > > $avp(tmp) = $var(tmp); > $dlg_val(dstSeq) = $avp(tmp); > $avp(tmp) = NULL; > > which feels messy. > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com From kingsley at dns99.co.uk Fri May 14 09:18:38 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Fri, 14 May 2021 10:18:38 +0100 Subject: [OpenSIPS-Users] opposite of {s.int} ? In-Reply-To: References: Message-ID: <7dea09d66acfee81eec61d0914f01769e8eb83f1.camel@dns99.co.uk> Wow that worked, thanks. So I guess the first value sets the type, whereupon it's OK to append an integer to a string, but not OK to add a string to an integer ... Cheers, Kingsley. On Thu, 2021-05-13 at 16:24 -0400, Ovidiu Sas wrote: > Try the other way around: > $dlg_val(dstSeq) = "" + $var(tmp); > > -ovidiu > From bogdan at opensips.org Fri May 14 10:19:57 2021 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 14 May 2021 13:19:57 +0300 Subject: [OpenSIPS-Users] OpenSIPS 2021 planning In-Reply-To: <2a3b7dd0-a1c4-8333-f1c2-6dab6cf5eba6@opensips.org> References: <2a3b7dd0-a1c4-8333-f1c2-6dab6cf5eba6@opensips.org> Message-ID: <2b5987a5-84af-d56c-c12b-338d4e2b5c50@opensips.org> Heads up, the date for the OpenSIPS 3.2 major release (beta version) is set for 27th of May 2021 !! Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2021 online https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 3/30/21 2:06 PM, Bogdan-Andrei Iancu wrote: > Hi OpenSIPS'ers! > > We all do plans in advance and the most helpful thing here is to know > what to expect, what to rely on, what upcoming events are. > > Well, we want to help all the OpenSIPS’ers and share with you the 2021 > calendar for OpenSIPS project, with the most relevant events. > > So, please check > https://blog.opensips.org/2021/03/30/opensips-calendar-for-2021/ > > > Happy planning, > From xaled at web.de Fri May 14 11:33:37 2021 From: xaled at web.de (xaled at web.de) Date: Fri, 14 May 2021 13:33:37 +0200 Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine Message-ID: <15a401d748b4$fb1b9140$f152b3c0$@web.de> Hi, Are the any examples of using the new B2B module in 3.2 with RTPProxy or RTPEngine? I tried adding _offer and _answer call accordingly but never saw RTPProxy or RTPEngine engaged. Even a simple example for A-B call with B2B and RTPEngine would be much appreciated. Thanks, Xaled From xaled at web.de Fri May 14 11:35:05 2021 From: xaled at web.de (xaled at web.de) Date: Fri, 14 May 2021 13:35:05 +0200 Subject: [OpenSIPS-Users] b2b_client_new ; transport=xxx string in dest_uri parameter In-Reply-To: <13f901d746c5$c18f3ad0$44adb070$@web.de> References: <13f901d746c5$c18f3ad0$44adb070$@web.de> Message-ID: <15a601d748b5$2fe3aed0$8fab0c70$@web.de> Any hints on how to set the outgoing transport protocol with b2b_client_new (OpenSIPS 3.2) if ;transport=xxx string does not work? From: Users On Behalf Of xaled at web.de Sent: Wednesday, May 12, 2021 2:29 AM To: 'OpenSIPS users mailling list' Subject: [OpenSIPS-Users] b2b_client_new ; transport=xxx string in dest_uri parameter Hi, It seems like b2b_client_new function ignores the ;transport=xxx string in dest_uri parameter. Is this true, or am I missing something? Thanks, Xaled -------------- next part -------------- An HTML attachment was scrubbed... URL: From bullehs at gmail.com Mon May 17 07:20:40 2021 From: bullehs at gmail.com (HS) Date: Mon, 17 May 2021 12:20:40 +0500 Subject: [OpenSIPS-Users] Config script - Opensips + RTPProxy + Freeswitch on EC2 Message-ID: Hi all. I keep writing from time to time asking for help as a newbie to Opensips. Somehow trial and error makes things work. I wanted to know if there's a book/tutorial available to understand how the .cfg file and script works and all the variables involved. Specifically trying to do the following on an Amazon EC2 setup: 1. Call centre implementation (I have the modules etc. setup), 2. Enable IVR, 3. Enable Conferencing, 4. Enable Voicemail, 5. Enable Push Notifications. I understand a lot of it has to do with Freeswitch (I have read the old tutorial) - and would like to understand how the routing aspect would work. Thanks again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon May 17 07:56:32 2021 From: miha at softnet.si (Miha) Date: Mon, 17 May 2021 09:56:32 +0200 Subject: [OpenSIPS-Users] TLS to UDP, record route Message-ID: <25150991-e74a-60f9-8ab1-732ca171035b@softnet.si> Hello i need a little help how to chnage RR in responses to UDP GW (requestes goes via TLS to MS teams). So in reply i have like this:  RECORD-ROUTE: ,. But i should have like this: RECORD-ROUTE: ,. I tried to do it like:  subst_uri('/mtsbc.test.com:5061;transport=tls/xxx.xxx.xxx.xxxx:5060/i'); but it does not match. thank you miha -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon May 17 08:15:54 2021 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 17 May 2021 09:15:54 +0100 Subject: [OpenSIPS-Users] TLS to UDP, record route In-Reply-To: <25150991-e74a-60f9-8ab1-732ca171035b@softnet.si> References: <25150991-e74a-60f9-8ab1-732ca171035b@softnet.si> Message-ID: subst_uri only works on the request uri, try again with subst()! On Mon, 17 May 2021 at 08:58, Miha via Users wrote: > Hello > > i need a little help how to chnage RR in responses to UDP GW (requestes > goes via TLS to MS teams). > > So in reply i have like this: > RECORD-ROUTE: > , > . > > But i should have like this: RECORD-ROUTE: > , > . > > I tried to do it like: subst_uri('/mtsbc.test.com:5061;transport=tls/xxx.xxx.xxx.xxxx:5060/i'); > but it does not match. > > > thank you > miha > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus **  |   Practice Index Reviews * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. *Our new office address: 22 Riduna Park, Melton IP12 1QT.* X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carsten at ng-voice.com Mon May 17 08:38:44 2021 From: carsten at ng-voice.com (Carsten Bock) Date: Mon, 17 May 2021 10:38:44 +0200 Subject: [OpenSIPS-Users] OpenSIPS 2021 planning In-Reply-To: <2b5987a5-84af-d56c-c12b-338d4e2b5c50@opensips.org> References: <2a3b7dd0-a1c4-8333-f1c2-6dab6cf5eba6@opensips.org> <2b5987a5-84af-d56c-c12b-338d4e2b5c50@opensips.org> Message-ID: Hi, just a quick note: I have some patches in the pipeline and I will publish a PR hopefully this week. The changes are on the b2bua module and add the following functionality: - server_address may contain pseudo-variables (e.g. "modparam("b2b_logic", "server_address", "sip:$rU@ $socket_in(advertised_ip):$socket_in(advertised_port)")") - dlg_bridge can be used on early dialogs - this will trigger an UPDATE (this may not work in all scenarios, so this can be disabled) - bug-fix: the contact for 200 OK after dlg_bridge could contain a wrong contact header (e.g. if it was received on a different interface than the initial dialog) - new config function "b2b_trigger_scenario" to trigger a scenario from the script (we need to process multiple REFERs in one single dialog) After going successfully through our QA process, I still need to do a bit of documentation. I hope this makes it into the 3.2 release. Thanks, Carsten -- Carsten Bock I CTO & Founder ng-voice GmbH Trostbrücke 1 I 20457 Hamburg I Germany T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com Registry Office at Local Court Hamburg, HRB 120189 Managing Directors: Dr. David Bachmann, Carsten Bock Am Fr., 14. Mai 2021 um 12:20 Uhr schrieb Bogdan-Andrei Iancu < bogdan at opensips.org>: > Heads up, the date for the OpenSIPS 3.2 major release (beta version) is > set for 27th of May 2021 !! > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp 2021 online > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 3/30/21 2:06 PM, Bogdan-Andrei Iancu wrote: > > Hi OpenSIPS'ers! > > > > We all do plans in advance and the most helpful thing here is to know > > what to expect, what to rely on, what upcoming events are. > > > > Well, we want to help all the OpenSIPS’ers and share with you the 2021 > > calendar for OpenSIPS project, with the most relevant events. > > > > So, please check > > https://blog.opensips.org/2021/03/30/opensips-calendar-for-2021/ > > > > > > Happy planning, > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Mon May 17 12:55:13 2021 From: miha at softnet.si (Miha) Date: Mon, 17 May 2021 14:55:13 +0200 Subject: [OpenSIPS-Users] TLS to UDP, record route In-Reply-To: References: <25150991-e74a-60f9-8ab1-732ca171035b@softnet.si> Message-ID: thank you. Anther thing, when you got ACK, how opensips route it, how it will choose right interface? Initial invite is send via tls to ms teams by opensips. But ACK which I get from another SBC is routed via UDP and not TLS? Where i should look for this issue? thank you miha U Opensips:5060 -> Another_SBC(Not opensips):5060 #5 SIP/2.0 200 OK. FROM: ;tag=3830244708-1542214291. TO: ;tag=797d0c0c74c94df5abf29cc5ba182311. CSEQ: 1 INVITE. CALL-ID: 16826581-3830244708-1607573954 at sbc2.test.com. VIA: SIP/2.0/UDP Another_SBC(Not opensips):5060;branch=z9hG4bK4c6433227c52d1863c051b23a170706e. RECORD-ROUTE: ,,. CONTACT: . Content-Length: 309. SUPPORTED: timer. CONTENT-TYPE: application/sdp. ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY. REQUIRE: timer. SESSION-EXPIRES: 3600;refresher=uac. SERVER: Microsoft.PSTNHub.SIPProxy v.2021.5.5.15 i.EUWE.3. U  Another_SBC(Not opensips):5060 -> Opensips:5060 #6 ACK sip:52.114.75.24:5061;x-i=d1df8c6c-2e6c-44b8-b670-de5b94e4b93e;x-c=e6e92b7127765ed3843b370d59046d54/s/1/6cff2c6f65024a6b86a5c5f3794202a5 SIP/2.0. Max-Forwards: 68. Route: . Route: . Route: . To: ;tag=797d0c0c74c94df5abf29cc5ba182311. From: ;tag=3830244708-1542214291. Call-ID: 16826581-3830244708-1607573954 at sbc2.test.com. CSeq: 1 ACK. Via: SIP/2.0/UDP  Another_SBC(Not opensips):5060;branch=z9hG4bK58b13e244cbca78925b45e9bcc69d3a2. Contact: . Content-Length: 0. . U Opensips:5060 -> 52.114.75.24:5061 #7 ACK sip:52.114.75.24:5061;x-i=d1df8c6c-2e6c-44b8-b670-de5b94e4b93e;x-c=e6e92b7127765ed3843b370d59046d54/s/1/6cff2c6f65024a6b86a5c5f3794202a5 SIP/2.0. Max-Forwards: 67. Route: . Route: . Route: . To: ;tag=797d0c0c74c94df5abf29cc5ba182311. From: ;tag=3830244708-1542214291. Call-ID: 16826581-3830244708-1607573954 at sbc2.test.com. CSeq: 1 ACK. Via: SIP/2.0/UDP Opensips:5060;branch=z9hG4bKed06.0b1dc487.2. Via: SIP/2.0/UDP  Another_SBC(Not opensips):5060;branch=z9hG4bK58b13e244cbca78925b45e9bcc69d3a2. Contact: . Content-Length: 0. Callum Guy je 5/17/2021 ob 10:15 AM napisal: > subst_uri only works on the request uri, try again with subst()! > > > On Mon, 17 May 2021 at 08:58, Miha via Users > wrote: > > Hello > > i need a little help how to chnage RR in responses to UDP GW > (requestes goes via TLS to MS teams). > > So in reply i have like this: >  RECORD-ROUTE: > ,. > > But i should have like this: RECORD-ROUTE: > ,. > > I tried to do it like:  subst_uri('/mtsbc.test.com > :5061;transport=tls/xxx.xxx.xxx.xxxx:5060/i'); > but it does not match. > > > thank you > miha > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > *^0333 332 0000  | x-on.co.uk   | > _**_^ > **^  | > Coronavirus > **^  > | Practice Index Reviews * > > THE ITSPA AWARDS 2020 AND Best > ITSP - Mid Market, Best Software and Best Vertical Solution are trade > marks of the Internet Telephony Services Providers' Association, used > under licence. > > *Our new office address: 22 Riduna Park, Melton IP12 1QT.* > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please > notify X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must > not use, disclose, disseminate, distribute, copy, print or reply to > this email. Views or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the > absence of viruses in this email or any attachments. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quick at smartvox.co.uk Tue May 18 09:15:10 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 18 May 2021 10:15:10 +0100 Subject: [OpenSIPS-Users] TLS to UDP, record route Message-ID: <001a01d74bc6$50fface0$f2ff06a0$@smartvox.co.uk> Miha Altering the text in the Record-Route headers with subst() function is not the correct approach. I believe the problem is that you are not inserting the correct RR headers in the first place. If you get the RR headers right then it will also fix the problem with ACK using the wrong protocol. This pseudo-code snippet illustrates what is required when adding RR headers to the initial INVITE request: if (INVITE-from-Teams-Proxy-to-us) { record_route_preset("IP:port", "SBC_FQDN:5061;transport=tls"); add_rr_param(";r2=on"); } else if (INVITE-from-us-to-Teams-Proxy) { record_route_preset( "SBC_FQDN:5061;transport=tls", "IP:port"); add_rr_param(";r2=on"); } else record_route(); Don't insert any RR headers when handling loose-routed requests. I tried to explain all this stuff in a number of articles. Here are the links: https://kb.smartvox.co.uk/opensips/opensips-as-ms-teams-sbc/ https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-4/ https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explaine d/ John Quick Smartvox Limited From miha at softnet.si Tue May 18 10:56:26 2021 From: miha at softnet.si (Miha) Date: Tue, 18 May 2021 12:56:26 +0200 Subject: [OpenSIPS-Users] TLS to UDP, record route In-Reply-To: <001a01d74bc6$50fface0$f2ff06a0$@smartvox.co.uk> References: <001a01d74bc6$50fface0$f2ff06a0$@smartvox.co.uk> Message-ID: hello John i have found what was causing the issue. is was topology hiding when ACK was received by opensips. thank you for all your help and time :) br miha John Quick je 5/18/2021 ob 11:15 AM napisal: > Miha > > Altering the text in the Record-Route headers with subst() function is not > the correct approach. > I believe the problem is that you are not inserting the correct RR headers > in the first place. > If you get the RR headers right then it will also fix the problem with ACK > using the wrong protocol. > This pseudo-code snippet illustrates what is required when adding RR headers > to the initial INVITE request: > > if (INVITE-from-Teams-Proxy-to-us) { > record_route_preset("IP:port", "SBC_FQDN:5061;transport=tls"); > add_rr_param(";r2=on"); > } else if (INVITE-from-us-to-Teams-Proxy) { > record_route_preset( "SBC_FQDN:5061;transport=tls", "IP:port"); > add_rr_param(";r2=on"); > } else > record_route(); > > Don't insert any RR headers when handling loose-routed requests. > > I tried to explain all this stuff in a number of articles. Here are the > links: > https://kb.smartvox.co.uk/opensips/opensips-as-ms-teams-sbc/ > https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-4/ > https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explaine > d/ > > John Quick > Smartvox Limited > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Tue May 18 10:59:05 2021 From: miha at softnet.si (Miha) Date: Tue, 18 May 2021 12:59:05 +0200 Subject: [OpenSIPS-Users] TLS to UDP, record route In-Reply-To: <001a01d74bc6$50fface0$f2ff06a0$@smartvox.co.uk> References: <001a01d74bc6$50fface0$f2ff06a0$@smartvox.co.uk> Message-ID: <4b2ed05d-f4a9-bd46-b283-5c3c613116dd@softnet.si> btw what is the trick if you have multiple trunks to sbc teams (inbound, outbound)? multiple companies? br miha John Quick je 5/18/2021 ob 11:15 AM napisal: > Miha > > Altering the text in the Record-Route headers with subst() function is not > the correct approach. > I believe the problem is that you are not inserting the correct RR headers > in the first place. > If you get the RR headers right then it will also fix the problem with ACK > using the wrong protocol. > This pseudo-code snippet illustrates what is required when adding RR headers > to the initial INVITE request: > > if (INVITE-from-Teams-Proxy-to-us) { > record_route_preset("IP:port", "SBC_FQDN:5061;transport=tls"); > add_rr_param(";r2=on"); > } else if (INVITE-from-us-to-Teams-Proxy) { > record_route_preset( "SBC_FQDN:5061;transport=tls", "IP:port"); > add_rr_param(";r2=on"); > } else > record_route(); > > Don't insert any RR headers when handling loose-routed requests. > > I tried to explain all this stuff in a number of articles. Here are the > links: > https://kb.smartvox.co.uk/opensips/opensips-as-ms-teams-sbc/ > https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-4/ > https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explaine > d/ > > John Quick > Smartvox Limited > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quick at smartvox.co.uk Tue May 18 11:02:36 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 18 May 2021 12:02:36 +0100 Subject: [OpenSIPS-Users] TLS to UDP, record route In-Reply-To: References: <001a01d74bc6$50fface0$f2ff06a0$@smartvox.co.uk> Message-ID: <001f01d74bd5$5368e6e0$fa3ab4a0$@smartvox.co.uk> Ah, topology hiding changes everything. I did not appreciate that it was involved. John Quick Smartvox Limited From: Miha Sent: 18 May 2021 11:56 To: john.quick at smartvox.co.uk; users at lists.opensips.org Subject: Re: [OpenSIPS-Users] TLS to UDP, record route hello John i have found what was causing the issue. is was topology hiding when ACK was received by opensips. thank you for all your help and time :) br miha John Quick je 5/18/2021 ob 11:15 AM napisal: Miha Altering the text in the Record-Route headers with subst() function is not the correct approach. I believe the problem is that you are not inserting the correct RR headers in the first place. If you get the RR headers right then it will also fix the problem with ACK using the wrong protocol. This pseudo-code snippet illustrates what is required when adding RR headers to the initial INVITE request: if (INVITE-from-Teams-Proxy-to-us) { record_route_preset("IP:port", "SBC_FQDN:5061;transport=tls"); add_rr_param(";r2=on"); } else if (INVITE-from-us-to-Teams-Proxy) { record_route_preset( "SBC_FQDN:5061;transport=tls", "IP:port"); add_rr_param(";r2=on"); } else record_route(); Don't insert any RR headers when handling loose-routed requests. I tried to explain all this stuff in a number of articles. Here are the links: https://kb.smartvox.co.uk/opensips/opensips-as-ms-teams-sbc/ https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-4/ https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explaine d/ John Quick Smartvox Limited From john.quick at smartvox.co.uk Tue May 18 11:07:49 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 18 May 2021 12:07:49 +0100 Subject: [OpenSIPS-Users] TLS to UDP, record route In-Reply-To: <4b2ed05d-f4a9-bd46-b283-5c3c613116dd@softnet.si> References: <001a01d74bc6$50fface0$f2ff06a0$@smartvox.co.uk> <4b2ed05d-f4a9-bd46-b283-5c3c613116dd@softnet.si> Message-ID: <002201d74bd6$0d9ac3d0$28d04b70$@smartvox.co.uk> The client I was working with used this: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants I touched on the topic in my article about MS Teams, under the heading "Terminology and multi-tenant solutions" John Quick Smartvox Limited > From: Miha > Sent: 18 May 2021 11:59 > To: john.quick at smartvox.co.uk; users at lists.opensips.org > Subject: Re: [OpenSIPS-Users] TLS to UDP, record route > > btw what is the trick if you have multiple trunks to sbc teams (inbound, outbound)? multiple companies? > > miha From homstr at gmail.com Tue May 18 11:23:48 2021 From: homstr at gmail.com (Alexey Hamstr) Date: Tue, 18 May 2021 13:23:48 +0200 Subject: [OpenSIPS-Users] Config script - Opensips + RTPProxy + Freeswitch on EC2 In-Reply-To: References: Message-ID: Hi. For example, you can try this book... ---- "Building Telephony Systems with OpenSIPS - Second Edition" https://www.amazon.com/Building-Telephony-Systems-OpenSIPS-Second/dp/1785280619 Regards, Alexey Borisov. пн, 17 мая 2021 г. в 09:23, HS : > Hi all. > > I keep writing from time to time asking for help as a newbie to Opensips. > Somehow trial and error makes things work. I wanted to know if there's a > book/tutorial available to understand how the .cfg file and script works > and all the variables involved. Specifically trying to do the following on > an Amazon EC2 setup: > > 1. Call centre implementation (I have the modules etc. setup), > 2. Enable IVR, > 3. Enable Conferencing, > 4. Enable Voicemail, > 5. Enable Push Notifications. > > I understand a lot of it has to do with Freeswitch (I have read the old > tutorial) - and would like to understand how the routing aspect would work. > > Thanks again. > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miha at softnet.si Tue May 18 11:25:59 2021 From: miha at softnet.si (miha at softnet.si) Date: Tue, 18 May 2021 13:25:59 +0200 Subject: [OpenSIPS-Users] TLS to UDP, record route In-Reply-To: <002201d74bd6$0d9ac3d0$28d04b70$@smartvox.co.uk> References: <001a01d74bc6$50fface0$f2ff06a0$@smartvox.co.uk> <4b2ed05d-f4a9-bd46-b283-5c3c613116dd@softnet.si> <002201d74bd6$0d9ac3d0$28d04b70$@smartvox.co.uk> Message-ID: <9b247edf-1e90-445d-8460-15d8b1807e44@Spark> Thank you I will check. Br miha On 18 May 2021, 13:08 +0200, John Quick , wrote: > The client I was working with used this: > https://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants > > I touched on the topic in my article about MS Teams, under the heading "Terminology and multi-tenant solutions" > > John Quick > Smartvox Limited > > > From: Miha > > Sent: 18 May 2021 11:59 > > To: john.quick at smartvox.co.uk; users at lists.opensips.org > > Subject: Re: [OpenSIPS-Users] TLS to UDP, record route > > > > btw what is the trick if you have multiple trunks to sbc teams (inbound, outbound)? multiple companies? > > > > miha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bullehs at gmail.com Tue May 18 12:49:18 2021 From: bullehs at gmail.com (HS) Date: Tue, 18 May 2021 17:49:18 +0500 Subject: [OpenSIPS-Users] Config script - Opensips + RTPProxy + Freeswitch on EC2 In-Reply-To: References: Message-ID: Hi Alexey. Thanks a lot for taking the time to respond. Incidentally, I had read the book a few months ago and took a look at it again yesterday. It has good details on scripting and integrating with Asterisk. Will have to do some trial-and-error, as usual. Thanks again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From homstr at gmail.com Tue May 18 13:08:38 2021 From: homstr at gmail.com (Alexey Hamstr) Date: Tue, 18 May 2021 15:08:38 +0200 Subject: [OpenSIPS-Users] Config script - Opensips + RTPProxy + Freeswitch on EC2 In-Reply-To: References: Message-ID: Yes... I would say "TRY-AND-CRY".... there is a usual method to work with SIPS (IMHO) Regards, Alexey. вт, 18 мая 2021 г. в 14:51, HS : > Hi Alexey. > > Thanks a lot for taking the time to respond. Incidentally, I had read the > book a few months ago and took a look at it again yesterday. It has good > details on scripting and integrating with Asterisk. Will have to do some > trial-and-error, as usual. > > Thanks again. > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpaivaa at gmail.com Tue May 18 13:35:01 2021 From: tpaivaa at gmail.com (Tomi Hakkarainen) Date: Tue, 18 May 2021 16:35:01 +0300 Subject: [OpenSIPS-Users] Config script - Opensips + RTPProxy + Freeswitch on EC2 In-Reply-To: References: Message-ID: Hi, I have to disagree as have not even once cried when learning SIPping ;) past decade. But I agree that its the best way to learn properly, at least for me, learn by doing. And some times it will help to understand config logic better if you can understand the source code. One more thing I have found very useful is when you’ve bee banging your head against wall try to explain your problem to someone it might reveal something you have not thought by your self earlier… ( When you do this prepare to found out new feelings about how stupid I am not thought this at first place etc...) Tomi On 18. May 2021, at 16.08, Alexey Hamstr wrote: Yes... I would say "TRY-AND-CRY".... there is a usual method to work with SIPS (IMHO) Regards, Alexey. вт, 18 мая 2021 г. в 14:51, HS >: Hi Alexey. Thanks a lot for taking the time to respond. Incidentally, I had read the book a few months ago and took a look at it again yesterday. It has good details on scripting and integrating with Asterisk. Will have to do some trial-and-error, as usual. Thanks again. _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From homstr at gmail.com Tue May 18 14:12:13 2021 From: homstr at gmail.com (Alexey Hamstr) Date: Tue, 18 May 2021 16:12:13 +0200 Subject: [OpenSIPS-Users] DLG_lifetime is empty In-Reply-To: References: Message-ID: I have found that the $DLG_lifetime variable belongs to the dialog module, but I was using the B2B_logic module with topology_hidding option, which creates its own dialogs... so when a started to use the topology_hidding module the $DLG_lifetime variable started to work as expected... Regards, Alexey вт, 11 мая 2021 г. в 14:07, Alexey Hamstr : > Hi All. > I'am trying to setup RADIUS accounting and i want to fill in the > Acct-Session-Time by $DLG_lifetime in STOP call as i have found in the > list archive > http://lists.opensips.org/pipermail/users/2010-August/014120.html > but I see that this pseudo variable is null. > Can anybody advise me how i can do that? Any help will be appreciated. > > Regards, Alexey. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quick at smartvox.co.uk Tue May 18 14:20:40 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 18 May 2021 15:20:40 +0100 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli Message-ID: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> The mi commands for the drouting module are not appearing in the list of allowed mi commands in opensips-cli. I'm looking for things like dr_reload, dr_gw_status, etc. Some of the commands that were available in opensipsctl, I am struggling to find the equivalent available in opensips-cli: "show" commands for address, domain, db etc. Now there is only "dump" Commands to manipulate or show the data used in the alias_db module Commands to add data to domain, drouting, address Are these now done using the database command in the cli? If so, please could someone post a few examples as I don't get the command format or help. Just a reminder - I posted to this forum on 5th May that "opensips-cli>database create" crashes if the username given in opensips-cli.cfg is anything other than opensips Not had any response. Do I need to post somewhere else? John Quick Smartvox Limited From kingsley at dns99.co.uk Tue May 18 14:37:43 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 18 May 2021 15:37:43 +0100 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> Message-ID: <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> Does "opensips-cli -x mi which" do what you want? Cheers, Kingsley. On Tue, 2021-05-18 at 15:20 +0100, John Quick wrote: > The mi commands for the drouting module are not appearing in the list of > allowed mi commands in opensips-cli. > I'm looking for things like dr_reload, dr_gw_status, etc. > > Some of the commands that were available in opensipsctl, I am struggling to > find the equivalent available in opensips-cli: > "show" commands for address, domain, db etc. Now there is only "dump" > Commands to manipulate or show the data used in the alias_db module > Commands to add data to domain, drouting, address > > Are these now done using the database command in the cli? If so, please > could someone post a few examples as I don't get the command format or help. > > Just a reminder - I posted to this forum on 5th May that > "opensips-cli>database create" crashes if the username given in > opensips-cli.cfg is anything other than opensips > Not had any response. Do I need to post somewhere else? > > John Quick > Smartvox Limited > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From john.quick at smartvox.co.uk Tue May 18 14:43:56 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 18 May 2021 15:43:56 +0100 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> Message-ID: <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> Unfortunately no. It just re-iterates the list that I was already looking at where I could not find any commands for the drouting module or to do the other operations I reported as missing. John Quick Smartvox Limited -----Original Message----- From: Kingsley Tart Sent: 18 May 2021 15:38 To: john.quick at smartvox.co.uk; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Some mi commands missing in opensips-cli Does "opensips-cli -x mi which" do what you want? Cheers, Kingsley. From kingsley at dns99.co.uk Tue May 18 14:46:46 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 18 May 2021 15:46:46 +0100 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> Message-ID: <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> Interesting. When I do it (with OpenSIPS 3.1.2), I get the below, with the dr_* commands listed: # opensips-cli -x mi which [ "get_statistics", "list_statistics", "reset_statistics", "uptime", "version", "pwd", "arg", "which", "ps", "kill", "log_level", "xlog_level", "shm_check", "cache_store", "cache_fetch", "cache_remove", "event_subscribe", "events_list", "subscribers_list", "raise_event", "list_tcp_conns", "mem_pkg_dump", "mem_shm_dump", "mem_rpm_dump", "reload_routes", "help", "list_blacklists", "t_uac_dlg", "t_uac_cancel", "t_hash", "t_reply", "dlg_list", "dlg_list_ctx", "dlg_end_dlg", "dlg_db_sync", "dlg_restore_db", "dlg_cluster_sync", "profile_get_size", "profile_list_dlgs", "profile_get_values", "list_all_profiles", "profile_end_dlgs", "dlg_push_var", "dlg_send_sequential", "address_reload", "address_dump", "subnet_dump", "allow_uri", "dr_reload", "dr_gw_status", "dr_carrier_status", "dr_number_routing", "dr_reload_status", "dr_enable_probing", "dp_reload", "dp_translate", "dp_show_partition", "cache_remove_chunk", "regex_reload" ] Cheers, Kingsley. On Tue, 2021-05-18 at 15:43 +0100, John Quick wrote: > Unfortunately no. > It just re-iterates the list that I was already looking at where I > could not find any commands for the drouting module or to do the > other operations I reported as missing. > > John Quick > Smartvox Limited > > > -----Original Message----- > From: Kingsley Tart > Sent: 18 May 2021 15:38 > To: john.quick at smartvox.co.uk; OpenSIPS users mailling list < > users at lists.opensips.org> > Subject: Re: [OpenSIPS-Users] Some mi commands missing in opensips- > cli > > Does "opensips-cli -x mi which" do what you want? > > Cheers, > Kingsley. > From liviu at opensips.org Tue May 18 14:51:43 2021 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 18 May 2021 17:51:43 +0300 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> Message-ID: <60f0b50c-ddf7-1c0a-996c-768d6ff288be@opensips.org> On 18.05.2021 17:46, Kingsley Tart wrote: > Interesting. When I do it (with OpenSIPS 3.1.2), I get the below, with > the dr_* commands listed: Hello, gents! That is because the "which" command has /dynamic /output, effectively /learning/ the loaded modules your OpenSIPS has, and only then listing the commands that it supports!  This way, we avoid code duplication of all MI Commands also in the OpenSIPS CLI project, which would be a complete nightmare to maintain. Moreover, this also saves us work going into the future, where developers will submit all kinds of new MI commands for approval, without anybody having to worry about: "what do they/I have to do so this command also works with the CLI?" Cheers, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS eBootcamp 2021 | www.opensips.org/training -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue May 18 14:52:46 2021 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 18 May 2021 17:52:46 +0300 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> Message-ID: On 18.05.2021 17:20, John Quick wrote: > Some of the commands that were available in opensipsctl, I am struggling to > find the equivalent available in opensips-cli: > "show" commands for address, domain, db etc. Now there is only "dump" > Commands to manipulate or show the data used in the alias_db module > Commands to add data to domain, drouting, address Hi, John! Instead of "ul show", you can now run "mi ul_dump", which is equivalent. DB provisioning via "opensips-cli" has never been there and the subject has been debated here [1].  In short: the plan is to solely rely on the Control Panel for the provisioning, giving the finite amount of code maintenance power that's available.  This way, each tool does what it's best at. Best Regards, [1]: https://github.com/OpenSIPS/opensips-cli/issues/20 -- Liviu Chircu www.twitter.com/liviuchircu |www.opensips-solutions.com OpenSIPS eBootcamp 2021 |www.opensips.org/training From john.quick at smartvox.co.uk Tue May 18 14:52:49 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 18 May 2021 15:52:49 +0100 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> Message-ID: <002f01d74bf5$7bf51910$73df4b30$@smartvox.co.uk> How curious. I wonder what is different about your config and mine. Here is my opensips-cli.cfg. Can you see anything wrong please? Or perhaps it is linked to the opensips.cfg script - I load the drouting module, but might not actually call any of the functions [default] log_level: WARNING prompt_intro: Hello mate prompt_name: osipscli-local database_url: mysql://opensips:@localhost database_name: opensips_v3 database_modules: acc alias_db auth_db avpops domain dialog drouting group permissions clusterer rtpproxy rtpengine tls_mgm usrloc registrant tracer fraud_detection freeswitch_scripting John Quick Smartvox Limited -----Original Message----- From: Kingsley Tart Sent: 18 May 2021 15:47 To: john.quick at smartvox.co.uk; 'OpenSIPS users mailling list' Subject: Re: [OpenSIPS-Users] Some mi commands missing in opensips-cli Interesting. When I do it (with OpenSIPS 3.1.2), I get the below, with the dr_* commands listed: # opensips-cli -x mi which [ "get_statistics", "list_statistics", "reset_statistics", "uptime", "version", "pwd", "arg", "which", "ps", "kill", "log_level", "xlog_level", "shm_check", "cache_store", "cache_fetch", "cache_remove", "event_subscribe", "events_list", "subscribers_list", "raise_event", "list_tcp_conns", "mem_pkg_dump", "mem_shm_dump", "mem_rpm_dump", "reload_routes", "help", "list_blacklists", "t_uac_dlg", "t_uac_cancel", "t_hash", "t_reply", "dlg_list", "dlg_list_ctx", "dlg_end_dlg", "dlg_db_sync", "dlg_restore_db", "dlg_cluster_sync", "profile_get_size", "profile_list_dlgs", "profile_get_values", "list_all_profiles", "profile_end_dlgs", "dlg_push_var", "dlg_send_sequential", "address_reload", "address_dump", "subnet_dump", "allow_uri", "dr_reload", "dr_gw_status", "dr_carrier_status", "dr_number_routing", "dr_reload_status", "dr_enable_probing", "dp_reload", "dp_translate", "dp_show_partition", "cache_remove_chunk", "regex_reload" ] Cheers, Kingsley. On Tue, 2021-05-18 at 15:43 +0100, John Quick wrote: > Unfortunately no. > It just re-iterates the list that I was already looking at where I > could not find any commands for the drouting module or to do the other > operations I reported as missing. > > John Quick > Smartvox Limited > > > -----Original Message----- > From: Kingsley Tart > Sent: 18 May 2021 15:38 > To: john.quick at smartvox.co.uk; OpenSIPS users mailling list < > users at lists.opensips.org> > Subject: Re: [OpenSIPS-Users] Some mi commands missing in opensips- > cli > > Does "opensips-cli -x mi which" do what you want? > > Cheers, > Kingsley. > From john.quick at smartvox.co.uk Tue May 18 14:59:25 2021 From: john.quick at smartvox.co.uk (John Quick) Date: Tue, 18 May 2021 15:59:25 +0100 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <60f0b50c-ddf7-1c0a-996c-768d6ff288be@opensips.org> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> <60f0b50c-ddf7-1c0a-996c-768d6ff288be@opensips.org> Message-ID: <003001d74bf6$68978f00$39c6ad00$@smartvox.co.uk> Damn. I was sure I’d loaded the drouting module, but now I checked and find I haven’t. Doh! Juggling too many scripts in my head. Liviu, and now you’ve also answered the second part of my question. Thanks. What about the crashing if you try to create a DB with any username except opensips? John Quick Smartvox Limited From: Liviu Chircu Sent: 18 May 2021 15:52 To: OpenSIPS users mailling list ; Kingsley Tart ; john.quick at smartvox.co.uk Subject: Re: [OpenSIPS-Users] Some mi commands missing in opensips-cli On 18.05.2021 17:46, Kingsley Tart wrote: Interesting. When I do it (with OpenSIPS 3.1.2), I get the below, with the dr_* commands listed: Hello, gents! That is because the "which" command has dynamic output, effectively learning the loaded modules your OpenSIPS has, and only then listing the commands that it supports! This way, we avoid code duplication of all MI Commands also in the OpenSIPS CLI project, which would be a complete nightmare to maintain. Moreover, this also saves us work going into the future, where developers will submit all kinds of new MI commands for approval, without anybody having to worry about: "what do they/I have to do so this command also works with the CLI?" Cheers, -- Liviu Chircu http://www.twitter.com/liviuchircu | http://www.opensips-solutions.com OpenSIPS eBootcamp 2021 | http://www.opensips.org/training From kingsley at dns99.co.uk Tue May 18 15:05:38 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 18 May 2021 16:05:38 +0100 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <002f01d74bf5$7bf51910$73df4b30$@smartvox.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> <002f01d74bf5$7bf51910$73df4b30$@smartvox.co.uk> Message-ID: <7e11a0b7355e1f4f1c550660528c01604e386aa3.camel@dns99.co.uk> Hi, I don't have a separate opensips-cli.cfg file on my system and I've never written one so I wouldn't know whether there's anything wrong with yours. In /etc/opensips there is just this: # ls -l total 36 -rw-r--r-- 1 root root 27561 May 18 15:53 opensips.cfg -rw-r--r-- 1 root root 3751 Mar 2 17:26 opensipsctlrc -rw-r--r-- 1 root root 353 Nov 17 13:45 scenario_callcenter.xml Nothing special in opensips.cfg. I only added the partition stuff recently but I was getting the dr_* commands listed before as well: loadmodule "drouting.so" modparam("drouting", "db_url", "mysql://opensips:@localhost/opensips") modparam("drouting", "probing_interval", 15) modparam("drouting", "use_partitions", 1) modparam("drouting", "db_partitions_url", "mysql://opensips:@localhost/opensips") modparam("drouting", "db_partitions_table", "dr_partitions") Does opensips-cli.cfg need to have a DB module listed as well? Is it listing commands from other modules that require a DB module? Cheers, Kingsley. On Tue, 2021-05-18 at 15:52 +0100, John Quick wrote: > How curious. I wonder what is different about your config and mine. > Here is my opensips-cli.cfg. Can you see anything wrong please? > Or perhaps it is linked to the opensips.cfg script - I load the > drouting module, but might not actually call any of the functions > > [default] > log_level: WARNING > prompt_intro: Hello mate > prompt_name: osipscli-local > database_url: mysql://opensips:@localhost > database_name: opensips_v3 > database_modules: acc alias_db auth_db avpops domain dialog drouting > group permissions clusterer rtpproxy rtpengine tls_mgm usrloc > registrant tracer fraud_detection freeswitch_scripting > > John Quick > Smartvox Limited > > > -----Original Message----- > From: Kingsley Tart > Sent: 18 May 2021 15:47 > To: john.quick at smartvox.co.uk; 'OpenSIPS users mailling list' < > users at lists.opensips.org> > Subject: Re: [OpenSIPS-Users] Some mi commands missing in opensips- > cli > > Interesting. When I do it (with OpenSIPS 3.1.2), I get the below, > with the dr_* commands listed: > > # opensips-cli -x mi which > [ > "get_statistics", > "list_statistics", > "reset_statistics", > "uptime", > "version", > "pwd", > "arg", > "which", > "ps", > "kill", > "log_level", > "xlog_level", > "shm_check", > "cache_store", > "cache_fetch", > "cache_remove", > "event_subscribe", > "events_list", > "subscribers_list", > "raise_event", > "list_tcp_conns", > "mem_pkg_dump", > "mem_shm_dump", > "mem_rpm_dump", > "reload_routes", > "help", > "list_blacklists", > "t_uac_dlg", > "t_uac_cancel", > "t_hash", > "t_reply", > "dlg_list", > "dlg_list_ctx", > "dlg_end_dlg", > "dlg_db_sync", > "dlg_restore_db", > "dlg_cluster_sync", > "profile_get_size", > "profile_list_dlgs", > "profile_get_values", > "list_all_profiles", > "profile_end_dlgs", > "dlg_push_var", > "dlg_send_sequential", > "address_reload", > "address_dump", > "subnet_dump", > "allow_uri", > "dr_reload", > "dr_gw_status", > "dr_carrier_status", > "dr_number_routing", > "dr_reload_status", > "dr_enable_probing", > "dp_reload", > "dp_translate", > "dp_show_partition", > "cache_remove_chunk", > "regex_reload" > ] > > Cheers, > Kingsley. > > On Tue, 2021-05-18 at 15:43 +0100, John Quick wrote: > > Unfortunately no. > > It just re-iterates the list that I was already looking at where I > > could not find any commands for the drouting module or to do the > > other > > operations I reported as missing. > > > > John Quick > > Smartvox Limited > > > > > > -----Original Message----- > > From: Kingsley Tart > > Sent: 18 May 2021 15:38 > > To: john.quick at smartvox.co.uk; OpenSIPS users mailling list < > > users at lists.opensips.org> > > Subject: Re: [OpenSIPS-Users] Some mi commands missing in > > opensips- > > cli > > > > Does "opensips-cli -x mi which" do what you want? > > > > Cheers, > > Kingsley. > > > > From kingsley at dns99.co.uk Tue May 18 15:06:17 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Tue, 18 May 2021 16:06:17 +0100 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <003001d74bf6$68978f00$39c6ad00$@smartvox.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> <60f0b50c-ddf7-1c0a-996c-768d6ff288be@opensips.org> <003001d74bf6$68978f00$39c6ad00$@smartvox.co.uk> Message-ID: I know that feeling ;) Cheers, Kingsley. On Tue, 2021-05-18 at 15:59 +0100, John Quick wrote: > Damn. I was sure I’d loaded the drouting module, but now I checked > and find I haven’t. Doh! > Juggling too many scripts in my head. From liviu at opensips.org Tue May 18 15:09:08 2021 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 18 May 2021 18:09:08 +0300 Subject: [OpenSIPS-Users] Some mi commands missing in opensips-cli In-Reply-To: <003001d74bf6$68978f00$39c6ad00$@smartvox.co.uk> References: <002b01d74bf0$feffa500$fcfeef00$@smartvox.co.uk> <65cd6b9d2428a535174d0162843b1974614fd3aa.camel@dns99.co.uk> <002c01d74bf4$3f0fea30$bd2fbe90$@smartvox.co.uk> <063fa09cc52f1d11795b792551dc89e1856c0891.camel@dns99.co.uk> <60f0b50c-ddf7-1c0a-996c-768d6ff288be@opensips.org> <003001d74bf6$68978f00$39c6ad00$@smartvox.co.uk> Message-ID: <07517dda-3ef5-7e41-8f10-50e533c56f23@opensips.org> On 18.05.2021 17:59, John Quick wrote: > What about the crashing if you try to create a DB with any username except opensips? I expect to find time to look into that very soon after the 3.2 beta release, if no one takes the lead, of course :) -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS eBootcamp 2021 | www.opensips.org/training From ti.jcarranza at gmail.com Tue May 18 23:09:51 2021 From: ti.jcarranza at gmail.com (Julio Carranza) Date: Tue, 18 May 2021 18:09:51 -0500 Subject: [OpenSIPS-Users] How to know how many workers configure / server support Message-ID: Im using "OpenSIPS (3.1.1 (x86_64/linux))" on a server with: 128GB on RAM 2x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz (32 cores) Basically is a redirect server with some logic configured, using mysql only to load configuration and redis to store some data, but with 32 workers configured i receive this messages on cli: Process 24 load: 100%, 99%, 99% (SIP receiver udp:XX.79.X.XX:5060) Process 25 load: 100%, 99%, 99% (SIP receiver udp:XX.79.X.XX:5060) Process 26 load: 100%, 99%, 99% (SIP receiver udp:XX.79.X.XX:5060) WARNING: the receive queue is NOT empty, SIP signaling may be slower! CRITICAL: 100% avg. currently used worker capacity!! Suggestion: see the DNS/SQL/NoSQL diagnosis for any slow query reports, otherwise increase 'use_workers' or 'udp_workers'! But when i see *htop* information the server is using few resources less than 2.0 of load average. As a first solution I already increased the number of workers to 200 but the question is, how to know how many workers can I configure or which is the best practice for this. (how is a worker internal behavior) I couldn't find deep information of this on documentation thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at nemeroff.com Wed May 19 00:56:02 2021 From: brett at nemeroff.com (Brett Nemeroff) Date: Tue, 18 May 2021 19:56:02 -0500 Subject: [OpenSIPS-Users] How to know how many workers configure / server support In-Reply-To: References: Message-ID: It really depends on your application but I suspect that 200 is overkill. What CPS are you running? What else is this server doing besides OpenSIPS? Is your db on the same server? How fast are those queries returning? The server is spinning doing something. How’s your disk IO look? I’ve seen very high rate of logging so this. If you remove traffic, does load go back to 0? On Tue, May 18, 2021 at 6:10 PM Julio Carranza wrote: > Im using "OpenSIPS (3.1.1 (x86_64/linux))" on a server with: > 128GB on RAM > 2x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz (32 cores) > > Basically is a redirect server with some logic configured, using mysql > only to load configuration and redis to store some data, but with 32 > workers configured i receive this messages on cli: > > Process 24 load: 100%, 99%, 99% (SIP receiver udp:XX.79.X.XX:5060) > Process 25 load: 100%, 99%, 99% (SIP receiver udp:XX.79.X.XX:5060) > Process 26 load: 100%, 99%, 99% (SIP receiver udp:XX.79.X.XX:5060) > > WARNING: the receive queue is NOT empty, SIP signaling may be slower! > CRITICAL: 100% avg. currently used worker capacity!! > > Suggestion: see the DNS/SQL/NoSQL diagnosis for any slow query > reports, otherwise increase 'use_workers' or 'udp_workers'! > > But when i see *htop* information the server is using few resources less > than 2.0 of load average. > > As a first solution I already increased the number of workers to 200 but > the question is, how to know how many workers can I configure or which is > the best practice for this. (how is a worker internal behavior) > > I couldn't find deep information of this on documentation > > > thanks in advance > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xaled at web.de Wed May 19 11:30:16 2021 From: xaled at web.de (xaled at web.de) Date: Wed, 19 May 2021 13:30:16 +0200 Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine In-Reply-To: <15a401d748b4$fb1b9140$f152b3c0$@web.de> References: <15a401d748b4$fb1b9140$f152b3c0$@web.de> Message-ID: <02b701d74ca2$574e6f50$05eb4df0$@web.de> Hi Would appreciate any hints on how to run the new 3.2 B2B module with RTPProxy or RTPEngine. Thanks, Xaled -----Original Message----- From: Users On Behalf Of xaled at web.de Sent: Friday, May 14, 2021 1:34 PM To: 'OpenSIPS users mailling list' Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine Hi, Are the any examples of using the new B2B module in 3.2 with RTPProxy or RTPEngine? I tried adding _offer and _answer call accordingly but never saw RTPProxy or RTPEngine engaged. Even a simple example for A-B call with B2B and RTPEngine would be much appreciated. Thanks, Xaled _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From sunil.more64sinfo at gmail.com Thu May 20 10:25:07 2021 From: sunil.more64sinfo at gmail.com (Sunil More) Date: Thu, 20 May 2021 15:55:07 +0530 Subject: [OpenSIPS-Users] STIR/Shaken payload issue. Message-ID: <2EE8ACE7-007E-4913-B718-B839147714F9@hxcore.ol> An HTML attachment was scrubbed... URL: From kneeoh at yahoo.com Thu May 20 18:29:22 2021 From: kneeoh at yahoo.com (Kneeoh) Date: Thu, 20 May 2021 11:29:22 -0700 (MST) Subject: [OpenSIPS-Users] Stir/Shaken Certificate Failed to Load Message-ID: <1621535362743-0.post@n2.nabble.com> Hi, following the docs and blog post here: https://opensips.org/docs/modules/3.1.x/stir_shaken.html and here: https://blog.opensips.org/2020/01/23/shaken-not-stirred/ I'm getting an error regarding certificate parsing and loading. I'm guessing it's got to do with how I'm loading the certs. I just want to see if I can make it add the identity header and this is a test run so it's just a simple hard code: # Do Stir/Shaken Signing $var(cert) = "/home/homey/key.pem-public.pem"; $var(privKey) = "/home/homey/private_key.pem"; stir_shaken_auth("A", "$ci", "$var(cert)", "$var(privKey)", "https://certs.example.org/cert.pem"); results in no identity header and the following in the logs: May 20 18:16:10 stir-shaken /usr/local/sbin/opensips[65744]: ERROR:stir_shaken:load_cert: Failed to parse certificate May 20 18:16:10 stir-shaken /usr/local/sbin/opensips[65744]: ERROR:stir_shaken:w_stir_auth: Failed to load certificate Any guidance would be appreciated. -- Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html From kurgan-rus at inbox.ru Fri May 21 06:00:46 2021 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Fri, 21 May 2021 09:00:46 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?GSM-gates_in_Brazil?= Message-ID: <1621576846.204140873@f335.i.mail.ru> Hi all,   I’m sure there are VoIP engineers from South America (Brazil preferably) among us.   If anybody knows where it’s possible to find VoIP equipment of Yeastar/Neogate/Leucotron vendors, please send me an e-mail.   I’m located on the other continent and it’s not so easy to find what I need.   ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Fri May 21 06:26:51 2021 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Fri, 21 May 2021 09:26:51 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?How_to_know_how_many_workers_configure?= =?utf-8?q?_/_server_support?= Message-ID: <1621578411.26509806@f528.i.mail.ru> Hello Julio, there was an article [1] in OpenSIPS Blog which may be helpful.   [1]:  https://blog.opensips.org/2019/02/25/auto-process-scaling-a-cure-for-load-and-resources-concerns/     ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From E75A4669 at exemail.com.au Fri May 21 06:41:07 2021 From: E75A4669 at exemail.com.au (Alexander Jankowsky) Date: Fri, 21 May 2021 16:11:07 +0930 Subject: [OpenSIPS-Users] GSM-gates in Brazil In-Reply-To: <1621576846.204140873@f335.i.mail.ru> References: <1621576846.204140873@f335.i.mail.ru> Message-ID: <000c01d74e0c$47c18d40$d744a7c0$@exemail.com.au> Hello Alexey, https://www.leucotron.com.br/ https://www.yeastar.com/ https://www.thetelecomshop.com/au/manufacturer/neogate Exactly what kind of equipment are you after? For what purposes? Only new equipment or old retired equipment for compatibility testing? Is this simply a language problem with reading the local vendors pages? Where exactly is this “other continent” you are in? Where are you located? Are you planning a major roll out or just compatibility issues to resolve? Alex From: Users [mailto:users-bounces at lists.opensips.org] On Behalf Of Alexey Kazantsev via Users Sent: Friday, 21 May 2021 3:31 PM To: users at lists.opensips.org Subject: [OpenSIPS-Users] GSM-gates in Brazil Hi all, I’m sure there are VoIP engineers from South America (Brazil preferably) among us. If anybody knows where it’s possible to find VoIP equipment of Yeastar/Neogate/Leucotron vendors, please send me an e-mail. I’m located on the other continent and it’s not so easy to find what I need. ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bullehs at gmail.com Fri May 21 10:00:28 2021 From: bullehs at gmail.com (HS) Date: Fri, 21 May 2021 15:00:28 +0500 Subject: [OpenSIPS-Users] Config script - Opensips + RTPProxy + Freeswitch on EC2 In-Reply-To: References: Message-ID: This made me laugh (Try-and-cry)! However, agree completely with Tomi. A lot of the times, people don't respond here - but typing stuff out helps loads. So calls are going through to the IVR and conference. But having the usual issues: 1. IVR/calls to Freeswitch disconnect after 30s. 2. Unsure if users are being pulled from the database or the profiles. 3. DTMF input isn't working (system doesn't respond to input.) So far so good :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingsley at dns99.co.uk Fri May 21 10:44:28 2021 From: kingsley at dns99.co.uk (Kingsley Tart) Date: Fri, 21 May 2021 11:44:28 +0100 Subject: [OpenSIPS-Users] coding style / {param.exists, name} and {param.value, name} Message-ID: <217bbb277efc12a7453de48623d1f042bc3946cb.camel@dns99.co.uk> Hi, Is one of these methods specifically preferred over another? The first seems more explicit, but seems to me that OpenSIPS would have to parse the param list twice - once to check whether the param exists and then again to get the value. Is the second method acceptable? Method 1: if ($(var(pstring){param.exists,customparam})) { $var(pval) = $(var(pstring){param.value,customparam}); # do other stuff } Method 2: $var(pval) = $(var(pstring){param.value,customparam}); if ($var(pval) != NULL { # do other stuff } There is a functional difference between them that in method 1, if the param doesn't exist then $var(pval) doesn't get set (it might already exist with a different value), but if this didn't matter in the context of the code, is one way preferred over the other? Cheers, Kingsley. From sunil.more64sinfo at gmail.com Mon May 24 06:10:49 2021 From: sunil.more64sinfo at gmail.com (Sunil More) Date: Mon, 24 May 2021 11:40:49 +0530 Subject: [OpenSIPS-Users] Fwd: STIR/Shaken payload issue. In-Reply-To: <2EE8ACE7-007E-4913-B718-B839147714F9@hxcore.ol> References: <2EE8ACE7-007E-4913-B718-B839147714F9@hxcore.ol> Message-ID: Hello All, I tried the same with Opensips version 3.1.2 , Still the same result. The Payload is not a valid JSON. version: opensips 3.1.2 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: 539ab0b3a main.c compiled on 05:43:20 May 24 2021 with gcc 7 Regards, Sunil More ---------- Forwarded message --------- From: Sunil More Date: Thu, 20 May 2021 at 15:55 Subject: STIR/Shaken payload issue. To: users at lists.opensips.org Hello All, I was working to use stir shaken module. The certificates are put in place and Identity Header is also created. However the Identity when tried to put on JWT.io for validation , I can observe that the payload is not good. Here is the identity Heade *Identity*: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9hcHBzLnNhbWVzcGFjZS5jb20vc2VydmVyLmNydCJ9 . eyJhdHRlc3QiOCIiwiZGVzdCI6eyJ0biI6WyI5MTk1MDMzMzgyNzUiXX0sImlhdCI6MTYyMDkxMDc3Nywib3JpZyI6eyJ0biI6IjkxOTUwMzMzODI3NiJ9LCJvcmlnaWQiOiJkc2FkYXNhc2Zkcy1kc2FkYXNkLXNWRzIn0 .JzYHlbStXK7gpmRWVZY_IC8VmeZfaKWBzGTOfGU82OQ3w28lctaYv- YAzBdjqjUGJKISid327KSzUGGvpXYBSg;info=;ppt="shaken" After JWT.io Header for algorithm and token type looks ok .. { "alg": "ES256", "ppt": "shaken", "typ": "passport", "x5u": "https://apps.samespace.com/server.crt" } However payload looks like this which is probably some invalid JSON, I am not sure what could cause this. "{\"attest\"8\"\"�&FW7B#��'F�#��#�\u0013�S\u0003333�#sR%���&�\u0017B#�\u0013c#\u0003�\u0013\u0003ssr�&�&�r#��'F�#�#�\u0013�S\u0003333�#sb'��&�&�v�B#�&G6\u0016F\u00176\u00176fG2�G6\u0016F\u00176B�5ds\"}" Here is the code snippet used . stir_shaken_auth("B", $var(origid),$var(cert), $var(privKey)," https://apps.samespace.com/server.crt","919503338276","919503338275"); I am using opensips version as below version: opensips 3.1.1 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: 229ec0793 main.c compiled on 11:50:44 Jan 15 2021 with gcc 7 Kindly let me know if there is something wrong that I could be doing. I checked the sample from *https://transnexus.com/whitepapers/understanding-stir-shaken/ * The Identity from this example shows a good payload. Regards, Sunil More Phone : 919503338275 Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Mon May 24 12:41:11 2021 From: solarmon at one-n.co.uk (solarmon) Date: Mon, 24 May 2021 13:41:11 +0100 Subject: [OpenSIPS-Users] regexp extraction in to a variable Message-ID: Hi, If I had a $fn (From display name) core variable in the format: "ABC123456789" I know how to match on "ABC", but how can I extract "1234567879" to put into another variable? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kneeoh at yahoo.com Mon May 24 12:42:08 2021 From: kneeoh at yahoo.com (Kneeoh) Date: Mon, 24 May 2021 12:42:08 +0000 (UTC) Subject: [OpenSIPS-Users] Fwd: STIR/Shaken payload issue. In-Reply-To: References: <2EE8ACE7-007E-4913-B718-B839147714F9@hxcore.ol> Message-ID: <689596221.2161349.1621860128014@mail.yahoo.com> Sunil,  I was having a similar issue... it looks like part 2 of the base64 string decodes to: {"attest"8""Â&FW7B#§²'Fâ#¥²#““S333ƒ#sR%×ÒÂ&–B#£c#“ssrÂ&÷&–r#§²'Fâ#¢#““S333ƒ#sb'ÒÂ&÷&–v–B#¢&G6F66fG2ÖG6F6B×5ds"} My problem was that I was using sngrep to find my identity header and it appears to have been truncating my string. upon using ngrep to get the raw packet data I found the identity string was totally different and decoded properly.  On Monday, May 24, 2021, 02:13:08 AM EDT, Sunil More wrote: Hello All, I tried the same with Opensips version 3.1.2 , Still the same result. The Payload is not a valid JSON. version: opensips 3.1.2 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: 539ab0b3a main.c compiled on 05:43:20 May 24 2021 with gcc 7 Regards,Sunil More ---------- Forwarded message --------- From: Sunil More Date: Thu, 20 May 2021 at 15:55 Subject: STIR/Shaken payload issue. To: users at lists.opensips.org Hello All,   I was working to use stir shaken module. The certificates are put in place and Identity Header is also created. However the Identity when tried to put on JWT.io for validation , I can observe that the payload is not good.   Here is the identity Heade Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9hcHBzLnNhbWVzcGFjZS5jb20vc2VydmVyLmNydCJ9.eyJhdHRlc3QiOCIiwiZGVzdCI6eyJ0biI6WyI5MTk1MDMzMzgyNzUiXX0sImlhdCI6MTYyMDkxMDc3Nywib3JpZyI6eyJ0biI6IjkxOTUwMzMzODI3NiJ9LCJvcmlnaWQiOiJkc2FkYXNhc2Zkcy1kc2FkYXNkLXNWRzIn0.JzYHlbStXK7gpmRWVZY_IC8VmeZfaKWBzGTOfGU82OQ3w28lctaYv-YAzBdjqjUGJKISid327KSzUGGvpXYBSg;info=;ppt="shaken" After JWT.io Header for algorithm and token type  looks ok .. {   "alg": "ES256",   "ppt": "shaken",   "typ": "passport",   "x5u": "https://apps.samespace.com/server.crt" } However payload looks like this which is probably some invalid JSON, I am not sure what could cause this. "{\"attest\"8\"\"�&FW7B#��'F�#��#�\u0013�S\u0003333�#sR%���&�\u0017B#�\u0013c#\u0003�\u0013\u0003ssr�&�&�r#��'F�#�#�\u0013�S\u0003333�#sb'��&�&�v�B#�&G6\u0016F\u00176\u00176fG2�G6\u0016F\u00176B�5ds\"}" Here is the code snippet used . stir_shaken_auth("B", $var(origid),$var(cert), $var(privKey),"https://apps.samespace.com/server.crt","919503338276","919503338275");    I am using opensips version as below   version: opensips 3.1.1 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: 229ec0793 main.c compiled on 11:50:44 Jan 15 2021 with gcc 7   Kindly let me know if there is something wrong that I could be doing. I checked the sample from https://transnexus.com/whitepapers/understanding-stir-shaken/ The Identity from this example shows a good payload.     Regards, Sunil More Phone : 919503338275 Sent from Mail for Windows 10   _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Mon May 24 23:38:12 2021 From: social at bohboh.info (Social Boh) Date: Mon, 24 May 2021 18:38:12 -0500 Subject: [OpenSIPS-Users] OpenSIPs 3.2 wolfssl module compilation error Message-ID: <2f2bda26-96a0-abce-172b-4bc0e0356595@bohboh.info> Hello, I'm trying to install OpenSIPs 3.2 on Almalinux 8 (CentOS 8) and I can't compile this module: make[2]: se entra en el directorio '/usr/src/opensips_3_2/modules/wolfssl' /bin/sh: linea 2: ./autogen.sh: No such file or directory Any hint? Regards -- --- I'm SoCIaL, MayBe From sunil.more64sinfo at gmail.com Tue May 25 05:46:55 2021 From: sunil.more64sinfo at gmail.com (Sunil More) Date: Tue, 25 May 2021 11:16:55 +0530 Subject: [OpenSIPS-Users] STIR/Shaken payload issue. In-Reply-To: References: <2EE8ACE7-007E-4913-B718-B839147714F9@hxcore.ol> Message-ID: Hello All, Thank you kneeoh at yahoo.com. Yes I was too using sngrep to grab the header. Upon using ngrep I found that everything was fine. Thanks for pointing it out. Regards, Sunil More On Mon, 24 May 2021 at 11:40, Sunil More wrote: > Hello All, > > I tried the same with Opensips version 3.1.2 , Still the same result. The > Payload is not a valid JSON. > > version: opensips 3.1.2 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > git revision: 539ab0b3a > main.c compiled on 05:43:20 May 24 2021 with gcc 7 > > Regards, > Sunil More > > ---------- Forwarded message --------- > From: Sunil More > Date: Thu, 20 May 2021 at 15:55 > Subject: STIR/Shaken payload issue. > To: users at lists.opensips.org > > > Hello All, > > > > I was working to use stir shaken module. The certificates are put in place > and Identity Header is also created. However the Identity when tried to put > on JWT.io for validation , I can observe that the payload is not good. > > Here is the identity Heade > *Identity*: > eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9hcHBzLnNhbWVzcGFjZS5jb20vc2VydmVyLmNydCJ9 > . > eyJhdHRlc3QiOCIiwiZGVzdCI6eyJ0biI6WyI5MTk1MDMzMzgyNzUiXX0sImlhdCI6MTYyMDkxMDc3Nywib3JpZyI6eyJ0biI6IjkxOTUwMzMzODI3NiJ9LCJvcmlnaWQiOiJkc2FkYXNhc2Zkcy1kc2FkYXNkLXNWRzIn0 > .JzYHlbStXK7gpmRWVZY_IC8VmeZfaKWBzGTOfGU82OQ3w28lctaYv- > YAzBdjqjUGJKISid327KSzUGGvpXYBSg;info= apps.samespace.com/server.crt>;ppt="shaken" > > > After JWT.io > Header for algorithm and token type looks ok .. > { > > "alg": "ES256", > > "ppt": "shaken", > > "typ": "passport", > > "x5u": "https://apps.samespace.com/server.crt" > > } > > However payload looks like this which is probably some invalid JSON, I am > not sure what could cause this. > > > "{\"attest\"8\"\"�&FW7B#��'F�#��#�\u0013�S\u0003333�#sR%���&�\u0017B#�\u0013c#\u0003�\u0013\u0003ssr�&�&�r#��'F�#�#�\u0013�S\u0003333�#sb'��&�&�v�B#�&G6\u0016F\u00176\u00176fG2�G6\u0016F\u00176B�5ds\"}" > > Here is the code snippet used . > > > stir_shaken_auth("B", $var(origid),$var(cert), $var(privKey)," > https://apps.samespace.com/server.crt","919503338276","919503338275"); > > > > I am using opensips version as below > > > > version: opensips 3.1.1 (x86_64/linux) > > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > > poll method support: poll, epoll, sigio_rt, select. > > git revision: 229ec0793 > > main.c compiled on 11:50:44 Jan 15 2021 with gcc 7 > > > > Kindly let me know if there is something wrong that I could be doing. I > checked the sample from *https://transnexus.com/whitepapers/understanding-stir-shaken/ > * > > The Identity from this example shows a good payload. > > > > > > Regards, > > Sunil More > > Phone : 919503338275 > > Sent from Mail for > Windows 10 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhc at 3clogic.com Tue May 25 13:17:29 2021 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Tue, 25 May 2021 18:47:29 +0530 Subject: [OpenSIPS-Users] TLS_MGM module with DB(MYSQL) Message-ID: Hi Opensips Team/Razvan, I am using the TLS_MGM module to validate my certificate file through a database (mysql) but getting the below error. May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: *ERROR:tls_mgm:load_certificate_db: Unable to load certificate from buffer* May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: WARNING:tls_mgm:init_tls_domains: Failed to init TLS domain 'default', skipping... The data i have put in DB is depicted below:- insert into tls_mgm (id,domain,match_ip_address,match_sip_domain,type,method,verify_cert,require_cert,certificate,private_key,crl_check_all,crl_dir,ca_list,ca_dir, cipher_list,dh_params,ec_curve) values ('1','default','20.0.xx.xx:443','','1','SSLv23','1','0','xxxx2021.der','xxxx.der','0','','xxxxx2021.der','','ALL','',''); *.der* files are the binary file for certificate file, private key file and ca_list . However the same is working fine through the configuration script. Can anybody confirm what I am doing wrong ? Best Regards Saurabh Chopra +918861979979 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Tue May 25 21:11:12 2021 From: david.villasmil.work at gmail.com (David Villasmil) Date: Tue, 25 May 2021 22:11:12 +0100 Subject: [OpenSIPS-Users] Ignore redirect? Message-ID: Hello guys, I'm receiving an INVITE which I forward to a redirect server. When this redirect server's response is not what i need, i need to continue processing the call normally, i.e.: No forward to redirect. I'm able to forward to the redirect server and get the 302 properly. But when the 302 is not what I need, how can I continue processing the call normally? i.e. using do_routing. Thanks all, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xaled at web.de Wed May 26 08:23:39 2021 From: xaled at web.de (xaled at web.de) Date: Wed, 26 May 2021 10:23:39 +0200 Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine In-Reply-To: <02b701d74ca2$574e6f50$05eb4df0$@web.de> References: <15a401d748b4$fb1b9140$f152b3c0$@web.de> <02b701d74ca2$574e6f50$05eb4df0$@web.de> Message-ID: <0e9c01d75208$6e827b60$4b877220$@web.de> Apologies for keep on bugging on this issue, but would really appreciate any hints. -----Original Message----- From: Users On Behalf Of xaled at web.de Sent: Wednesday, May 19, 2021 1:30 PM To: 'OpenSIPS users mailling list' Subject: Re: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine Hi Would appreciate any hints on how to run the new 3.2 B2B module with RTPProxy or RTPEngine. Thanks, Xaled -----Original Message----- From: Users On Behalf Of xaled at web.de Sent: Friday, May 14, 2021 1:34 PM To: 'OpenSIPS users mailling list' Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine Hi, Are the any examples of using the new B2B module in 3.2 with RTPProxy or RTPEngine? I tried adding _offer and _answer call accordingly but never saw RTPProxy or RTPEngine engaged. Even a simple example for A-B call with B2B and RTPEngine would be much appreciated. Thanks, Xaled _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From kurgan-rus at inbox.ru Wed May 26 09:22:37 2021 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Wed, 26 May 2021 12:22:37 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?regexp_extraction_in_to_a_variable?= In-Reply-To: References: Message-ID: <1622020957.287660679@f416.i.mail.ru> Hello,   the regexp matching digits will look like \d+ (backslash, d letter, plus sign).   Maybe this can be also useful to you: https://www.opensips.org/Documentation/Script-Tran-3-1#toc6   ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/   -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Wed May 26 09:27:28 2021 From: david.villasmil.work at gmail.com (David Villasmil) Date: Wed, 26 May 2021 10:27:28 +0100 Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine In-Reply-To: <0e9c01d75208$6e827b60$4b877220$@web.de> References: <15a401d748b4$fb1b9140$f152b3c0$@web.de> <02b701d74ca2$574e6f50$05eb4df0$@web.de> <0e9c01d75208$6e827b60$4b877220$@web.de> Message-ID: Are you 100% sure opensips can “talk” to rtpengine? How do you know? On Wed, 26 May 2021 at 09:24, wrote: > Apologies for keep on bugging on this issue, but would really appreciate > any hints. > > -----Original Message----- > From: Users On Behalf Of xaled at web.de > Sent: Wednesday, May 19, 2021 1:30 PM > To: 'OpenSIPS users mailling list' > Subject: Re: [OpenSIPS-Users] opensips 3.2 B2B module and > RTPProxy/RTPEngine > > Hi > > Would appreciate any hints on how to run the new 3.2 B2B module with > RTPProxy or RTPEngine. > > Thanks, > Xaled > -----Original Message----- > From: Users On Behalf Of xaled at web.de > Sent: Friday, May 14, 2021 1:34 PM > To: 'OpenSIPS users mailling list' > Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine > > Hi, > > Are the any examples of using the new B2B module in 3.2 with RTPProxy or > RTPEngine? I tried adding _offer and _answer call accordingly but never saw > RTPProxy or RTPEngine engaged. > > Even a simple example for A-B call with B2B and RTPEngine would be much > appreciated. > > Thanks, > Xaled > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at ugnd.org Wed May 26 10:36:11 2021 From: jeff at ugnd.org (Jeff Pyle) Date: Wed, 26 May 2021 06:36:11 -0400 Subject: [OpenSIPS-Users] Ignore redirect? In-Reply-To: References: Message-ID: David, You catch the 302 in the failure_route, decide if it's what you want, and if not just send to another route block for do_routing and such? - Jeff On Tue, May 25, 2021 at 5:12 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > Hello guys, > > I'm receiving an INVITE which I forward to a redirect server. When this > redirect server's response is not what i need, i need to continue > processing the call normally, i.e.: No forward to redirect. > > I'm able to forward to the redirect server and get the 302 properly. But > when the 302 is not what I need, how can I continue processing the call > normally? i.e. using do_routing. > > Thanks all, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Wed May 26 11:15:57 2021 From: mark at allenclan.co.uk (Mark Allen) Date: Wed, 26 May 2021 12:15:57 +0100 Subject: [OpenSIPS-Users] Am I seeing SIP message fragmentation? Message-ID: I'm seeing a weird, intermittent error. The most common occurrence is with a 200OK returned by Mid-Registrar on a re-REGISTER using registration throttling, but we see it elsewhere. It appears that the 200OK message is getting garbled. We have a bit of a weird setup to overcome issues we were having with Mid-Registrar and WebSocket addressing. Mid-Registrar is looping back 200OK to OpenSIPS before it then gets sent down the WebSocket. 90+% of the time it's absolutely fine, but occasionally the 200OK seems to be corrupted. Here's an example. What we are seeing in this message is... Contact: User-Agent: MWWRTC 3.4.21042#015#012Accept: application/sdp,application/dtmf-relay,text/plain ...preceding... SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.1.23:5060 ;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4 ...etc... ...so OpenSIPS is failing to parse the message. What I'd like to know is, is this a sign of SIP message fragmentation? Log entries (IP addresses, domains, and extensions changed to protect the innocent!): ERROR:core:parse_method: invalid character : DBG:core:tcp_read_req: tcp_read_req end INFO:core:parse_first_line: failed to parse the method INFO:core:parse_first_line: bad message DBG:core:parse_msg: invalid message ERROR:core:parse_msg: message=#015#012User-Agent: MWWRTC 3.4.21042#015#012Accept: application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 OK#015#012Via: SIP/2.0/TCP 192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4#015#012Via: SIP/2.0/WSS 98kaag0xmybq.invalid;received=4.56.78.110;branch=z9hG4bKU6O3fJQGeLvuACMTXTArJgJW73rOD5dU;rport=52570#015#012From: ;tag=Lyk010G476K7xcKrE84M#015#012To: < sip:1234 at abc.def.com>;tag=af78-6213d386c3edcd02707b0c0aa8423d3a#015#012Call-ID: 666b5e7c-cef3-f306-4b79-60d3160dc5d0#015#012CSeq: 28825 REGISTER#015#012Contact: ;expires=60;received="sip:4.56.78.110:52570"#015#012Server: OpenSIPS (3.1.1 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012> ERROR:core:receive_msg: Unable to parse msg received from [192.168.1.23:5060 ] ERROR:core:tcp_handle_req: receive_msg failed DBG:core:tcp_read_req: tcp_read_req end -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Wed May 26 11:23:46 2021 From: david.villasmil.work at gmail.com (David Villasmil) Date: Wed, 26 May 2021 12:23:46 +0100 Subject: [OpenSIPS-Users] Ignore redirect? In-Reply-To: References: Message-ID: Many thanks Jeff! That’s exactly what I did :) Appreciate the help. David On Wed, 26 May 2021 at 11:36, Jeff Pyle wrote: > David, > > You catch the 302 in the failure_route, decide if it's what you want, and > if not just send to another route block for do_routing and such? > > > - Jeff > > On Tue, May 25, 2021 at 5:12 PM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> Hello guys, >> >> I'm receiving an INVITE which I forward to a redirect server. When this >> redirect server's response is not what i need, i need to continue >> processing the call normally, i.e.: No forward to redirect. >> >> I'm able to forward to the redirect server and get the 302 properly. But >> when the 302 is not what I need, how can I continue processing the call >> normally? i.e. using do_routing. >> >> Thanks all, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Wed May 26 11:34:33 2021 From: callum.guy at x-on.co.uk (Callum Guy) Date: Wed, 26 May 2021 12:34:33 +0100 Subject: [OpenSIPS-Users] TLS_MGM module with DB(MYSQL) In-Reply-To: References: Message-ID: You need to insert the certificate contents into the table rather than a file, to my understanding - you'd probably want to convert the certs to PEM format prior to doing this. On Tue, 25 May 2021 at 14:20, Saurabh Chopra wrote: > Hi Opensips Team/Razvan, > > I am using the TLS_MGM module to validate my certificate file through a > database (mysql) but getting the below error. > > May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: > NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none > May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: *ERROR:tls_mgm:load_certificate_db: > Unable to load certificate from buffer* > May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: > WARNING:tls_mgm:init_tls_domains: Failed to init TLS domain 'default', > skipping... > > The data i have put in DB is depicted below:- > > insert into tls_mgm > (id,domain,match_ip_address,match_sip_domain,type,method,verify_cert,require_cert,certificate,private_key,crl_check_all,crl_dir,ca_list,ca_dir, > cipher_list,dh_params,ec_curve) values > ('1','default','20.0.xx.xx:443','','1','SSLv23','1','0','xxxx2021.der','xxxx.der','0','','xxxxx2021.der','','ALL','',''); > > *.der* files are the binary file for certificate file, private key file > and ca_list . However the same is working fine through the configuration > script. > > Can anybody confirm what I am doing wrong ? > > > Best Regards > Saurabh Chopra > +918861979979 > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus **  |   Practice Index Reviews * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. *Our new office address: 22 Riduna Park, Melton IP12 1QT.* X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Thu May 27 10:56:14 2021 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 27 May 2021 11:56:14 +0100 Subject: [OpenSIPS-Users] error_route not triggered for parsing error Message-ID: In my script, I have an error_route... error_route { xlog("--- error route class=$(err.class) level=$(err.level) info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n"); xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n"); sl_send_reply($err.rcode, "$err.rreason"); exit; } ...but when I get a message parsing error, the error_route seems to ignore it. What am I doing wrong? ERROR:core:parse_method: invalid character : INFO:core:parse_first_line: failed to parse the method INFO:core:parse_first_line: bad message ERROR:core:parse_msg: message=#015#012User-Agent: MWWRTC 3.4.21042#015#012Accept: application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 OK#015#012Via: SIP/2.0/TCP 192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From: ;tag=33e693c3#015#012To: ;tag=1550918023#015#012Call-ID: fc585e54-72a5d21-ab2 at 192.168.1.23#015#012CSeq: 1 OPTIONS#015#012User-Agent: Yealink SIP-T54W#015#012Content-Length: 0#015#012#015#012> ERROR:core:receive_msg: Unable to parse msg received from [192.168.1.23:5060 ] ERROR:core:tcp_handle_req: receive_msg failed We are running OpenSIPS 3.1 (this is a follow-up to my other query http://lists.opensips.org/pipermail/users/2021-May/044776.html) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Thu May 27 11:57:39 2021 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 27 May 2021 12:57:39 +0100 Subject: [OpenSIPS-Users] error_route not triggered for parsing error In-Reply-To: References: Message-ID: This seems to link to a past thread where error_route is not triggering if the first line is malformed. Unfortunately, there is no resolution to this past thread - link here: https://opensips.org/pipermail/users/2019-February/040605.html On Thu, 27 May 2021 at 11:56, Mark Allen wrote: > > In my script, I have an error_route... > > error_route { > xlog("--- error route class=$(err.class) level=$(err.level) > info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) > ---\n"); > xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n"); > sl_send_reply($err.rcode, "$err.rreason"); > exit; > } > > ...but when I get a message parsing error, the error_route seems to ignore > it. What am I doing wrong? > > ERROR:core:parse_method: invalid character : > INFO:core:parse_first_line: failed to parse the method > INFO:core:parse_first_line: bad message > ERROR:core:parse_msg: message=#015#012User-Agent: > MWWRTC 3.4.21042#015#012Accept: > application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 > OK#015#012Via: SIP/2.0/TCP 192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From: > ;tag=33e693c3#015#012To: > ;tag=1550918023#015#012Call-ID: > fc585e54-72a5d21-ab2 at 192.168.1.23#015#012CSeq > : 1 > OPTIONS#015#012User-Agent: Yealink SIP-T54W#015#012Content-Length: > 0#015#012#015#012> > ERROR:core:receive_msg: Unable to parse msg received from [ > 192.168.1.23:5060] > ERROR:core:tcp_handle_req: receive_msg failed > > > We are running OpenSIPS 3.1 > > > (this is a follow-up to my other query > http://lists.opensips.org/pipermail/users/2021-May/044776.html) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu May 27 16:45:12 2021 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 27 May 2021 19:45:12 +0300 Subject: [OpenSIPS-Users] [Release] OpenSIPS 3.2.0 major release, beta version Message-ID: <3c4acaa8-5dc9-7015-6bb4-1f3f4194a957@opensips.org> Hi there !! One more year, one more ambitious roadmap , one more OpenSIPS major release. So, we are all happy to announce the beta release of OpenSIPS 3.2.0 major version - and this 3.2 version is all about Clustering, Integration, Security and IMS. But here is the shortest possible description of this release; and be aware that it's actually not so short as nothing is short about 3.2 ! Please keep in mind that 3.2.0 is still a beta release, targeting mid July to become fully stable. So, we still have some testing ahead of us :). Many thanks to our awesome community for contributing with ideas, code, patches, tests and reports! Looking for downloading it? See the tarball or the GIT repo . Packages (rpms and debs ) are also already available! Enjoy it, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2021 online https://opensips.org/training/OpenSIPS_eBootcamp_2021/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From schu at schu.net Thu May 27 19:33:52 2021 From: schu at schu.net (Matthew Schumacher) Date: Thu, 27 May 2021 12:33:52 -0700 Subject: [OpenSIPS-Users] [Release] OpenSIPS 3.2.0 major release, beta version In-Reply-To: <3c4acaa8-5dc9-7015-6bb4-1f3f4194a957@opensips.org> References: <3c4acaa8-5dc9-7015-6bb4-1f3f4194a957@opensips.org> Message-ID: I was able to compile the software without any issue and it loaded my config and seems to work with only changing the listen to socket, however an issue that I was having with the old version (and the reason to try the new one) is not resolved. The issue is that I have two instances of opensips running on the same host with different sets of public and private addresses (4 total). Instance one (3.0.2) has listen=udp:a.a.a.a:5060 listen=udp:b.b.b.b:5060 Instance two (3.2.0-beta) has socket=udp:x.x.x.x:5060 socket=tcp:x.x.x.x:5060 socket=udp:y.y.y.y:5060 socket=tcp:y.y.y.y:5060 On instance two, when relaying with UDP I get: May 27 11:24:59 [7095] ERROR:core:get_out_socket: outbound IP b.b.b.b not found as listener May 27 11:24:59 [7095] ERROR:core:get_out_socket: failed to find route to May 27 11:24:59 [7095] ERROR:tm:update_uac_dst: failed to fwd to af 2, proto 1  (no corresponding listening socket) May 27 11:24:59 [7095] ERROR:tm:t_forward_nonack: failure to add branches But this only happens on UDP traffic, not TCP traffic.  So, instance two is trying to send the UDP packet with a source address it's not listening on, probably because it's the host's first IP address. If this a known or unknown issue?  Can I define for instance two which IP to source from? Thanks, Matt On 5/27/21 9:45 AM, Bogdan-Andrei Iancu wrote: > Hi there !! > > One more year, one more ambitious roadmap > , one more > OpenSIPS major release. > > So, we are all happy to announce the beta release of OpenSIPS 3.2.0 > major version - and this 3.2 version is all about Clustering, > Integration, Security and IMS. But here is the shortest possible > description > of > this release; and be aware that it's actually not so short as nothing > is short about 3.2 ! > > Please keep in mind that 3.2.0 is still a beta release, targeting mid > July to become fully stable. So, we still have some testing ahead of > us :). > > Many thanks to our awesome community for contributing with ideas, > code, patches, tests and reports! > > Looking for downloading it? See the tarball > or the GIT repo > . Packages (rpms > and debs ) are > also already available! > > Enjoy it, > -- > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp 2021 online > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From schu at schu.net Thu May 27 20:34:26 2021 From: schu at schu.net (Matthew Schumacher) Date: Thu, 27 May 2021 13:34:26 -0700 Subject: [OpenSIPS-Users] [Release] OpenSIPS 3.2.0 major release, beta version In-Reply-To: References: <3c4acaa8-5dc9-7015-6bb4-1f3f4194a957@opensips.org> Message-ID: <7e1e0a0d-1c5d-cfc1-a512-d942500175ff@schu.net> nevermind,  $socket_out fixed my issue. Looks like 3.2.0 is running fine for my limited use case. On 5/27/21 12:33 PM, Matthew Schumacher wrote: > I was able to compile the software without any issue and it loaded my > config and seems to work with only changing the listen to socket, > however an issue that I was having with the old version (and the > reason to try the new one) is not resolved. > > The issue is that I have two instances of opensips running on the same > host with different sets of public and private addresses (4 total). > > Instance one (3.0.2) has > > listen=udp:a.a.a.a:5060 > listen=udp:b.b.b.b:5060 > > Instance two (3.2.0-beta) has > > socket=udp:x.x.x.x:5060 > socket=tcp:x.x.x.x:5060 > socket=udp:y.y.y.y:5060 > socket=tcp:y.y.y.y:5060 > > On instance two, when relaying with UDP I get: > > May 27 11:24:59 [7095] ERROR:core:get_out_socket: outbound IP b.b.b.b > not found as listener > May 27 11:24:59 [7095] ERROR:core:get_out_socket: failed to find route > to > May 27 11:24:59 [7095] ERROR:tm:update_uac_dst: failed to fwd to af 2, > proto 1  (no corresponding listening socket) > May 27 11:24:59 [7095] ERROR:tm:t_forward_nonack: failure to add branches > > But this only happens on UDP traffic, not TCP traffic.  So, instance > two is trying to send the UDP packet with a source address it's not > listening on, probably because it's the host's first IP address. > > If this a known or unknown issue?  Can I define for instance two which > IP to source from? > > Thanks, > Matt > > > On 5/27/21 9:45 AM, Bogdan-Andrei Iancu wrote: >> Hi there !! >> >> One more year, one more ambitious roadmap >> , one >> more OpenSIPS major release. >> >> So, we are all happy to announce the beta release of OpenSIPS 3.2.0 >> major version - and this 3.2 version is all about Clustering, >> Integration, Security and IMS. But here is the shortest possible >> description >> of >> this release; and be aware that it's actually not so short as nothing >> is short about 3.2 ! >> >> Please keep in mind that 3.2.0 is still a beta release, targeting mid >> July to become fully stable. So, we still have some testing ahead of >> us :). >> >> Many thanks to our awesome community for contributing with ideas, >> code, patches, tests and reports! >> >> Looking for downloading it? See the tarball >> or the GIT repo >> . Packages (rpms >> and debs ) are >> also already available! >> >> Enjoy it, >> -- >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Bootcamp 2021 online >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri May 28 05:54:44 2021 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 28 May 2021 08:54:44 +0300 Subject: [OpenSIPS-Users] error_route not triggered for parsing error In-Reply-To: References: Message-ID: Hi Mark, Consider opening a ticket on github. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2021 online https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 5/27/21 2:57 PM, Mark Allen wrote: > This seems to link to a past thread where error_route is not > triggering if the first line is malformed. Unfortunately, there is no > resolution to this past thread - link here: > https://opensips.org/pipermail/users/2019-February/040605.html > > > On Thu, 27 May 2021 at 11:56, Mark Allen > wrote: > > > In my script, I have an error_route... > > error_route { >    xlog("--- error route class=$(err.class) level=$(err.level) >         info=$(err.info ) rcode=$(err.rcode) > rreason=$(err.rreason) ---\n"); >    xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n"); >    sl_send_reply($err.rcode, "$err.rreason"); >    exit; > } > > ...but when I get a message parsing error, the error_route seems > to ignore it. What am I doing wrong? > > ERROR:core:parse_method: invalid character : > INFO:core:parse_first_line: failed to parse the method > INFO:core:parse_first_line: bad message > ERROR:core:parse_msg: message= >#015#012User-Agent: MWWRTC > 3.4.21042#015#012Accept: > application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 > 200 OK#015#012Via: SIP/2.0/TCP > 192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From: > >;tag=33e693c3#015#012To: > ;tag=1550918023#015#012Call-ID: > fc585e54-72a5d21-ab2 at 192.168.1.23#015#012CSeq > : 1 > OPTIONS#015#012User-Agent: Yealink SIP-T54W#015#012Content-Length: > 0#015#012#015#012> > ERROR:core:receive_msg: Unable to parse msg received from > [192.168.1.23:5060 ] > ERROR:core:tcp_handle_req: receive_msg failed > > > We are running OpenSIPS 3.1 > > > (this is a follow-up to my other query > http://lists.opensips.org/pipermail/users/2021-May/044776.html > ) > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri May 28 05:56:51 2021 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 28 May 2021 08:56:51 +0300 Subject: [OpenSIPS-Users] OpenSIPs HA with KeepAlived In-Reply-To: References: Message-ID: <84d6216e-0953-dc80-9e04-07d68b7457b5@opensips.org> Hi, no English version of it ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2021 online https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 4/30/21 4:12 PM, Social Boh wrote: > > Hello list, > > maybe someone might be interested: "OpenSIPs 3.1 HA with KeepAlilved": > > https://www.voztovoice.org/?q=node/2879 > > Spanish Article > > -- > --- > I'm SoCIaL, MayBe > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Fri May 28 05:59:21 2021 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 28 May 2021 08:59:21 +0300 Subject: [OpenSIPS-Users] pkmem statistics for version 3.1 In-Reply-To: References: Message-ID: <9f7efa2e-b094-2cd9-2905-48b12d128ce3@opensips.org> Hi Federico, Starting 3.0, the way we fetch the pkg stats from all the procs did change, from the unreliable and problem maker mechanism based on SIGUSR1, to using the internal IPC support. Unfortunately the extra MI procs have no IPC support, but this was fixed in 3.2. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2021 online https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 4/30/21 7:34 PM, Federico Edorna wrote: > Hello! moving from 2.4 to 3.1 I've found something strange in > pkmem stats. MI is showing zero values for the first 7 processes > > /opensips-cli -x mi get_statistics pkmem: -o output_type=lines > /pkmem:1-used_size: 0 > pkmem:1-real_used_size: 0 > pkmem:1-max_used_size: 0 > pkmem:1-free_size: 0 > pkmem:1-fragments: 0 > pkmem:2-used_size: 0 > pkmem:2-real_used_size: 0 > pkmem:2-max_used_size: 0 > pkmem:2-free_size: 0 > pkmem:2-fragments: 0 > pkmem:3-used_size: 0 > pkmem:3-real_used_size: 0 > pkmem:3-max_used_size: 0 > pkmem:3-free_size: 0 > pkmem:3-fragments: 0 > pkmem:4-used_size: 0 > pkmem:4-real_used_size: 0 > pkmem:4-max_used_size: 0 > pkmem:4-free_size: 0 > pkmem:4-fragments: 0 > pkmem:5-used_size: 0 > pkmem:5-real_used_size: 0 > pkmem:5-max_used_size: 0 > pkmem:5-free_size: 0 > pkmem:5-fragments: 0 > pkmem:6-used_size: 0 > pkmem:6-real_used_size: 0 > pkmem:6-max_used_size: 0 > pkmem:6-free_size: 0 > pkmem:6-fragments: 0 > pkmem:7-used_size: 0 > pkmem:7-real_used_size: 0 > pkmem:7-max_used_size: 0 > pkmem:7-free_size: 0 > pkmem:7-fragments: 0 > pkmem:8-used_size: 3167224 > pkmem:8-real_used_size: 3387464 > pkmem:8-max_used_size: 3396024 > pkmem:8-free_size: 13389752 > pkmem:8-fragments: 3561 > pkmem:9-used_size: 3164712 > pkmem:9-real_used_size: 3385048 > pkmem:9-max_used_size: 3393616 > pkmem:9-free_size: 13392168 > pkmem:9-fragments: 3559 > pkmem:10-used_size: 3164736 > pkmem:10-real_used_size: 3385360 > pkmem:10-max_used_size: 3393904 > pkmem:10-free_size: 13391856 > pkmem:10-fragments: 3559 > pkmem:11-used_size: 3164688 > pkmem:11-real_used_size: 3385840 > pkmem:11-max_used_size: 3394384 > pkmem:11-free_size: 13391376 > pkmem:11-fragments: 3558 > pkmem:12-used_size: 3163936 > pkmem:12-real_used_size: 3379712 > pkmem:12-max_used_size: 3379896 > pkmem:12-free_size: 13397504 > pkmem:12-fragments: 3547 > pkmem:13-used_size: 3163936 > pkmem:13-real_used_size: 3379712 > pkmem:13-max_used_size: 3379896 > pkmem:13-free_size: 13397504 > pkmem:13-fragments: 3547 > pkmem:14-used_size: 3163936 > pkmem:14-real_used_size: 3379664 > pkmem:14-max_used_size: 3379728 > pkmem:14-free_size: 13397552 > pkmem:14-fragments: 3547 > pkmem:15-used_size: 3163936 > pkmem:15-real_used_size: 3379712 > pkmem:15-max_used_size: 3379896 > pkmem:15-free_size: 13397504 > pkmem:15-fragments: 3547 > pkmem:16-used_size: 3163936 > pkmem:16-real_used_size: 3379664 > pkmem:16-max_used_size: 3379728 > pkmem:16-free_size: 13397552 > pkmem:16-fragments: 3547 > pkmem:17-used_size: 3163936 > pkmem:17-real_used_size: 3379664 > pkmem:17-max_used_size: 3379728 > pkmem:17-free_size: 13397552 > pkmem:17-fragments: 3547 > pkmem:18-used_size: 3163936 > pkmem:18-real_used_size: 3379664 > pkmem:18-max_used_size: 3379728 > pkmem:18-free_size: 13397552 > pkmem:18-fragments: 3547 > pkmem:19-used_size: 3163936 > pkmem:19-real_used_size: 3379664 > pkmem:19-max_used_size: 3379728 > pkmem:19-free_size: 13397552 > pkmem:19-fragments: 3547 > pkmem:20-used_size: 3163936 > pkmem:20-real_used_size: 3379664 > pkmem:20-max_used_size: 3379728 > pkmem:20-free_size: 13397552 > pkmem:20-fragments: 3547 > pkmem:21-used_size: 3163936 > pkmem:21-real_used_size: 3379664 > pkmem:21-max_used_size: 3379728 > pkmem:21-free_size: 13397552 > pkmem:21-fragments: 3547 > pkmem:22-used_size: 3163936 > pkmem:22-real_used_size: 3379712 > pkmem:22-max_used_size: 3379896 > pkmem:22-free_size: 13397504 > pkmem:22-fragments: 3547 > pkmem:23-used_size: 3163936 > pkmem:23-real_used_size: 3379664 > pkmem:23-max_used_size: 3379728 > pkmem:23-free_size: 13397552 > pkmem:23-fragments: 3547 > pkmem:24-used_size: 3163936 > pkmem:24-real_used_size: 3379664 > pkmem:24-max_used_size: 3379728 > pkmem:24-free_size: 13397552 > pkmem:24-fragments: 3547 > pkmem:25-used_size: 3163936 > pkmem:25-real_used_size: 3379664 > pkmem:25-max_used_size: 3379728 > pkmem:25-free_size: 13397552 > pkmem:25-fragments: 3547 > pkmem:26-used_size: 3163936 > pkmem:26-real_used_size: 3379712 > pkmem:26-max_used_size: 3379896 > pkmem:26-free_size: 13397504 > pkmem:26-fragments: 3547 > pkmem:27-used_size: 3163936 > pkmem:27-real_used_size: 3379664 > pkmem:27-max_used_size: 3379728 > pkmem:27-free_size: 13397552 > pkmem:27-fragments: 3547 > pkmem:28-used_size: 3164016 > pkmem:28-real_used_size: 3380848 > pkmem:28-max_used_size: 3385616 > pkmem:28-free_size: 13396368 > pkmem:28-fragments: 3549 > pkmem:29-used_size: 3164016 > pkmem:29-real_used_size: 3380848 > pkmem:29-max_used_size: 3385616 > pkmem:29-free_size: 13396368 > pkmem:29-fragments: 3549 > pkmem:30-used_size: 3164016 > pkmem:30-real_used_size: 3380848 > pkmem:30-max_used_size: 3385616 > pkmem:30-free_size: 13396368 > pkmem:30-fragments: 3549 > pkmem:31-used_size: 3164016 > pkmem:31-real_used_size: 3380848 > pkmem:31-max_used_size: 3385616 > pkmem:31-free_size: 13396368 > pkmem:31-fragments: 3549 > pkmem:32-used_size: 3167120 > pkmem:32-real_used_size: 3386496 > pkmem:32-max_used_size: 3395216 > pkmem:32-free_size: 13390720 > pkmem:32-fragments: 3556 > pkmem:33-used_size: 3166664 > pkmem:33-real_used_size: 3386040 > pkmem:33-max_used_size: 3451584 > pkmem:33-free_size: 13391176 > pkmem:33-fragments: 3554 > pkmem:34-used_size: 3164064 > pkmem:34-real_used_size: 3381952 > pkmem:34-max_used_size: 3389440 > pkmem:34-free_size: 13395264 > pkmem:34-fragments: 3550 > pkmem:35-used_size: 3163936 > pkmem:35-real_used_size: 3379664 > pkmem:35-max_used_size: 3379728 > pkmem:35-free_size: 13397552 > pkmem:35-fragments: 3547 > pkmem:36-used_size: 3163936 > pkmem:36-real_used_size: 3379664 > pkmem:36-max_used_size: 3379728 > pkmem:36-free_size: 13397552 > pkmem:36-fragments: 3547 > pkmem:37-used_size: 3163936 > pkmem:37-real_used_size: 3379664 > pkmem:37-max_used_size: 3379728 > pkmem:37-free_size: 13397552 > pkmem:37-fragments: 3547 > pkmem:38-used_size: 3163936 > pkmem:38-real_used_size: 3379664 > pkmem:38-max_used_size: 3379728 > pkmem:38-free_size: 13397552 > pkmem:38-fragments: 3547 > pkmem:39-used_size: 3166392 > pkmem:39-real_used_size: 3382936 > pkmem:39-max_used_size: 3384192 > pkmem:39-free_size: 13394280 > pkmem:39-fragments: 3548 > pkmem:40-used_size: 3163936 > pkmem:40-real_used_size: 3379712 > pkmem:40-max_used_size: 3379896 > pkmem:40-free_size: 13397504 > pkmem:40-fragments: 3547 > pkmem:41-used_size: 3166456 > pkmem:41-real_used_size: 3383048 > pkmem:41-max_used_size: 3384440 > pkmem:41-free_size: 13394168 > pkmem:41-fragments: 3549 > pkmem:42-used_size: 3166392 > pkmem:42-real_used_size: 3382936 > pkmem:42-max_used_size: 3384240 > pkmem:42-free_size: 13394280 > pkmem:42-fragments: 3548 > pkmem:43-used_size: 3163936 > pkmem:43-real_used_size: 3379712 > pkmem:43-max_used_size: 3379896 > pkmem:43-free_size: 13397504 > pkmem:43-fragments: 3547 > pkmem:44-used_size: 3163936 > pkmem:44-real_used_size: 3379664 > pkmem:44-max_used_size: 3379728 > pkmem:44-free_size: 13397552 > pkmem:44-fragments: 3547 > pkmem:45-used_size: 3166392 > pkmem:45-real_used_size: 3382936 > pkmem:45-max_used_size: 3384192 > pkmem:45-free_size: 13394280 > pkmem:45-fragments: 3548 > pkmem:46-used_size: 3166392 > pkmem:46-real_used_size: 3382936 > pkmem:46-max_used_size: 3384240 > pkmem:46-free_size: 13394280 > pkmem:46-fragments: 3548 > pkmem:47-used_size: 3166392 > pkmem:47-real_used_size: 3382936 > pkmem:47-max_used_size: 3384240 > pkmem:47-free_size: 13394280 > pkmem:47-fragments: 3548 > pkmem:48-used_size: 3166392 > pkmem:48-real_used_size: 3382936 > pkmem:48-max_used_size: 3384264 > pkmem:48-free_size: 13394280 > pkmem:48-fragments: 3548 > pkmem:49-used_size: 2960896 > pkmem:49-real_used_size: 3175664 > pkmem:49-max_used_size: 3175664 > pkmem:49-free_size: 13601552 > pkmem:49-fragments: 2071 > > > I've checked the log, in the initialization the process count seems to > be fine, it finds 50 processes: > > /opensips[4644]: DBG:core:init_pkg_stats: setting stats for 50 processes > / > > > This is the output for /opensips-cli ps:/ > > opensips-cli -x mi ps -o output_type=lines > Processes: >     ID: 0 >     PID: 4644 >     Type: attendant >     ID: 1 >     PID: 4645 >     Type: HTTPD 10.10.10.184:9999 >     ID: 2 >     PID: 4646 >     Type: MI Datagram >     ID: 3 >     PID: 4647 >     Type: RabbitMQ sender >     ID: 4 >     PID: 4648 >     Type: Stun loop >     ID: 5 >     PID: 4649 >     Type: MI FIFO >     ID: 6 >     PID: 4650 >     Type: time_keeper >     ID: 7 >     PID: 4651 >     Type: timer >     ID: 8 >     PID: 4652 >     Type: SIP receiver udp:XXXX:YYY >     ID: 9 >     PID: 4653 >     Type: SIP receiver udp:XXXX:YYY >     ID: 10 >     PID: 4654 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 11 >     PID: 4655 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 12 >     PID: 4656 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 13 >     PID: 4657 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 14 >     PID: 4658 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 15 >     PID: 4659 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 16 >     PID: 4660 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 17 >     PID: 4661 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 18 >     PID: 4662 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 19 >     PID: 4663 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 20 >     PID: 4664 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 21 >     PID: 4665 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 22 >     PID: 4666 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 23 >     PID: 4667 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 24 >     PID: 4668 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 25 >     PID: 4669 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 26 >     PID: 4670 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 27 >     PID: 4671 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 28 >     PID: 4672 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 29 >     PID: 4673 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 30 >     PID: 4674 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 31 >     PID: 4675 >     Type: SIP receiver udp:XXXX:YYYY >     ID: 32 >     PID: 4676 >     Type: TCP receiver >     ID: 33 >     PID: 4677 >     Type: TCP receiver >     ID: 34 >     PID: 4678 >     Type: TCP receiver >     ID: 35 >     PID: 4679 >     Type: TCP receiver >     ID: 36 >     PID: 4680 >     Type: TCP receiver >     ID: 37 >     PID: 4681 >     Type: TCP receiver >     ID: 38 >     PID: 4682 >     Type: TCP receiver >     ID: 39 >     PID: 4683 >     Type: TCP receiver >     ID: 40 >     PID: 4684 >     Type: TCP receiver >     ID: 41 >     PID: 4685 >     Type: TCP receiver >     ID: 42 >     PID: 4686 >     Type: TCP receiver >     ID: 43 >     PID: 4687 >     Type: TCP receiver >     ID: 44 >     PID: 4688 >     Type: TCP receiver >     ID: 45 >     PID: 4689 >     Type: TCP receiver >     ID: 46 >     PID: 4690 >     Type: TCP receiver >     ID: 47 >     PID: 4691 >     Type: TCP receiver >     ID: 48 >     PID: 4692 >     Type: Timer handler >     ID: 49 >     PID: 4693 >     Type: TCP main > > > Is this an expected behaviour? Just wondering if pkmem stats are > available only for workers..(?) > > Thanks! > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Fri May 28 06:32:38 2021 From: mark at allenclan.co.uk (Mark Allen) Date: Fri, 28 May 2021 07:32:38 +0100 Subject: [OpenSIPS-Users] error_route not triggered for parsing error In-Reply-To: References: Message-ID: Thanks Bogdan - will do On Fri, 28 May 2021 at 06:54, Bogdan-Andrei Iancu wrote: > Hi Mark, > > Consider opening a ticket on github. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp 2021 online > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 5/27/21 2:57 PM, Mark Allen wrote: > > This seems to link to a past thread where error_route is not triggering if > the first line is malformed. Unfortunately, there is no resolution to this > past thread - link here: > https://opensips.org/pipermail/users/2019-February/040605.html > > On Thu, 27 May 2021 at 11:56, Mark Allen wrote: > >> >> In my script, I have an error_route... >> >> error_route { >> xlog("--- error route class=$(err.class) level=$(err.level) >> info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) >> ---\n"); >> xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n"); >> sl_send_reply($err.rcode, "$err.rreason"); >> exit; >> } >> >> ...but when I get a message parsing error, the error_route seems to >> ignore it. What am I doing wrong? >> >> ERROR:core:parse_method: invalid character : >> INFO:core:parse_first_line: failed to parse the method >> INFO:core:parse_first_line: bad message >> ERROR:core:parse_msg: message=#015#012User-Agent: >> MWWRTC 3.4.21042#015#012Accept: >> application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 >> OK#015#012Via: SIP/2.0/TCP 192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From: >> ;tag=33e693c3#015#012To: >> ;tag=1550918023#015#012Call-ID: >> fc585e54-72a5d21-ab2 at 192.168.1.23#015#012CSeq >> : 1 >> OPTIONS#015#012User-Agent: Yealink SIP-T54W#015#012Content-Length: >> 0#015#012#015#012> >> ERROR:core:receive_msg: Unable to parse msg received from [ >> 192.168.1.23:5060] >> ERROR:core:tcp_handle_req: receive_msg failed >> >> >> We are running OpenSIPS 3.1 >> >> >> (this is a follow-up to my other query >> http://lists.opensips.org/pipermail/users/2021-May/044776.html) >> >> > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Fri May 28 07:27:52 2021 From: mark at allenclan.co.uk (Mark Allen) Date: Fri, 28 May 2021 08:27:52 +0100 Subject: [OpenSIPS-Users] error_route not triggered for parsing error In-Reply-To: References: Message-ID: Ticket raised - https://github.com/OpenSIPS/opensips/issues/2533 On Fri, 28 May 2021 at 07:32, Mark Allen wrote: > Thanks Bogdan - will do > > On Fri, 28 May 2021 at 06:54, Bogdan-Andrei Iancu > wrote: > >> Hi Mark, >> >> Consider opening a ticket on github. >> >> Regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Bootcamp 2021 online >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 5/27/21 2:57 PM, Mark Allen wrote: >> >> This seems to link to a past thread where error_route is not triggering >> if the first line is malformed. Unfortunately, there is no resolution to >> this past thread - link here: >> https://opensips.org/pipermail/users/2019-February/040605.html >> >> On Thu, 27 May 2021 at 11:56, Mark Allen wrote: >> >>> >>> In my script, I have an error_route... >>> >>> error_route { >>> xlog("--- error route class=$(err.class) level=$(err.level) >>> info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) >>> ---\n"); >>> xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n"); >>> sl_send_reply($err.rcode, "$err.rreason"); >>> exit; >>> } >>> >>> ...but when I get a message parsing error, the error_route seems to >>> ignore it. What am I doing wrong? >>> >>> ERROR:core:parse_method: invalid character : >>> INFO:core:parse_first_line: failed to parse the method >>> INFO:core:parse_first_line: bad message >>> ERROR:core:parse_msg: message=#015#012User-Agent: >>> MWWRTC 3.4.21042#015#012Accept: >>> application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 >>> OK#015#012Via: SIP/2.0/TCP 192.168.1.23:5060;rport=57559;received=192.168.1.23;branch=z9hG4bK72a5d21#015#012From: >>> ;tag=33e693c3#015#012To: >>> ;tag=1550918023#015#012Call-ID: >>> fc585e54-72a5d21-ab2 at 192.168.1.23#015#012CSeq >>> : 1 >>> OPTIONS#015#012User-Agent: Yealink SIP-T54W#015#012Content-Length: >>> 0#015#012#015#012> >>> ERROR:core:receive_msg: Unable to parse msg received from [ >>> 192.168.1.23:5060] >>> ERROR:core:tcp_handle_req: receive_msg failed >>> >>> >>> We are running OpenSIPS 3.1 >>> >>> >>> (this is a follow-up to my other query >>> http://lists.opensips.org/pipermail/users/2021-May/044776.html) >>> >>> >> _______________________________________________ >> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Fri May 28 08:41:38 2021 From: johan at democon.be (johan) Date: Fri, 28 May 2021 10:41:38 +0200 Subject: [OpenSIPS-Users] problem on compiling 3.2 Message-ID: <157707ac-00e2-76fc-c1f1-6db9319bdec2@democon.be> Although I did not request to include tls, the installer tries to compile the tls modules. which fails on wolf tls. (same problem as Social Boh). Is there a solution for this ? BR, -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xD7D896F7DDA70EC3.asc Type: application/pgp-keys Size: 2450 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From johan at democon.be Fri May 28 10:39:48 2021 From: johan at democon.be (johan) Date: Fri, 28 May 2021 12:39:48 +0200 Subject: [OpenSIPS-Users] avp scope bug in 3.2 ? Message-ID: script : local_route {     xlog("callid=$ci: local_route: received message $mb");     xlog("callid=$ci: local_route: what ever comes from local goes to b2bua");     $avp(b2bua)=1;     xlog("callid=$ci: avp(b2bua)=$avp(b2bua)"); } route[relay] {     # for INVITEs enable some additional helper routes     xlog("route realy ft [$ft] tt [$tt]");     if (is_method("INVITE"))     {         t_on_branch("per_branch_ops");         t_on_reply("handle_nat");         t_on_failure("missed_call");         route(rtpengine);     }     if ($avp(b2bua)==1)     {         xlog("route relay: avp(b2bua)=$avp(b2bua)==1; adding record-route, reset avp and sending to b2bua");         $avp(b2bua)=0;         record_route();         if (!t_relay(,"udp:192.168.68.116:5060"))         {             send_reply(500,"Internal Error");             xlog("route relay: routing to b2bua failed");         }     }     else     {         xlog("route relay: avp(b2bua)=$avp(b2bua)!=1; normal call flow ");         if (!t_relay())         {             send_reply(500,"Internal Error");         }     }     exit; } expected behaviour :when local_route is entered the avp value goes to 1. I would expect it to be 1 in route[relay] also. However : May 28 06:31:02 debian10opensips31 /data/opensips/sbin/opensips[13548]: callid=1976ffb3-6749-4920-b7ef-5ce56cef6c8a: local_route: what ever comes from local goes to b2bua May 28 06:31:02 debian10opensips31 /data/opensips/sbin/opensips[13548]: callid=1976ffb3-6749-4920-b7ef-5ce56cef6c8a: avp(b2bua)=1 ... May 28 06:31:02 debian10opensips31 /data/opensips/sbin/opensips[13543]: route relay: avp(b2bua)=!=1; normal call flow => avp(b2bua) is not seen in route[relay].  Is this a bug or is this intended behaviour ? __ _ _ _wkr, _ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xD7D896F7DDA70EC3.asc Type: application/pgp-keys Size: 2450 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From social at bohboh.info Fri May 28 10:58:55 2021 From: social at bohboh.info (Social Boh) Date: Fri, 28 May 2021 05:58:55 -0500 Subject: [OpenSIPS-Users] OpenSIPs HA with KeepAlived In-Reply-To: <84d6216e-0953-dc80-9e04-07d68b7457b5@opensips.org> References: <84d6216e-0953-dc80-9e04-07d68b7457b5@opensips.org> Message-ID: Hello, I'l try to traslate tu english soon, after a new testing. Regards --- I'm SoCIaL, MayBe El 28/05/2021 a las 12:56 a. m., Bogdan-Andrei Iancu escribió: > Hi, no English version of it ? > > Regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp 2021 online > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > On 4/30/21 4:12 PM, Social Boh wrote: >> >> Hello list, >> >> maybe someone might be interested: "OpenSIPs 3.1 HA with KeepAlilved": >> >> https://www.voztovoice.org/?q=node/2879 >> >> Spanish Article >> >> -- >> --- >> I'm SoCIaL, MayBe >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhc at 3clogic.com Fri May 28 11:56:19 2021 From: saurabhc at 3clogic.com (Saurabh Chopra) Date: Fri, 28 May 2021 17:26:19 +0530 Subject: [OpenSIPS-Users] TLS_MGM module with DB(MYSQL) In-Reply-To: References: Message-ID: Hi Opensips Team/ Callum, Thanks for the response, I successfully inserted the content of my files(certificate) in mysql DB. But when I try to run the script the opensips is crashing now with errors. May 28 11:45:59 /usr/local/sbin/opensips[1268]: CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '.36.64:443,match_sip_domain,type,method,0,0,certificate,private_key,crl_check_al' at line 1 May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:core:db_do_query: error while submitting query - [select id,xxxx.i3clogic.com,x.x.36.64:443,match_sip_domain,type,method,0,0,certificate,private_key,crl_check_all,crl_dir,ca_list,ca_dir,cipher_list,dh_params,ec_curve from tls_mgm ] May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:tls_mgm:load_info: DB query failed - retrieve valid connections May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:tls_mgm:load_info: Unable to load domains info from DB May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:core:init_mod: failed to initialize module tls_mgm May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:core:main: error while initializing modules Given these parameters in the config script. loadmodule "tls_mgm.so" modparam("tls_mgm", "db_url", "mysql://root:xxxxx at localhost/opensips") modparam("tls_mgm", "db_table", "tls_mgm") modparam("tls_mgm", "domain_col", "xxxxxx.i3clogic.com") modparam("tls_mgm", "match_ip_address_col", "xx.xx36.64:443") modparam("tls_mgm", "tls_method_col", "method") modparam("tls_mgm", "verify_cert_col", "0") modparam("tls_mgm", "require_cert_col", "0") modparam("tls_mgm", "certificate_col", "certificate") modparam("tls_mgm", "private_key_col", "private_key") modparam("tls_mgm", "crl_check_all_col", "crl_check_all") modparam("tls_mgm", "crl_dir_col", "crl_dir") modparam("tls_mgm", "ca_list_col", "ca_list") Kindly help in this matter. Best Regards Saurabh Chopra +918861979979 On Wed, May 26, 2021 at 5:06 PM Callum Guy wrote: > You need to insert the certificate contents into the table rather than a > file, to my understanding - you'd probably want to convert the certs to PEM > format prior to doing this. > > > > > > On Tue, 25 May 2021 at 14:20, Saurabh Chopra wrote: > >> Hi Opensips Team/Razvan, >> >> I am using the TLS_MGM module to validate my certificate file through a >> database (mysql) but getting the below error. >> >> May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: >> NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none >> May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: *ERROR:tls_mgm:load_certificate_db: >> Unable to load certificate from buffer* >> May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: >> WARNING:tls_mgm:init_tls_domains: Failed to init TLS domain 'default', >> skipping... >> >> The data i have put in DB is depicted below:- >> >> insert into tls_mgm >> (id,domain,match_ip_address,match_sip_domain,type,method,verify_cert,require_cert,certificate,private_key,crl_check_all,crl_dir,ca_list,ca_dir, >> cipher_list,dh_params,ec_curve) values >> ('1','default','20.0.xx.xx:443','','1','SSLv23','1','0','xxxx2021.der','xxxx.der','0','','xxxxx2021.der','','ALL','',''); >> >> *.der* files are the binary file for certificate file, private key file >> and ca_list . However the same is working fine through the configuration >> script. >> >> Can anybody confirm what I am doing wrong ? >> >> >> Best Regards >> Saurabh Chopra >> +918861979979 >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > *0333 332 0000 | x-on.co.uk | ** > > ** | Coronavirus > ** > | Practice Index Reviews * > > THE ITSPA AWARDS 2020 AND Best > ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks > of the Internet Telephony Services Providers' Association, used under > licence. > > *Our new office address: 22 Riduna Park, Melton IP12 1QT.* > > X-on is a trading name of Storacall Technology Ltd a limited company > registered in England and Wales. > Registered Office : Avaland House, 110 London Road, Apsley, Hemel > Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient, please notify > X-on immediately on +44(0)333 332 0000 and delete the > message from your computer. If you are not a named addressee you must not > use, disclose, disseminate, distribute, copy, print or reply to this email. Views > or opinions expressed by an individual > within this email may not necessarily reflect the views of X-on or its > associated companies. Although X-on routinely screens for viruses, > addressees should scan this email and any attachments > for viruses. X-on makes no representation or warranty as to the absence of > viruses in this email or any attachments. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedorna at anura.com.ar Fri May 28 12:23:27 2021 From: fedorna at anura.com.ar (Federico Edorna) Date: Fri, 28 May 2021 09:23:27 -0300 Subject: [OpenSIPS-Users] pkmem statistics for version 3.1 In-Reply-To: <9f7efa2e-b094-2cd9-2905-48b12d128ce3@opensips.org> References: <9f7efa2e-b094-2cd9-2905-48b12d128ce3@opensips.org> Message-ID: Ok, thanks Bogdan! On Fri, May 28, 2021 at 2:59 AM Bogdan-Andrei Iancu wrote: > Hi Federico, > > Starting 3.0, the way we fetch the pkg stats from all the procs did > change, from the unreliable and problem maker mechanism based on SIGUSR1, > to using the internal IPC support. Unfortunately the extra MI procs have no > IPC support, but this was fixed in 3.2. > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Bootcamp 2021 online > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 4/30/21 7:34 PM, Federico Edorna wrote: > > Hello! moving from 2.4 to 3.1 I've found something strange in pkmem stats. > MI is showing zero values for the first 7 processes > > > *opensips-cli -x mi get_statistics pkmem: -o output_type=lines *pkmem:1-used_size: > 0 > pkmem:1-real_used_size: 0 > pkmem:1-max_used_size: 0 > pkmem:1-free_size: 0 > pkmem:1-fragments: 0 > pkmem:2-used_size: 0 > pkmem:2-real_used_size: 0 > pkmem:2-max_used_size: 0 > pkmem:2-free_size: 0 > pkmem:2-fragments: 0 > pkmem:3-used_size: 0 > pkmem:3-real_used_size: 0 > pkmem:3-max_used_size: 0 > pkmem:3-free_size: 0 > pkmem:3-fragments: 0 > pkmem:4-used_size: 0 > pkmem:4-real_used_size: 0 > pkmem:4-max_used_size: 0 > pkmem:4-free_size: 0 > pkmem:4-fragments: 0 > pkmem:5-used_size: 0 > pkmem:5-real_used_size: 0 > pkmem:5-max_used_size: 0 > pkmem:5-free_size: 0 > pkmem:5-fragments: 0 > pkmem:6-used_size: 0 > pkmem:6-real_used_size: 0 > pkmem:6-max_used_size: 0 > pkmem:6-free_size: 0 > pkmem:6-fragments: 0 > pkmem:7-used_size: 0 > pkmem:7-real_used_size: 0 > pkmem:7-max_used_size: 0 > pkmem:7-free_size: 0 > pkmem:7-fragments: 0 > pkmem:8-used_size: 3167224 > pkmem:8-real_used_size: 3387464 > pkmem:8-max_used_size: 3396024 > pkmem:8-free_size: 13389752 > pkmem:8-fragments: 3561 > pkmem:9-used_size: 3164712 > pkmem:9-real_used_size: 3385048 > pkmem:9-max_used_size: 3393616 > pkmem:9-free_size: 13392168 > pkmem:9-fragments: 3559 > pkmem:10-used_size: 3164736 > pkmem:10-real_used_size: 3385360 > pkmem:10-max_used_size: 3393904 > pkmem:10-free_size: 13391856 > pkmem:10-fragments: 3559 > pkmem:11-used_size: 3164688 > pkmem:11-real_used_size: 3385840 > pkmem:11-max_used_size: 3394384 > pkmem:11-free_size: 13391376 > pkmem:11-fragments: 3558 > pkmem:12-used_size: 3163936 > pkmem:12-real_used_size: 3379712 > pkmem:12-max_used_size: 3379896 > pkmem:12-free_size: 13397504 > pkmem:12-fragments: 3547 > pkmem:13-used_size: 3163936 > pkmem:13-real_used_size: 3379712 > pkmem:13-max_used_size: 3379896 > pkmem:13-free_size: 13397504 > pkmem:13-fragments: 3547 > pkmem:14-used_size: 3163936 > pkmem:14-real_used_size: 3379664 > pkmem:14-max_used_size: 3379728 > pkmem:14-free_size: 13397552 > pkmem:14-fragments: 3547 > pkmem:15-used_size: 3163936 > pkmem:15-real_used_size: 3379712 > pkmem:15-max_used_size: 3379896 > pkmem:15-free_size: 13397504 > pkmem:15-fragments: 3547 > pkmem:16-used_size: 3163936 > pkmem:16-real_used_size: 3379664 > pkmem:16-max_used_size: 3379728 > pkmem:16-free_size: 13397552 > pkmem:16-fragments: 3547 > pkmem:17-used_size: 3163936 > pkmem:17-real_used_size: 3379664 > pkmem:17-max_used_size: 3379728 > pkmem:17-free_size: 13397552 > pkmem:17-fragments: 3547 > pkmem:18-used_size: 3163936 > pkmem:18-real_used_size: 3379664 > pkmem:18-max_used_size: 3379728 > pkmem:18-free_size: 13397552 > pkmem:18-fragments: 3547 > pkmem:19-used_size: 3163936 > pkmem:19-real_used_size: 3379664 > pkmem:19-max_used_size: 3379728 > pkmem:19-free_size: 13397552 > pkmem:19-fragments: 3547 > pkmem:20-used_size: 3163936 > pkmem:20-real_used_size: 3379664 > pkmem:20-max_used_size: 3379728 > pkmem:20-free_size: 13397552 > pkmem:20-fragments: 3547 > pkmem:21-used_size: 3163936 > pkmem:21-real_used_size: 3379664 > pkmem:21-max_used_size: 3379728 > pkmem:21-free_size: 13397552 > pkmem:21-fragments: 3547 > pkmem:22-used_size: 3163936 > pkmem:22-real_used_size: 3379712 > pkmem:22-max_used_size: 3379896 > pkmem:22-free_size: 13397504 > pkmem:22-fragments: 3547 > pkmem:23-used_size: 3163936 > pkmem:23-real_used_size: 3379664 > pkmem:23-max_used_size: 3379728 > pkmem:23-free_size: 13397552 > pkmem:23-fragments: 3547 > pkmem:24-used_size: 3163936 > pkmem:24-real_used_size: 3379664 > pkmem:24-max_used_size: 3379728 > pkmem:24-free_size: 13397552 > pkmem:24-fragments: 3547 > pkmem:25-used_size: 3163936 > pkmem:25-real_used_size: 3379664 > pkmem:25-max_used_size: 3379728 > pkmem:25-free_size: 13397552 > pkmem:25-fragments: 3547 > pkmem:26-used_size: 3163936 > pkmem:26-real_used_size: 3379712 > pkmem:26-max_used_size: 3379896 > pkmem:26-free_size: 13397504 > pkmem:26-fragments: 3547 > pkmem:27-used_size: 3163936 > pkmem:27-real_used_size: 3379664 > pkmem:27-max_used_size: 3379728 > pkmem:27-free_size: 13397552 > pkmem:27-fragments: 3547 > pkmem:28-used_size: 3164016 > pkmem:28-real_used_size: 3380848 > pkmem:28-max_used_size: 3385616 > pkmem:28-free_size: 13396368 > pkmem:28-fragments: 3549 > pkmem:29-used_size: 3164016 > pkmem:29-real_used_size: 3380848 > pkmem:29-max_used_size: 3385616 > pkmem:29-free_size: 13396368 > pkmem:29-fragments: 3549 > pkmem:30-used_size: 3164016 > pkmem:30-real_used_size: 3380848 > pkmem:30-max_used_size: 3385616 > pkmem:30-free_size: 13396368 > pkmem:30-fragments: 3549 > pkmem:31-used_size: 3164016 > pkmem:31-real_used_size: 3380848 > pkmem:31-max_used_size: 3385616 > pkmem:31-free_size: 13396368 > pkmem:31-fragments: 3549 > pkmem:32-used_size: 3167120 > pkmem:32-real_used_size: 3386496 > pkmem:32-max_used_size: 3395216 > pkmem:32-free_size: 13390720 > pkmem:32-fragments: 3556 > pkmem:33-used_size: 3166664 > pkmem:33-real_used_size: 3386040 > pkmem:33-max_used_size: 3451584 > pkmem:33-free_size: 13391176 > pkmem:33-fragments: 3554 > pkmem:34-used_size: 3164064 > pkmem:34-real_used_size: 3381952 > pkmem:34-max_used_size: 3389440 > pkmem:34-free_size: 13395264 > pkmem:34-fragments: 3550 > pkmem:35-used_size: 3163936 > pkmem:35-real_used_size: 3379664 > pkmem:35-max_used_size: 3379728 > pkmem:35-free_size: 13397552 > pkmem:35-fragments: 3547 > pkmem:36-used_size: 3163936 > pkmem:36-real_used_size: 3379664 > pkmem:36-max_used_size: 3379728 > pkmem:36-free_size: 13397552 > pkmem:36-fragments: 3547 > pkmem:37-used_size: 3163936 > pkmem:37-real_used_size: 3379664 > pkmem:37-max_used_size: 3379728 > pkmem:37-free_size: 13397552 > pkmem:37-fragments: 3547 > pkmem:38-used_size: 3163936 > pkmem:38-real_used_size: 3379664 > pkmem:38-max_used_size: 3379728 > pkmem:38-free_size: 13397552 > pkmem:38-fragments: 3547 > pkmem:39-used_size: 3166392 > pkmem:39-real_used_size: 3382936 > pkmem:39-max_used_size: 3384192 > pkmem:39-free_size: 13394280 > pkmem:39-fragments: 3548 > pkmem:40-used_size: 3163936 > pkmem:40-real_used_size: 3379712 > pkmem:40-max_used_size: 3379896 > pkmem:40-free_size: 13397504 > pkmem:40-fragments: 3547 > pkmem:41-used_size: 3166456 > pkmem:41-real_used_size: 3383048 > pkmem:41-max_used_size: 3384440 > pkmem:41-free_size: 13394168 > pkmem:41-fragments: 3549 > pkmem:42-used_size: 3166392 > pkmem:42-real_used_size: 3382936 > pkmem:42-max_used_size: 3384240 > pkmem:42-free_size: 13394280 > pkmem:42-fragments: 3548 > pkmem:43-used_size: 3163936 > pkmem:43-real_used_size: 3379712 > pkmem:43-max_used_size: 3379896 > pkmem:43-free_size: 13397504 > pkmem:43-fragments: 3547 > pkmem:44-used_size: 3163936 > pkmem:44-real_used_size: 3379664 > pkmem:44-max_used_size: 3379728 > pkmem:44-free_size: 13397552 > pkmem:44-fragments: 3547 > pkmem:45-used_size: 3166392 > pkmem:45-real_used_size: 3382936 > pkmem:45-max_used_size: 3384192 > pkmem:45-free_size: 13394280 > pkmem:45-fragments: 3548 > pkmem:46-used_size: 3166392 > pkmem:46-real_used_size: 3382936 > pkmem:46-max_used_size: 3384240 > pkmem:46-free_size: 13394280 > pkmem:46-fragments: 3548 > pkmem:47-used_size: 3166392 > pkmem:47-real_used_size: 3382936 > pkmem:47-max_used_size: 3384240 > pkmem:47-free_size: 13394280 > pkmem:47-fragments: 3548 > pkmem:48-used_size: 3166392 > pkmem:48-real_used_size: 3382936 > pkmem:48-max_used_size: 3384264 > pkmem:48-free_size: 13394280 > pkmem:48-fragments: 3548 > pkmem:49-used_size: 2960896 > pkmem:49-real_used_size: 3175664 > pkmem:49-max_used_size: 3175664 > pkmem:49-free_size: 13601552 > pkmem:49-fragments: 2071 > > > I've checked the log, in the initialization the process count seems to be > fine, it finds 50 processes: > > > *opensips[4644]: DBG:core:init_pkg_stats: setting stats for 50 processes * > > > This is the output for *opensips-cli ps:* > > opensips-cli -x mi ps -o output_type=lines > Processes: > ID: 0 > PID: 4644 > Type: attendant > ID: 1 > PID: 4645 > Type: HTTPD 10.10.10.184:9999 > ID: 2 > PID: 4646 > Type: MI Datagram > ID: 3 > PID: 4647 > Type: RabbitMQ sender > ID: 4 > PID: 4648 > Type: Stun loop > ID: 5 > PID: 4649 > Type: MI FIFO > ID: 6 > PID: 4650 > Type: time_keeper > ID: 7 > PID: 4651 > Type: timer > ID: 8 > PID: 4652 > Type: SIP receiver udp:XXXX:YYY > ID: 9 > PID: 4653 > Type: SIP receiver udp:XXXX:YYY > ID: 10 > PID: 4654 > Type: SIP receiver udp:XXXX:YYYY > ID: 11 > PID: 4655 > Type: SIP receiver udp:XXXX:YYYY > ID: 12 > PID: 4656 > Type: SIP receiver udp:XXXX:YYYY > ID: 13 > PID: 4657 > Type: SIP receiver udp:XXXX:YYYY > ID: 14 > PID: 4658 > Type: SIP receiver udp:XXXX:YYYY > ID: 15 > PID: 4659 > Type: SIP receiver udp:XXXX:YYYY > ID: 16 > PID: 4660 > Type: SIP receiver udp:XXXX:YYYY > ID: 17 > PID: 4661 > Type: SIP receiver udp:XXXX:YYYY > ID: 18 > PID: 4662 > Type: SIP receiver udp:XXXX:YYYY > ID: 19 > PID: 4663 > Type: SIP receiver udp:XXXX:YYYY > ID: 20 > PID: 4664 > Type: SIP receiver udp:XXXX:YYYY > ID: 21 > PID: 4665 > Type: SIP receiver udp:XXXX:YYYY > ID: 22 > PID: 4666 > Type: SIP receiver udp:XXXX:YYYY > ID: 23 > PID: 4667 > Type: SIP receiver udp:XXXX:YYYY > ID: 24 > PID: 4668 > Type: SIP receiver udp:XXXX:YYYY > ID: 25 > PID: 4669 > Type: SIP receiver udp:XXXX:YYYY > ID: 26 > PID: 4670 > Type: SIP receiver udp:XXXX:YYYY > ID: 27 > PID: 4671 > Type: SIP receiver udp:XXXX:YYYY > ID: 28 > PID: 4672 > Type: SIP receiver udp:XXXX:YYYY > ID: 29 > PID: 4673 > Type: SIP receiver udp:XXXX:YYYY > ID: 30 > PID: 4674 > Type: SIP receiver udp:XXXX:YYYY > ID: 31 > PID: 4675 > Type: SIP receiver udp:XXXX:YYYY > ID: 32 > PID: 4676 > Type: TCP receiver > ID: 33 > PID: 4677 > Type: TCP receiver > ID: 34 > PID: 4678 > Type: TCP receiver > ID: 35 > PID: 4679 > Type: TCP receiver > ID: 36 > PID: 4680 > Type: TCP receiver > ID: 37 > PID: 4681 > Type: TCP receiver > ID: 38 > PID: 4682 > Type: TCP receiver > ID: 39 > PID: 4683 > Type: TCP receiver > ID: 40 > PID: 4684 > Type: TCP receiver > ID: 41 > PID: 4685 > Type: TCP receiver > ID: 42 > PID: 4686 > Type: TCP receiver > ID: 43 > PID: 4687 > Type: TCP receiver > ID: 44 > PID: 4688 > Type: TCP receiver > ID: 45 > PID: 4689 > Type: TCP receiver > ID: 46 > PID: 4690 > Type: TCP receiver > ID: 47 > PID: 4691 > Type: TCP receiver > ID: 48 > PID: 4692 > Type: Timer handler > ID: 49 > PID: 4693 > Type: TCP main > > > Is this an expected behaviour? Just wondering if pkmem stats are available > only for workers..(?) > > Thanks! > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Fri May 28 12:56:13 2021 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Fri, 28 May 2021 15:56:13 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?OpenSIPs_HA_with_KeepAlived?= In-Reply-To: References: <84d6216e-0953-dc80-9e04-07d68b7457b5@opensips.org> Message-ID: <1622206573.239715521@f430.i.mail.ru> Nice article, but nothing about RTPEngine High Availability ;)   Storing RTPEngine data in 2 Redis instances (RW and RO) by each OpenSIPS node is the way to keep active calls going on in case of any problems with some of nodes.   ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/   -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Fri May 28 13:51:42 2021 From: callum.guy at x-on.co.uk (Callum Guy) Date: Fri, 28 May 2021 14:51:42 +0100 Subject: [OpenSIPS-Users] TLS_MGM module with DB(MYSQL) In-Reply-To: References: Message-ID: I'm a bit lost with regards to your setup/intentions but I think you might be misusing those config values - if in doubt try the vanilla implementation using an unmodified table and limited module parameters, start small and build! Of concern: modparam("tls_mgm", "domain_col", "xxxxxx.i3clogic.com") < is that really your column name?? modparam("tls_mgm", "match_ip_address_col", "xx.xx36.64:443") < is that really your column name?? I'm wondering if you have interpreted those as default values? https://opensips.org/html/docs/modules/3.0.x/tls_mgm.html#idp5640928 Initially just try with the value "default" for domain - thats a special catch all value: [image: image.png] On Fri, 28 May 2021 at 12:59, Saurabh Chopra wrote: > Hi Opensips Team/ Callum, > > Thanks for the response, I successfully inserted the content of my > files(certificate) in mysql DB. But when I try to run the script the > opensips is crashing now with errors. > > May 28 11:45:59 /usr/local/sbin/opensips[1268]: > CRITICAL:db_mysql:wrapper_single_mysql_real_query: driver error (1064): You > have an error in your SQL syntax; check the manual that corresponds to your > MySQL server version for the right syntax to use near > '.36.64:443,match_sip_domain,type,method,0,0,certificate,private_key,crl_check_al' > at line 1 > May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:core:db_do_query: > error while submitting query - [select id,xxxx.i3clogic.com,x.x.36.64:443,match_sip_domain,type,method,0,0,certificate,private_key,crl_check_all,crl_dir,ca_list,ca_dir,cipher_list,dh_params,ec_curve > from tls_mgm ] > May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:tls_mgm:load_info: > DB query failed - retrieve valid connections > May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:tls_mgm:load_info: > Unable to load domains info from DB > May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:core:init_mod: > failed to initialize module tls_mgm > May 28 11:45:59 /usr/local/sbin/opensips[1268]: ERROR:core:main: error > while initializing modules > > Given these parameters in the config script. > > loadmodule "tls_mgm.so" > modparam("tls_mgm", "db_url", "mysql://root:xxxxx at localhost/opensips") > modparam("tls_mgm", "db_table", "tls_mgm") > modparam("tls_mgm", "domain_col", "xxxxxx.i3clogic.com") > modparam("tls_mgm", "match_ip_address_col", "xx.xx36.64:443") > modparam("tls_mgm", "tls_method_col", "method") > modparam("tls_mgm", "verify_cert_col", "0") > modparam("tls_mgm", "require_cert_col", "0") > modparam("tls_mgm", "certificate_col", "certificate") > modparam("tls_mgm", "private_key_col", "private_key") > modparam("tls_mgm", "crl_check_all_col", "crl_check_all") > modparam("tls_mgm", "crl_dir_col", "crl_dir") > modparam("tls_mgm", "ca_list_col", "ca_list") > > Kindly help in this matter. > > Best Regards > Saurabh Chopra > +918861979979 > > > On Wed, May 26, 2021 at 5:06 PM Callum Guy wrote: > >> You need to insert the certificate contents into the table rather than a >> file, to my understanding - you'd probably want to convert the certs to PEM >> format prior to doing this. >> >> >> >> >> >> On Tue, 25 May 2021 at 14:20, Saurabh Chopra >> wrote: >> >>> Hi Opensips Team/Razvan, >>> >>> I am using the TLS_MGM module to validate my certificate file through a >>> database (mysql) but getting the below error. >>> >>> May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: >>> NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none >>> May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: *ERROR:tls_mgm:load_certificate_db: >>> Unable to load certificate from buffer* >>> May 25 12:41:28 ip-20-0-36-64 /usr/local/sbin/opensips[16297]: >>> WARNING:tls_mgm:init_tls_domains: Failed to init TLS domain 'default', >>> skipping... >>> >>> The data i have put in DB is depicted below:- >>> >>> insert into tls_mgm >>> (id,domain,match_ip_address,match_sip_domain,type,method,verify_cert,require_cert,certificate,private_key,crl_check_all,crl_dir,ca_list,ca_dir, >>> cipher_list,dh_params,ec_curve) values >>> ('1','default','20.0.xx.xx:443','','1','SSLv23','1','0','xxxx2021.der','xxxx.der','0','','xxxxx2021.der','','ALL','',''); >>> >>> *.der* files are the binary file for certificate file, private key file >>> and ca_list . However the same is working fine through the configuration >>> script. >>> >>> Can anybody confirm what I am doing wrong ? >>> >>> >>> Best Regards >>> Saurabh Chopra >>> +918861979979 >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> *0333 332 0000 | x-on.co.uk | ** >> >> ** | Coronavirus >> ** >> | Practice Index Reviews * >> >> THE ITSPA AWARDS 2020 AND Best >> ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks >> of the Internet Telephony Services Providers' Association, used under >> licence. >> >> *Our new office address: 22 Riduna Park, Melton IP12 1QT.* >> >> X-on is a trading name of Storacall Technology Ltd a limited company >> registered in England and Wales. >> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >> The information in this e-mail is confidential and for use by the >> addressee(s) only. If you are not the intended recipient, please notify >> X-on immediately on +44(0)333 332 0000 and delete the >> message from your computer. If you are not a named addressee you must not >> use, disclose, disseminate, distribute, copy, print or reply to this email. Views >> or opinions expressed by an individual >> within this email may not necessarily reflect the views of X-on or its >> associated companies. Although X-on routinely screens for viruses, >> addressees should scan this email and any attachments >> for viruses. X-on makes no representation or warranty as to the absence >> of viruses in this email or any attachments. >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus **  |   Practice Index Reviews * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. *Our new office address: 22 Riduna Park, Melton IP12 1QT.* X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 10668 bytes Desc: not available URL: From bogdan at opensips.org Fri May 28 14:33:39 2021 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Fri, 28 May 2021 17:33:39 +0300 Subject: [OpenSIPS-Users] OpenSIPs HA with KeepAlived In-Reply-To: References: <84d6216e-0953-dc80-9e04-07d68b7457b5@opensips.org> Message-ID: <829f70e4-d2a7-819e-f2f0-fe55f519fe60@opensips.org> If you have an English one, we can link it from the opensips.org web page ;) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Bootcamp 2021 online https://opensips.org/training/OpenSIPS_eBootcamp_2021/ On 5/28/21 1:58 PM, Social Boh wrote: > > Hello, > > I'l try to traslate tu english soon, after a new testing. > > Regards > > --- > I'm SoCIaL, MayBe > El 28/05/2021 a las 12:56 a. m., Bogdan-Andrei Iancu escribió: >> Hi, no English version of it ? >> >> Regards, >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS Bootcamp 2021 online >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> On 4/30/21 4:12 PM, Social Boh wrote: >>> >>> Hello list, >>> >>> maybe someone might be interested: "OpenSIPs 3.1 HA with KeepAlilved": >>> >>> https://www.voztovoice.org/?q=node/2879 >>> >>> Spanish Article >>> >>> -- >>> --- >>> I'm SoCIaL, MayBe >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Mon May 31 18:47:16 2021 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 31 May 2021 19:47:16 +0100 Subject: [OpenSIPS-Users] Getting header from 302 Message-ID: Hello Guys, I'm getting a header on a 302 which i'm trying to get, but for some reason I can't. This is an example 302: 2021/05/31 18:42:36.499157 10.231.32.237:5060 -> 10.231.57.11:6075 SIP/2.0 302 Redirect Via: SIP/2.0/UDP 1.2.3.4: 6075;branch=z9hG4bKd8e8.50036ee6.0;received=10.231.57.11 Via: SIP/2.0/UDP 10.231.33.135;branch=z9hG4bKd8e8.fe2738f41d26b2b68328691c326a077a.0 v:SIP/2.0/UDP 10.231.49.211:6060 ;received=10.231.49.211;rport=6060;branch=z9hG4bK68SgceeareaUa f:"+18883333333";tag=ZBQ713X9pgD5S t:;tag=9dd61ff61e802d8e2bef5f14621ef3c2.50cf6b6c i:cf649a38-3ce2-123a-eaad-122eaa5d9655 CSeq:36689486 INVITE Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9vcHMtc3RhdGljLnMzLmFtYXpvbmF3cy5jb20vc3Rpci1zaGFrZW4vZWMyNTYtcHVibGljLnBlbSJ9.eyJhdHRlc3QiO BIiwiZGVzdCI6eyJ0biI6WyIxNzg2NDEwNzgzNyJdfSwiaWF0IjoxNjIyNDg2NTU2LCJvcmlnIjp7InRuIjoiKzEzMTU5ODUyNTk0In0sIm9yaWdpZCI6IjhlZGE4M2Q1LWY1MjEtNDQzZC1iNDI0LWIzNDQ3MDc4ZjYxZCJ9.cjIz9VwlS9_6qA 6mmDgottk41BLpQcA40HdvV_6jAPqQ1EIL3_jLWl25oHeVEWOzTMhcERp4Jn-JZ4vP_n3w;info=< https://somedomain.com/stir-shaken/ec256-public.pem>;alg=ES256;ppt=shaken Server: kamailio (5.5.0 (x86_64/linux)) Content-Length: 0 I'm trying to get the "Identity" header with: $avp(identity_header) = $(hdr(Identity)); But It's coming up Any ideas of what I'm doing wrong? Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Mon May 31 19:22:18 2021 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 31 May 2021 20:22:18 +0100 Subject: [OpenSIPS-Users] Getting header from 302 In-Reply-To: References: Message-ID: This is really weird, if (is_present_hf("Identity")) says it is not present, but it is! Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Mon, May 31, 2021 at 7:47 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > Hello Guys, > > I'm getting a header on a 302 which i'm trying to get, but for some reason > I can't. > > This is an example 302: > > 2021/05/31 18:42:36.499157 10.231.32.237:5060 -> 10.231.57.11:6075 > SIP/2.0 302 Redirect > Via: SIP/2.0/UDP 1.2.3.4: > 6075;branch=z9hG4bKd8e8.50036ee6.0;received=10.231.57.11 > Via: SIP/2.0/UDP > 10.231.33.135;branch=z9hG4bKd8e8.fe2738f41d26b2b68328691c326a077a.0 > v:SIP/2.0/UDP 10.231.49.211:6060 > ;received=10.231.49.211;rport=6060;branch=z9hG4bK68SgceeareaUa > f:"+18883333333";tag=ZBQ713X9pgD5S > t: >;tag=9dd61ff61e802d8e2bef5f14621ef3c2.50cf6b6c > i:cf649a38-3ce2-123a-eaad-122eaa5d9655 > CSeq:36689486 INVITE > Identity: > eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9vcHMtc3RhdGljLnMzLmFtYXpvbmF3cy5jb20vc3Rpci1zaGFrZW4vZWMyNTYtcHVibGljLnBlbSJ9.eyJhdHRlc3QiO > > BIiwiZGVzdCI6eyJ0biI6WyIxNzg2NDEwNzgzNyJdfSwiaWF0IjoxNjIyNDg2NTU2LCJvcmlnIjp7InRuIjoiKzEzMTU5ODUyNTk0In0sIm9yaWdpZCI6IjhlZGE4M2Q1LWY1MjEtNDQzZC1iNDI0LWIzNDQ3MDc4ZjYxZCJ9.cjIz9VwlS9_6qA > > 6mmDgottk41BLpQcA40HdvV_6jAPqQ1EIL3_jLWl25oHeVEWOzTMhcERp4Jn-JZ4vP_n3w;info=< > https://somedomain.com/stir-shaken/ec256-public.pem>;alg=ES256;ppt=shaken > Server: kamailio (5.5.0 (x86_64/linux)) > Content-Length: 0 > > I'm trying to get the "Identity" header with: > > $avp(identity_header) = $(hdr(Identity)); > > But It's coming up > > Any ideas of what I'm doing wrong? > > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Mon May 31 20:11:42 2021 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 31 May 2021 21:11:42 +0100 Subject: [OpenSIPS-Users] Getting header from 302 In-Reply-To: References: Message-ID: So weird, I can get the From header, but not "Identity"... Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Mon, May 31, 2021 at 8:22 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > This is really weird, > > if (is_present_hf("Identity")) > > says it is not present, but it is! > > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > > > On Mon, May 31, 2021 at 7:47 PM David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> Hello Guys, >> >> I'm getting a header on a 302 which i'm trying to get, but for some >> reason I can't. >> >> This is an example 302: >> >> 2021/05/31 18:42:36.499157 10.231.32.237:5060 -> 10.231.57.11:6075 >> SIP/2.0 302 Redirect >> Via: SIP/2.0/UDP 1.2.3.4: >> 6075;branch=z9hG4bKd8e8.50036ee6.0;received=10.231.57.11 >> Via: SIP/2.0/UDP >> 10.231.33.135;branch=z9hG4bKd8e8.fe2738f41d26b2b68328691c326a077a.0 >> v:SIP/2.0/UDP 10.231.49.211:6060 >> ;received=10.231.49.211;rport=6060;branch=z9hG4bK68SgceeareaUa >> f:"+18883333333";tag=ZBQ713X9pgD5S >> t:> >;tag=9dd61ff61e802d8e2bef5f14621ef3c2.50cf6b6c >> i:cf649a38-3ce2-123a-eaad-122eaa5d9655 >> CSeq:36689486 INVITE >> Identity: >> eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9vcHMtc3RhdGljLnMzLmFtYXpvbmF3cy5jb20vc3Rpci1zaGFrZW4vZWMyNTYtcHVibGljLnBlbSJ9.eyJhdHRlc3QiO >> >> BIiwiZGVzdCI6eyJ0biI6WyIxNzg2NDEwNzgzNyJdfSwiaWF0IjoxNjIyNDg2NTU2LCJvcmlnIjp7InRuIjoiKzEzMTU5ODUyNTk0In0sIm9yaWdpZCI6IjhlZGE4M2Q1LWY1MjEtNDQzZC1iNDI0LWIzNDQ3MDc4ZjYxZCJ9.cjIz9VwlS9_6qA >> >> 6mmDgottk41BLpQcA40HdvV_6jAPqQ1EIL3_jLWl25oHeVEWOzTMhcERp4Jn-JZ4vP_n3w;info=< >> https://somedomain.com/stir-shaken/ec256-public.pem>;alg=ES256;ppt=shaken >> Server: kamailio (5.5.0 (x86_64/linux)) >> Content-Length: 0 >> >> I'm trying to get the "Identity" header with: >> >> $avp(identity_header) = $(hdr(Identity)); >> >> But It's coming up >> >> Any ideas of what I'm doing wrong? >> >> Regards, >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: