It seems that you are on the right path now. Regards, Ovidiu Sas
On Wed, Sep 7, 2011 at 5:22 AM, Sarat C. Vemuri <sarat.vem...@fthco.com> wrote: > Ovidiu, > > Thanks for your time. The "fixes" I pulled in is the latest rr module only. > I didn't see anything in that diff to make this work. Could you elaborate a > little? > > However, I was able to get "Outbound" working properly by adding ";r2=on" to > the record_route_preset IPs. In going through the source code, I noticed > that this is what regular record_route uses to enable double rr and it would > automatically take both headers out if it sees that. That seems to have > worked. Any pitfals with this? > > I am still working on "Inbound". For some reason my carrier GW keeps > resending invites even after receiving ACK. I need to see if it is an issue > with the carrier. > > Thanks > SV. > > > -----Original Message----- > From: Ovidiu Sas [mailto:o...@voipembedded.com] > Sent: Tuesday, September 06, 2011 9:50 AM > To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users > Mailing List > Subject: Re: [SR-Users] Kamailio + rtpproxy talking to multiple carrier > gateways > > It seems that something is miss configured on your server. The fixes that I > made in the trunk (and you pulled in your local 3.1 repo) were designed to > handle the scenario that you are trying to implement. > The ACK should be handled properly and routed to the upstream carrier > (following the same path as the initial INVITE). > > > Regards, > Ovidiu Sas > > On Mon, Sep 5, 2011 at 5:07 PM, Sarat C. Vemuri <sarat.vem...@fthco.com> > wrote: >> Again, I apologize for this clumsy way of replying. >> >> Ovidiu, >> >> Thanks for the pointer on set_advertised_address. I had to patch rtpproxy >> module (and rr module for the two parameters to request_route_preset) since >> I am running 3.1. >> >> However, I still have a problem with ACKs after following what you suggested. >> >> INVITE from Internal to Carrier routes properly (two Request-Route headers, >> one internal IP and other public IP). On 200 OK, the carrier GW properly >> copies the route set in to Route header. Now the route contains two >> entries, the public IP and the private IP of Kamailio. The Internal UAC >> then sends the ACK back to Kamailio. Everything is fine till this point. >> Now, Kamailio removes the top entry, which is the private IP and then >> promptly sends the ACK to the public IP of itself!. Of course, that doesn't >> go anywhere. >> >> How do I remove the "public IP" entry from the route set before forwarding >> the reply to Internal UAC? Is there another way to deal with this? I've >> tried to set an alias= core parameter with the public IP, but doesn't seem >> to have any effect. The public IP is not reachable from internal network. >> >> Thanks for your help >> >> SV. >> ------------------------------ >> >> Message: 3 >> Date: Sat, 3 Sep 2011 16:44:22 -0700 >> From: Ovidiu Sas <o...@voipembedded.com> >> Subject: Re: [SR-Users] Kamailio + rtpproxy talking to multiple >> carrier gateways - some via Firewall/NAT >> To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - >> Users Mailing List" <sr-users@lists.sip-router.org> >> Message-ID: >> >> <CAND0Lkt_dpcTm2WKMywMhX6rdsX1ia0r=lyrzb1wfx3on32...@mail.gmail.com> >> Content-Type: text/plain; charset=windows-1252 >> >> 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_advertis >> ed_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 >> > > > > > _______________________________________________ > 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
