Re: [SR-Users] Postgres: server version < 9.5 does not support insert_update
Hello, kamailio works fine if the database server does not support insert_update statement, this being used only if enabled via usrloc module parameter. Not being the developer of db postgres module, I guess the message is just an usual warning to make the voip admin aware and not enable use of this statement for user location/registrar. Cheers, Daniel On Tue, Oct 23, 2018 at 7:46 AM Minh Phan wrote: > Hello List, > > I have just installed the version 5.1.6 and I get this warning message > when Kamailio starts: > > > db_postgres_new_connection(): server version < 9.5 does not support > insert_update > > Does it mean Kamailio will not be working properly with my current > Postgres Server (9.4)? What are the consequence of not having support for > insert_update command? > > Best regards, > Minh Phan > > > > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine
No calls to fix_nated_sdp(). -Original Message- From: sr-users On Behalf Of Alex Balashov Sent: Tuesday, October 23, 2018 9:58 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Also, is there any possibility that you are calling fix_nated_sdp() and rtpengine_offer/manage() successively? -- Sent from mobile. Apologies for brevity and errors. ___ 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] Double Session Description Protocol Version (v) 0 data when using rtpengine
Let me check...Thank you. -Original Message- From: sr-users On Behalf Of Alex Balashov Sent: Tuesday, October 23, 2018 9:58 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Also, is there any possibility that you are calling fix_nated_sdp() and rtpengine_offer/manage() successively? -- Sent from mobile. Apologies for brevity and errors. ___ 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] Double Session Description Protocol Version (v) 0 data when using rtpengine
I thought using data would imply what I meant to say, but I guess I was wrong. Sometime I take to many shortcuts in typing. -Original Message- From: sr-users On Behalf Of Alex Balashov Sent: Tuesday, October 23, 2018 9:57 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Then your description of the problem, and the subject line of your post, is not accurate. :-) This should not be happening. What does the rtpengine log show for the given Call-ID? -- Sent from mobile. Apologies for brevity and errors. -Original Message- From: "Wilkins, Steve" To: "Kamailio (SER) - Users Mailing List" Sent: Tue, 23 Oct 2018 9:55 PM Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Entire section. -Original Message- From: sr-users On Behalf Of Alex Balashov Sent: Tuesday, October 23, 2018 9:31 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Is the entire SDP body doubled, or just the v=0 line? -- Sent from mobile. Apologies for brevity and errors. -Original Message- From: "Wilkins, Steve" To: "Kamailio (SER) - Users Mailing List" Sent: Tue, 23 Oct 2018 9:07 PM Subject: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Hello all, I noticed double Session Description Protocol Version (v) 0 data in the SDP section when using rtpengine with Kamailio. Has any else noticed this? Is there a way for Kamailio to remove one of them? Thank you, -Steve ___ 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 ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine
Also, is there any possibility that you are calling fix_nated_sdp() and rtpengine_offer/manage() successively? -- Sent from mobile. Apologies for brevity and errors. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine
Then your description of the problem, and the subject line of your post, is not accurate. :-) This should not be happening. What does the rtpengine log show for the given Call-ID? -- Sent from mobile. Apologies for brevity and errors. -Original Message- From: "Wilkins, Steve" To: "Kamailio (SER) - Users Mailing List" Sent: Tue, 23 Oct 2018 9:55 PM Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Entire section. -Original Message- From: sr-users On Behalf Of Alex Balashov Sent: Tuesday, October 23, 2018 9:31 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Is the entire SDP body doubled, or just the v=0 line? -- Sent from mobile. Apologies for brevity and errors. -Original Message- From: "Wilkins, Steve" To: "Kamailio (SER) - Users Mailing List" Sent: Tue, 23 Oct 2018 9:07 PM Subject: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Hello all, I noticed double Session Description Protocol Version (v) 0 data in the SDP section when using rtpengine with Kamailio. Has any else noticed this? Is there a way for Kamailio to remove one of them? Thank you, -Steve ___ 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
Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine
Entire section. -Original Message- From: sr-users On Behalf Of Alex Balashov Sent: Tuesday, October 23, 2018 9:31 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Is the entire SDP body doubled, or just the v=0 line? -- Sent from mobile. Apologies for brevity and errors. -Original Message- From: "Wilkins, Steve" To: "Kamailio (SER) - Users Mailing List" Sent: Tue, 23 Oct 2018 9:07 PM Subject: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Hello all, I noticed double Session Description Protocol Version (v) 0 data in the SDP section when using rtpengine with Kamailio. Has any else noticed this? Is there a way for Kamailio to remove one of them? Thank you, -Steve ___ 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] Double Session Description Protocol Version (v) 0 data when using rtpengine
Is the entire SDP body doubled, or just the v=0 line? -- Sent from mobile. Apologies for brevity and errors. -Original Message- From: "Wilkins, Steve" To: "Kamailio (SER) - Users Mailing List" Sent: Tue, 23 Oct 2018 9:07 PM Subject: [SR-Users] Double Session Description Protocol Version (v) 0 data when using rtpengine Hello all, I noticed double Session Description Protocol Version (v) 0 data in the SDP section when using rtpengine with Kamailio. Has any else noticed this? Is there a way for Kamailio to remove one of them? Thank you, -Steve ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] kamailio+asterisk+webrtc
Hi, Thank you for the reply! I tried advertising udp port like this listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060. How to advertise RTP ports? Kamailio+RTPengine on a Centos s/m with a priv ip - 192.168.1.x Asterisk is on another CentOs s/m with a priv ip - 192.168.1.y pfsense on pub ip - 182.75.xx.yy PORT FORWARDING on pfsense- sip and rtp ports to kamailio+rtpengine server 192.168.1.x. How to make RTPengine listen on public interface-- 182.75.181.70? sip.conf [general] context=external realm=192.168.1.y bindaddr=0.0.0.0:5080 tcpenable=no allowoverlap=no transport=udp,wss,ws srvlookup=yes qualify=yes directmedia=no canreinvite=no ;-NAT SUPPORT- externip=182.75.xx.yy localnet=192.168.1.0/255.255.255.0 nat=yes ;nat=no //tried but no RTP ;nat=force_rport,comedia //tried but no RTP ;---RTP SUPPORT rtpkeepalive=30 disallow=all allow=gsm allow=ulaw allow=opus allow=alaw allow=g723 == and i am using asterisk realtime support for mysql to store peer details. With Regards, Arish Haque ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] kamailio + asterisk + webrtc
Hi, Thank you for the reply! I tried advertising udp port like this listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060. How to advertise RTP ports? Kamailio+RTPengine on a Centos s/m with a priv ip - 192.168.1.x Asterisk is on another CentOs s/m with a priv ip - 192.168.1.y pfsense on pub ip - 182.75.xx.yy PORT FORWARDING on pfsense- sip and rtp ports to kamailio+rtpengine server 192.168.1.x. sip.conf [general] context=external realm=192.168.1.y bindaddr=0.0.0.0:5080 tcpenable=no allowoverlap=no transport=udp,wss,ws srvlookup=yes qualify=yes directmedia=no canreinvite=no ;-NAT SUPPORT- externip=182.75.xx.yy localnet=192.168.1.0/255.255.255.0 nat=yes ;nat=no //tried but no RTP ;nat=force_rport,comedia //tried but no RTP ;---RTP SUPPORT rtpkeepalive=30 disallow=all allow=gsm allow=ulaw allow=opus allow=alaw allow=g723 == How to make RTPengine listen to public interface-- 182.75.181.70? With Regards, Arish Haque ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio as SBC
+1 Regards, David Villasmil email: david.villasmil.w...@gmail.com phone: +34669448337 ᐧ On Tue, Oct 23, 2018 at 1:31 PM Alex Balashov wrote: > Ellad, > > The reason for the lukewarm replies is not a failure on the part of the > public to understand the detailed content of your request; you don't > need to "simplify" it for them by individuating the paragraphs. > > The central obstacle is that you don't appear to understand that > Kamailio is a SIP proxy at the core. There is a well-defined mechanism > by which they relay various kinds of requests to user agents (UAs), and > this does not consist of capriciously "rewriting IP/UDP headers". > > In this sense, the valuable conceptual comprehension from so-called > "general words" precedes "eager and spirited implementation", and is the > reason why you have been encouraged to consider "general words". > > Having said that: > > 1. Kamailio can certainly relay REGISTERs to an upstream registrar; > > 2. This presents the problem of letting the registrar know that the > registrant has to be reached back through Kamailio as an adjacency, and > the solution to this is provided by the Path extension: > > https://tools.ietf.org/html/rfc3327 > > This Path header is added to the REGISTER and serves a similar purpose > to the one served by Record-Route in dialog-forming requests; it shunts > all subsequent inbound requests to the registrant through Kamailio, > which removes the Path header and passes it on. > > 3. As a proxy, Kamailio will dutifully forward authentication > challenges back to the caller, as it will do with any final > transaction-disposing reply. > > 4. Proxies do not hide topology in the manner you propose, whether in > the context of forwarding registrations or for any other purpose. The > message headers will consist mostly of information populated by the user > agent that constructed the message, with a few additional bits of > information added by Kamailio to reflects its role in the process. This > is mainly in the form of an additional Via hop, a Record-Route, etc. > > Kamailio has a number of modules which can accomplish this in a somewhat > "unorthodox" manner: > > https://kamailio.org/docs/modules/5.1.x/modules/topoh.html > https://kamailio.org/docs/modules/5.1.x/modules/topos.html > > However, these are used mainly for security-motivated topology > concealment relative to third parties. The problems invited by these > approaches are certainly not worthwhile for use inside one's own > network. > > 5. A REGISTER flow is not a dialog. The term "dialog" has a very > specific meaning articulated in 3261 § 12. > > In core SIP, and notwithstanding subscribe/notify or any other > extensions, only INVITEs are dialog-forming requests. > > 6. There is no need for Kamailio to maintain - to "remember" or > "memorise" - any state for this flow. It can take part in an entirely > stateless way. > > 7. The 'htable' module, as suggested by others, is the best way to > implement any sort of temporary IP banning. Otherwise, log the offending > IP via xlog() and have fail2ban deal with it. > > -- Alex > > On Tue, Oct 23, 2018 at 12:30:03PM +0300, Ellad Yatsko wrote: > > > Ok. Let's divide overall task onto several little steps. > > > > I. How to implement the following: > >- when Kamailio receives REGISTER from user in the Internet > >- Kamailio rewrites IP/UDP headers - it acts with Asterisk on behalf > > of User, Asterisk should know just Kamailio IP (add "Via"?) > >- Kamailio remembers [somehow] this dialog (how?) and > >- retransmits REGISTER to Asterisk > >- on receiving Unauthorized Kamailio retransmits it to User - this is > > an intermediate step, no action needed > >- User repeats steps on Registration with the Nonce > >- on receiving OK [from Asterisk] for the memorized dialog Kamailio > > retransmits OK to User and composes User Location > >- on receiving NOT FOUND, FORBIDDEN, etc Kamailio retransmits SIP > > answer to User and after several unsuccessful attempts blocks User IP > >- Fail2Ban completes the rest - inserts new rule > > Every time Kamailio retransmit SIP packet to the User from Asterisk it > > HIDES topology (IP/UDP headers and all SIP-related Info from SIP > > Packets). User should know just about Kamailio as about its counterpart. > > > > How to track SIP REGISTER related messages inside Kamailio? > > > > TO: Yu Boot - is it "standalone" implementation? How do you think? :-) > > > > Kind regards, > > Ellad > > > > > > 22.10.2018 20:16, Yu Boot пишет: > > > I can help you with cfg, if you 're ready to implement standalone > > > softswitch on your Kamailio :) > > > > > > > > > 22.10.2018 17:21, Ellad Yatsko пишет: > > >> May you help?.. :-) > > >> > > >> Kind regards, > > >> Ellad > > >> > > >> 22.10.2018 17:12, Alex Balashov пишет: > > >>> I did not say that my article represents a complete answer to every > > >>> part > > >>> of every one of your questions, at every level of abstraction and > >
Re: [SR-Users] Kamailio as SBC
Ellad, The reason for the lukewarm replies is not a failure on the part of the public to understand the detailed content of your request; you don't need to "simplify" it for them by individuating the paragraphs. The central obstacle is that you don't appear to understand that Kamailio is a SIP proxy at the core. There is a well-defined mechanism by which they relay various kinds of requests to user agents (UAs), and this does not consist of capriciously "rewriting IP/UDP headers". In this sense, the valuable conceptual comprehension from so-called "general words" precedes "eager and spirited implementation", and is the reason why you have been encouraged to consider "general words". Having said that: 1. Kamailio can certainly relay REGISTERs to an upstream registrar; 2. This presents the problem of letting the registrar know that the registrant has to be reached back through Kamailio as an adjacency, and the solution to this is provided by the Path extension: https://tools.ietf.org/html/rfc3327 This Path header is added to the REGISTER and serves a similar purpose to the one served by Record-Route in dialog-forming requests; it shunts all subsequent inbound requests to the registrant through Kamailio, which removes the Path header and passes it on. 3. As a proxy, Kamailio will dutifully forward authentication challenges back to the caller, as it will do with any final transaction-disposing reply. 4. Proxies do not hide topology in the manner you propose, whether in the context of forwarding registrations or for any other purpose. The message headers will consist mostly of information populated by the user agent that constructed the message, with a few additional bits of information added by Kamailio to reflects its role in the process. This is mainly in the form of an additional Via hop, a Record-Route, etc. Kamailio has a number of modules which can accomplish this in a somewhat "unorthodox" manner: https://kamailio.org/docs/modules/5.1.x/modules/topoh.html https://kamailio.org/docs/modules/5.1.x/modules/topos.html However, these are used mainly for security-motivated topology concealment relative to third parties. The problems invited by these approaches are certainly not worthwhile for use inside one's own network. 5. A REGISTER flow is not a dialog. The term "dialog" has a very specific meaning articulated in 3261 § 12. In core SIP, and notwithstanding subscribe/notify or any other extensions, only INVITEs are dialog-forming requests. 6. There is no need for Kamailio to maintain - to "remember" or "memorise" - any state for this flow. It can take part in an entirely stateless way. 7. The 'htable' module, as suggested by others, is the best way to implement any sort of temporary IP banning. Otherwise, log the offending IP via xlog() and have fail2ban deal with it. -- Alex On Tue, Oct 23, 2018 at 12:30:03PM +0300, Ellad Yatsko wrote: > Ok. Let's divide overall task onto several little steps. > > I. How to implement the following: > - when Kamailio receives REGISTER from user in the Internet > - Kamailio rewrites IP/UDP headers - it acts with Asterisk on behalf > of User, Asterisk should know just Kamailio IP (add "Via"?) > - Kamailio remembers [somehow] this dialog (how?) and > - retransmits REGISTER to Asterisk > - on receiving Unauthorized Kamailio retransmits it to User - this is > an intermediate step, no action needed > - User repeats steps on Registration with the Nonce > - on receiving OK [from Asterisk] for the memorized dialog Kamailio > retransmits OK to User and composes User Location > - on receiving NOT FOUND, FORBIDDEN, etc Kamailio retransmits SIP > answer to User and after several unsuccessful attempts blocks User IP > - Fail2Ban completes the rest - inserts new rule > Every time Kamailio retransmit SIP packet to the User from Asterisk it > HIDES topology (IP/UDP headers and all SIP-related Info from SIP > Packets). User should know just about Kamailio as about its counterpart. > > How to track SIP REGISTER related messages inside Kamailio? > > TO: Yu Boot - is it "standalone" implementation? How do you think? :-) > > Kind regards, > Ellad > > > 22.10.2018 20:16, Yu Boot пишет: > > I can help you with cfg, if you 're ready to implement standalone > > softswitch on your Kamailio :) > > > > > > 22.10.2018 17:21, Ellad Yatsko пишет: > >> May you help?.. :-) > >> > >> Kind regards, > >> Ellad > >> > >> 22.10.2018 17:12, Alex Balashov пишет: > >>> I did not say that my article represents a complete answer to every > >>> part > >>> of every one of your questions, at every level of abstraction and > >>> specificity. Just that it might be helpful. :-) > >>> > >>> On Mon, Oct 22, 2018 at 04:40:03PM +0300, Ellad Yatsko wrote: > >>> > Dear Alex, > > your article is just "general words". :-) There is a couple of > questions: > > - can my "vision" be completed? > - how can it be implemented? > >
Re: [SR-Users] kamailio + asterisk + webrtc
You don't, when forwarding a call out you need to configure rtpengine properly with rtpengine_offer([flags]), etc. You should read http://www.kamailio.org/docs/modules/5.0.x/modules/rtpeng On Tue, Oct 23, 2018, 11:28 arish haque wrote: > Hi Fred, > I have advertised the udp port in kamailio.cfg like below - > listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060 > But how to advertise rtp Ports?? > > I have attached sip.conf > > *Asterisk 1\* > > * \ -- **Kamailio+RTPPROXY ** FW (pfsense > **182.75.xx.yy public-IP)**--- INTERNET**\ **(private > ip - 192.168.1.x)* > > *Asterisk n--\ * > > > > *Th**anks & Regards,* > > *Arish Haque* > > > ___ > 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 + asterisk + webrtc
Hi Arish, You can start rtpengine with --interface parameter like below for running behind NAT. rtpengine --interface=*192.168.1.x*\!*182.75.xx.yy* --listen-ng= 127.0.0.1:2 -m 1 -M 2 arish haque , 23 Eki 2018 Sal, 13:28 tarihinde şunu yazdı: > Hi Fred, > I have advertised the udp port in kamailio.cfg like below - > listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060 > But how to advertise rtp Ports?? > > I have attached sip.conf > > *Asterisk 1\* > > * \ -- **Kamailio+RTPPROXY ** FW (pfsense > **182.75.xx.yy public-IP)**--- INTERNET**\ **(private > ip - 192.168.1.x)* > > *Asterisk n--\ * > > > > *Th**anks & Regards,* > > *Arish Haque* > > > ___ > 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 + asterisk + webrtc
Hi Fred, I have advertised the udp port in kamailio.cfg like below - listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060 But how to advertise rtp Ports?? I have attached sip.conf *Asterisk 1\* * \ -- **Kamailio+RTPPROXY ** FW (pfsense **182.75.xx.yy public-IP)**--- INTERNET**\ **(private ip - 192.168.1.x)* *Asterisk n--\ * *Th**anks & Regards,* *Arish Haque* sip.conf Description: Binary data ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio as SBC
Ok. Let's divide overall task onto several little steps. I. How to implement the following: - when Kamailio receives REGISTER from user in the Internet - Kamailio rewrites IP/UDP headers - it acts with Asterisk on behalf of User, Asterisk should know just Kamailio IP (add "Via"?) - Kamailio remembers [somehow] this dialog (how?) and - retransmits REGISTER to Asterisk - on receiving Unauthorized Kamailio retransmits it to User - this is an intermediate step, no action needed - User repeats steps on Registration with the Nonce - on receiving OK [from Asterisk] for the memorized dialog Kamailio retransmits OK to User and composes User Location - on receiving NOT FOUND, FORBIDDEN, etc Kamailio retransmits SIP answer to User and after several unsuccessful attempts blocks User IP - Fail2Ban completes the rest - inserts new rule Every time Kamailio retransmit SIP packet to the User from Asterisk it HIDES topology (IP/UDP headers and all SIP-related Info from SIP Packets). User should know just about Kamailio as about its counterpart. How to track SIP REGISTER related messages inside Kamailio? TO: Yu Boot - is it "standalone" implementation? How do you think? :-) Kind regards, Ellad 22.10.2018 20:16, Yu Boot пишет: > I can help you with cfg, if you 're ready to implement standalone > softswitch on your Kamailio :) > > > 22.10.2018 17:21, Ellad Yatsko пишет: >> May you help?.. :-) >> >> Kind regards, >> Ellad >> >> 22.10.2018 17:12, Alex Balashov пишет: >>> I did not say that my article represents a complete answer to every >>> part >>> of every one of your questions, at every level of abstraction and >>> specificity. Just that it might be helpful. :-) >>> >>> On Mon, Oct 22, 2018 at 04:40:03PM +0300, Ellad Yatsko wrote: >>> Dear Alex, your article is just "general words". :-) There is a couple of questions: - can my "vision" be completed? - how can it be implemented? The major problem as I see is to modify algorithm so Kamailio will not check database but will lean on answers of its upstream to generate UL. It should not BALANCE, just forward SIP traffic, ANALYZE answers of Upstream SIP-Server, make decision about attacks and PROXY RTP. It should be more clear definition what I would like to achieve. I could be confused about exact terminology of "Session Border Controller". But I'd like to implement FRAUD/BruteForce protection of my Asterisk using Kamailio (in the middle) because I heard it highly effective in the point of view of heavy loads. Asterisk might not bear a "tons" of SIP requests (dialogs). Kind regards, Ellad 22.10.2018 12:07, Alex Balashov пишет: > I hate to plug my own articles, but in this case it might help: > > http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/ > > -- > Sent from mobile. Apologies for brevity and errors. > > -Original Message- > From: Ellad Yatsko > To: sr-users@lists.kamailio.org > Sent: Mon, 22 Oct 2018 3:28 AM > Subject: [SR-Users] Kamailio as SBC > > Hello! > > I'd like to implement the following diagram: > > Users -> Internet -> Kamailio -> Asterisk > > 1. Kamailio has no own users, it just re-writes headers and re-send > REGISTER messages to Asterisk where usres are located. > > 2. Depending on Astersisk's answers Kamailio either form UL (using > original IP from the first, original REGISTER from Users) or > translates > Asterisk's answer back to Users. If it is error (e.g. > forbidden/notfound) Kamailio blocks User's IP (for instance using > pike > module) and Fail2Ban adds affected IP into IPSet's List to block > it by > IPTables Permanently. > > 3. INVITEs are translated to Asterisk as to the only Upstream > SIP-Server. And again Errors from Asterisk are processed in the > same way > as Bad REGISTERs. Pike in conjunction with IPSet/IPTables block > affected > IPs. > > 4. Astersisk sees all registrations from Internet user as they are > directly behind Kamailio. Kamailio rewirtes headers twice: from > Users to > Asterisk and from Asterisk to Users - this allows to hide topology > from > users (they deal ONLY with Kamailio) and block non-static IPs on the > Asterisk's side. > > Is this possible? > > Kind regards, > Ellad Yatsko > > > > > > ___ > 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 >
Re: [SR-Users] htable 1 Millon registers
Am Montag, 22. Oktober 2018, 22:35:17 CEST schrieb Brooks Bridges: > IMHO, anything more than about 100k keys really should be stored in > something external to Kamailio (such as redis) to prevent exactly this > issue. If you’re running redis on the same server as Kamailio and using > localhost to access it, then the latency increase for accessing the data > via redis as opposed to htable is almost nonexistent. Hi Brooks, this is of course also a valid option. Some years ago I was asked to optimized the carrierroute module to properly take care of a 1 million routing tree for several users. So there are some use cases to do something like this, but probably (nowadays) not that many anymore, I agree. 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
