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

Kevin Olbrich ko at sv01.de
Wed Oct 3 21:44:22 CEST 2018


Hi!

Sorry if you received an empty email, accidently clicked the send button
when resizing the windows.

I am finally able to test a setup with both kamailio and asterisk on public
network.
Currently I struggle with RTP flow - what do I need to change to have rtp
flow directly to asterisk instead of rtpproxy?
Rtpproxy is working fine but when I disable NAT, there is no audio (did not
yet check SDP).

Kind regards
Kevin

Am Do., 16. Aug. 2018 um 12:47 Uhr schrieb Dmitri Savolainen <
savolainen at erinaco.ru>:

> is RTP folowing to FS directly in this case?
>
> Yes, it woks fine in 99% and no any additional STUN/ICE are required
>
> On 16 August 2018 at 13:32, Kevin Olbrich <ko at sv01.de> wrote:
>
>> Hi Dmitri,
>>
>> is RTP folowing to FS directly in this case? This would allow us to use
>> STUN as well as ICE, etc. from Asterisk (which is currently the case
>> without Kamailio SBC in prod).
>>
>> Kevin
>>
>>
>>
>> Am Do., 16. Aug. 2018 um 12:29 Uhr schrieb Dmitri Savolainen <
>> savolainen at erinaco.ru>:
>>
>>> Hi Kevin.
>>> I use Kamailio  as FreeSwitch set balancer almost without rtpengine (rtpengine
>>> is used only in some specific cases). All in public IPs.
>>> I just tune FS SIP profile  to let it get requests only from Kamailio
>>> IP:PORT and add same firewall rules also.
>>> All RPC commands work via local interface only.
>>> PUBLIC NET SIP-Phone ==> Kamailio(PUBLIC)  ==> FS(PUBLIC) ==> Kamailio
>>> (PUBLIC)   ==> Carrier
>>>
>>>
>>> On 16 August 2018 at 12:57, Kevin Olbrich <ko at sv01.de> wrote:
>>>
>>>> Hi!
>>>>
>>>> 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.
>>>>
>>>> Thank you very much.
>>>>
>>>> Kind regards
>>>> Kevin
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Savolainen Dmitri
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Savolainen Dmitri
> _______________________________________________
> 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/20181003/700173ef/attachment.html>


More information about the sr-users mailing list