Hi,
We are building a service where we need to detect NAT when the clients register to our server. We are struggling in analyzing NAT status of some clients which modify their IP addresses/ports in the headers according to the value of "received" parameter sent during "401 Unauthorized" response.
Here's the flow:
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: sip:user@192.168.0.1:42251;transport=TLS;ob ... Server->Client SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias;received=1.2.3.4 WWW-Authenticate: ... ...
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 1.2.3.4:6201 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: <sip:user@ 1.2.3.4:6201;transport=TLS;ob> Authorization: ... ...
By the time the client is authenticated, there is no way to detect whether the request was coming from a natted device or not by just analysing the Via or Contact headers.
Thanks in advance.
There probably is a better way of doing this, but maybe you can store the fact that the first register came from a natted device in the locations table (or a hash).
Or maybe add a parameter when challenging where you state the client is natting?
Something like this
https://kamailio.org/docs/modules/3.1.x/modules_k/siputils.html#id2769802
Hope that helps
David
On Fri, 28 Feb 2020 at 12:03, Awal Junanto a.junanto@gmail.com wrote:
Hi,
We are building a service where we need to detect NAT when the clients register to our server. We are struggling in analyzing NAT status of some clients which modify their IP addresses/ports in the headers according to the value of "received" parameter sent during "401 Unauthorized" response.
Here's the flow:
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: sip:user@192.168.0.1:42251;transport=TLS;ob ... Server->Client SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias;received=1.2.3.4 WWW-Authenticate: ... ...
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 1.2.3.4:6201 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: <sip:user@ 1.2.3.4:6201;transport=TLS;ob> Authorization: ... ...
By the time the client is authenticated, there is no way to detect whether the request was coming from a natted device or not by just analysing the Via or Contact headers.
Thanks in advance.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
I added a call to add_uri_param("nat=yes") before auth_challenge("$fd", "0"), but couldn't see any difference in the actual SIP messages. The challenge (and the response) didn't contain that newly added keyword. Or am I missing something here?
On Fri, 28 Feb 2020 at 13:58, David Villasmil < david.villasmil.work@gmail.com> wrote:
There probably is a better way of doing this, but maybe you can store the fact that the first register came from a natted device in the locations table (or a hash).
Or maybe add a parameter when challenging where you state the client is natting?
Something like this
https://kamailio.org/docs/modules/3.1.x/modules_k/siputils.html#id2769802
Hope that helps
David
On Fri, 28 Feb 2020 at 12:03, Awal Junanto a.junanto@gmail.com wrote:
Hi,
We are building a service where we need to detect NAT when the clients register to our server. We are struggling in analyzing NAT status of some clients which modify their IP addresses/ports in the headers according to the value of "received" parameter sent during "401 Unauthorized" response.
Here's the flow:
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: sip:user@192.168.0.1:42251;transport=TLS;ob ... Server->Client SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias;received=1.2.3.4 WWW-Authenticate: ... ...
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 1.2.3.4:6201 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: <sip:user@ 1.2.3.4:6201;transport=TLS;ob> Authorization: ... ...
By the time the client is authenticated, there is no way to detect whether the request was coming from a natted device or not by just analysing the Via or Contact headers.
Thanks in advance.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Can you paste the challenge and responses?
On Fri, 28 Feb 2020 at 14:50, Awal Junanto a.junanto@gmail.com wrote:
I added a call to add_uri_param("nat=yes") before auth_challenge("$fd", "0"), but couldn't see any difference in the actual SIP messages. The challenge (and the response) didn't contain that newly added keyword. Or am I missing something here?
On Fri, 28 Feb 2020 at 13:58, David Villasmil < david.villasmil.work@gmail.com> wrote:
There probably is a better way of doing this, but maybe you can store the fact that the first register came from a natted device in the locations table (or a hash).
Or maybe add a parameter when challenging where you state the client is natting?
Something like this
https://kamailio.org/docs/modules/3.1.x/modules_k/siputils.html#id2769802
Hope that helps
David
On Fri, 28 Feb 2020 at 12:03, Awal Junanto a.junanto@gmail.com wrote:
Hi,
We are building a service where we need to detect NAT when the clients register to our server. We are struggling in analyzing NAT status of some clients which modify their IP addresses/ports in the headers according to the value of "received" parameter sent during "401 Unauthorized" response.
Here's the flow:
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: sip:user@192.168.0.1:42251;transport=TLS;ob ... Server->Client SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias;received=1.2.3.4 WWW-Authenticate: ... ...
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 1.2.3.4:6201 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: <sip:user@ 1.2.3.4:6201;transport=TLS;ob> Authorization: ... ...
By the time the client is authenticated, there is no way to detect whether the request was coming from a natted device or not by just analysing the Via or Contact headers.
Thanks in advance.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Best Regards, Awal _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
But why it becomes a problem? It looks like client reloves NAT issue on his side. So during the call of this user you will send request to the proper destination address anyway.
On Fri, 28 Feb 2020, 18:03 David Villasmil, david.villasmil.work@gmail.com wrote:
Can you paste the challenge and responses?
On Fri, 28 Feb 2020 at 14:50, Awal Junanto a.junanto@gmail.com wrote:
I added a call to add_uri_param("nat=yes") before auth_challenge("$fd", "0"), but couldn't see any difference in the actual SIP messages. The challenge (and the response) didn't contain that newly added keyword. Or am I missing something here?
On Fri, 28 Feb 2020 at 13:58, David Villasmil < david.villasmil.work@gmail.com> wrote:
There probably is a better way of doing this, but maybe you can store the fact that the first register came from a natted device in the locations table (or a hash).
Or maybe add a parameter when challenging where you state the client is natting?
Something like this
https://kamailio.org/docs/modules/3.1.x/modules_k/siputils.html#id2769802
Hope that helps
David
On Fri, 28 Feb 2020 at 12:03, Awal Junanto a.junanto@gmail.com wrote:
Hi,
We are building a service where we need to detect NAT when the clients register to our server. We are struggling in analyzing NAT status of some clients which modify their IP addresses/ports in the headers according to the value of "received" parameter sent during "401 Unauthorized" response.
Here's the flow:
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: sip:user@192.168.0.1:42251;transport=TLS;ob ... Server->Client SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias;received=1.2.3.4 WWW-Authenticate: ... ...
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 1.2.3.4:6201 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: <sip:user@ 1.2.3.4:6201;transport=TLS;ob> Authorization: ... ...
By the time the client is authenticated, there is no way to detect whether the request was coming from a natted device or not by just analysing the Via or Contact headers.
Thanks in advance.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Best Regards, Awal _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Because I may need to bridge media when another client who may not handle NAT that well calls this client.
On Fri, 28 Feb 2020 at 18:05, Yuriy Gorlichenko ovoshlook@gmail.com wrote:
But why it becomes a problem? It looks like client reloves NAT issue on his side. So during the call of this user you will send request to the proper destination address anyway.
On Fri, 28 Feb 2020, 18:03 David Villasmil, < david.villasmil.work@gmail.com> wrote:
Can you paste the challenge and responses?
On Fri, 28 Feb 2020 at 14:50, Awal Junanto a.junanto@gmail.com wrote:
I added a call to add_uri_param("nat=yes") before auth_challenge("$fd", "0"), but couldn't see any difference in the actual SIP messages. The challenge (and the response) didn't contain that newly added keyword. Or am I missing something here?
On Fri, 28 Feb 2020 at 13:58, David Villasmil < david.villasmil.work@gmail.com> wrote:
There probably is a better way of doing this, but maybe you can store the fact that the first register came from a natted device in the locations table (or a hash).
Or maybe add a parameter when challenging where you state the client is natting?
Something like this
https://kamailio.org/docs/modules/3.1.x/modules_k/siputils.html#id2769802
Hope that helps
David
On Fri, 28 Feb 2020 at 12:03, Awal Junanto a.junanto@gmail.com wrote:
Hi,
We are building a service where we need to detect NAT when the clients register to our server. We are struggling in analyzing NAT status of some clients which modify their IP addresses/ports in the headers according to the value of "received" parameter sent during "401 Unauthorized" response.
Here's the flow:
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: sip:user@192.168.0.1:42251;transport=TLS;ob ... Server->Client SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias;received=1.2.3.4 WWW-Authenticate: ... ...
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 1.2.3.4:6201 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: <sip:user@ 1.2.3.4:6201;transport=TLS;ob> Authorization: ... ...
By the time the client is authenticated, there is no way to detect whether the request was coming from a natted device or not by just analysing the Via or Contact headers.
Thanks in advance.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Best Regards, Awal _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi David,
Sorry for the late reply, but here it is:
My config:
if(is_method("REGISTER")){ if (is_present_hf("Authorization")) { route(ATTEMPT_AUTHORIZATION); } else { add_uri_param("nat=yes"); auth_challenge("$fd", "0"); exit; } }
Challenge and response:
SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 192.168.0.1:39329 ;rport=43648;branch=z9hG4bK1b76da3e-1749-46f5-8e87-7320b967c5a4;alias;received=1.2.3.4 From: sip:user@sip.domain.com;tag=f11c81da-ad20-4df1-9c71-cb8bace862ce To: sip:user@sip.domain.com;tag=61fed0b66377dfce2e6266f6ac54bc0e.fc1b940b Call-ID: abbd756e-d89a-42be-a668-f5f1597e233a CSeq: 3583 REGISTER WWW-Authenticate: Digest realm="sip.domain.com", nonce="Xlz8IV5c+vWQwkBJWZGyufmmkpGUNohH" Content-Length: 0
REGISTER sip:sip.domain.com:5061;transport=tls SIP/2.0 Via: SIP/2.0/TLS 1.2.3.4:43648 ;rport;branch=z9hG4bKd1d8a846-5e3f-4d5e-a9cf-6920bbceceb2;alias Max-Forwards: 69 From: sip:user@sip.domain.com;tag=f11c81da-ad20-4df1-9c71-cb8bace862ce To: sip:user@sip.domain.com Call-ID: abbd756e-d89a-42be-a668-f5f1597e233a CSeq: 3584 REGISTER User-Agent: TalkHome/3.0.9 (samsung SM-G973F; Android 10) pjsip/2.6 Supported: outbound, path Contact: sip:user@1.2.3.4:43648 ;transport=TLS;ob;+sip.ice;reg-id=1;+sip.instance="urn:uuid:00000000-0000-0000-0000-0000e922f243" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Authorization: Digest username="user", realm="sip.domain.com", nonce="Xlz8IV5c+vWQwkBJWZGyufmmkpGUNohH", uri="sip:sip.domain.com:5061;transport=tls", response="97e3445bc7302a4bcc6a74b145dc4efc" Content-Length: 0
Thanks
On Fri, 28 Feb 2020 at 17:03, David Villasmil < david.villasmil.work@gmail.com> wrote:
Can you paste the challenge and responses?
On Fri, 28 Feb 2020 at 14:50, Awal Junanto a.junanto@gmail.com wrote:
I added a call to add_uri_param("nat=yes") before auth_challenge("$fd", "0"), but couldn't see any difference in the actual SIP messages. The challenge (and the response) didn't contain that newly added keyword. Or am I missing something here?
On Fri, 28 Feb 2020 at 13:58, David Villasmil < david.villasmil.work@gmail.com> wrote:
There probably is a better way of doing this, but maybe you can store the fact that the first register came from a natted device in the locations table (or a hash).
Or maybe add a parameter when challenging where you state the client is natting?
Something like this
https://kamailio.org/docs/modules/3.1.x/modules_k/siputils.html#id2769802
Hope that helps
David
On Fri, 28 Feb 2020 at 12:03, Awal Junanto a.junanto@gmail.com wrote:
Hi,
We are building a service where we need to detect NAT when the clients register to our server. We are struggling in analyzing NAT status of some clients which modify their IP addresses/ports in the headers according to the value of "received" parameter sent during "401 Unauthorized" response.
Here's the flow:
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: sip:user@192.168.0.1:42251;transport=TLS;ob ... Server->Client SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 192.168.0.1:41157 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias;received=1.2.3.4 WWW-Authenticate: ... ...
Client->Server REGISTER sip:... Via: SIP/2.0/TLS 1.2.3.4:6201 ;rport;branch=z9hG4bKPj30093e5d-550d-4d4c-a9a2-22c3bd1cda7e;alias Contact: <sip:user@ 1.2.3.4:6201;transport=TLS;ob> Authorization: ... ...
By the time the client is authenticated, there is no way to detect whether the request was coming from a natted device or not by just analysing the Via or Contact headers.
Thanks in advance.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Best Regards, Awal _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Awal Junanto -
David Villasmil -
Yuriy Gorlichenko