Am Freitag, 4. Januar 2019, 01:28:23 CET schrieb Andrew Chen:
> Yup.  The default configuaration already have the nathelper.so loaded.
> Plus, there are other places in the config where nat_uac_test was called
> but never error out.

Hi Andrew,

sounds strange. I would suggest to minimize the configuration step by step to
find out the issue. Maybe it is some other error nearby that confuses the cfg
parser (just guessing).

Best regards,

Henning

> On Thu, Jan 3, 2019 at 5:39 PM Sergey Okhapkin <sos@sokhapkin.dyndns.org>
>
> wrote:
> > Did you load the module?
> >
> > On Thursday, January 3, 2019 5:27:12 PM EST Andrew Chen wrote:
> >
> > Hey it's me again.
> >
> >
> > So I'm following the instructions in the Kamailio 5.1.x wiki module page
> > for websocket configuration and it specifically mention to set this block:
> >
> >
> > onreply_route[WS_REPLY] {
> >
> >         xlog("L_INFO", "[CSeq $cs] Is in WS_REPLY.");
> >         
> >         xlog("L_INFO", "[CSeq $cs] Sending $rs $rr to $sel(via[2].host)
> >
> > via $sel(via[2].transport) len: $ml");
> >
> >         xlog("L_INFO", "[CSeq $cs] \n$mb \n");
> >         
> >         
> >         if(nat_uac_test("64")) {
> >         
> >                 # Do NAT traversal stuff for replies to a WebSocket
> >
> > connection
> >
> >                 # - even if it is not behind a NAT!
> >                 
> >                 # This won't be needed in the future if Kamailio and the
> >                 
> >                 # WebSocket client support Outbound and Path.
> >                 
> >                 add_contact_alias();
> >         
> >         }
> >
> > }
> >
> >
> > When I did this and started up Kamailio, it gave me an error:
> >
> >
> > Jan  3 22:19:43 sjomainkama55 kamailio: ERROR: <core> [core/cfg.y:3309]:
> > yyparse(): cfg. parser: failed to find command nat_uac_test (params 1)
> >
> >
> > I moved that if statement to a route block and I was able to start it up.
> >
> >
> > The wiki page for nathelper module specify this function can be run in
> > onreply_route as well:
> >
> >
> >
> > 5.5.  nat_uac_test(flags)
> >
> > Tries to guess if client's request originated behind a nat. The parameter
> > determines what heuristics is used.
> >
> > Meaning of the flags is as follows:
> >    - 1 - The “Contact” header field is searched for occurrence of RFC1918
> >    or RFC6598 addresses.
> >    - 2 - the "received" test is used: address in the “Via” header is
> >    compared against source IP address of signaling
> >    - 4 - The Top Most “Via” is searched for occurrence of RFC1918 or
> >    RFC6598 addresses
> >    - 8 - The SDP is searched for occurrence of RFC1918 or RFC6598
> >    addresses
> >    - 16 - Test if the source port is different from the port in
> >    the “Via” header
> >    - 32 - Test if the source IP address of signaling is a RFC1918 or
> >    RFC6598 address
> >    - 64 - Test if the source connection of signaling is a WebSocket
> >    - 128 - Test if the “Contact” header URI port differs from the source
> >    port of the request (Warning: this is might be legal or even intended
> >    combination in non NATted scenarios)
> >
> > All flags can be bitwise combined, the test returns true if any of the
> > tests identified a NAT.
> >
> > This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
> > FAILURE_ROUTE, BRANCH_ROUTE.
> >
> >
> > is this some known bug in 5.1.x?
> >
> > Thanks
> >
> >
> > --
> >
> > Andy Chen
> >
> > achen@ <achen@thinkingphones.com>fuze.com


--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
Kamailio security assessment - https://skalatan.de/de/assessment