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 <[email protected]> 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, < > [email protected]> wrote: > >> Can you paste the challenge and responses? >> >> On Fri, 28 Feb 2020 at 14:50, Awal Junanto <[email protected]> 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 < >>> [email protected]> 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 <[email protected]> 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:[email protected]: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 >>>>> [email protected] >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> >>>> -- >>>> Regards, >>>> >>>> David Villasmil >>>> email: [email protected] >>>> phone: +34669448337 >>>> _______________________________________________ >>>> Kamailio (SER) - Users Mailing List >>>> [email protected] >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>> >>> >>> -- >>> Best Regards, >>> Awal >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> [email protected] >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> -- >> Regards, >> >> David Villasmil >> email: [email protected] >> phone: +34669448337 >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Best Regards, Awal
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
