Hello, if you know that the contact address is valid and should be used for opening connections towards UA, then do not call fix_nated_register() for REGISTER request.
Unfortunately UA behind NAT using STUN can lead to public address in Via/Contact/etc... but with a wrong port, therefore we have many tests to decide if UA should be considered behind NAT or no. In your case, should not be considered behind nat. The received parameter in Via header was fixed, but I am quite sure 3.2.x doesn't have it, that's quite old. You have to upgrade to a more recent version. Cheers, Daniel On 13/02/15 17:55, Joachim Büchse wrote: > Good day, > > I’m experiencing some problems with our VoiP providers handling of REGISTER > requests. We are using a Gigaset PRO N720 as UAC behind a Juniper SSG 140 > with SIP-Alg enabled. This setup kind of works with UDP but our provider > wants us to use TCP. With TCP enforced incoming calls don’t work. I’ve done > some wire tracing and to me it seems that the providers configuration is to > blame, but then - there are many RFCs out there and many NAT and UAC bug > workarounds. Anyway, I wanted to get the opinion of “the" experts about how > the requests send to the UAS SHOULD be correctly interpreted. > > > The REGISTER requests/responses look like this (outside of the firewall): > > Protocol TCP! > client port 19091 <-> server port 5060 > > REGISTER sip:pbx.peoplefone.ch SIP/2.0 > Via: SIP/2.0/TCP > 212.126.160.92:6717;rport;branch=z9hG4bKc1375589832468de63a719eac31156ec > From: "Michel" <sip:90780408...@pbx.peoplefone.ch>;tag=2153084485 > To: "Michel" <sip:90780408...@pbx.peoplefone.ch> > Call-ID: 2825358480@10_10_128_10 > CSeq: 1 REGISTER > Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp> > Max-Forwards: 70 > User-Agent: N720-DM-PRO/70.089.00.000.000 > Expires: 180 > Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY > Content-Length: 0 > > SIP/2.0 401 Unauthorized > Via: SIP/2.0/TCP > 212.126.160.92:6717;rport=19091;branch=z9hG4bKc1375589832468de63a719eac31156ec > From: "Michel" <sip:90780408...@pbx.peoplefone.ch>;tag=2153084485 > To: "Michel" > <sip:90780408...@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.b8fc > Call-ID: 2825358480@10_10_128_10 > CSeq: 1 REGISTER > WWW-Authenticate: Digest realm="pbx.peoplefone.ch", > nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy" > Server: kamailio (3.2.1 (x86_64/linux)) > Content-Length: 0 > > REGISTER sip:pbx.peoplefone.ch SIP/2.0 > Via: SIP/2.0/TCP > 212.126.160.92:6717;rport;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0 > From: "Michel" <sip:90780408...@pbx.peoplefone.ch>;tag=2153084485 > To: "Michel" <sip:90780408...@pbx.peoplefone.ch> > Call-ID: 2825358480@10_10_128_10 > CSeq: 2 REGISTER > Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp> > Authorization: Digest username="90780408050", realm="pbx.peoplefone.ch", > uri="sip:pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy", > response="764f371a08d258157a249f8d1b852514" > Max-Forwards: 70 > User-Agent: N720-DM-PRO/70.089.00.000.000 > Expires: 180 > Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY > Content-Length: 0 > > SIP/2.0 200 OK > Via: SIP/2.0/TCP > 212.126.160.92:6717;rport=19091;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0 > From: "Michel" <sip:90780408...@pbx.peoplefone.ch>;tag=2153084485 > To: "Michel" > <sip:90780408...@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.6bda > Call-ID: 2825358480@10_10_128_10 > CSeq: 2 REGISTER > Contact: > <sip:90780408050@212.126.160.92:6717;transport=tcp>;q=0;expires=180;received="sip:212.126.160.92:19091;transport=TCP" > Server: kamailio (3.2.1 (x86_64/linux)) > Content-Length: 0 > > > The ip:port the firewall is sending those requests from is ip 212.126.160.92 > port 19091. So this does NOT match the port from the Contact header. For TCP > this seems rather logical to me, as one cant be listening on a TCP port and > use it for sending at the same time. The UAC closes this “register > connection” with TCP FIN after the register, and so does the firewall. > > However unfortunately subsequent requests from the provider (ie UAS) come in > on port 19091 (not port 6717 from the Contact header) and the firewall simply > drops them. > > Observations: > - the server does NOT include received=212.126.160.92 in the Via of the > reponse. According to RFC3581 this is mandatory when rport is present in the > request, so this is probably an error in the server. > - the server does include > received="sip:212.126.160.92:19091;transport=TCP” in the Contact of the > response. I didnt see this in any RFC (which means nothing;-) but it could be > an error. > - after the client received the 200 OK it closes the TCP connection. > - the server tries several times to re-contact the client (incoming TCP > SYN). However not on port 6717 (defined in the Contact header) but on port > 19091 (where the REGISTER came from). > > RFC3581 defines special behaviour when “rport” is defined in the request > (i.e. response should go to the same port the request came from) - however > it’s not so clear if this should apply to subsequent (INVITE/OPTIONS) > requests from the server to the client. Those are strictly spoken not replies > (or are they?). > > RFC5626 defines that a “proxy” should keep track of the flows over which it > received a registration and send requests over the same flow. It is not clear > if RFC5626 should be applied. The RFC5626 defines that a UAC includes an “ob” > parameter in the Contact field if it whishes further requests over the same > flow. Also the RFC mandates a client to add a "reg-id=x" in the Contact > field. Both are not the case here, so in short I think RFC5626 should NOT be > applied. In which case conecting to the originating port (instead of the > Contact port) would be a server error. > > So in short and if I interpret the RFCs correctly, the client is reachable > and should be contacted on > Transport: TCP > IP: 212.126.160.92 > Port: 6717 > > > If anyone who lives and breathes SIP could enlighten me if the UAS is right > to call back on 19091 instead of 6717 I would really appreciate it;-)) > > Best regards, > Joachim > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
