Unfortunately this breaks registration for my regular devices which use auth_username as not they get a 403 instead of a 401 reply. It looks like anonymous is the first method being attempted and as this fails for registratios (no AOR) the auth_usernamen method is not being attempted which would require a 401 challenge being sent.
I seem to recall, there was a setting to always send 401 but I can’t find it anymore. Was this in chan_sip perhaps?
This could also be handy for accepting unauthenticated calls send by others as a result of an ENUM or DUNDi lookup.
You can not have anonymous enabled while also requiring auth_username. For auth_username to work Asterisk has to challenge the sending side, but you can’t do that if you have anonymous enabled because you’re configuring Asterisk to not challenge unknown sources. The source is unknown because it can only be known after the challenge when the remote side authenticates to Asterisk.
The chan_pjsip module has no option for this, as it always does this - if anonymous is not enabled.
That’s actually a pretty common situation with exposed SIP ports
If you want to “play” with those unauthenticated INVITEs, you’re on the right track.
With res_pjsip_endpoint_identifier_anonymous.so, you can catch INVITEs that don’t match any authenticated endpoint and route them somewhere harmless (or entertaining).
Basic idea:
Enable anonymous matching
Make sure the module is loaded and you have an endpoint that matches anonymous traffic:
@Rynox The OP seems to have got this far before the thread started. His problem is not how to set up a telesales torturer (incidentally tt_ in sound files mean they are for this purpose, and there is other support for this built in), for voice spam, but rather how to handle a legitimate caller, who is being matched on auth username, rather than From user, at the same time, as matching voice spam with anonymous..