Re: [SR-Users] Meaning of shmem stats and question on dmq dialog sharing behaviour
Hello, I get image not found on that link, have you removed it? Cheers, Daniel On 01.06.20 13:57, George Diamantopoulos wrote: > Hello all, > > I've recently been experimenting with dmq, and I've noticed something > that seemed a little odd. shmem use would often be abnormally high on > otherwise idle kamailio nodes (literally, only dispatcher module > OPTIONS were exchanged at the time besides KDMQ messages). > > After disabling the "enable_dmq" parameter for the dialog module, this > sort of absurd behaviour ceased. To get a quantified idea of this > change's effect, check out the following screenshot from our > monitoring system: > https://pasteboard.co/Jb430lD.png > > As you can see, the spikes stopped manifesting at around 05:00, when > dmq was disabled for dialog (albeit still employed for htable). shmem > use then grew as traffic was introduced to these nodes, and htables > began filling with data. > > I was wondering if this to be expected, which I find highly odd given > that at the time other productive systems in the DMQ cluster were also > idle (given the time of the day), not to mention that their shmem > usage was not nearly as high. > > Could this be attributed to some configuration error, with updates > looping endlessly (or until some counter reaches zero or something) > among nodes? Or could memory be used for other housekeeping purposes > unrelated to dmq dialog sharing? > > Lastly, what is the meaning (and differences) of these shmem stats? > > * real_used_size > * used_size > * max_used_size > > Max used size I get (I'm guessing maximum seen since server was > started?) but what's the difference between real_used and used? Thanks! > > Best regards, > George > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] No module matching found, failed to load module
Hello, have you compiled and installed http_client module? It has to be added to "include_modules", see: * https://kamailio.org/docs/tutorials/devel/kamailio-install-guide-git/#tuning-makefiles Cheers, Daniel On 01.06.20 22:39, ke...@alcall.net wrote: > Hello @everybody > > i can't load http_client module, can someone advice ? > > ERROR: No module matching found, failed to load module > > > version: kamailio 5.3.3 ( installed from GIT ) > libcurl4-openssl-dev is installed too in Debian 9 > > thank for your attention > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] No module matching found, failed to load module
Hello @everybody i can't load http_client module, can someone advice ? ERROR: No module matching found, failed to load module version: kamailio 5.3.3 ( installed from GIT ) libcurl4-openssl-dev is installed too in Debian 9 thank for your attention ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation
George, I understand. Have you considered begrudgingly adding a lightweight B2BUA such as SEMS in the middle? I understand it greatly increases the operational complexity and moving parts of your setup, to say nothing of infrastructural costs. I am all for using Kamailio alone to solve problems that the disinformation/spam of the SBC industry tells us we need a conventional SBC to solve. I gave a presentation at the last Kamailio World[1] whose general tenor was that all one needs is a little Kamailio, and which could be interpreted as a winding, circumlocutory middle finger to the SBC industry. :-) But this really does strike me as a valid use-case for an “SBC” type setup as we’ve been made to understand the term — that is, in what Oracle/Metaswitch/Sansay/Sonus/etc would like to have you think of as “the ordinary sense”. RTPEngine is minimally invasive and, outside of its mandate to change the media endpoint addresses, is designed for additive capabilities, not to fix problems or maladaptive behaviours. Meanwhile, tweaking the SDP body, despite the existence of extensive technical capability on the part of Kamailio, is not something a proxy should be doing; it’s just not faithful to the endpoints’ tacit assumption that the SDP offer/answer they send is the one being operated upon by the other party. And, as you’ve noted, it is problematic to both tweak the SDP body and press RTPEngine into service simultaneously. There may be — in fact, it’s likely — a solution to your most immediate technical problem, though I’m not sure offhand. But for the sake of manageability and conceptual integrity to your voice architecture going forward, I would urge you to reconsider whether this is the best way of doing things overall. ... unless you’re already well past that point, to which I think your references to the size and complexity of your config allude. :-) In that case, a nihilistic attitude may better suit the dark, ghastly hue of the situation. — Alex [1] https://youtu.be/j-0C6eHfocI — Sent from mobile, with due apologies for brevity and errors. > On Jun 1, 2020, at 8:15 AM, George Diamantopoulos > wrote: > > > Hello Alex, > > Thank you for your reply. Well, I'm interfacing with several PSTN operators, > and some of their networks' SIP endpoints (or other obscure IMS entity there) > are very picky in that if they don't like the capabilities you serve for > telephone-event (which is if they don't match theirs), then the transaction > is rejected with "488 SDP Parameter Error In SIP Request" (or if it's a reply > I'm sending, they will send a BYE immediately). > > Trying to reason with them (the operators) has failed, my SIP UA provides no > way to choose these values when the SDP is created (and since it apparently > has to match the other side some static configuration wouldn't do much here), > so all I'm left with is the option of growing my config file by yet another > 50 lines... :-\ > > BR, > George > >> On Mon, 1 Jun 2020 at 14:41, Alex Balashov wrote: >> George, >> >> It may be orthogonal to the answer that you seek, but I’m going to ask >> anyway: what is the overall motive underlying your SDP manipulation? >> >> It seems to me that one should reason backward from that root cause. The >> kind of SDP manipulation you are doing is seldom necessary in ordinarily >> imaginable contexts... >> >> — Alex >> >> — >> Sent from mobile, with due apologies for brevity and errors. >> On Jun 1, 2020, at 7:35 AM, George Diamantopoulos wrote: >>> >>> Hello all, >>> >>> I'm facing one of those cases where I need to edit the body of a SIP >>> message, which is then to be fed to rtpengine for processing. Although I've >>> taken every precaution I've read about on this list and elsewhere, I can't >>> prevent the edited line from appearing twice in the outgoing message. >>> >>> The configuration file used is huge, so I'm going to try to provide a >>> high-level overview here. But first, the things (I think) I know to be >>> requirements, and which I have striven to meet: >>> If SDP is to be edited, then all such processing is to be carried out in >>> such a way in the script, so that msg_apply_changes() is run as many times >>> as needed before rtpengine offer/answer/manage is called. >>> rtpengine offer/answer/manage is to be called only once per script iteration >>> msg_apply_changes can only be called in a request route, or in the core >>> reply_route (i.e. not in tm-managed on_reply_route[XXX] blocks) >>> In my case, additionally the following are true: >>> SDP processing (other than the one performed by rtpengine) takes place in >>> one common route for all cases where it needs to happen. These are two at >>> the moment in my scenario: >>> Early in the WITHINDLG route (of the example config file) >>> After the sanity checks in the reply_route (of the example config file) >>> msg_apply changes() is called once, for each script
Re: [SR-Users] Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation
Hello Alex, Thank you for your reply. Well, I'm interfacing with several PSTN operators, and some of their networks' SIP endpoints (or other obscure IMS entity there) are very picky in that if they don't like the capabilities you serve for telephone-event (which is if they don't match theirs), then the transaction is rejected with "488 SDP Parameter Error In SIP Request" (or if it's a reply I'm sending, they will send a BYE immediately). Trying to reason with them (the operators) has failed, my SIP UA provides no way to choose these values when the SDP is created (and since it apparently has to match the other side some static configuration wouldn't do much here), so all I'm left with is the option of growing my config file by yet another 50 lines... :-\ BR, George On Mon, 1 Jun 2020 at 14:41, Alex Balashov wrote: > George, > > It may be orthogonal to the answer that you seek, but I’m going to ask > anyway: what is the overall motive underlying your SDP manipulation? > > It seems to me that one should reason backward from that root cause. The > kind of SDP manipulation you are doing is seldom necessary in ordinarily > imaginable contexts... > > — Alex > > — > Sent from mobile, with due apologies for brevity and errors. > > On Jun 1, 2020, at 7:35 AM, George Diamantopoulos > wrote: > > > Hello all, > > I'm facing one of those cases where I need to edit the body of a SIP > message, which is then to be fed to rtpengine for processing. Although I've > taken every precaution I've read about on this list and elsewhere, I can't > prevent the edited line from appearing twice in the outgoing message. > > The configuration file used is huge, so I'm going to try to provide a > high-level overview here. But first, the things (I think) I know to be > requirements, and which I have striven to meet: > >- If SDP is to be edited, then all such processing is to be carried >out in such a way in the script, so that msg_apply_changes() is run as many >times as needed before rtpengine offer/answer/manage is called. >- rtpengine offer/answer/manage is to be called only once per script >iteration >- msg_apply_changes can only be called in a request route, or in the >core reply_route (i.e. *not* in tm-managed on_reply_route[XXX] blocks) > > In my case, additionally the following are true: > >- SDP processing (other than the one performed by rtpengine) takes >place in one common route for all cases where it needs to happen. These are >two at the moment in my scenario: >- Early in the WITHINDLG route (of the example config file) > - After the sanity checks in the reply_route (of the example config > file) >- msg_apply changes() is called once, for each script iteration: > - right before rtpengine_manage() is called, provided that > t_is_request_route() returns true (so that I don't accidentally call it > from a branch route or anything) > - rtpengine_manage() is called in its own route, which is very > similar to the example config file's "NATMANAGE" route. Since > NATMANAGE is > called in all branch and on_reply_routes, I employ > t_is_request_route() > here to make sure it won't execute in those cases. > - at the end of the "core" reply_route > > Now regarding the actual config-file-controlled SDP manipulation, it only > consists of a single call to replace_body_str(). The purpose is to edit a > line in the message body from something like: > >- a=fmtp:101 0-16 > > to something along the lines of: > >- a=fmtp:101 0-15 > > For replies, this works as expected. > > For in-dialog requests, however, I end up with both the original and the > edited lines: > a=fmtp:101 0-16 (the original line) > ... other SDP stuff ... > a=fmtp:101 0-15 (the edited line) > > If anyone could point out any misconceptions I have about > msg_apply_changes, SDP rewriting from the script and rtp_engine_X() > interoperability, I would be more than grateful. > > Thank you in advance and I apologize for the long read. > > Best regards, > George Diamantopoulos > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Meaning of shmem stats and question on dmq dialog sharing behaviour
Hello all, I've recently been experimenting with dmq, and I've noticed something that seemed a little odd. shmem use would often be abnormally high on otherwise idle kamailio nodes (literally, only dispatcher module OPTIONS were exchanged at the time besides KDMQ messages). After disabling the "enable_dmq" parameter for the dialog module, this sort of absurd behaviour ceased. To get a quantified idea of this change's effect, check out the following screenshot from our monitoring system: https://pasteboard.co/Jb430lD.png As you can see, the spikes stopped manifesting at around 05:00, when dmq was disabled for dialog (albeit still employed for htable). shmem use then grew as traffic was introduced to these nodes, and htables began filling with data. I was wondering if this to be expected, which I find highly odd given that at the time other productive systems in the DMQ cluster were also idle (given the time of the day), not to mention that their shmem usage was not nearly as high. Could this be attributed to some configuration error, with updates looping endlessly (or until some counter reaches zero or something) among nodes? Or could memory be used for other housekeeping purposes unrelated to dmq dialog sharing? Lastly, what is the meaning (and differences) of these shmem stats? - real_used_size - used_size - max_used_size Max used size I get (I'm guessing maximum seen since server was started?) but what's the difference between real_used and used? Thanks! Best regards, George ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation
George, It may be orthogonal to the answer that you seek, but I’m going to ask anyway: what is the overall motive underlying your SDP manipulation? It seems to me that one should reason backward from that root cause. The kind of SDP manipulation you are doing is seldom necessary in ordinarily imaginable contexts... — Alex — Sent from mobile, with due apologies for brevity and errors. > On Jun 1, 2020, at 7:35 AM, George Diamantopoulos > wrote: > > > Hello all, > > I'm facing one of those cases where I need to edit the body of a SIP message, > which is then to be fed to rtpengine for processing. Although I've taken > every precaution I've read about on this list and elsewhere, I can't prevent > the edited line from appearing twice in the outgoing message. > > The configuration file used is huge, so I'm going to try to provide a > high-level overview here. But first, the things (I think) I know to be > requirements, and which I have striven to meet: > If SDP is to be edited, then all such processing is to be carried out in such > a way in the script, so that msg_apply_changes() is run as many times as > needed before rtpengine offer/answer/manage is called. > rtpengine offer/answer/manage is to be called only once per script iteration > msg_apply_changes can only be called in a request route, or in the core > reply_route (i.e. not in tm-managed on_reply_route[XXX] blocks) > In my case, additionally the following are true: > SDP processing (other than the one performed by rtpengine) takes place in one > common route for all cases where it needs to happen. These are two at the > moment in my scenario: > Early in the WITHINDLG route (of the example config file) > After the sanity checks in the reply_route (of the example config file) > msg_apply changes() is called once, for each script iteration: > right before rtpengine_manage() is called, provided that t_is_request_route() > returns true (so that I don't accidentally call it from a branch route or > anything) > rtpengine_manage() is called in its own route, which is very similar to the > example config file's "NATMANAGE" route. Since NATMANAGE is called in all > branch and on_reply_routes, I employ t_is_request_route() here to make sure > it won't execute in those cases. > at the end of the "core" reply_route > Now regarding the actual config-file-controlled SDP manipulation, it only > consists of a single call to replace_body_str(). The purpose is to edit a > line in the message body from something like: > a=fmtp:101 0-16 > to something along the lines of: > a=fmtp:101 0-15 > For replies, this works as expected. > > For in-dialog requests, however, I end up with both the original and the > edited lines: > a=fmtp:101 0-16 (the original line) > ... other SDP stuff ... > a=fmtp:101 0-15 (the edited line) > > If anyone could point out any misconceptions I have about msg_apply_changes, > SDP rewriting from the script and rtp_engine_X() interoperability, I would be > more than grateful. > > Thank you in advance and I apologize for the long read. > > Best regards, > George Diamantopoulos > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Can't work around double SDP rewrite issue with rtpengine and config script SDP manipulation
Hello all, I'm facing one of those cases where I need to edit the body of a SIP message, which is then to be fed to rtpengine for processing. Although I've taken every precaution I've read about on this list and elsewhere, I can't prevent the edited line from appearing twice in the outgoing message. The configuration file used is huge, so I'm going to try to provide a high-level overview here. But first, the things (I think) I know to be requirements, and which I have striven to meet: - If SDP is to be edited, then all such processing is to be carried out in such a way in the script, so that msg_apply_changes() is run as many times as needed before rtpengine offer/answer/manage is called. - rtpengine offer/answer/manage is to be called only once per script iteration - msg_apply_changes can only be called in a request route, or in the core reply_route (i.e. *not* in tm-managed on_reply_route[XXX] blocks) In my case, additionally the following are true: - SDP processing (other than the one performed by rtpengine) takes place in one common route for all cases where it needs to happen. These are two at the moment in my scenario: - Early in the WITHINDLG route (of the example config file) - After the sanity checks in the reply_route (of the example config file) - msg_apply changes() is called once, for each script iteration: - right before rtpengine_manage() is called, provided that t_is_request_route() returns true (so that I don't accidentally call it from a branch route or anything) - rtpengine_manage() is called in its own route, which is very similar to the example config file's "NATMANAGE" route. Since NATMANAGE is called in all branch and on_reply_routes, I employ t_is_request_route() here to make sure it won't execute in those cases. - at the end of the "core" reply_route Now regarding the actual config-file-controlled SDP manipulation, it only consists of a single call to replace_body_str(). The purpose is to edit a line in the message body from something like: - a=fmtp:101 0-16 to something along the lines of: - a=fmtp:101 0-15 For replies, this works as expected. For in-dialog requests, however, I end up with both the original and the edited lines: a=fmtp:101 0-16 (the original line) ... other SDP stuff ... a=fmtp:101 0-15 (the edited line) If anyone could point out any misconceptions I have about msg_apply_changes, SDP rewriting from the script and rtp_engine_X() interoperability, I would be more than grateful. Thank you in advance and I apologize for the long read. Best regards, George Diamantopoulos ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users