[OpenSER-Users] NAT problem in bridging mode

[Christian Koch]

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 at 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 at 192.168.103.189 192.168.103.189 
> 49156 207860870326595;1"
>    new session 9D740CB7-18A4-40B2-A96D-13FC3C5B27D3 at 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 at 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