Is there a reason why you cannot disable SIP ALG? --fred
On 07/30/2015 03:12 PM, Joachim Büchse wrote: > I’m coming back to this very old question as we have still not resolved > this issue with Juniper. > > 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? > > I’m seeing the following behavior of SER/OpenSER. > > REGISTER request is received from UAC via TCP. > VIA header contains an IP + port. > TCP source port of REGISTER request does NOT match port in VIA header: > -> UAS ignores CONTACT header and uses effective (TCP source) port + IP > of REGISTER > request as contact address for future INVITE messages it sends to > the UAC > > 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. > > 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. > > Best regards, > Joachim > >>> 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 >>>> <http://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 <http://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 <mailto: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 >>> <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 > _______________________________________________ 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
