<div dir="ltr">Asterisk is compatible with "path" in pjsip.<div><br></div><div>If you need it for chan_sip in was implemented in asterisk v12 AFAIR.<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 24, 2018 at 11:11 PM Ellad Yatsko <<a href="mailto:eyatsko@ngs.ru">eyatsko@ngs.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Alex!<br>
<br>
1. First of all I'd like to apologize about my yesterday unwise notice. :-)<br>
<br>
2. Regarding your paragraph 2 -> "Via ..." & "Supported: path"?<br>
   And how to make Kamailio to "proxy" REIGISTER to upstream registrar<br>
   (Asterisk - do you know it supports "path"? For a what degree does<br>
   Asterisk follow "the letter of RFCs"?)?<br>
<br>
3. Regarding "topoh" I will read, ok. As I remember MY config has something<br>
     modparam("topoh", "mask_ip", "1.1.1.2")<br>
     modparam("topoh", "mask_callid", 0)<br>
   I think I will cope this by myself.. :-)<br>
<br>
4. Yes, I know about "htable", I can complete it by myself. I familiar<br>
   with this.<br>
<br>
Thank you for your asnwers Alex.<br>
<br>
Kind regards,<br>
Ellad<br>
<br>
> 23.10.2018 15:27, Alex Balashov пишет:<br>
>> Ellad,<br>
>><br>
>> The reason for the lukewarm replies is not a failure on the part of the<br>
>> public to understand the detailed content of your request; you don't<br>
>> need to "simplify" it for them by individuating the paragraphs. <br>
>><br>
>> The central obstacle is that you don't appear to understand that<br>
>> Kamailio is a SIP proxy at the core. There is a well-defined mechanism<br>
>> by which they relay various kinds of requests to user agents (UAs), and<br>
>> this does not consist of capriciously "rewriting IP/UDP headers".<br>
>><br>
>> In this sense, the valuable conceptual comprehension from so-called<br>
>> "general words" precedes "eager and spirited implementation", and is the<br>
>> reason why you have been encouraged to consider "general words".<br>
>><br>
>> Having said that:<br>
>><br>
>> 1. Kamailio can certainly relay REGISTERs to an upstream registrar;<br>
>><br>
>> 2. This presents the problem of letting the registrar know that the<br>
>> registrant has to be reached back through Kamailio as an adjacency, and<br>
>> the solution to this is provided by the Path extension:<br>
>><br>
>> <a href="https://tools.ietf.org/html/rfc3327" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc3327</a><br>
>><br>
>> This Path header is added to the REGISTER and serves a similar purpose<br>
>> to the one served by Record-Route in dialog-forming requests; it shunts<br>
>> all subsequent inbound requests to the registrant through Kamailio,<br>
>> which removes the Path header and passes it on.<br>
>><br>
>> 3. As a proxy, Kamailio will dutifully forward authentication<br>
>> challenges back to the caller, as it will do with any final<br>
>> transaction-disposing reply.<br>
>><br>
>> 4. Proxies do not hide topology in the manner you propose, whether in<br>
>> the context of forwarding registrations or for any other purpose. The<br>
>> message headers will consist mostly of information populated by the user<br>
>> agent that constructed the message, with a few additional bits of<br>
>> information added by Kamailio to reflects its role in the process. This<br>
>> is mainly in the form of an additional Via hop, a Record-Route, etc.<br>
>><br>
>> Kamailio has a number of modules which can accomplish this in a somewhat<br>
>> "unorthodox" manner:<br>
>><br>
>> <a href="https://kamailio.org/docs/modules/5.1.x/modules/topoh.html" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.1.x/modules/topoh.html</a><br>
>> <a href="https://kamailio.org/docs/modules/5.1.x/modules/topos.html" rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.1.x/modules/topos.html</a><br>
>><br>
>> However, these are used mainly for security-motivated topology<br>
>> concealment relative to third parties. The problems invited by these<br>
>> approaches are certainly not worthwhile for use inside one's own<br>
>> network.<br>
>><br>
>> 5. A REGISTER flow is not a dialog. The term "dialog" has a very<br>
>> specific meaning articulated in 3261 § 12. <br>
>><br>
>> In core SIP, and notwithstanding subscribe/notify or any other<br>
>> extensions, only INVITEs are dialog-forming requests.<br>
>><br>
>> 6. There is no need for Kamailio to maintain - to "remember" or<br>
>> "memorise" - any state for this flow. It can take part in an entirely<br>
>> stateless way.<br>
>><br>
>> 7. The 'htable' module, as suggested by others, is the best way to<br>
>> implement any sort of temporary IP banning. Otherwise, log the offending<br>
>> IP via xlog() and have fail2ban deal with it.<br>
>><br>
>> -- Alex<br>
>><br>
>> On Tue, Oct 23, 2018 at 12:30:03PM +0300, Ellad Yatsko wrote:<br>
>><br>
>>> Ok. Let's divide overall task onto several little steps.<br>
>>><br>
>>> I. How to implement the following:<br>
>>>    - when Kamailio receives REGISTER from user in the Internet<br>
>>>    - Kamailio rewrites IP/UDP headers - it acts with Asterisk on behalf<br>
>>> of User, Asterisk should know just Kamailio IP (add "Via"?)<br>
>>>    - Kamailio remembers [somehow] this dialog (how?) and<br>
>>>    - retransmits REGISTER to Asterisk<br>
>>>    - on receiving Unauthorized Kamailio retransmits it to User - this is<br>
>>> an intermediate step, no action needed<br>
>>>    - User repeats steps on Registration with the Nonce<br>
>>>    - on receiving OK [from Asterisk] for the memorized dialog Kamailio<br>
>>> retransmits OK to User and composes User Location<br>
>>>    - on receiving NOT FOUND, FORBIDDEN, etc Kamailio retransmits SIP<br>
>>> answer to User and after several unsuccessful attempts blocks User IP<br>
>>>    - Fail2Ban completes the rest - inserts new rule<br>
>>> Every time Kamailio retransmit SIP packet to the User from Asterisk it<br>
>>> HIDES topology (IP/UDP headers and all SIP-related Info from SIP<br>
>>> Packets). User should know just about Kamailio as about its counterpart.<br>
>>><br>
>>> How to track SIP REGISTER related messages inside Kamailio?<br>
>>><br>
>>> TO: Yu Boot - is it "standalone" implementation? How do you think? :-)<br>
>>><br>
>>> Kind regards,<br>
>>> Ellad<br>
>>><br>
>>><br>
>>> 22.10.2018 20:16, Yu Boot пишет:<br>
>>>> I can help you with cfg, if you 're ready to implement standalone<br>
>>>> softswitch on your Kamailio :)<br>
>>>><br>
>>>><br>
>>>> 22.10.2018 17:21, Ellad Yatsko пишет:<br>
>>>>> May you help?.. :-)<br>
>>>>><br>
>>>>> Kind regards,<br>
>>>>> Ellad<br>
>>>>><br>
>>>>> 22.10.2018 17:12, Alex Balashov пишет:<br>
>>>>>> I did not say that my article represents a complete answer to every<br>
>>>>>> part<br>
>>>>>> of every one of your questions, at every level of abstraction and<br>
>>>>>> specificity. Just that it might be helpful. :-)<br>
>>>>>><br>
>>>>>> On Mon, Oct 22, 2018 at 04:40:03PM +0300, Ellad Yatsko wrote:<br>
>>>>>><br>
>>>>>>> Dear Alex,<br>
>>>>>>><br>
>>>>>>> your article is just "general words". :-) There is a couple of<br>
>>>>>>> questions:<br>
>>>>>>><br>
>>>>>>>    - can my "vision" be completed?<br>
>>>>>>>    - how can it be implemented?<br>
>>>>>>><br>
>>>>>>> The major problem as I see is to modify algorithm so Kamailio will<br>
>>>>>>> not check<br>
>>>>>>> database but will lean on answers of its upstream to generate<br>
>>>>>>> UL. It should not BALANCE, just forward SIP traffic, ANALYZE<br>
>>>>>>> answers of<br>
>>>>>>> Upstream<br>
>>>>>>> SIP-Server, make decision about attacks and PROXY RTP. It should be<br>
>>>>>>> more<br>
>>>>>>> clear<br>
>>>>>>> definition what I would like to achieve.<br>
>>>>>>><br>
>>>>>>> I could be confused about exact terminology of "Session Border<br>
>>>>>>> Controller".<br>
>>>>>>> But I'd like to implement FRAUD/BruteForce protection of my<br>
>>>>>>> Asterisk using<br>
>>>>>>> Kamailio (in the middle) because I heard it highly effective in the<br>
>>>>>>> point<br>
>>>>>>> of view of heavy loads. Asterisk might not bear a "tons" of SIP<br>
>>>>>>> requests<br>
>>>>>>> (dialogs).<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Kind regards,<br>
>>>>>>> Ellad<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> 22.10.2018 12:07, Alex Balashov пишет:<br>
>>>>>>>> I hate to plug my own articles, but in this case it might help:<br>
>>>>>>>><br>
>>>>>>>> <a href="http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/" rel="noreferrer" target="_blank">http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/</a><br>
>>>>>>>><br>
>>>>>>>> -- <br>
>>>>>>>> Sent from mobile. Apologies for brevity and errors.<br>
>>>>>>>><br>
>>>>>>>> -----Original Message-----<br>
>>>>>>>> From: Ellad Yatsko <<a href="mailto:eyatsko@ngs.ru" target="_blank">eyatsko@ngs.ru</a>><br>
>>>>>>>> To: <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
>>>>>>>> Sent: Mon, 22 Oct 2018 3:28 AM<br>
>>>>>>>> Subject: [SR-Users] Kamailio as SBC<br>
>>>>>>>><br>
>>>>>>>> Hello!<br>
>>>>>>>><br>
>>>>>>>> I'd like to implement the following diagram:<br>
>>>>>>>><br>
>>>>>>>>   Users  -> Internet -> Kamailio -> Asterisk<br>
>>>>>>>><br>
>>>>>>>> 1. Kamailio has no own users, it just re-writes headers and re-send<br>
>>>>>>>> REGISTER messages to Asterisk where usres are located.<br>
>>>>>>>><br>
>>>>>>>> 2. Depending on Astersisk's answers Kamailio either form UL (using<br>
>>>>>>>> original IP from the first, original REGISTER from Users) or<br>
>>>>>>>> translates<br>
>>>>>>>> Asterisk's answer back to Users. If it is error (e.g.<br>
>>>>>>>> forbidden/notfound) Kamailio blocks User's IP (for instance using<br>
>>>>>>>> pike<br>
>>>>>>>> module) and Fail2Ban adds affected IP into IPSet's List to block<br>
>>>>>>>> it by<br>
>>>>>>>> IPTables Permanently.<br>
>>>>>>>><br>
>>>>>>>> 3. INVITEs are translated to Asterisk as to the only Upstream<br>
>>>>>>>> SIP-Server. And again Errors from Asterisk are processed in the<br>
>>>>>>>> same way<br>
>>>>>>>> as Bad REGISTERs. Pike in conjunction with IPSet/IPTables block<br>
>>>>>>>> affected<br>
>>>>>>>> IPs.<br>
>>>>>>>><br>
>>>>>>>> 4. Astersisk sees all registrations from Internet user as they are<br>
>>>>>>>> directly behind Kamailio. Kamailio rewirtes headers twice: from<br>
>>>>>>>> Users to<br>
>>>>>>>> Asterisk and from Asterisk to Users - this allows to hide topology<br>
>>>>>>>> from<br>
>>>>>>>> users (they deal ONLY with Kamailio) and block non-static IPs on the<br>
>>>>>>>> Asterisk's side.<br>
>>>>>>>><br>
>>>>>>>> Is this possible?<br>
>>>>>>>><br>
>>>>>>>> Kind regards,<br>
>>>>>>>> Ellad Yatsko<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> Kamailio (SER) - Users Mailing List<br>
>>>>>>>> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
>>>>>>>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> Kamailio (SER) - Users Mailing List<br>
>>>>>>>> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
>>>>>>>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>>>>>>> _______________________________________________<br>
>>>>>>> Kamailio (SER) - Users Mailing List<br>
>>>>>>> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
>>>>>>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>>>>> _______________________________________________<br>
>>>>> Kamailio (SER) - Users Mailing List<br>
>>>>> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
>>>>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>>>> _______________________________________________<br>
>>>> Kamailio (SER) - Users Mailing List<br>
>>>> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
>>>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Kamailio (SER) - Users Mailing List<br>
>>> <a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
>>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
><br>
<br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>