[SR-Users] Interpretation of Contact header

Thu Jul 30 21:45:20 CEST 2015

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:90780408050 at pbx.peoplefone.ch>;tag=2153084485
>>>> To: "Michel" <sip:90780408050 at pbx.peoplefone.ch>
>>>> Call-ID: 2825358480 at 10_10_128_10
>>>> CSeq: 1 REGISTER
>>>> Contact: <sip:90780408050 at 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:90780408050 at pbx.peoplefone.ch>;tag=2153084485
>>>> To: "Michel"
>>>> <sip:90780408050 at pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.b8fc
>>>> Call-ID: 2825358480 at 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:90780408050 at pbx.peoplefone.ch>;tag=2153084485
>>>> To: "Michel" <sip:90780408050 at pbx.peoplefone.ch>
>>>> Call-ID: 2825358480 at 10_10_128_10
>>>> CSeq: 2 REGISTER
>>>> Contact: <sip:90780408050 at 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:90780408050 at pbx.peoplefone.ch>;tag=2153084485
>>>> To: "Michel"
>>>> <sip:90780408050 at pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.6bda
>>>> Call-ID: 2825358480 at 10_10_128_10
>>>> CSeq: 2 REGISTER
>>>> Contact:
>>>> <sip:90780408050 at 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 at lists.sip-router.org <mailto:sr-users at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> 