[OpenSER-Users] NAT problem in bridging mode

[Christian Koch]

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
> <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
>>
>>