Thanks!!! With that flag it works without modifying the rtpproxy code. I simply missed that flag.
Ovidiu Sas schrieb: > Try to use flag 'w' when you use force_rtp_proxy(). > http://www.openser.org/docs/modules/1.3.x/nathelper.html#AEN316 > > Regards, > Ovidiu Sas > > On Wed, May 21, 2008 at 8:23 AM, Christian Koch > <[EMAIL PROTECTED]> 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: >>> >>> [EMAIL PROTECTED] rtpproxy]# /usr/local/bin/rtpproxy -l >>> 192.168.103.121/2.3.4.5 -f >>> rtpproxy started, pid 22125 >>> received command "UIE >>> [EMAIL PROTECTED] 192.168.103.189 >>> 49156 207860870326595;1" >>> new session [EMAIL PROTECTED], >>> 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 >>> [EMAIL PROTECTED] 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 >> [email protected] >> http://lists.openser.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
