Try to use flag 'w' when you use force_rtp_proxy().
Regards,
Ovidiu Sas
On Wed, May 21, 2008 at 8:23 AM, Christian Koch
<chri.koch.vier(a)googlemail.com> wrote:
Just in case anybody is facing the same problem: I
found the solution
for this configuration. rtpproxy handles the bridging mode in a way
which doesn't fit my configuration. It assumes UAC1 is not behind a NAT.
So you have to remove the following line from the rtpproxy code and
recompile:
asymmetric = (bmode != 0) ? 1 : 0;
See also:
http://lists.iptel.org/pipermail/serusers/2004-June/009305.html
I will ask on the rtpproxy mailing list for the reasons for this
behaviour, as I think it may be a bug.
Christian Koch schrieb:
Hi,
I have a problem with openser and rtpproxy. I'm trying to use them as
a gateway between the public internet and a LAN. Clients in the
internet may be natted, so I'm using nathelper. Calls are only made
from LAN to outside or vice versa, but not from LAN to LAN or from
outside to outside. The following should illustrate my configuation:
----- ------------------
UAC1 --- | NAT | ------------- | OpenSER/rtpproxy | ----------------UAC2
----- ------------------ |
| | | |
dynamic public IP 2.3.4.5 192.168.103.121
192.168.103.189
(e.g. 1.2.3.4)
UAC1 and UAC2 are both registered at OpenSER. Now
I'm making a call from UAC1 to UAC2. SIP messages are passed just
fine, but the RTP traffic from UAC2 to UAC1 is dropped at the NAT. I
used tcpdump on the OpenSER/rtpproxy machine to figure out what
happens to RTP and it shows the following (ports and IPs are just
examples):
stream1: 1.2.3.4:10000 -> 2.3.4.5:35000 ->RTP is forwarded by
rtpproxy-> 192.168.103.121:35000 -> 192.168.103.189:11000
stream2: 1.2.3.4:20000 <- 2.3.4.5:35000 <-RTP is forwarded by
rtpproxy<- 192.168.103.121:35000 <- 192.168.103.189:11000
Port 20000 in stream2 is the RTP-port used internally by UAC1 behind
the NAT (this port is found in the INVITE from UAC1 to OpenSER). I
understand, that rtpproxy sends the first packets to port 20000. But,
after receiving some packets from port 10000, shouldn't it change the
destination port to 20000 so they can pass the NAT?
rtpproxy is started like this: "./rtpproxy -l 192.168.103.121/2.3.4.5
-f ".
It produces the following output:
[root@192 rtpproxy]# /usr/local/bin/rtpproxy -l
192.168.103.121/2.3.4.5 -f
rtpproxy started, pid 22125
received command "UIE
9D740CB7-18A4-40B2-A96D-13FC3C5B27D3(a)192.168.103.189 192.168.103.189
49156 207860870326595;1"
new session 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3(a)192.168.103.189,
tag 207860870326595;1 requested, type strong
new session on a port 35000 created, tag 207860870326595;1
pre-filling caller's address with 192.168.103.189:49156
sending reply "35000 2.3.4.5
"
received command "L
9D740CB7-18A4-40B2-A96D-13FC3C5B27D3(a)192.168.103.189 1.2.3.4 49154
207860870326595;1 5364140283;1"
lookup on ports 35000/35000, session timer restarted
pre-filling callee's address with 1.2.3.4:49154
sending reply "35000 192.168.103.121
In my openser.cfg I'm not really checking wheter a client is really
natted, but I think it shouldn't be a problem to assume, that all
clients are behind a NAT? I attached the openser.cfg to this mail
(real public IP is changed to 2.3.4.5).
Do you have any ideas how to fix this problem? Any help would be
greatly appreciated!
Thanks,
Christian
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users