On Nov 12, 2004 at 12:26, Tamas J <thomasj(a)eworld.hu> wrote:
Friday, November 12, 2004, 10:02:06 AM, Andrei wrote:
APO> On Nov 11, 2004 at 00:04, Thomas <thomasj(a)eworld.hu> wrote:
>
> Hello!
>
> I'm trying to make my 1st SIP-based system working. I use SER-0.8.14
> on Linux Sarge. I have usually UAs behind NAT firewalls.
>
> I found a case, when UAs are working very oddly, I can't call from one
> of them, after sime time I can't reach one of them from outside, after
> some time when I call one UA, the 2nd is answering (and the same time
> when I call 2nd UA, the 2nd is answering).
>
> I have 2 UAs [Grandstream BT100 & X-Lite v2.0] behind a linux NAT
> firewall. Both UAs use the same STUN and SER server.
> I did some tcpdumps and I found an interesting thing:
>
> Internet Protocol, Src Addr: <FWPUBLICIP> (<FWPUBLICIP>), Dst Addr:
<SERIP> (<SERIP>)
> User Datagram Protocol, Src Port: 1024 (1024), Dst Port: 5060 (5060)
> Session Initiation Protocol
> Request-Line: REGISTER sip:<MYDOMAIN> SIP/2.0
> Method: REGISTER
> Resent Packet: True
> Suspected resend of frame: 31
> Message Header
> Via: SIP/2.0/UDP
> <FWPUBLICIP>;branch=z9hG4bK0dbeeb499dbd416e
APO> [...]
> What is interesting is that REGISTER message
went out from port 1024
> but 200 OK came to port 5060. Is this OK? I think here is some problem
> and this can make the phones working oddly.
APO> If the phone wanted the answer on 1024, it should have advertised it in
APO> the REGISTER's via. A least it should have added a rport parameter to
APO> the Via.
APO> You can try using force_rport() in ser config for all requests (or for
APO> requests comming from this phone). This might break asymmetric UAs
APO> though (not very common these days).
APO> Andrei
Hello!
Thank you for your fast answer.
force_rport() is already present in config (for REGISTER). Where
should I put it? (maybe I have in wrong place)
In your config snippet force_rport() is called only for requests which
look like comming from behind a nat (private ip in Via, Contact or
different ip in Via than the src_ip of the packet).
Because you use STUN, your UA will use the correct ip in the packet, so
the request will fail the nat_uac_test and the block where you use
force_rport will never be entered.
Try to place force_rport() somewhere at the beginning of your cfg.
How could I trace the problem? What would help me/you
to say where is
the problem? Maybe the NAT firewall messes up those ports? (that is a
classical NAT firewall based on linux and netfilter, nothing special)
Unfortunately I don't have much experience with SIP (just 1 week),
however I'm reading manuals, but it looks, too hard problem at the
beginning for me. But I will keep trying ;)
Linux NAT is symmetric port-preserving. This and bad stun
implementations trick the UAs into believing they are behind a
port-retricted firewall and that they can use the STUN detected ip &
port.
An UA behind a linux or bsd nat box will work with STUN as long as there
is no other UA using the same port to communicate with the same
destination (e.g. outbound proxy/registrar).
So as long as you use only one UA behind the same NAT you should be fine
even with STUN on (there are still some race conditions if dhcp and
changing addresses are involved but you are very unlikely to trigger
them).
If you want more than one you have 3 solution:
(1) turn STUN off and rely on nathelper/rtproxy
(2) configure the phones to use diferent ports (both for SIP and RTP).
(3) statically port forward some ports from the natbox to the UAs
(again SIP & RTP)
Andrei