From medeanwz at gmail.com Mon Oct 6 10:27:04 2025 From: medeanwz at gmail.com (M S) Date: Mon, 6 Oct 2025 12:27:04 +0200 Subject: [OpenSIPS-Users] media_exchange Message-ID: Hi Opensips developers, While going through media_exchang.c code: static int b2b_media_notify(struct sip_msg *msg, str *key, int type, str *logic_key, void *param, int flags) { .... terminate: *MEDIA_LEG_LOCK(msl);* if (initial_state == MEDIA_SESSION_STATE_INIT) { /* this is the initial leg, not a re-invite */ *MEDIA_LEG_UNLOCK(msl);* handle_media_session_negative(msl); } else { *MEDIA_LEG_UNLOCK(msl);* } return -1; } there is no point in lock and unlock above.... unless the first unlock is supposed to be after handle_media_session_negative(msl);? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From slackway2me at gmail.com Wed Oct 8 08:28:12 2025 From: slackway2me at gmail.com (Alexey) Date: Wed, 8 Oct 2025 13:28:12 +0500 Subject: [OpenSIPS-Users] IDS/IPS integration Message-ID: Hi list, does anyone have an experience of using Intrusion Detection/Prevention Systems with/for OpenSIPS? I mean Suricata [1], to be more precise. There may be two approaches - running Suricata on the same server as OpenSIPS, or running it on a separate server to which the VoIP traffic is mirrored (or on the gateway which is in the OpenSIPS server traffic path). My case is running IDS/IPS on the same server. The server itself is opened to the whole world as it serves REGISTER requests from tens of thousands of mobile devices. And here's the question - do I really need to use IDS/IPS, or it is enough to configure OpenSIPS, as it has modules like pike, ratelimit, can count (un)successful requests and detect user-agents like those used by sipp, sipvicious and other sip-scanners. The question appeared after grep'ing some key words in Suricata rules and looking at log messages they generate: grep -i voip /var/lib/suricata/rules/suricata.rules - https://pastebin.com/EXanpJn1 grep -i sip /var/lib/suricata/rules/suricata.rules - https://pastebin.com/ih5rA5fz [1] https://suricata.io/ -- best regards, Alexey https://alexeyka.zantsev.com/ From razvan at opensips.org Thu Oct 9 12:17:15 2025 From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=) Date: Thu, 9 Oct 2025 15:17:15 +0300 Subject: [OpenSIPS-Users] CDR change before sending to database In-Reply-To: References: Message-ID: <3f8da1ac-2c70-471e-b435-36b83a7e409f@opensips.org> Hello! The E_ACC_CDR event is executed asynchronously, thus the dialog/acc context may no longer be available. Thus you should not try to modify it. Your best change is to make sure that the acc variables are final after the BYE/200 OK is processed. But if you could give us more information about what you are trying to do, we might be able to help you. Best regards, Răzvan Crainea OpenSIPS Core Developer / SIPhub CTO http://www.opensips-solutions.com / https://www.siphub.com On 9/27/25 2:03 PM, M S wrote: > Hi list, > I was wondering if anybody has any ideas about making changes to CDR > variables before sending them to the database. > Documents say the acc module calls E_ACC_CDR, is this before sending it to > the database, or in a parallel branch? if I change a variable in here, does > it change what's written to the database? > > Thanks! > > > Hi list, > I was wondering if anybody has any ideas about making changes to CDR > variables before sending them to the database. > Documents say the acc module calls E_ACC_CDR, is this before sending it > to the database, or in a parallel branch? if I change a variable in > here, does it change what's written to the database? > > Thanks! > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From razvan at opensips.org Thu Oct 9 12:26:02 2025 From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=) Date: Thu, 9 Oct 2025 15:26:02 +0300 Subject: [OpenSIPS-Users] media_exchange In-Reply-To: References: Message-ID: Pretty sure the lock is not needed at all - can you please open a BUG report, so we can investigate a bit how to properly handle the termination case? Best regards, Răzvan Crainea OpenSIPS Core Developer / SIPhub CTO http://www.opensips-solutions.com / https://www.siphub.com On 10/6/25 1:27 PM, M S wrote: > Hi Opensips developers, > While going through media_exchang.c code: > > static int b2b_media_notify(struct sip_msg *msg, str *key, int type, > str *logic_key, void *param, int flags) > { > .... > terminate: > *MEDIA_LEG_LOCK(msl);* > if (initial_state == MEDIA_SESSION_STATE_INIT) { > /* this is the initial leg, not a re-invite */ > *MEDIA_LEG_UNLOCK(msl);* > handle_media_session_negative(msl); > } else { > *MEDIA_LEG_UNLOCK(msl);* > } > return -1; > } > > there is no point in lock and unlock above.... unless the first unlock is > supposed to be after handle_media_session_negative(msl);? > > Thanks! > > > Hi Opensips developers, > While going through media_exchang.c code: > > static int b2b_media_notify(struct sip_msg *msg, str *key, int type, >                 str *logic_key, void *param, int flags) > { > .... > terminate: > *MEDIA_LEG_LOCK(msl);* >         if (initial_state == MEDIA_SESSION_STATE_INIT) { >                 /* this is the initial leg, not a re-invite */ > *MEDIA_LEG_UNLOCK(msl);* >                 handle_media_session_negative(msl); >         } else { > *MEDIA_LEG_UNLOCK(msl);* >         } >         return -1; > } > > there is no point in lock and unlock above.... unless the first > unlock is supposed to be after handle_media_session_negative(msl);? > > Thanks! > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From medeanwz at gmail.com Thu Oct 9 13:30:34 2025 From: medeanwz at gmail.com (M S) Date: Thu, 9 Oct 2025 15:30:34 +0200 Subject: [OpenSIPS-Users] media_exchange In-Reply-To: References: Message-ID: On the contrary, the lock seems to be needed. I found quite a few bugs in media_exchange, seems like msl can be changed in other threads, etc which causes segfault. in this case also I ended up in this part of code because of a segfault and adding lock seems to fix it. On Thu, Oct 9, 2025 at 2:28 PM Răzvan Crainea wrote: > Pretty sure the lock is not needed at all - can you please open a BUG > report, so we can investigate a bit how to properly handle the > termination case? > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer / SIPhub CTO > http://www.opensips-solutions.com / https://www.siphub.com > > On 10/6/25 1:27 PM, M S wrote: > > Hi Opensips developers, > > While going through media_exchang.c code: > > > > static int b2b_media_notify(struct sip_msg *msg, str *key, int type, > > str *logic_key, void *param, int flags) > > { > > .... > > terminate: > > *MEDIA_LEG_LOCK(msl);* > > if (initial_state == MEDIA_SESSION_STATE_INIT) { > > /* this is the initial leg, not a re-invite */ > > *MEDIA_LEG_UNLOCK(msl);* > > handle_media_session_negative(msl); > > } else { > > *MEDIA_LEG_UNLOCK(msl);* > > } > > return -1; > > } > > > > there is no point in lock and unlock above.... unless the first unlock is > > supposed to be after handle_media_session_negative(msl);? > > > > Thanks! > > > > > > Hi Opensips developers, > > While going through media_exchang.c code: > > > > static int b2b_media_notify(struct sip_msg *msg, str *key, int type, > > str *logic_key, void *param, int flags) > > { > > .... > > terminate: > > *MEDIA_LEG_LOCK(msl);* > > if (initial_state == MEDIA_SESSION_STATE_INIT) { > > /* this is the initial leg, not a re-invite */ > > *MEDIA_LEG_UNLOCK(msl);* > > handle_media_session_negative(msl); > > } else { > > *MEDIA_LEG_UNLOCK(msl);* > > } > > return -1; > > } > > > > there is no point in lock and unlock above.... unless the first > > unlock is supposed to be after handle_media_session_negative(msl);? > > > > Thanks! > > > > _______________________________________________ > > 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: