[SR-Users] What is the typical network setup for kamailio?

Mon Aug 20 20:01:08 CEST 2018

>
>  If Kamailio is going to act as your registrar, then you will need to
> find some way to expose the registered contacts to Asterisk -
>
Matthew, could you explain why Asterisk have to know about reg contacts in
you approch?  Asterisk just may sends all to Kamailio (second call leg)
and let Kamailio route this call to appropriate contact.

On 20 August 2018 at 18:23, Matthew Jordan <mjordan at digium.com> wrote:

> For what it's worth, we've set up a network/system where Asterisk resides
> completely on a private network with Kamailio acting as an edge proxy.
> RTPEngine is necessary as well to help the media through to the private
> network, but that's probably not surprising. It is completely doable,
> although the suggestions below about simply restricting Asterisk on a
> public network to the locations of the Kamailio proxies also works quite
> well.
>
> Matching inbound requests in Asterisk to only the pool of Kamailio proxies
> can be done in a variety of fashions - IP address matching being the
> simplest. You will obviously need to think carefully about how Asterisk
> handles its outbound calling. If Kamailio is going to act as your
> registrar, then you will need to find some way to expose the registered
> contacts to Asterisk - we chose this route, and wrote a small REST sidecar
> to Kamailio for that purpose. If Asterisk is going to act as your
> registrar, you will need to fork the REGISTER requests to all of the
> Asterisk instances. Additionally, for INVITE requests being initiated by
> Asterisk, you will want to force those to flow through your edge proxies.
> This can be done using Asterisk's outbound_proxy setting on the AOR object
> in pjsip.conf.
>
> On Mon, Aug 20, 2018 at 6:23 AM Kevin Olbrich <ko at sv01.de> wrote:
>
>> Hi Henning,
>>
>> I browsed the files but was unable to find one using Kamailio as SBC
>> without exposing the Asterisk core.
>> Most examples indeed expose the node and let media flow directly (
>> https://www.kamailio.org/events/2017-KamailioWorld/
>> Day1/08-David.Casem-Building-A-Global-VoIP-Network.pdf - interesting
>> solution with e/iBGP which we would also be able to deploy).
>>
>> There was just a single presentation that I was able to locate that had
>> the proxy only on the edge:
>> https://www.kamailio.org/events/2017-KamailioWorld/
>> Day2/15-Sebasitan.Damm-Anti-Fraud-With-HTables.pdf
>> At least it looks like they are located behind the SBC.
>>
>> After the research my impression is, that co-locating the B2BUA with the
>> Edge-Proxy and firewall-ing it, seems best practice.
>> We will try to add some security by bridge-firewalling and BGP.
>>
>> If anyone has a hint for a presentation with high-security edge-proxy, I
>> would appreciate it. Thank you.
>>
>> Kind regards,
>> Kevin
>>
>>
>> Am Do., 16. Aug. 2018 um 19:12 Uhr schrieb Henning Westerholt <
>> hw at kamailio.org>:
>>
>>> Am Donnerstag, 16. August 2018, 11:57:03 CEST schrieb Kevin Olbrich:
>>> > I am working successfully with Kamailio in my lab setup where Kamailio
>>> is
>>> > the SBC for Asterisk.
>>> > The network layout is looking like this:
>>> >
>>> > SIP-Phone <== PUBLIC NET ==> Kamailio (SBC) <== PRIVATE NET ==>
>>> Asterisk
>>> > <== PUBLIC NET ==> Carrier
>>> >
>>> > Each public network is reachable from the internet and has a local
>>> firewall
>>> > with IP whitelists.
>>> > The internal SIP transactions are UDP-only but for external phones I
>>> would
>>> > like to also listen for TCP/TLS.
>>> >
>>> > For this layout to work with rtpproxy (before we move on to
>>> RTPengine), we
>>> > have to enable mhomed in Kamailio.
>>> > We also have some routing issues with packets leaving with the wrong
>>> IP via
>>> > rtpproxy (when call between carrier and external phone needs to be
>>> bridged).
>>> >
>>> > Most examples show that Asterisk is deployed on the same network as the
>>> > external interface of Kamailio (-> Asterisk exposed to the public
>>> network).
>>> > In our tests, this works much better but I have great security concerns
>>> > because this Asterisk instance itself does not need to be reachable
>>> from
>>> > external.
>>> >
>>> > How do other users deploy Kamailio in front of Asterisk or similar as
>>> SBC
>>> > to secure internals?
>>> > There is lot of docs for Kamailio's config but IMHO less for the setup
>>> as
>>> > DMZ (SBC) proxy.
>>>
>>> Hello Kevin,
>>>
>>> this is indeed a common setup to protect asterisk and to have also much
>>> greater flexibility with regards to balancing and/or SIP message
>>> adaptions.
>>>
>>> To get some ideas, have a look to the last years conferences available
>>> here:
>>>
>>> https://www.kamailio.org/events/
>>>
>>> There should be some talks about using Kamailio to in front of asterisk,
>>> the
>>> talk name is usually in the file name.
>>>
>>> I think even on this year cluecon Fred Posner did a talk about Kamailio
>>> as
>>> Edge Proxy, and also on astricon there were some talks  about this
>>> scenario if
>>> I remember correctly.
>>>
>>> You should also find in the Kamailio World or FOSDEM talks a lot of
>>> information about this scenario.  You find all the talks available from
>>> Kamailio World in our youtube channel:
>>>
>>> https://www.youtube.com/kamailioworld
>>>
>>> Best regards,
>>>
>>> Henning
>>>
>>> --
>>> Henning Westerholt
>>> https://skalatan.de/blog/
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Matthew Jordan
> Digium, Inc. | CTO
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>

-- 
Savolainen Dmitri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180820/128a766c/attachment.html>