3 Feb
2005
3 Feb
'05
12:29 p.m.
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.
4 Feb
4 Feb
8:34 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7257
days inactive
7258
days old
1 comments
2 participants
participants (2)
-
Ashling O'Driscoll -
Greger V. Teigre