[SR-Users] Configuring Kamailio as an upstream proxy for FreeSwitch and which RTP proxy to choose

[Sean Kemball]

Hi

New to Kamailio and FreeSwitch, loosely familiar with SIP mechanics, and not a complete network idiot... but please be gentle. :)

We're trying to get Kamailio set up in front of a FreeSwitch-based SIP application server, to do some simple policy controls and, using one of the RTP proxy modules, to help handle the media side of things. Our SIP trunks come from our provider on a VLAN addressed as 10.x, and they provide an upstream proxy/media server (10.y address). The link also carries Internet traffic so we're running it through a Cisco ASA which breaks out the VLANs and static NATs the SIP stuff to our DMZ (10.z address). This is where we want to put the Kamailio box, where it should receive the calls and route them back through the ASA to the internal address (10.w range - all 10.w/x/y/z are separate, non-overlapping networks).

Outbound calls from the application server (there are very few) should pass back up to Kamailio which will validate the numbers against an approved list (the app should only dial a subset of numbers) and pass them to the upstream proxy if necessary. We need to ensure that inbound calls from outside trombone through our application server so that the caller doesn't get billed for any calls, but this should be the default I think as that side of things is handled by FS (the app stands up a new call and bridges it to the incoming). This topology should allow us to use Kamailio to hide details of the FS app from the outside world, and make life easier for the app developer who should just send/receive to the Kamailio box with no further thought or complexity.

If we put the FreeSwitch box in the DMZ where we want to put Kamailio, and then turn on SIP packet inspection in the ASA, calls flow but quality is poor for some callers. If we turn off SIP packet inspection, we get no audio - I can't find any clear Cisco documentation for this but I think the SIP inspection stuff in the ASA seems to handle RTP NAT fixups and the like too. But with no docs it may as well be magic, and I want to remove it if possible. With Kamailio in the DMZ and FS internal, we loosely followed http://kb.asipto.com/freeswitch:kamailio-3.3.x-freeswitch-1.2.x-sbc and hacked out the voicemail and Lua stuff, but couldn't get calls to flow, whether or not we used the SIP inspection on the ASA. We were confused why this example isn't define as WITH_NAT and doesn't use a local RTP proxy. Surely that would be needed?

Questions:

1.    Should the proposed topology, with Kamailio + an RTP proxy behind a firewall, relaying to FS on an inside interface, work? (Can't see why not)

2.    Does it need a local RTP proxy on the Kamailio box, particularly if we turn off the ASA SIP inspect stuff?

3.    Can you recommend which RTP proxy to use? There seem to be at least 3 that work with Kamailio. The box is CentOS 6.5, and it would be nice to use known-to-work packages rather than compile from source. (But eh, if I haveta).

4.    Can anyone point me to some docs to explain what ports need to be open between the Kamailio box and my upstream proxy/media server? I can be more liberal between inside and DMZ I guess.

5.    Is static NAT in this environment going to bite me, or should it be OK?

6.    Is there any better documentation that we should be using to make this easier, or should I just man up and try harder?

TIA
Sean
Volunteer for our Red Puppy street appeal to help puppies
like Gordy become guide dogs.
#############################################################################
This email, including any attachments, is intended solely for the addressee(s)
It is confidential and may be legally privileged.
If you are not the intended recipient, you must not copy, disclose, distribute
or otherwise use it or the information in it. Please notify the sender at once
and delete it from your system immediately.
Any views or opinions expressed are solely those of the author and do not
necessarily represent those of  Blind Foundation.
The Blind Foundation does not accept responsibility for any viruses or other
malicious code that may be transmitted with this email.
#############################################################################


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140224/1bcdf80b/attachment.html>