On Nov 12, 2004 at 12:26, Tamas J thomasj@eworld.hu wrote:
Friday, November 12, 2004, 10:02:06 AM, Andrei wrote:
APO> On Nov 11, 2004 at 00:04, Thomas thomasj@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