Hi Razvan, Thanks for your replies but i figured that i was using wrong flags along with ie. Its working fine after fixing the flags.
Regards, Qasim On Fri, May 10, 2013 at 2:13 PM, Răzvan Crainea <[email protected]> wrote: > Hi, Qasim! > > I am not sure what's your problem then. Are you saying that the SDP is > properly changed for both Invite and 200 OK? Can you send a trace? Or at > least explain exactly how each message (INVITE and 200 OK) is sent out by > OpenSIPS. > > > Best regards, > > Razvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.**com <http://www.opensips-solutions.com> > > On 05/10/2013 06:41 AM, [email protected] wrote: > >> Yes exactly that is being done perfectly but what i want to do is to >> handle NAT on client's end. The IP of client that comes in the SDP's c= >> param is his local IP address and rtpproxy swaps that IP with server's >> local IP but on the other way arround it tries to send the IP back to >> client's local IP address which is not visible to server. >> >> Actually we have two nated acenerios. One on the server end and the >> other on the client's end. >> >> Regards, >> Qasim >> >> >> On Thu, May 9, 2013 at 5:59 PM, Răzvan Crainea <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, Qasim! >> >> Basically this is what the rtpproxy module does: when you call >> rtpproxy_offer("ei") function, opensips tells the rtpproxy server >> that a new session has to be created and the media flow will be from >> external to internal. Rtpproxy assigns the proper interface(IP) and >> port and returns them to OpenSIPS, which advertises in the ongoing >> INVITE. So, considering the rtpproxy server has been configured >> correctly, all you have to do is call rtpproxy_offer() with the >> proper direction. >> >> >> Best regards, >> >> Razvan Crainea >> OpenSIPS Core Developer >> http://www.opensips-solutions.**__com <http://www.opensips-** >> solutions.com <http://www.opensips-solutions.com>> >> >> On 05/09/2013 02:54 PM, [email protected] >> >> <mailto:[email protected]> wrote: >> >> Hi Razvan, >> >> My scenerio is like this >> >> Client <-------> NAT <-------> OpenSIPs/RTPProxy <-------> Client >> >> >> in this scenerio left side of OpenSIPs is public side and the >> right side >> is on private network. Secondly i have tried using >> rtpproxy_offer/answer() but the same problem. I will try using >> rtpproxy_offer/answer() again in a bit more detail now specially >> after >> hearing about problems in engage_rtpproxy in brigding mode. Now >> can you >> point me how i can achieve nat handling in rtpproxy module? >> >> Regards, >> Qasim >> >> >> On Thu, May 9, 2013 at 5:39 PM, Răzvan Crainea >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> Hi, Qasim! >> >> There are two problems with your approach: the first one is >> that you >> are using the engage_rtp_proxy() function in a bridging mode >> scenario. The behavior of this is undefined, because the >> rtpproxy >> module cannot fully determine your scenario (for example >> what's the >> direction of the media flow in the reply). That's why you >> should use >> the rtpproxy_offer() and rtpproxy_answer() functions to >> explicitly >> indicate the direction in INVITE and replies. >> The second problem is that you try to change the SDP twice: >> first by >> the fix_nated_sdp() and then by engage_rtp_proxy(). These >> changes >> confuse OpenSIPS, who tries to apply both of them. Try to >> use only >> one. My suggestion is to rtpproxy_offer/answer() to fix the >> SDP, >> without calling fix_nated_sdp(). >> >> Best regards, >> >> Razvan Crainea >> OpenSIPS Core Developer >> > > ______________________________**_________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-**bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
