It is feasable to what you want: kamailio behind NAT proxying traffic from/to public internet to/from private network. You will need to properly craft the INVITE and use proper record route headers. Use set_advertised_address when needed: http://kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#set_advertised_address Also, use record_route_preset (note that there are two parameters): http://kamailio.org/docs/modules/devel/modules_k/rr.html#id2547566
That should do it. You don't need any patches for rtpproxy. Just use force_rtpp_proxy (and force the IP address): http://kamailio.org/docs/modules/devel/modules/rtpproxy.html#id2546034 Note: Make sure that you understand how in-dialog requests are routed by a proxy in order to know how to properly handle the initial INVITE. Regards, Ovidiu Sas On Sat, Sep 3, 2011 at 2:53 PM, Sarat C. Vemuri <sarat.vem...@fthco.com> wrote: > We are trying to configure Kamailio (3.1.x) as a “boarder proxy” where it > acts as the front for various carrier gateways so that internal UACs and > UASs are unaware of the carrier gateways. > > > > Let me try to present a clear picture of our setup. > > 1. Kamailio has several NICs (physical or vlan). Each on a different > subnet. One subnet is internal/has routes for internal. Other subnets are > private connections to carriers or a route to public Internet. > > 2. All of these subnets are non-routable from Internet. In addition , > the carrier private connections are not routable internally. > > 3. Connection to public internet is via a FW/NAT (one-to-one NAT), > which maps to one of the interfaces. > > 4. All internal UAC/UAS connect on the internal subnet. > > 5. We are using RTPProxy (at least one instance per carrier) to relay > media between internal and carrier subnets > > > > We are able to make this setup up work great except for one scenario. One > of the carriers is only reachable via public Internet. Due to security > requirements, our Kamailio cannot have a public IP address and must use > FW/NAT. I guess this scenario is “Proxy behind NAT” and not really > encouraged. But I would like to see if there is a way to make this work. We > cannot use the “advertised_address” since it changes the IP for every > “route”. > > > > We were able to get this mostly working by doing the following > > 1. mhomed=1 > > 2. Small patch in the rtpproxy module so that force_rtp_proxy > actually uses the IP address passed (public IP). > > 3. Using request_route_preset(“publicIP”) > > > > The above “mostly” works. By that I mean, the INVITE transaction is > properly passed between internal UAS and carrier SBC and the call is setup. > However, further transactions (BYE/re-INVITE) etc do not work properly. So, > far-end hangups are not working etc. > > > > I’ve searched various archives of this and other SER lists looking to see if > anyone was able to get this scenario working, but couldn’t find a definitive > answer. Most of them point to using “advertised_address”. > > > > So, and ideas on how to make “Proxy behind NAT” work without using > advertised_address? Am I wasting my time? > > > > Thanks in advance for any help you can offer. > > > > SV. > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
