Ok here's what I have done. You have to set a NAT detected flag from ser.cfg after a successful nat_uac_test - ie.
if nat_uac_test(..) { setflag(6) }
(Thanks to Klaus for the tip!!)
In nathelper.c, force_rtp_proxy_f checks if flag 6 (am harcoding 6 into the code at the moment) is set. If yes, it tells RTP proxy not to save the IP:port which is in the SDP body. So rtpproxy will have to wait for atleast one packet from this UA before it knows the correct natted IP:port to which RTP packets from the other end is to be sent.
If this nat flag is not set, nathelper will forward the IP:port from SDP body to rtpproxy. Since rtpproxy knows the right IP:port for this end, it will forward any RTP packets coming from the other end without waiting for any UDP packets to come from this end.
There is another problem with the existing nathelper + rtpproxy which I did not mention in my previous email. rtpproxy expects BOTH ends to be sending and receiving on the same port (symmetric RTP) - otherwise it does not work. But if a UA is not behind NAT, it should work with or without symmetric RTP support (regardless of whether the other end is natted or not). I have tried to solve this as follows -
first rtpproxy tries to match IP:port of the sender with the ones (addr1 and addr2) it has in its record. If it finds a match, it will forward the packet to the other IP:port. However if no match is found and addr1 and addr2 are not NULL, rtpproxy tries to do a match using only the IP address (ie. port number is not taken into consideration). If the sender's IP address matches with one of the two stored addresses (but port number does not match), forward the packet to the other IP:port.
I have made the necessary modifications - but will test it on Monday.
Regards,
Dhiraj
-----Original Message----- From: Klaus Darilion [mailto:darilion@ict.tuwien.ac.at] Sent: Fri 12/12/2003 20:31 To: serdev@iptel.org Cc: Bhuyan,D,Dhiraj,XVR3 R; jiri@iptel.org; sobomax@portaone.com Subject: RE: nat + multiple RTP proxy ...just some thoughts from me ...
You also must change the behaviour of the rtpproxy - rtpproxy should be enhanced to be symmetrical only in one direction:
imagine the following scenario:
ua1 ----NAT----ser+rtpproxy-------ua2
ua1 is behind NAT, ua2 not: rtpproxy should relay rtp packets from ua2 to the ip-address:port it received the packets from ua1 (therefore it has to receive at least one packet from ua1 before relaying from ua2->ua1). RTP packets from ua1 to the rtpproxy should be forwarded the ip-address:port announced in the SDP from ua2 - this can be done immediately.
Therefore, I suggest to make decision if a UA is NATed or not in the ser script, but enhance the force_rtp_proxy() and use a parameter, e.g. force_rtp_proxy(0) should tell the rtp-proxy to be symmetrical to this client, whereas force_rtp_proxy(1) will tell the rtp-proxy to relay to this client using the ip-address:port in the SDP
maybe it will be useful to use two ports at the rtpproxy (one for each client) to easily distinguish the two clients.
-----Original Message----- From: dhiraj.2.bhuyan@bt.com [mailto:dhiraj.2.bhuyan@bt.com] Sent: Friday, December 12, 2003 8:49 PM To: Klaus Darilion; jiri@iptel.org; sobomax@portaone.com; serdev@iptel.org Cc: serusers@iptel.org Subject: nat + multiple RTP proxy
Hello List, I am trying to get SER + nathelper working with multiple RTP proxies on the route (please read the mail appended below on the problem I am trying to solve and how am trying to solve it). I spent sometime understanding the internals of SER - but it will be great if anyone can help me with the following problem -
My test settings is -
UA1 ---- NAT ---- SER/RTP1 ----- SER/RTP2 ------- UA2
I am forcing rtpproxy on SER2 also.
In file nathelper.c, I added a test case in force_rtp_proxy_f(..) to check if the SIP/SDP packet was sent by a device behind NAT. I use the SER received_test(msg) to do this check (which is basically a msg->via1->host == msg->rcv.src_ip test). I try setting up a call from UA1 to UA2. When SER1 receives the SIP/SDP packet from UA1, the received_test correctly detects that UA1 is behind NAT. But when UA2 sends back an OK with its SDP data (which SER2 modifies before sending it to SER1), a received_test (in SER1) on this SIP/SDP message returns positive (isn't via1 added by SER2? and via2 the one added by UA1?).
I will appreciate any help on this. Is there any better way to do this? I am not doing a check on contact header since fix_nated_contact may have already been called (save reason for not checking the SDP contact information).
Sorry I am unable to add any debugging information - as I am writing from home.
Regards,
Dhiraj
Network Security Specialist, BT Exact
-----Original Message----- From: dhiraj.2.bhuyan@bt.com [mailto:dhiraj.2.bhuyan@bt.com] Sent: Friday, December 12, 2003 6:39 PM To: jiri@iptel.org; sobomax@portaone.com Cc: serusers@iptel.org Subject: [Serusers] nat + multiple RTP proxy
Greetings list, I spent some time looking into the rtpproxy and nathelper code. Currently, nathelper + rtpproxy will work ONLY if there is "one" RTP proxy on the path. In a scenario like -
UA1 ---- NAT ---- SER/RTP1 ----- SER/RTP2 ---- NAT --- UA2
where UA1 and UA2 are subscribed to two different SERs and are also behind NAT, RTP proxy 1 never forwards the RTP traffic from UA1 to RTP proxy 2 (because of the way it is designed) since RTP1 is waiting for at least one RTP packet from RTP proxy 2 and vice versa - hence the deadlock.
This can be fixed if the RTP proxy waits for one UDP packet from the device behind NAT, but does not wait for any packets from the device it thinks is not behind NAT before forwarding it the RTP traffic (coming from the other end). Thus in the above scenario, RTP 1 waits for at least one packet from UA1
- but does not wait for any packet from RTP2.
I am writing a patch for nathelper and rtpproxy to add this functionality (should be available by next week). Anyone - any thoughts on this?
Dhiraj Bhuyan Network Security Specialist, BT Exact Business Assurance Solutions
Tel: +44 1473 643932 Mob: +44 7962 012145 Email: dhiraj.2.bhuyan@bt.com
Serusers mailing list Serusers@iptel.org http://mail.iptel.org/mailman/listinfo/serusers