Asterisk is compatible with "path" in pjsip. If you need it for chan_sip in was implemented in asterisk v12 AFAIR.
On Wed, Oct 24, 2018 at 11:11 PM Ellad Yatsko <eyat...@ngs.ru> wrote: > Hello Alex! > > 1. First of all I'd like to apologize about my yesterday unwise notice. :-) > > 2. Regarding your paragraph 2 -> "Via ..." & "Supported: path"? > And how to make Kamailio to "proxy" REIGISTER to upstream registrar > (Asterisk - do you know it supports "path"? For a what degree does > Asterisk follow "the letter of RFCs"?)? > > 3. Regarding "topoh" I will read, ok. As I remember MY config has something > modparam("topoh", "mask_ip", "1.1.1.2") > modparam("topoh", "mask_callid", 0) > I think I will cope this by myself.. :-) > > 4. Yes, I know about "htable", I can complete it by myself. I familiar > with this. > > Thank you for your asnwers Alex. > > Kind regards, > Ellad > > > 23.10.2018 15:27, Alex Balashov пишет: > >> 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? > >>>>>>> > >>>>>>> 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 <eyat...@ngs.ru> > >>>>>>>> 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 > >>>>>>>> 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 > >>> > >>> _______________________________________________ > >>> 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