[OpenSER-Users] NAT problem in bridging mode

[Ovidiu Sas]

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
<chri.koch.vier at 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 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>