Dear Ashling, I think you may be looking in the wrong direction. From your dump, it looks like the SIP signalling does not reach the remote client.
rtpproxy is NOT used for SIP signalling. The nathelper module will, dependent on your config, rewrite the RTP related information (SDP) in SIP messages. The rewrites are the following (in a "normal" setup with all clients outside the ser's LAN): 1. When a client REGISTERs, the public IP address and port of the NAT in front of the client should be used as contact, not the privat address. This is fix_nated_register(); 2. When an INVITE is sent, the RTP contact information is rewritten to match the public IP/port in #1. This is fix_nated_sdp("1"); 3. If the client is behind a symmetric NAT and somebody is calling TO the client, nathelper will initiate the rtpproxy to set up a relay for rtp and rtcp packets. The INVITE and OKs will be rewritten so that both clients will contact the correct ports on the proxy. This is force_rtp_proxy() 4. The force_rport() function is used to force rport to be included in all Via headers
Please note that in order to "get hold of" all SIP messages, the nathelper code must be placed in the correct places in your config, including in the reply route. mediaproxy does basically the same. Paul (Java Rockxx) has several times posted a working config.
Here are a few things you need to make sure in your setup: - #1 above must handle registration of both LAN-local and remote-LAN users, i.e. you shold rewrite those on remote LAN, but not your local - Your ser server is probably multihomed? You must make sure that ser sends the packets on the correct network interface. 0.9.0 has an auto-detect (mhomed=1). From your ethereal dump, it looks like you have a problem here, as the SIP signalling seems to never reach the remote client. Check also firewalls! - You will probably not use rtpproxy or nathelper for your LAN users, as they don't ned it, but you want nathelper and rtpproxy for remote calls. Your config must handle this. - Your rtpproxy must be run in bridging mode (using -l insideIP/outsideIP) if you have a multihomed host
If these things do not help you, I suggest that you use ngrep to make a dump of all SIP packets on both interfaces for both an inside call and inside-outside call. If you replace IP addresses before posting, make sure you do so with a search and replace so that the replacement is consistent.
Good luck! g-)
Ashling O'Driscoll wrote:
I really need to sort out my nat situation with ser as soon as possible....Im beginning to believe its not doable.
SER is behind nat and clients are behind nat (one on the same lan as ser) and the other on a totally different nat. Both clients register with a public address and port forwarding the nat router forwards the sip traffic to ser. I know this situation is horrible but I cant do anything about it. I have setup nathelper and rtpproxy on ser.
Now if a client behind nat (which is on the same lan as ser) rings another client behind nat (on same lan as ser), then everything works fine and the audio flows. However if a lcient behind (on the same lan as ser) rings a client on behind on nat on DIFFERENT network to ser, then no audio flows. I realise this is because of that fact that they both have internal IP addresses and a middle man is needed. That is why I set up rtpproxy. But will rtpproxy work when its also behind nat??....
I've did an ethereal sniff of remote client and also of ser when calling from my client on ser lan to the remote client and the results are below.
My config was a jumble of various emails from the mailing list so Im going to start from scratch and say my ser.cfg is just like the basic one included in the below link.
http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/Cookbook_D 2/ch04s07.html#d0e5091
Please, Please give me guidance. I know this is a horrible nat situation but i just cant figure out how to solve it or if it can be solved.
Thanks, Aisling
ethereal sniff of remote client (not on same lan as ser, but behind nat)xxx.xxx.xxx.xxx is my public address
SIP INVITE xxx.xxx.xxx.xxx. -> 10.0.1.21 (internal address of remote client) 100 trying 10.0.1.21 -> xxx.xxx.xxx.xxx 180 ringing 10.0.1.21 -> xxx.xxx.xxx.xxx 200 ok 10.0.1.21 -> xxx.xxx.xxx.xxx rtp 10.0..1.21 -> xxx.xxx.xxx.xxx
ethereal sniff of ser (with nathelper and rtpproxy) but behind nat
INVITE 172.16.3.28 (internal address of client on same lan as ser) -> xxx.xxx.xxx.xxx invite xxx.xxx.xxx.xxx.172.16.3.15(internal address of ser) 100 trying 172.16.3.15 -> xxx.xxx.xxx.xxx invite 172.16.3.15 -> 157.190.70.231(public address of remote client) 100 xxx.xxx.xxx.xxx -> 172.16.3.28 100 trying 157.190.70.231 -> 172.16.3.15 icmp 172.16.3.15 -> 157.190.70.231 dest unreachable same happens for 180 ringing and 200 ok.
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers