30 Jul
2015
30 Jul
'15
10:45 p.m.
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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@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:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel"
<sip:90780408050@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:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel" <sip:90780408050@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:90780408050@pbx.peoplefone.ch>;tag=2153084485
To: "Michel"
<sip:90780408050@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(a)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/>