Kamailio + Asterisk in AWS Architecture validation

Hello folks,

I’m fairly new to the topic and I’m trying to wrap my head around all of the concepts that the beautiful and powerful world of SIP offer.

Background
Until now I just had very simple Asterisk setups with two asterisk machines, on public IPs and I was authorizing clients by IP directly in PJSIP

Where I’d want to go
Due to scaling/manageability concerns, I wanted to transition to something in which I didn’t have to spawn a new pair of servers every time a new client is coming up, which led me to Kamailio and Asterisk setup.

I sketched my (partial) understanding before actually going there, trying to catch some early pitfalls.

I’ve a few open questions that I hope you might be able to give a direction:

1) Keep Kamailio simple?

If possible (and suggested), I would like to keep Kamailio as easy as possible, no authorizations, etc… but just provide a disaptcher.lst and forget. Is this possible, is there a good configuration for this?
I saw a ton of “sample” configurations for this but I imagine that the second I start using those, being just sample they give me the impression that they are not robust at all. Do you have any go-to template/github that I should consider?
I was looking https://github.com/dOpensource/dsiprouter but it seems already fairly complex and that tries managing the authentication

The reason is: I like managing all of the PJSIP authorization/configurations through Asterisk due to the PJSIP familiarity I have and flexibility it offers (IP/auth/pointing out servers/inbound vs outbound etc…) since my dialplan are fairly complex.

2) Does Kamailio need RTP_PROXY? Will that bring scalability concerns?

3) If I want to do the authorization in Asterisk, can I avoid putting the Kamailio IPs in PJSIP?
I’m scared that if I put Kamailio IPs, all of the messages going through Kamailio will be authenticated as legit

4) Can my customers just put the Kamailio IPs in their PJSIP? Do they also need the NAT one?
I have inbound and outbound calls. Ideally if I could have all of the communication going through Kamailio, those Ip would be the only ones I should share

Feel free to share any code or github!

I hope this can be an opportunity to share and consolidate some of the learning in this kind of set up since I imagine a few people are going through this learning path :slight_smile:

Resources:
PJSIP NAT (but doesn’t consider Kamailio):
https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT

Well the first thing you would have to do is look at setting up Kamailio behind NAT because that is what happens when you are at AWS. So first you’ll need to get at least 3-5 Elastic IPs (gotta pay for them) because if the server goes offline or shutdown for any reason the public IP can change when brought back up so you need statics for each box.

Then Kamailio needs to be setup to listen on its local IPs while being told what public IPs to advertise. Incoming traffic from the Internet will need to be translated from the public IPs being used to the private IPs of Kamailio and update the SIP message with those IPs. This is going to require RTPProxy or RTPEngine to proxy the media through Kamailio.

Asterisk and Kamailio will be what talk to each other not Asterisk and the end users. Everything from the end users and everything from Asterisk will need to pass through the Kamailio servers.

They only auth as legit if you auth them as legit. You are in charge of that process on Kamailio. So how every you decide you’re going to auth them and validate them is up to you.

Yes, as I stated everything would go through Kamailio, that is why you have them.


I think you may need to step back and look at things in the larger picture. How many providers out there do you know that are behind NAT? Both sides being behind NAT is not how, as a provider, you want to handle these things.

I would never recommend any looking to provide SIP based services to the masses use AWS for it.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.