[OpenSIPS-Users] auth_radius via non-digest methods

-- Andrew Yager, Managing Director (MACS BCompSc MCP) Real World Technology Solutions Pty Ltd ph: 1300 798 718 or (02) 9037 0500 fax: (02) 9037 0591 mob: 0405 152 568 http://www.rwts.com.au/ or http://www.stonebridgecomputing.com.au/ ___ Users

[OpenSIPS-Users] Extract userid from SIP URI for radius accounting purposes

. Is there already an AVP that has this information, or alternatively a module we can use to extract this information and insert it into an AVP? Thanks, Andrew -- Andrew Yager, Managing Director (MACS BCompSc MCP) Real World Technology Solutions Pty Ltd - your IT department ph: 1300 798 718 or (02) 9037

[OpenSIPS-Users] opensips-cp cdrviewer

. What is the table structure/standard db extra fields that should be passed to get this to work? Thanks, Andrew -- Andrew Yager, Managing Director (MACS BCompSc MCP) Real World Technology Solutions Pty Ltd ph: 1300 798 718 or (02) 9037 0500 fax: (02) 9037 0591 mob: 0405 152 568 http

[OpenSIPS-Users] Multi-Leg accounting

for the various src_leg and dst_leg parameters? Thanks, Andrew -- Andrew Yager, Managing Director (MACS BCompSc MCP) Real World Technology Solutions Pty Ltd ph: 1300 798 718 or (02) 9037 0500 fax: (02) 9037 0591 mob: 0405 152 568 http://www.rwts.com.au/ or http://www.stonebridgecomputing.com.au

[OpenSIPS-Users] Restricting CallerID

go about this? I think I would like to reject calls with invalid outbound caller id, but otherwise I could just rewrite it to be blank. Andrew -- Andrew Yager, Managing Director (MACS BCompSc MCP) Real World Technology Solutions Pty Ltd - your IT department ph: 1300 798 718 or (02) 9037

Re: [OpenSIPS-Users] Restricting CallerID

) it will restrict them to a single outbound callerid, where we would like them to be able to set any in their range. Am I wrong in my assumption? Thanks, Andrew -- Andrew Yager, Managing Director (MACS BCompSc MCP) Real World Technology Solutions Pty Ltd - your IT department ph: 1300 798 718 or (02) 9037

[OpenSIPS-Users] Hold and Transfer from Mitel PBX drops call

or attempt to transfer, the call simply drops. According to the SIP messaging, it looks as though we simply receive a BYE message. The other thing I would appreciate is any advise on where to look to trouble-shoot this issue. Thanks, Andrew -- Andrew Yager, Managing Director (MACS BCompSc MCP

Re: [OpenSIPS-Users] bla_presentity_spec variable seems to not work?

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

[OpenSIPS-Users] bla_presentity_spec variable seems to not work?

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@127.0.0.1:3306/opensips")

[OpenSIPS-Users] TLS NOTIFY transmit fails

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

Re: [OpenSIPS-Users] TLS NOTIFY transmit fails

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

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

etr = 0 reply_status = RPS_COMPLETED uas_rb = 0x7f6ed4bd8330 cb_s = {s = 0x7f6fc6d83c00 "\f", len = -681049792} text = {s = 0x55b7abec1e50 "ȬB\311n\177", len = 0} __FUNCTION__ = "relay_reply" [snip] -- Andrew Yager, CEO (BCompSc,

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

dow = {0 , 301288, 0 }, last_time = 1633625259739989, is_busy = 1 '\001'}} Andrew -- Andrew Yager, CEO (BCompSc, JNCIS-SP, MACS (Snr) CP) business nbn™ advisor (advisor 01783150) Real World Technology Solutions - IT People you can trust Voice | Data | IT Procurement | Managed IT rwts.com.au |

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

ttps://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 >https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 10/8/21 2:43 PM, Andrew Yager wrote: > > Hi Bogdan-Andrei, > > > > Have restarted since the last bt, but have recreated again and > > at

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

S eBootcamp 2021 >https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 10/8/21 1:43 AM, Andrew Yager wrote: > > Interestingly, where I usually see a range of continued messages from > > a process continually in the debug log, they appear to stop for this > > PID

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

; On Sat, 9 Oct 2021 at 00:19, Bogdan-Andrei Iancu > wrote: > > > > Hi Andrew, > > > > The second blocked process (doing the TLS/TCP stuff) surprisingly got > > stuck while waiting for a TCP fd from the TCP Main process. > > > > You mentioned that

Re: [OpenSIPS-Users] Segfault in 3.2.2 (inc nightly) but not 3.2 in mid_registrar

Just further to this, I'm pretty sure this is a regression introduced in https://github.com/OpenSIPS/opensips/commit/c11f92698c6f345d8921d645177f71aa36c9791d . On Tue, 28 Sept 2021 at 19:04, Andrew Yager wrote: > Hi, > > Since testing 3.2.2 we've noticed a segfault affecting regi

[OpenSIPS-Users] Segfault in 3.2.2 (inc nightly) but not 3.2 in mid_registrar

Hi, Since testing 3.2.2 we've noticed a segfault affecting registrations pretty regularly through mid_registrar. The issue occurs intermittently, but seemingly when the contact doesn't exist and needs to be created. We are currently using in-memory mid_registrar without DB backing to test;

Re: [OpenSIPS-Users] Segfault in 3.2.2 (inc nightly) but not 3.2 in mid_registrar

, September 28, 2021 9:56:43 PM To: OpenSIPS users mailling list ; Andrew Yager Subject: Re: [OpenSIPS-Users] Segfault in 3.2.2 (inc nightly) but not 3.2 in mid_registrar On 28.09.2021 14:29, Liviu Chircu wrote: > Will put up a fix soon, thanks again for the nice hint! Done, see: https://github.

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

//www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 10/6/21 12:24 AM, Andrew Yager wrote: > > Also restarting opensips produces this: > > Restarting opensips (via systemctl): opensips.serviceERROR: com

[OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

Hi, Not entirely sure where to start digging on this one. On 3.1.3 we've had an issue appear "suddenly" whereby our mi command output seems to "block" and not return any useful data. Restarting opensips processes restores comms. We end up with a huge number of opensips_fifo_reply_\* files in the

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

Just further to this, I think it's the ul_dump command that seems to cause the issue first. Andrew On Sat, 2 Oct 2021 at 13:05, Andrew Yager wrote: > Hi, > > Not entirely sure where to start digging on this one. On 3.1.3 we've had > an issue appear "suddenly" whereby

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

Also restarting opensips produces this: Restarting opensips (via systemctl): opensips.serviceERROR: communication exception for 'which' returned: cannot access fifo file /tmp/opensips_fifo: [Errno 32] Broken pipe! Andrew On Wed, 6 Oct 2021 at 08:23, Andrew Yager wrote: > Hi, >

Re: [OpenSIPS-Users] mi_fifo lock on reply after a period of time in 3.1.3

ps[1186172]: DBG:core:ipc_handle_job: received job type 0[RPC] from process 1 Oct 6 04:49:32 hvprxy osips[1186173]: DBG:core:ipc_handle_job: received job type 0[RPC] from process 1 Oct 6 04:49:32 hvprxy osips[1186174]: DBG:core:ipc_handle_job: received job type 0[RPC] from process 1 And

Re: [OpenSIPS-Users] 3.2.3 TLS issue

Do you have a core dump with the backtrace when it dies? There are a few fixes in the nightly releases around some TLS things, and we've found these to be a better choice for SSL performance. Thanks, Andrew On Fri, 12 Nov 2021 at 02:30, Gregory Massel wrote: > Thanks. > > This report lists it