### Description
Testing on latest master deb nightly build (`5.3.0~dev7+0~20190904005559.1479+buster`)
I've noticed that `$Au` is not being set correctly, at least according to my tests.
_$Au - Acc username: username for accounting purposes. It's a selective pseudo
variable (inherited from acc module). It returns auth username ($au) if exists or From
username ($fU) otherwise._
I have the following log statement in several places in a test box:
xlog("L_NOTICE", "[DEBUG] Au=$Au au=$au aU=$aU ar=$ar fU=$fU fu=$fu -
\n");
And when I run through them I get the following:
Initial log (at the beginning of request_route):
```
Sep 5 01:54:39 csbc01 csbc[20380]: NOTICE: {1 1 REGISTER
f597522fd7e52fe99f2a54a834101efa@0:0:0:0:0:0:0:0} <script>: [DEBUG]
Au=1063362(a)some.domain au=<null> aU=<null> ar=<null> fU=1063362
fu=sip:1063362@some.domain -
```
After a 401 challenge, the following log statements look like this one:
```
Sep 5 01:54:40 csbc01 csbc[20385]: NOTICE: {1 2 REGISTER
f597522fd7e52fe99f2a54a834101efa@0:0:0:0:0:0:0:0} <script>: [DEBUG]
Au=1063362(a)some.domain au=1063362 aU=1063362 ar=custom-realm fU=1063362
fu=sip:1063362@some.domain -
```
At this point I would expect `$Au` to not have the `@domain` part in it.
And strangely, after an `auth_check()`, it changes again:
```
Sep 5 01:54:40 csbc01 csbc[20385]: NOTICE: {1 2 REGISTER
f597522fd7e52fe99f2a54a834101efa@0:0:0:0:0:0:0:0} <script>: [DEBUG]
Au=1063362@custom-realm au=1063362 aU=1063362 ar=custom-realm fU=1063362
fu=sip:1063362@some.domain -
```
From that point onward, it no longer has the domain and
now contains the realm.
I believe both these behaviors are incorrect, or at least they don't match what the
documentation says.
### Troubleshooting
@henningw commented about this in the email thread I started:
_Hello Joel,_
_I did a quick look into the code, this is basically unchanged since 2008. I also tested
5.2.3, it shows the same behavior._
_NOTICE: {1 1 REGISTER 363545605-1445114084-1880652839} <script>: [DEBUG]
Au=82621(a)116.203.XXX.XXX au=<null> aU=<null> fU=82621
fu=sip:82621@116.203.XXX.XXX -
root@sip:~# kamcmd core.version
kamailio 5.2.3 (x86_64/linux)
I certainly would make more sense in a way like it is documented. Can you easily check an
older version?_
_Cheers,_
_Henning_
### Reproduction
Print `$Au` in logs before challenge, after a successful auth, and after an `auth_check()`
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
root@csbc01:/etc/kamailio# kamailio -v
version: kamailio 5.3.0-dev7 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST,
DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY,
USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535,
DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 8.3.0
root@csbc01:/etc/kamailio#
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04,
CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2056