Re: [SR-Users] force_send_socket
Henning, I personally agree with this. But perhaps there are different points of view out there - about how multiple ways to do a thing represents a thriving marketplace of ideas. After all, there is a reason Perl evolved the way it did, surely... -- Sent from mobile. Apologies for brevity and errors. -Original Message- From: Henning Westerholt To: sr-users@lists.kamailio.org Cc: Alex Balashov Sent: Mon, 08 Oct 2018 3:47 PM Subject: Re: [SR-Users] force_send_socket Am Montag, 8. Oktober 2018, 13:24:22 CEST schrieb Alex Balashov: > OK, I touched off a controversy with my use of the word "deprecated" > that I did not intend, as the implied intellectual or policy commitment > to that word is not really strong. :-) > [..] > Not everyone shares this exact set of tacit assumptions, I imagine, and > I think that's what got folk exercised when I said "deprecated". These > functions will surely remain for backward compatibility. Hello Alex, to add something more on the general level: If we have old core functions (in a class like this one) that can be replaced completely with a new PV assigment or similar function, then we should indeed deprecate them with a log warning and then remove them completely later. It is probably confusing especially for newcomers to Kamailio to have several functions with different semantics and syntax. Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio security assessment - https://skalatan.de/de/assessment ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio with Asterisk as Media Relay
Also asterisk is a B2BUA, so if calls are delivered to the B side by asterisk, the B side will see call coming from the Asterisks, not from the Kamailio. On Mon, Oct 8, 2018, 15:54 Alex Balashov wrote: > On Mon, Oct 08, 2018 at 02:35:54PM +0200, Daniel Tryba wrote: > > > On Mon, Oct 08, 2018 at 07:16:43AM -0400, Alex Balashov wrote: > > > The SDP-bearing INVITE and response are simply passed along as-is by > > > Kamailio, and it is the SDP which specifies where the media goes. So, > if > > > endpoint A calls through Kamailio proxy B to Asterisk server C via SIP, > > > A and C will negotiate media amongst themselves without any > intervention > > > or special measures on your part whatsoever. > > > > In theory, but with Asterisk in the middle be prepared to have this fail > > since it initially is in the loop regarding RTP and can negotiate > > incompatible RTP legs between AB and BC which will not be fixed when > > Asterisk leaves the RTP path. Mainly I experience this with > > dtmf/telephone-events mapping, e.g.: a=rtpmap:101 telephone-event/8000 > > If a and c have different values, dtmf will fail. > > Well, yes, all kinds of interesting things can happen in the bridging > process. But in principle, at least, it is possible to bridge RTP across > two call legs without such issues. :-) > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > ___ > 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
Re: [SR-Users] Kamailio with Asterisk as Media Relay
On Mon, Oct 08, 2018 at 02:35:54PM +0200, Daniel Tryba wrote: > On Mon, Oct 08, 2018 at 07:16:43AM -0400, Alex Balashov wrote: > > The SDP-bearing INVITE and response are simply passed along as-is by > > Kamailio, and it is the SDP which specifies where the media goes. So, if > > endpoint A calls through Kamailio proxy B to Asterisk server C via SIP, > > A and C will negotiate media amongst themselves without any intervention > > or special measures on your part whatsoever. > > In theory, but with Asterisk in the middle be prepared to have this fail > since it initially is in the loop regarding RTP and can negotiate > incompatible RTP legs between AB and BC which will not be fixed when > Asterisk leaves the RTP path. Mainly I experience this with > dtmf/telephone-events mapping, e.g.: a=rtpmap:101 telephone-event/8000 > If a and c have different values, dtmf will fail. Well, yes, all kinds of interesting things can happen in the bridging process. But in principle, at least, it is possible to bridge RTP across two call legs without such issues. :-) -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio with Asterisk as Media Relay
On Mon, Oct 08, 2018 at 07:16:43AM -0400, Alex Balashov wrote: > The SDP-bearing INVITE and response are simply passed along as-is by > Kamailio, and it is the SDP which specifies where the media goes. So, if > endpoint A calls through Kamailio proxy B to Asterisk server C via SIP, > A and C will negotiate media amongst themselves without any intervention > or special measures on your part whatsoever. In theory, but with Asterisk in the middle be prepared to have this fail since it initially is in the loop regarding RTP and can negotiate incompatible RTP legs between AB and BC which will not be fixed when Asterisk leaves the RTP path. Mainly I experience this with dtmf/telephone-events mapping, e.g.: a=rtpmap:101 telephone-event/8000 If a and c have different values, dtmf will fail. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] force_send_socket
Alex Balashov writes: > In the core, there are lots of functions such as strip(), prefix(), > rewritehostport(), and, in my view, force_send_socket(). These functions > don't take PV arguments, and are superceded by the more flexible direct > manipulation of the RURI, the destination set, and $fs, along with the > wealth of transformations available nowadays, which can be chained. It would be nice if $fs would supersede force_send_socket, i.e, allow proto to be missing. I haven't tried myself. If proto is mandatory in $fs then its use is more cumbersome than that of force_send_socket. -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] set_advertised_address with variable
Hi Daniel! Thanks for the effort! Really appreciate it! I am not using the 5.2 version yet, so it I won't be able to test it right away... Best regards, Patrick Wakano On Fri, 5 Oct 2018 at 18:37, Daniel-Constantin Mierla wrote: > Hello, > > yesterday afternoon I pushed an alternative for allowing setting the > address and port in local Via headers using XAVP, see: > > - https://www.kamailio.org/wiki/cookbooks/devel/core#xavp_via_fields > > I didn't have the time to do any tests, but was in master before freezing > code for 5.2.x series, so it will be in the next major release. Test and if > there is any bug, report and it will be fixed. > > I also looked at extending the set_advertised_address(), but it actually > uses pointers to some static values available at kamailio startup, so > making that dynamic would have been more complex to do in a short time. > > Cheers, > Daniel > > On 03.10.18 03:28, Patrick Wakano wrote: > > Thanks for the replies Daniel and Henning! > The problem with the listen address is that it can't be set at run time > per call, for example, after reading the value from the DB And also it > is way too dirty to use the set_advertised_address with a static string > value > Long story short, we have a weird telco setup which only allows the SIP > trunk to terminate in their own network, which then puts my Kamailio behind > a NAT box only for them. And because they are the biggest carrier in that > country, we will have to workaround the issue. > Kamailio itself has only one network interface to communicate with > everyone (other provider and extensions), so I was trying to actually only > set the advertise address before sending call to this specific telco. For > calls to anyone else I would not set the advertise address. Looks simple, > but seems not that easy to implement. > > Cheers, > Patrick Wakano > > On Tue, 2 Oct 2018 at 15:39, Daniel-Constantin Mierla > wrote: > >> Hello, >> >> the pseudo-variable is read only. >> >> The recommended way would be to use listen with advertise, like: >> >> listen=udp:1.2.3.4:5060 advertise 5.6.7.8:5060 >> >> That will take care of both Via and Record-Route headers as well as >> matching myself, no need to do other stuff in route blocks. Doesn't work >> for you? >> >> Cheers, >> Daniel >> >> >> On 01.10.18 22:16, Henning Westerholt wrote: >> > Am Freitag, 28. September 2018, 07:16:18 CEST schrieb Patrick Wakano: >> >> Sorry to annoy again, but I did find a couple of more emails asking >> around >> >> about the possibility to pass a variable to the >> set_advertised_address, but >> >> no one was replied >> >> How is the status of these old core functions that don't accept >> variables >> >> as parameters? Is it something being worked on? >> > Hi Patrick, >> > >> > about the old core function - I think that indeed some of them are still >> > missing PV support. Regarding your question, have you already tried to >> use >> > this PV: >> > >> > >> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#rai_-_received_advertised_ip_address >> > >> > Best regards, >> > >> > Henning >> > >> >> -- >> Daniel-Constantin Mierla -- www.asipto.com >> www.twitter.com/miconda -- www.linkedin.com/in/miconda >> Kamailio World Conference -- www.kamailioworld.com >> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com >> >> >> ___ >> 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.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > Kamailio World Conference -- www.kamailioworld.com > Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com > > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Sending INVITE from loopback subnet
Hi Joonas, Well, that's right -- Kamailio is not especially well-suited to forwarding traffic among more than a handful of interfaces, for precisely the reasons you have discovered. There are some ugly hacks around some of it available, but none are pretty nor come recommended. -- Alex On Mon, Oct 08, 2018 at 11:34:44AM +0300, Joonas Kamailio wrote: > Dear List, > > I am trying to achieve a scenario where I can recognize the original peer > and mask it as peer from subnet 10.0.7.0/24 with kamailio. Basic IP > connectivity is established with the following network configuration > (Debian9): > > auto lo:1 > iface lo:1 inet static > address 10.0.0.0/24 > > And of course I have routed 10.0.0.0/24 to servers public IP address (hereby > known as x.x.x.1) in my router. > > Please consider the following scenario: > > - Peer1 192.168.0.1 is sending INVITE to kamailio at IP x.x.x.1 > - Kamailio sends INVITE to peer2 at 172.10.0.1 from socket 10.0.0.1 > - Peer2 receives the INVITE and knows that since it came from IP 10.0.0.1 it > means that INVITE is originally from peer1 > - IF peer2 sends INVITE to kamailio, it should be sent to peerX from socket > 10.0.0.2 > > This works if I list both 10.0.0.1 and 10.0.0.2 with 'listen=' parameter but > things get out of hand if I have multiple peers. In my tests I have noticed > that 60 peers equals 60 listen parameters which equals roughly 500 kamailio > processes. At some point there are just too many processes and everything > melts. If I omit the listen parameter altogether, kamailio has only one > socket from /24 subnet and it is 10.0.0.0. > > Error message when listen parameter is omitted: > [pv_core.c:2612]: pv_set_force_sock(): no socket found to match [10.0.0.1] > > My kamailio has the following configuration in request_route: > > $avp(e_private) = $(sht(get_private=>$si)); > $fs = $avp(e_private); > > I know that the case is a bit confusing and totally something normal people > won't do. If you have any questions I am happy to answer. > > Best Regards, > Joonas Keskitalo > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] force_send_socket
OK, I touched off a controversy with my use of the word "deprecated" that I did not intend, as the implied intellectual or policy commitment to that word is not really strong. :-) What I meant through that particular choice of words is that there is, among those with some lengthy experience with the OpenSER pedigree, a recognised set of core functions and ancient modules which correspond to a different era of SER/OpenSER, and are not complementary to the ways of doing things that are concomitant with the present generation of the system. Examples from modules include most of the `avpops` module functions, as well as the `usr_preferences` table - both take us back to a time before generic SQL queries and arbitrary data sources were a first-class aspect of Kamailio, as with the `sqlops` module, `htable`, etc. In the core, there are lots of functions such as strip(), prefix(), rewritehostport(), and, in my view, force_send_socket(). These functions don't take PV arguments, and are superceded by the more flexible direct manipulation of the RURI, the destination set, and $fs, along with the wealth of transformations available nowadays, which can be chained. Not everyone shares this exact set of tacit assumptions, I imagine, and I think that's what got folk exercised when I said "deprecated". These functions will surely remain for backward compatibility. -- Alex On Mon, Oct 08, 2018 at 02:07:23PM +0300, Juha Heinanen wrote: > > Le 08/10/2018 à 02:27, Alex Balashov a écrit : > > > Hi, > > > > > > 1. force_send_socket() is essentially deprecated in favour of mutating > > > $fs: > > > > > > $fs = 'udp:67.215.186.219:5060'; > > According to wiki, $fs cannot deprecate force_send_socket. > > In force_send_socket, proto can be left out: > > force_send_socket > > Force to send the message from the specified socket (it _must_ be one of > the sockets specified with the “listen” directive). If the protocol > doesn't match (e.g. UDP message “forced” to a TCP socket) the closest > socket of the same protocol is used. > > wheres: > > $fs - Forced socket > > $fs - reference to the forced socket for message sending (if any) in > the form proto:ip:port > > -- Juha > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio with Asterisk as Media Relay
Hi Benjamin, No positive action on your part is required of you or Kamailio to make this scenario work; it's simply the default. The SDP-bearing INVITE and response are simply passed along as-is by Kamailio, and it is the SDP which specifies where the media goes. So, if endpoint A calls through Kamailio proxy B to Asterisk server C via SIP, A and C will negotiate media amongst themselves without any intervention or special measures on your part whatsoever. -- Alex On Mon, Oct 08, 2018 at 01:12:56PM +0200, Benjamin Marty wrote: > I would like to ask if there is any available informations on how to use > Kamailio as a SIP Proxy but letting (multiple) Asterisk Instances do the > Media Relaying. Is this scenario supported and if yes are there any > tutorials or documentation available for it? > > I know the Kamailio Dispatcher Module, but this does as far as I know a > dispatching of also the SIP Traffic. Not just the Media Traffic. > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio with Asterisk as Media Relay
Hello I would like to ask if there is any available informations on how to use Kamailio as a SIP Proxy but letting (multiple) Asterisk Instances do the Media Relaying. Is this scenario supported and if yes are there any tutorials or documentation available for it? I know the Kamailio Dispatcher Module, but this does as far as I know a dispatching of also the SIP Traffic. Not just the Media Traffic. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Server_id expects number only
Err I'm sorry I didn't pay close enough attention to your int, the network address for 192.168.100.100 would be ... 3232261220 On Mon, Oct 8, 2018 at 4:10 AM Brandon Armstead wrote: > Sorry for late reply - however ; yes -- if it will accept this int - i've > not tried it. > > On Mon, Oct 1, 2018 at 7:26 AM Denys Pozniak > wrote: > >> Do you mean like server_id="192.168.100.100" --> server_id=192168100100 >> ? >> Generally I use similar logic to recover IP from number. >> >> пн, 1 окт. 2018 г. в 16:52, Brandon Armstead : >> >>> You could try using network address for the ip? >>> >>> On Mon, Oct 1, 2018 at 6:48 AM Denys Pozniak >>> wrote: >>> Hello! I need to separate Kamailio's dmq_usrloc by server_id and will be much easily if server_id can accept string values also, like: server_id="192.168.100.100" But currently it accepts only integer: https://www.kamailio.org/wiki/cookbooks/5.1.x/core#server_id Syslog: 0(11488) CRITICAL: [core/cfg.y:3447]: yyerror_at(): parse error in config file /etc/kamailio/global.cfg, line 126, column 11-24: syntax error 0(11488) CRITICAL: [core/cfg.y:3447]: yyerror_at(): parse error in config file /etc/kamailio/global.cfg, line 126, column 11-24: number expected -- BR, Denys Pozniak ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> -- >>> Sent from Gmail Mobile >>> ___ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> >> >> -- >> >> BR, >> Denys Pozniak >> >> >> ___ >> Kamailio (SER) - Users Mailing List >> sr-users@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > > -- > Sincerely, > Brandon Armstead > CTO / CRYY.com > -- Sincerely, Brandon Armstead CTO / CRYY.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Server_id expects number only
Sorry for late reply - however ; yes -- if it will accept this int - i've not tried it. On Mon, Oct 1, 2018 at 7:26 AM Denys Pozniak wrote: > Do you mean like server_id="192.168.100.100" --> server_id=192168100100 ? > Generally I use similar logic to recover IP from number. > > пн, 1 окт. 2018 г. в 16:52, Brandon Armstead : > >> You could try using network address for the ip? >> >> On Mon, Oct 1, 2018 at 6:48 AM Denys Pozniak >> wrote: >> >>> Hello! >>> >>> I need to separate Kamailio's dmq_usrloc by server_id and will be much >>> easily if server_id can accept string values also, like: >>> server_id="192.168.100.100" >>> >>> But currently it accepts only integer: >>> https://www.kamailio.org/wiki/cookbooks/5.1.x/core#server_id >>> >>> Syslog: >>> 0(11488) CRITICAL: [core/cfg.y:3447]: yyerror_at(): parse error >>> in config file /etc/kamailio/global.cfg, line 126, column 11-24: syntax >>> error >>> 0(11488) CRITICAL: [core/cfg.y:3447]: yyerror_at(): parse error >>> in config file /etc/kamailio/global.cfg, line 126, column 11-24: number >>> expected >>> >>> >>> -- >>> >>> BR, >>> Denys Pozniak >>> >>> >>> ___ >>> Kamailio (SER) - Users Mailing List >>> sr-users@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> -- >> Sent from Gmail Mobile >> ___ >> Kamailio (SER) - Users Mailing List >> sr-users@lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > > -- > > BR, > Denys Pozniak > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Sincerely, Brandon Armstead CTO / CRYY.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] force_send_socket
> Le 08/10/2018 à 02:27, Alex Balashov a écrit : > > Hi, > > > > 1. force_send_socket() is essentially deprecated in favour of mutating > > $fs: > > > > $fs = 'udp:67.215.186.219:5060'; According to wiki, $fs cannot deprecate force_send_socket. In force_send_socket, proto can be left out: force_send_socket Force to send the message from the specified socket (it _must_ be one of the sockets specified with the “listen” directive). If the protocol doesn't match (e.g. UDP message “forced” to a TCP socket) the closest socket of the same protocol is used. wheres: $fs - Forced socket $fs - reference to the forced socket for message sending (if any) in the form proto:ip:port -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] force_send_socket
It was a point of view rather than an official position, since force_send_socket doesn't accept PVs and is an old core function. -- Sent from mobile. Apologies for brevity and errors. -Original Message- From: Mathias To: sr-users@lists.kamailio.org Sent: Mon, 08 Oct 2018 2:28 AM Subject: Re: [SR-Users] force_send_socket Hi Alex, You said that force_send_socket() is deprecated. Could you give me a reference as i did not see this information. Thanks Mathias Le 08/10/2018 à 02:27, Alex Balashov a écrit : > Hi, > > 1. force_send_socket() is essentially deprecated in favour of mutating > $fs: > > $fs = 'udp:67.215.186.219:5060'; > > 2. Do you have an exact matching[1] listener for this outgoing > interface? > > [1] Transport, IP, port. > ___ 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] Sending INVITE from loopback subnet
Dear List, I am trying to achieve a scenario where I can recognize the original peer and mask it as peer from subnet 10.0.7.0/24 with kamailio. Basic IP connectivity is established with the following network configuration (Debian9): auto lo:1 iface lo:1 inet static address 10.0.0.0/24 And of course I have routed 10.0.0.0/24 to servers public IP address (hereby known as x.x.x.1) in my router. Please consider the following scenario: - Peer1 192.168.0.1 is sending INVITE to kamailio at IP x.x.x.1 - Kamailio sends INVITE to peer2 at 172.10.0.1 from socket 10.0.0.1 - Peer2 receives the INVITE and knows that since it came from IP 10.0.0.1 it means that INVITE is originally from peer1 - IF peer2 sends INVITE to kamailio, it should be sent to peerX from socket 10.0.0.2 This works if I list both 10.0.0.1 and 10.0.0.2 with 'listen=' parameter but things get out of hand if I have multiple peers. In my tests I have noticed that 60 peers equals 60 listen parameters which equals roughly 500 kamailio processes. At some point there are just too many processes and everything melts. If I omit the listen parameter altogether, kamailio has only one socket from /24 subnet and it is 10.0.0.0. Error message when listen parameter is omitted: [pv_core.c:2612]: pv_set_force_sock(): no socket found to match [10.0.0.1] My kamailio has the following configuration in request_route: $avp(e_private) = $(sht(get_private=>$si)); $fs = $avp(e_private); I know that the case is a bit confusing and totally something normal people won't do. If you have any questions I am happy to answer. Best Regards, Joonas Keskitalo ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] force_send_socket
Hi Alex, You said that force_send_socket() is deprecated. Could you give me a reference as i did not see this information. Thanks Mathias Le 08/10/2018 à 02:27, Alex Balashov a écrit : Hi, 1. force_send_socket() is essentially deprecated in favour of mutating $fs: $fs = 'udp:67.215.186.219:5060'; 2. Do you have an exact matching[1] listener for this outgoing interface? [1] Transport, IP, port. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
