<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m coming back to this very old question as we have still not resolved this issue with Juniper.<div class=""><br class=""></div><div class="">Are you aware of any RFC section that mandates, that the VIA headers IP+port should match the effective (transport) IP+port. Or how a UAS should interpret a mismatch?</div><div class=""><br class=""></div><div class="">I’m seeing the following behavior of SER/OpenSER.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>REGISTER request is received from UAC via TCP.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>VIA header contains an IP + port.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>TCP source port of REGISTER request does NOT match port in VIA header:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-> UAS ignores CONTACT header and uses effective (TCP source) port + IP of REGISTER</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> request as contact address for future INVITE messages it sends to the UAC</div><div class=""><br class=""></div><div class="">I understand WHY this is done (i.e. to make UAC behind NAT work). However I wonder if this specific behavior is based on a particular RFC recommendation.</div><div class=""><br class=""></div><div class="">The reason for my question is, that the above scenario happens with the SIP-Alg of our Juniper firewall. However the firewall rejects the INVITEs from the UAS. Juniper acknowledged, that the port in the rewritten VIA header of the REGISTER request does match the effective TCP port used to send it to the UAS, but they do not consider this being in contradiction to any RFC.</div><div class=""><br class=""><div class="">Best regards,</div><div class="">Joachim</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 13/02/15 17:55, Joachim Büchse wrote:<br class=""><blockquote type="cite" class="">Good day,<br class=""><br class="">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.<br class=""><br class=""><br class="">The REGISTER requests/responses look like this (outside of the firewall):<br class=""><br class="">Protocol TCP!<br class="">client port 19091 <-> server port 5060<br class=""><br class="">REGISTER <a href="sip:pbx.peoplefone.ch" class="">sip:pbx.peoplefone.ch</a> SIP/2.0<br class="">Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bKc1375589832468de63a719eac31156ec<br class="">From: "Michel" <<a href="sip:90780408050@pbx.peoplefone.ch" class="">sip:90780408050@pbx.peoplefone.ch</a>>;tag=2153084485<br class="">To: "Michel" <<a href="sip:90780408050@pbx.peoplefone.ch" class="">sip:90780408050@pbx.peoplefone.ch</a>><br class="">Call-ID: 2825358480@10_10_128_10<br class="">CSeq: 1 REGISTER<br class="">Contact: <<a href="sip:90780408050@212.126.160.92:6717;transport=tcp" class="">sip:90780408050@212.126.160.92:6717;transport=tcp</a>><br class="">Max-Forwards: 70<br class="">User-Agent: N720-DM-PRO/70.089.00.000.000<br class="">Expires: 180<br class="">Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY<br class="">Content-Length: 0<br class=""><br class="">SIP/2.0 401 Unauthorized<br class="">Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bKc1375589832468de63a719eac31156ec<br class="">From: "Michel" <<a href="sip:90780408050@pbx.peoplefone.ch" class="">sip:90780408050@pbx.peoplefone.ch</a>>;tag=2153084485<br class="">To: "Michel" <<a href="sip:90780408050@pbx.peoplefone.ch" class="">sip:90780408050@pbx.peoplefone.ch</a>>;tag=a0440f545f39b2694d387b475a5f6bc9.b8fc<br class="">Call-ID: 2825358480@10_10_128_10<br class="">CSeq: 1 REGISTER<br class="">WWW-Authenticate: Digest realm="<a href="http://pbx.peoplefone.ch/" class="">pbx.peoplefone.ch</a>", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy"<br class="">Server: kamailio (3.2.1 (x86_64/linux))<br class="">Content-Length: 0<br class=""><br class="">REGISTER <a href="sip:pbx.peoplefone.ch" class="">sip:pbx.peoplefone.ch</a> SIP/2.0<br class="">Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0<br class="">From: "Michel" <<a href="sip:90780408050@pbx.peoplefone.ch" class="">sip:90780408050@pbx.peoplefone.ch</a>>;tag=2153084485<br class="">To: "Michel" <<a href="sip:90780408050@pbx.peoplefone.ch" class="">sip:90780408050@pbx.peoplefone.ch</a>><br class="">Call-ID: 2825358480@10_10_128_10<br class="">CSeq: 2 REGISTER<br class="">Contact: <<a href="sip:90780408050@212.126.160.92:6717;transport=tcp" class="">sip:90780408050@212.126.160.92:6717;transport=tcp</a>><br class="">Authorization: Digest username="90780408050", realm="<a href="http://pbx.peoplefone.ch/" class="">pbx.peoplefone.ch</a>", uri="<a href="sip:pbx.peoplefone.ch" class="">sip:pbx.peoplefone.ch</a>", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy", response="764f371a08d258157a249f8d1b852514"<br class="">Max-Forwards: 70<br class="">User-Agent: N720-DM-PRO/70.089.00.000.000<br class="">Expires: 180<br class="">Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY<br class="">Content-Length: 0<br class=""><br class="">SIP/2.0 200 OK<br class="">Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0<br class="">From: "Michel" <<a href="sip:90780408050@pbx.peoplefone.ch" class="">sip:90780408050@pbx.peoplefone.ch</a>>;tag=2153084485<br class="">To: "Michel" <<a href="sip:90780408050@pbx.peoplefone.ch" class="">sip:90780408050@pbx.peoplefone.ch</a>>;tag=a0440f545f39b2694d387b475a5f6bc9.6bda<br class="">Call-ID: 2825358480@10_10_128_10<br class="">CSeq: 2 REGISTER<br class="">Contact: <<a href="sip:90780408050@212.126.160.92:6717;transport=tcp" class="">sip:90780408050@212.126.160.92:6717;transport=tcp</a>>;q=0;expires=180;received="<a href="sip:212.126.160.92:19091;transport=TCP" class="">sip:212.126.160.92:19091;transport=TCP</a>"<br class="">Server: kamailio (3.2.1 (x86_64/linux))<br class="">Content-Length: 0<br class=""><br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">Observations:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- 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.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- the server does include received="<a href="sip:212.126.160.92:19091;transport=TCP" class="">sip:212.126.160.92:19091;transport=TCP</a>” in the Contact of the response. I didnt see this in any RFC (which means nothing;-) but it could be an error.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- after the client received the 200 OK it closes the TCP connection.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- 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).<br class=""><br class="">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?).<br class=""><br class="">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.<br class=""><br class="">So in short and if I interpret the RFCs correctly, the client is reachable and should be contacted on<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Transport:<span class="Apple-tab-span" style="white-space:pre"> </span>TCP<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>IP:<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>212.126.160.92<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Port:<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>6717<br class=""><br class=""><br class="">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;-))<br class=""><br class="">Best regards,<br class="">Joachim<br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br class=""><a href="mailto:sr-users@lists.sip-router.org" class="">sr-users@lists.sip-router.org</a><br class=""><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" class="">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br class=""></blockquote><br class="">-- <br class="">Daniel-Constantin Mierla<br class=""><a href="http://twitter.com/#!/miconda" class="">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" class="">http://www.linkedin.com/in/miconda</a><br class="">Kamailio World Conference, May 27-29, 2015<br class="">Berlin, Germany - <a href="http://www.kamailioworld.com/" class="">http://www.kamailioworld.com</a><br class=""><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></body></html>