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
On 05/09/2013 02:54 PM, qasimak...@gmail.com 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 <raz...@opensips.org
<mailto:raz...@opensips.org>> 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
http://www.opensips-solutions.__com <http://www.opensips-solutions.com>
On 05/09/2013 02:33 PM, Nick Khamis wrote:
It's not a bug, many of us here use RTP proxy in the same scenario.
Can you please provide a sip trace using ngrep
(http://wiki.freeswitch.org/__wiki/Packet_Capture
<http://wiki.freeswitch.org/wiki/Packet_Capture>). Secondly,
post the
relevant far end nat related scripting please.
Nick.
On 5/9/13, qasimak...@gmail.com <mailto:qasimak...@gmail.com>
<qasimak...@gmail.com <mailto:qasimak...@gmail.com>> wrote:
Hi,
I am facing a problem when a client connects to opensips
from NATed
network. I am using rtpproxy in bridging mode i.e. from
publicnetwork to
private network. When i use fix_nated_sdp function from
nathelper the local
IP address of the caller is replaced by its public IP but
the problem
starts when i use engage_rtp_proxy instead of replacing
server's public ip
to private it embeds private ip after the caller's publicIP like
X.X.X.XY.Y.Y.Y. I have tried fix_nated_ip with flag 3 and
engage_rtp_proxy
with flag rie.
The question is am i using something wrong here or should it
be counted as
a bug.
If you want some more clarification can draw a flow diagram
also.
Regards,
Qasim
_________________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-__bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_________________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-__bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
