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


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
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
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


--
Best Regards,
Awal