SEMS - ip_auth_reject_if_no_matched

1

What is the correct/best setting for this? I’m upgrading from Yeti 10 → Yeti 13

We’re using Kamailio load balancers in front of sems and during our last upgrade/test run we had inconsistent call issues - I later found one server had this asfalse and the other 3 astrue

Should they all be set as false?

2

Please use configuration provided in documentation:

3

I think I asked this question incorrectly - how was this handled in SEMS 1.4 so I can migrate to Yeti 13/SEMS 1.162? I need to keep the same functionality for our migration.

4

I think this option didn’t exist in sems 1.4. Anyway you should use recommended value from documentation(currently true), it doesn’t matter what version you upgrading from - during each upgrade you have to use sems.conf from new version documentation. Also I doubt this option may cause “inconsistent call issues” whatever it means.

5

The option is not there in our SEMS 1.4 config - I’ve built new configs based on the documentation but wasn’t sure how to keep the functionality the same with regards to that item.

By “inconsistent call issues” - we noted 1 in 4 calls failed, and the ones that worked did not have audio. Will be doing further testing soon and hopefully sort this issue out.

6

i do not think that issues you are facing can be somehow related to this option.
when everything is ok this option should make no difference.
“failed” is very vague term: check CDRs,AuthLogs, logs, actual SIP reply. it hardly fails silently.

for clarity:

  • ip_auth_reject_if_no_matched option was introduced in yeti 1.12 with default value: no. (was added in 7 days after related auth offloading feature itself)
  • since auth offloading (1.11.31) it had ip_auth_reject_if_no_matched=yes behavior (and it has no analogues for anything with version less-than 1.11.31)
  • related commit: add option 'ip_auth_reject_if_no_matched' · yeti-switch/sems-yeti@088b384 · GitHub
  • reasonable value is ‘no’ as current default and less strict approach. but you should see something in any case:
    • related INFO messages on matching issues if ip_auth_reject_if_no_matched=no
    • related auth logs in DB if call was rejected ip_auth_reject_if_no_matched=yes

thank you for reminding about that one.
i think we should hardcode ‘yes’ behavior and remove this option in the future, because initially ‘no’ value was temporary thing for upgrading safely (in case of a bugs in the yeti node or DB).

7

Thanks so much!!! - I think the issue with our calls was due to having yes set on 3 SEMS servers and no on one server.

We were testing at 5am in the morning, so our troubleshooting skills were broken! We’ve updated our process so that we can do this at a time that our brains still work.