17 Feb
2015
17 Feb
'15
1:12 p.m.
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
<miconda(a)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: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",
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", 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
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