Thanks for the answer Daniel, I’ve done some more digging and your answer makes perfect sense to me now. Actually when looking at the packet traces again, I saw that the Via sent by our firewall in the REGISTER says 212.126.160.92:6717 but the request is actually sent from port 19091 by the firewall. So I think this probably triggers the detection of “NAT case” in kamailio.
The SIP-Alg of the firewall leaves no additional clues in the request (i.e. modification of User-Agent header or something) that could be used for an exception rule. So I will raise this as a defect with Juniper. I think the Via must represent the exact IP + port the request is coming from, would you agree? Best regards, Joachim > On 16.02.2015, at 17:35, Daniel-Constantin Mierla <mico...@gmail.com> wrote: > > 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
