[SR-Users] Kamailio as SBC

Joel Serrano joel at textplus.com
Thu Oct 25 23:25:25 CEST 2018 

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 <eyatsko at 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 <eyatsko at ngs.ru>
> >>>>>>>> To: sr-users at 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 at lists.kamailio.org
> >>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Kamailio (SER) - Users Mailing List
> >>>>>>>> sr-users at lists.kamailio.org
> >>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>>>>> _______________________________________________
> >>>>>>> Kamailio (SER) - Users Mailing List
> >>>>>>> sr-users at lists.kamailio.org
> >>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>>> _______________________________________________
> >>>>> Kamailio (SER) - Users Mailing List
> >>>>> sr-users at lists.kamailio.org
> >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>> _______________________________________________
> >>>> Kamailio (SER) - Users Mailing List
> >>>> sr-users at lists.kamailio.org
> >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>
> >>> _______________________________________________
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users at lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181025/7a3cf66a/attachment.html>

More information about the sr-users mailing list