[SR-Users] Re: Sudden TCP errors and shared memory spikes
Hi Henning, Thank you for that. I was not sure what direction to take traces in, so possible network issues with clients using TCP is a good indicator. We'll look into that. On Mon, 29 Apr 2024 at 22:20, Henning Westerholt wrote: > Hello, > > > > if Kamailio can’t send out messages due to network issues I would expect > some spikes in private and/or shared memory usage. > > > > Have you investigated e.g., with some traces to get more information about > the possible causes of this issues? > > > > Besides that, with the given information I can only recommend the usual > update to the latest stable version (e.g. 5.8.1) as the 5.2.x release > series is long end of life. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > *From:* David Cunningham via sr-users > *Sent:* Freitag, 26. April 2024 02:27 > *To:* Kamailio (SER) - Users Mailing List > *Cc:* David Cunningham > *Subject:* [SR-Users] Sudden TCP errors and shared memory spikes > > > > Hello, > > > > We have a production Kamailio 5.2.7 server which has suddenly started > reporting spikes in the shared memory use. When looking into this, we > noticed that at the same time as the memory spikes Kamailio also logs a > huge amount of errors like the following. > > > > Can anyone help with an explanation for what's going on? The xx.xx.52.202 > address is the Kamailio server itself. We record historical numbers of > network connections for the server overall, and that doesn't show any > increase in the number of TCP connections, either at the time of the spikes > or as a general trend. > > > > Thanks in advance! > > > > Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: > [core/tcp_main.c:2703]: tcpconn_1st_send(): connect xx.xx.52.202:42726 > failed (RST) Connection refused > Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: > [core/tcp_main.c:2711]: tcpconn_1st_send(): xx.xx.52.202:42726: connect & > send for 0x14bbf44c9f40 failed: Connection refused (111) > Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: tm > [../../core/forward.h:293]: msg_send_buffer(): tcp_send failed > Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: WARNING: > [core/tcp_main.c:1149]: tcp_do_connect(): xx.xx.52.202:42726: could not > find corresponding listening socket for xx.xx.52.202, using default... > > > > -- > > David Cunningham, Voisonics Limited > http://voisonics.com/ > USA: +1 213 221 1092 > New Zealand: +64 (0)28 2558 3782 > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Sudden TCP errors and shared memory spikes
Hello, We have a production Kamailio 5.2.7 server which has suddenly started reporting spikes in the shared memory use. When looking into this, we noticed that at the same time as the memory spikes Kamailio also logs a huge amount of errors like the following. Can anyone help with an explanation for what's going on? The xx.xx.52.202 address is the Kamailio server itself. We record historical numbers of network connections for the server overall, and that doesn't show any increase in the number of TCP connections, either at the time of the spikes or as a general trend. Thanks in advance! Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: [core/tcp_main.c:2703]: tcpconn_1st_send(): connect xx.xx.52.202:42726 failed (RST) Connection refused Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: [core/tcp_main.c:2711]: tcpconn_1st_send(): xx.xx.52.202:42726: connect & send for 0x14bbf44c9f40 failed: Connection refused (111) Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: ERROR: tm [../../core/forward.h:293]: msg_send_buffer(): tcp_send failed Apr 26 09:23:16 vpbx11 /sbin/kamailio[44272]: WARNING: [core/tcp_main.c:1149]: tcp_do_connect(): xx.xx.52.202:42726: could not find corresponding listening socket for xx.xx.52.202, using default... -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
Thanks Richard. It was "SRTP uses something that OpenSSL doesn't directly support" that our FIPS expert told us, which led us down this line of enquiry. I didn't understand exactly what the something was, but your explanation makes sense. On Thu, 11 Apr 2024 at 10:41, Richard Fuchs wrote: > On 10/04/2024 17.46, David Cunningham wrote: > > I was asking whether OpenSSL was used because of a question we had > > about FIPS validation. FIPS requires that all cryptography components > > go through a validation process, which some versions of OpenSSL (but > > not all) have done. > > > > My understanding is that RTPengine uses OpenSSL for the AES, but not > > for all of the key functions. Is that right? If so then even if we're > > using a FIPS validated version of OpenSSL, not all of the cryptography > > components of RTPengine would be using it, so we wouldn't be fully > > FIPS validated. > > DTLS is entirely provided by OpenSSL, except for the raw network I/O. > > Once the DTLS handshake completes, the SRTP keys are extracted out of > OpenSSL. > > The cipher implementation (AES) as well as the digest implementation > (SHA-1) are provided by OpenSSL. > > For AEAD-GCM, the entire encryption, decryption, and authentication > process is handled by OpenSSL. > > For the other cipher suites (AES-CM, AES-F8), OpenSSL is used to create > the block key via AES, and then rtpengine has its own implementation of > the counter-mode cipher to apply the AES key to the SRTP payload. This > is because SRTP uses a peculiar version of AES-CM that OpenSSL doesn't > directly support. (This really isn't much more than XOR'ing the AES key > onto the SRTP payload and so isn't really doing much cryptography.) > > For SRTP in the kernel module, it's more or less exactly the same, > except that the kernel's crypto API is used instead of OpenSSL. (DTLS is > done in userspace only.) > > Cheers > > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
Thank you Richard, it does sound like DTLS is an improvement then. I was asking whether OpenSSL was used because of a question we had about FIPS validation. FIPS requires that all cryptography components go through a validation process, which some versions of OpenSSL (but not all) have done. My understanding is that RTPengine uses OpenSSL for the AES, but not for all of the key functions. Is that right? If so then even if we're using a FIPS validated version of OpenSSL, not all of the cryptography components of RTPengine would be using it, so we wouldn't be fully FIPS validated. On Wed, 10 Apr 2024 at 22:50, Richard Fuchs via sr-users < sr-users@lists.kamailio.org> wrote: > On 09/04/2024 23.14, Alex Balashov via sr-users wrote: > > Exchanging keys directly in the SDP body is rather suboptimal from a security > standpoint, even if the signalling is encrypted, but it's certainly simpler. > > I suppose that makes DTLS "more secure", but in every other sense, I'm not > sure DTLS is "better". W3C WebRTC standards mandate DTLS-SRTP, as far as I > know, so I suppose it's more fit for that purpose. > > To add to that, one benefit DTLS has over SDES is that key exchange can > happen as soon as media can flow, which theoretically can be immediately > after the initial offer (invite), especially if ICE is also in use, as is > the case with WebRTC. Whereas with SDES, since key exchange happens in-line > with the signalling, key exchange can only be completed once an answer to > the initial offer has been received. Which means that at least in theory > DTLS is faster to establish media than SDES is. (Caveat: Not all DTLS > clients actually allow this.) > > As for security: The most commonly used SRTP key types that can be > exchanged are the same between SDES and DTLS, so in this aspect neither is > more secure than the other. As for key exchange itself, DTLS is more > sophisticated as it uses a peer-to-peer (with rtpengine being one of the > peers in your case) public-key exchange to set up SRTP, whereas SDES relies > on the signalling transport to be encrypted, which almost certainly isn't > the case peer-to-peer (i.e. any involved signalling gateway or proxy can > inspect or possibly modify the keys). > > In theory DTLS also allows extra trust to be established via verification > of the DTLS certificates, but in practice this isn't usually done as the > certificates are often self-signed. > > Cheers > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
Thank you Alex! On Wed, 10 Apr 2024 at 15:26, Alex Balashov via sr-users < sr-users@lists.kamailio.org> wrote: > > > On Apr 9, 2024, at 7:25 PM, David Cunningham via sr-users < > sr-users@lists.kamailio.org> wrote: > > > > Thank you very much for the information. In our Kamailio configuration > the rtpengine_manage() lines have "SDES-off", so presumably then we are > using DTLS? > > Exactly so. My response was more presumptuous than Richard's, because SDES > has fallen out of fashion. > > > Are either SDES or DTLS considered more secure or "better" in any way? > > Exchanging keys directly in the SDP body is rather suboptimal from a > security standpoint, even if the signalling is encrypted, but it's > certainly simpler. > > I suppose that makes DTLS "more secure", but in every other sense, I'm not > sure DTLS is "better". W3C WebRTC standards mandate DTLS-SRTP, as far as I > know, so I suppose it's more fit for that purpose. > > -- Alex > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
Hi Richard and Alex, Thank you very much for the information. In our Kamailio configuration the rtpengine_manage() lines have "SDES-off", so presumably then we are using DTLS? Are either SDES or DTLS considered more secure or "better" in any way? On Wed, 10 Apr 2024 at 10:32, Richard Fuchs via sr-users < sr-users@lists.kamailio.org> wrote: > On 09/04/2024 17.40, David Cunningham via sr-users wrote: > > How does rtpengine get the TLS certificates, and what crypto library > > does it use (openssl?). > > SRTP itself doesn't use any certificates, and is not TLS. The underlying > cipher (AES) is provided by OpenSSL, while the SRTP implementation > itself is its own. > > TLS and certificates are relevant when it comes to the key exchange. > With SDES, keys are exchanged in-line and nothing else is needed. > > The other option is DTLS: Here a self-signed certificate is used > (generated at startup), and keys are exchanged using the DTLS > implementation provided by OpenSSL. The certificate's fingerprint is > exchanged in-line and that's how the peer's certificate is verified. > After the key exchange completes, the SRTP keys are extracted from the > handshake, DTLS is done, and the rest is just regular SRTP. > > Cheers > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Kamailio with rtpengine for RTP encryption/decryption
Hello, We're using kamailio, with rtpengine for RTP encryption/decryption. It works fine but I would like to understand the integration better. How does rtpengine get the TLS certificates, and what crypto library does it use (openssl?). Thank you in advance, -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Sharing load between rtpengine servers
Thank you everyone, I appreciate that input. With the line changed to the following it does distribute load evenly; we'll try adding different sets soon. #!define RTPENGINE_ADDR "udp:22.22.22.22:7724 udp:33.33.33.33:7724" On Fri, 10 Nov 2023 at 05:11, Daniel-Constantin Mierla via sr-users < sr-users@lists.kamailio.org> wrote: > You might be right. > > I haven't used second parameter for set_rtpengine_set(), I don't recall > who implemented it, but maybe someone else can confirm if it is like that > and eventually add a clearer sentence there. > > Cheers, > Daniel > On 09.11.23 16:26, Ben Kaufman wrote: > > From a strictly linguistic point of view the sentence, “This is supported > by all rtpengine commands except rtpengine_manage()” is at the end of the > second paragraph, which is in reference to the second argument. I would > take it to mean that the second argument is not supported by > rtpengine_manage() – not that the entire function is not supported. Does > that seem correct? > > > > > > As reference the full section: > > > > --- > > 5.1. set_rtpengine_set(setid[, setid]) > > > > Sets the ID of the RTP proxy set to be used for the next > rtpengine_delete(), rtpengine_offer(), rtpengine_answer() or > rtpengine_manage() command. The parameter can be an integer or a config > variable holding an integer. > > > > A second set ID can be specified to daisy-chain two RTP proxies. The two > set IDs must be distinct from each other and there must not be any overlap > in the proxies present in both sets. In this use case, the request (offer, > answer, etc) is first sent to an RTP proxy from the first set, which > rewrites the SDP body and sends it back to the module. The rewritten SDP > body is then used to make another request to an RTP proxy from the second > set, which rewrites the SDP body another time and sends it back to the > module to be placed back into the SIP message. This is useful if you have a > set of RTP proxies that the caller must use, and another distinct set of > RTP proxies that the callee must use. This is supported by all rtpengine > commands except rtpengine_manage(). > > --- > > > > > > > > *From:* Daniel-Constantin Mierla via sr-users > > *Sent:* Thursday, November 9, 2023 2:25 AM > *To:* Kamailio (SER) - Users Mailing List > > *Cc:* Daniel-Constantin Mierla > *Subject:* [SR-Users] Re: Sharing load between rtpengine servers > > > > *CAUTION:* This email originated from outside the organization. *Do not > click links or open attachments* unless you recognize the sender and know > the content is safe. > > > > Hello, > > not sure why that remark is there, because contradicts with the first > paragraph that has: > > "Sets the ID of the RTP proxy set to be used for the next > rtpengine_delete(), rtpengine_offer(), rtpengine_answer() or > rtpengine_manage() command." > > - > https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html#rtpengine.f.set_rtpengine_set > > I don't think that the last statement is good, maybe it propagated without > notice from a very old version. From code point of view, there is no reason > for set_rtpengine_set() not to work for rtpengine_manage(), this function > is a pretty simple wrapper for rtpengine_offer()/_answer()/_delete(). > > I am going to remove that last statement from docs. > > Cheers, > Daniel > > On 09.11.23 01:06, David Cunningham via sr-users wrote: > > Hi Alex, > > > > It's on the page that you linked to: "This is supported by all rtpengine > commands except rtpengine_manage()." > > > > Thanks. > > > > > > On Thu, 9 Nov 2023 at 12:55, Alex Balashov > wrote: > > Hi David, > > Whence the impression that sets aren't compatible with rtpengine_manage()? > > > https://kamailio.org/docs/modules/5.7.x/modules/rtpengine.html#rtpengine.f.set_rtpengine_set > >"Sets the ID of the RTP proxy set to be used for the next > rtpengine_delete(), > rtpengine_offer(), rtpengine_answer() or rtpengine_manage() command. > The parameter > can be an integer or a config variable holding an integer." > > Or are you using an earlier version of Kamailio in which this may not have > been true? > > -- Alex > > > On 8 Nov 2023, at 18:52, David Cunningham > wrote: > > > > Hi Alex, > > > > Thank you for the reply. We use a large weight of to send > almost all calls to the 22.x and 33.x servers without using sets. We > avoided sets because our Kamailio configuration uses rtpengine_manage(), > which according to the documentation is not compat
[SR-Users] Re: Sharing load between rtpengine servers
Hi Alex,
It's on the page that you linked to: "This is supported by all rtpengine
commands except rtpengine_manage()."
Thanks.
On Thu, 9 Nov 2023 at 12:55, Alex Balashov
wrote:
> Hi David,
>
> Whence the impression that sets aren't compatible with rtpengine_manage()?
>
>
> https://kamailio.org/docs/modules/5.7.x/modules/rtpengine.html#rtpengine.f.set_rtpengine_set
>
>"Sets the ID of the RTP proxy set to be used for the next
> rtpengine_delete(),
> rtpengine_offer(), rtpengine_answer() or rtpengine_manage() command.
> The parameter
> can be an integer or a config variable holding an integer."
>
> Or are you using an earlier version of Kamailio in which this may not have
> been true?
>
> -- Alex
>
> > On 8 Nov 2023, at 18:52, David Cunningham
> wrote:
> >
> > Hi Alex,
> >
> > Thank you for the reply. We use a large weight of to send
> almost all calls to the 22.x and 33.x servers without using sets. We
> avoided sets because our Kamailio configuration uses rtpengine_manage(),
> which according to the documentation is not compatible with
> set_rtpengine_set(). I'll try it without the 11.x server and the large
> weights, and see if the calls are evenly distributed between the 22.x and
> 33.x servers then.
> >
> > Thanks again.
> >
> >
> > On Thu, 9 Nov 2023 at 10:25, Alex Balashov via sr-users <
> sr-users@lists.kamailio.org> wrote:
> > Hi,
> >
> > From the docs:
> >
> > "The balancing inside a set is done automatically by the module based on
> the weight of each RTPEngine from the set. The default weight is 1, if
> another RTPEngine should be used twice as often as the first one, one would
> specify the weight 2 for this server, for example."
> >
> > I am unsure as to what effect such large values as might have
> on this arithmetic.
> >
> > It seems to me that if what you really want to accomplish is to evenly
> distribute calls between 22.22.22.22 and 33.33.33.33, with 11.11.11.11 only
> as a last-resort backup, then you should put the first two into one naive
> set without any weights, e.g.
> >
> >modparam("rtpengine_sock", "1 == udp:22.22.22.22:7724 udp:
> 33.33.33.33:7724")
> >
> > Then put 11.11.11.11 into a set of its own:
> >
> >modparam("rtpengine_sock", "2 == udp:11.11.11.11:22724")
> >
> > By default, set 1 should be invoked:
> >
> >set_rtpengine_set("1");
> >rtpengine_{offer,manage}("...");
> >
> > According to the docs, rtpengine_offer() will return a negative value if
> there is a failure of both:
> >
> >"The function will return true on success and false (-1) on various
> failures, like
> > using rtp_engine_offer() on a SIP MESSAGE request or communication
> with rtpengine fails."
> >
> > Presumably, rtpengine_manage() does the same. Accordingly, you can do
> something like:
> >
> >set_rtpengine_set("1");
> >
> >if(!rtpengine_offer("...")) {
> >if($rc == -1) {
> >set_rtpengine_set("2");
> >rtpengine_offer("...");
> >}
> >}
> >
> > Exact details and your mileage may vary.
> >
> > -- Alex
> >
> > > On 8 Nov 2023, at 15:33, David Cunningham via sr-users <
> sr-users@lists.kamailio.org> wrote:
> > >
> > > Hello,
> > >
> > > We have a Kamailio configuration with the following, however all the
> load is going to the server at 22.22.22.22 (hiding the real IP obviously)
> instead of being shared evenly between 22.22.22.22 and 33.33.33.33. Can
> anyone please tell me why? The rtpengine server at 11.11.11.11 is intended
> to only receive calls if the other two are offline. Thank you very much.
> > >
> > > #!define RTPENGINE_ADDR "udp:11.11.11.11:7724=1
> > > udp:22.22.22.22:7724=
> udp:33.33.33.33:7724="
> > >
> > > modparam( "rtpengine", "rtpengine_sock", RTPENGINE_ADDR )
> > >
> > > --
> > > David Cunningham, Voisonics Limited
> > > http://voisonics.com/
> > > USA: +1 213 221 1092
> > > New Zealand: +64 (0)28 2558 3782
> > > __
> > > Kamailio - Users Mailing List - Non Commercial Discussions
> > > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > > Important: keep the mailing list in the recipients, do not reply
[SR-Users] Re: Sharing load between rtpengine servers
Hi Alex,
Thank you for the reply. We use a large weight of to send almost
all calls to the 22.x and 33.x servers without using sets. We avoided sets
because our Kamailio configuration uses rtpengine_manage(), which according
to the documentation is not compatible with set_rtpengine_set(). I'll try
it without the 11.x server and the large weights, and see if the calls are
evenly distributed between the 22.x and 33.x servers then.
Thanks again.
On Thu, 9 Nov 2023 at 10:25, Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:
> Hi,
>
> From the docs:
>
> "The balancing inside a set is done automatically by the module based on
> the weight of each RTPEngine from the set. The default weight is 1, if
> another RTPEngine should be used twice as often as the first one, one would
> specify the weight 2 for this server, for example."
>
> I am unsure as to what effect such large values as might have on
> this arithmetic.
>
> It seems to me that if what you really want to accomplish is to evenly
> distribute calls between 22.22.22.22 and 33.33.33.33, with 11.11.11.11 only
> as a last-resort backup, then you should put the first two into one naive
> set without any weights, e.g.
>
>modparam("rtpengine_sock", "1 == udp:22.22.22.22:7724 udp:
> 33.33.33.33:7724")
>
> Then put 11.11.11.11 into a set of its own:
>
>modparam("rtpengine_sock", "2 == udp:11.11.11.11:22724")
>
> By default, set 1 should be invoked:
>
>set_rtpengine_set("1");
>rtpengine_{offer,manage}("...");
>
> According to the docs, rtpengine_offer() will return a negative value if
> there is a failure of both:
>
>"The function will return true on success and false (-1) on various
> failures, like
> using rtp_engine_offer() on a SIP MESSAGE request or communication
> with rtpengine fails."
>
> Presumably, rtpengine_manage() does the same. Accordingly, you can do
> something like:
>
>set_rtpengine_set("1");
>
>if(!rtpengine_offer("...")) {
>if($rc == -1) {
>set_rtpengine_set("2");
>rtpengine_offer("...");
>}
>}
>
> Exact details and your mileage may vary.
>
> -- Alex
>
> > On 8 Nov 2023, at 15:33, David Cunningham via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >
> > Hello,
> >
> > We have a Kamailio configuration with the following, however all the
> load is going to the server at 22.22.22.22 (hiding the real IP obviously)
> instead of being shared evenly between 22.22.22.22 and 33.33.33.33. Can
> anyone please tell me why? The rtpengine server at 11.11.11.11 is intended
> to only receive calls if the other two are offline. Thank you very much.
> >
> > #!define RTPENGINE_ADDR "udp:11.11.11.11:7724=1
> > udp:22.22.22.22:7724=
> udp:33.33.33.33:7724="
> >
> > modparam( "rtpengine", "rtpengine_sock", RTPENGINE_ADDR )
> >
> > --
> > David Cunningham, Voisonics Limited
> > http://voisonics.com/
> > USA: +1 213 221 1092
> > New Zealand: +64 (0)28 2558 3782
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> > Edit mailing list options or unsubscribe:
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Sharing load between rtpengine servers
Hello, We have a Kamailio configuration with the following, however all the load is going to the server at 22.22.22.22 (hiding the real IP obviously) instead of being shared evenly between 22.22.22.22 and 33.33.33.33. Can anyone please tell me why? The rtpengine server at 11.11.11.11 is intended to only receive calls if the other two are offline. Thank you very much. #!define RTPENGINE_ADDR "udp:11.11.11.11:7724=1 udp:22.22.22.22:7724= udp:33.33.33.33:7724=" modparam( "rtpengine", "rtpengine_sock", RTPENGINE_ADDR ) -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782 __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
